Issue/Introduction:
This article describes an issue where a race condition prevents Check Point synchronization from completing successfully.After chassis is reloaded, Check Point application (R70/R71/R75) may not come up successfully.
The cphaprob state command shows the synchronization status as Down and fw ctl pstat reports Sync: off.
Cause:
Problem
This issue may be caused by a race condition between the Check Point application booting and trying to sync with other cluster members while the circuit configured for synchronization is not yet fully initialized. The cluster synchronization doesn't recover automatically even after the circuit is ready.
Resolution:
XOS 9.5.5 implements a new optional parameter to delay the start of the application until circuits configured as management-circuit are up and running.
Release Notes
ID 29374 If the APMs on a chassis initialize before the NPMs are ready to process traffic, the applications on the APMs may not have a path to access the external network and application startup issues may result.
Best practice is to configure Check Point synchronization and management circuits with the
management-circuit parameter. For example:
circuit sync
vap-group fw
management-circuit
Workaround
There are two possible temporary workarounds for this issue:
1) After the application boots, it is possible to trigger a new synchronization attempt by manually running "
fw fcu <other-member-ip>" on the VAP(s).
2) By disabling NPM diagnostics, the boot time of the NPM is much shorter and circuits on APMs will be initialized before the application starts. To disable boot diagnostics, use the Unix command
/crossbeam/bin/bootdiagtool. For details about this command see inline help (-h) and the KB article 4641 (Enable boot diagnostics in XOS -- HOWTO).
Note: Boot diagnostics is enabled by default and essential to detect potential hardware issues. It should not be disabled unless necessary and only considered as a temporary measure.