Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Tobias_Moritz
Collaborator

Breaking IA change in R80.40 JHF T91 / R80.30 JHF T227 - sk170516

Jump to solution

Very recently, sk170516 was published.

It is linked in R80.40 JHF T91 / R80.30 JHF T227

PRJ-18247,
PRJ-18124
Identity AwarenessNEW: Added Identity Sharing's performance and functionality improvements. Refer to sk170516.

 

The sk170516 tells us, that we need to clear the internal IA tables on all gateways after upgrading to JHFs that include this improvements:

We recommend to run the following command on all members of all clusters in the policy simultaneously and only after the Jumbo Hotfix upgrade was finished.
Running the following command will remove zombie entries from Identity Awareness kernel tables and will initiate a sync between all PDP and PEP Security Gateways.

Note: This procedure removes all identities that were learned, therefore perform it during the maintenance window.

The commands are the well-known ones, that do a complete purge of all IA data.

This sounds like there was some breaking change done here which is just incompatible with the old internal data structure.

This can be a little challenging in the field, because usually in customers environments, not all gateways are updated during the same maintenance window.

I would really appriciate getting some clarification here about when to do this procedure and if it is possible to mix old versions and new versions (regarding this change) together in Identity Sharing environment.

Example scenario:

  • GW1: PDP and PEP, R80.40 JHF T89 on SMS-1
  • GW2:  PEP only, R80.30 JHF T226 on SMS-2 (foreign IA-Trust: sk65404 )
  • GW3-n: PEP only, R80.40 JHF T89 on SMS-1
  • SMS-1: R80.40 JHF T89
  • SMS-2: R80.30 JHF T226

Now the customer wants to schedule different maintenance windows to update these boxes. What should we tell them?

  1. Not possible, because we have to update all of them at the same time.
  2. Possible, but we need to clear the tables after every update.
  3. Possible, but we need to clear the tables after update of GW2 (because only this one is a PDP).
  4. Some other.

Thank you for clarification 🙂

It would also good to know, what kind of "functionality improvements" were implemented here, but maybe Check Point does not want to disclose this.

1 Solution

Accepted Solutions
Royi_Priov
Employee
Employee

Hi @Tobias_Moritz !

I will start with the bottom line - the key for success will be:

Once the PDP/PEP finished the JHF upgrade - clear it's tables. If it's cluster, clear all members at once.

There is no breaking change between PDP to PEP sharing in this bundle.

 

And for the long version:

In Identity Awareness R&D, we have done an internal quality cycle on Identity Sharing flows, to raise issues proactively.

As part of this cycle, we have created more than 20 code changes which are both functional, optimization and debuggability improvements.

This bundle was already implemented with some key customers production and in large QA cycle to ensure high quality before adding to the JHF.

If the IDA tables will not be cleared, 2 main behaviors are possible:

1. leftovers on the kernel tables, which usually not cause any issue other than memory taken by them.

2. temporary sync issues to PEP in Identity Sharing, until the next sharing sync.

Since upgrading JHF anyhow involves maintenance window, I prefer writing the above SK to avoid such undesired behaviors.

 

If you have any additional questions, feel free to tag me 😊

Thanks,
Royi Priov
Group manager, Identity Awareness R&D

View solution in original post

7 Replies
G_W_Albrecht
Champion
Champion

I would suggest rather to contact TAC with your questions, that will supply an official wording for the customer. Or contact your local SE first.

0 Kudos
Reply
Royi_Priov
Employee
Employee

Hi @Tobias_Moritz !

I will start with the bottom line - the key for success will be:

Once the PDP/PEP finished the JHF upgrade - clear it's tables. If it's cluster, clear all members at once.

There is no breaking change between PDP to PEP sharing in this bundle.

 

And for the long version:

In Identity Awareness R&D, we have done an internal quality cycle on Identity Sharing flows, to raise issues proactively.

As part of this cycle, we have created more than 20 code changes which are both functional, optimization and debuggability improvements.

This bundle was already implemented with some key customers production and in large QA cycle to ensure high quality before adding to the JHF.

If the IDA tables will not be cleared, 2 main behaviors are possible:

1. leftovers on the kernel tables, which usually not cause any issue other than memory taken by them.

2. temporary sync issues to PEP in Identity Sharing, until the next sharing sync.

Since upgrading JHF anyhow involves maintenance window, I prefer writing the above SK to avoid such undesired behaviors.

 

If you have any additional questions, feel free to tag me 😊

Thanks,
Royi Priov
Group manager, Identity Awareness R&D

View solution in original post

Tobias_Moritz
Collaborator

Hi @Royi_Priov,

thank you very much for you fast and detailed response. Really appreciated.

That sounds much better that what I expected after reading the sk.

Maybe someone can update the sk and add the info that purging these tables on PDP side after updating PDP gateways is enough and that there is no action needed on PEP-only gateways. And that there are no compatibility issues between updated and not updated gateways 🙂

0 Kudos
Reply
Royi_Priov
Employee
Employee

@Tobias_Moritz - Will do, thanks for the suggestion.

Thanks,
Royi Priov
Group manager, Identity Awareness R&D
ProxyOps
Participant

We as a intensive IA using company, are looking foward for this JHF to become GA so we can push it to all our PEPs and our dedicated PDP Brokers, in our IA enviroment.

With the recent improvoments coming with the offical release of the PDP Broker and now the finished quality lifecyle for IA flows, CheckPoint is definitly going in the right direction regarding the Identity Awareness Blade. The scalabillity and reliabillity improvments are great.

@Royi_PriovGreat work and kudos to the complete team !

Royi_Priov
Employee
Employee

Hi @ProxyOps ,

Thanks for the kind words!

Thanks,
Royi Priov
Group manager, Identity Awareness R&D
0 Kudos
Reply
G_W_Albrecht
Champion
Champion

This procedure should be performed after upgrading clustered gateways with enabled Identity Awareness Blade of the following versions:

I have seen issues with MUH agent after upgrades without performing it.

0 Kudos
Reply