- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Breaking IA change in R80.40 JHF T91 / R80.30 ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Breaking IA change in R80.40 JHF T91 / R80.30 JHF T227 - sk170516
Very recently, sk170516 was published.
It is linked in R80.40 JHF T91 / R80.30 JHF T227
PRJ-18247, PRJ-18124 | Identity Awareness | NEW: 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?
- Not possible, because we have to update all of them at the same time.
- Possible, but we need to clear the tables after every update.
- Possible, but we need to clear the tables after update of GW2 (because only this one is a PDP).
- 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.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 😊
Royi Priov
R&D Group manager, Infinity Identity
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 😊
Royi Priov
R&D Group manager, Infinity Identity
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Tobias_Moritz - Will do, thanks for the suggestion.
Royi Priov
R&D Group manager, Infinity Identity
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This procedure should be performed after upgrading clustered gateways with enabled Identity Awareness Blade of the following versions:
- R80.10 Jumbo Hotfix Take 287 and below upgraded to Take 288 and higher
- R80.30 Jumbo Hotfix Take 226 and below upgraded to Take 227 and higher
- R80.30 Jumbo Hotfix Gaia 3.10 Take 227 and below upgraded to Take 228 and higher
- R80.40 Jumbo Hotfix Take 90 and below upgraded to Take 91 and higher
- R81 Jumbo Hotfix Take 11 and below upgraded to Take 13 and higher
I have seen issues with MUH agent after upgrades without performing it.
