Accelerated policy installation and ClusterXL

[Alex-]

R81.10 T30

A customer has defined a cluster interface in the topology of the firewall and installed the policy.

It turned out after that on one of the cluster members, that interface had a wrong IP so the VIP wouldn't show up under cphaprob -a if.

When it was corrected, the policy was pushed but the VIP still wouldn't show up until the trick described by @Timothy_Hall to disable accelerated installation was applied and then the VIP showed up.

Changing cluster properties seem to always cause a non-accelerated policy installation but, in this case, interface reconfiguration happened after so I suppose the feature bypasses topology update/refresh unlike non-accelerated installation.

[Chris_Atkinson]

So you used sk168055 to disable accelerated policy or another process?

[Alex-]

Yes, I right-clicked at the installation screen and unchecked acceleration.

More context, this is a VLAN interface linked to a bond on a 5000 series. 

Actually the issue is fixed now since all VIP are now similar on both gateways. I was just wondering if policy acceleration would bypass topology (re-)generation if the cluster object wasn't changed in Smart Console but afterwards on the system themselves.

[Timothy_Hall]

Unlikely that changes to a cluster object would be eligible for accelerated policy install, as any changes made to a cluster object have to be handled by the legacy fwm process, which is single-threaded and accounts for why the initial open and saving of a cluster object after hitting OK are relatively slow compared to the majority of other operations which are handled by cpm.  In some cases these type of cluster operations can even cause the SmartConsole to freeze for a moment or two waiting for fwm. 

This limitation may have changed in later releases, and is also why cluster objects could not be manipulated until Management API 1.6+.

[Alex-]

Indeed, what I meant is that the intended topology was created on the cluster object, which behaved as you described and policy was slow-pushed, but then the interface's IP was fixed on the gateway itself after all that and the VIP on that member would appear only if the policy was slow-pushed again.

[Timothy_Hall]

Ah I see a full policy install was required to sync back up the interface IP in Gaia against the IP defined in the firewall object's topology.  Not sure what Check Point is going to be able to do about this since it is the SMS that makes the accelerated policy decision, and it has no real way of knowing that a change was made in the Gaia OS out on the firewall.

[Alex-]

Yes and in this case the matter is closed, but then comes the inevitable question about turning off accelerated installation as the customer isn't sure some other settings might be "missed" and in regular environments, accelerated installation is more of a luxury than a much-needed feature. Concurrent policies installation is generally more seen as a real improvement over accelerated ones from the feedback I've been gathering.

[the_rock]

I cant check sk @Chris_Atkinson gave, as support site is down at the moment, but I checked this in my lab and customer's environment in R81.10 and I dont see the same problem, even if accelerated policy process takes place with policy push to the clusterXL. Maybe someone in R&D can confirm this.