Version mismatch on Check Point cluster members may cause traffic loss during an upgradeThis article refers to following DBHA scenario during an upgrade:

The current VRRP Master chassis is already upgraded to a higher XOS version and higher Check Point version. As the next step, the customer upgrades XOS and reloads the Backup chassis. This step can lead to a traffic outage since Check Point application is still at a lower version on the Backup. Cluster members on the Master chassis detect the boot of members at lower version and may switch to "Ready" state (i.e. stop processing traffic despite the chassis itself is VRRP master). This cluster behavior is documented in Check Point SecureKnowledge article sk42096.  

Goal: Describe Check Point cluster behavior when members run different version within one cluster.

N/A

Workaround

To avoid this condition, there are several options:

1. Disable all interfaces on the lower version chassis before the reload (both traffic and sync interfaces need to be disabled because CCP packets are broadcasted out of all interfaces after reboot) .

2. Disable automatic start of the application before reload with "application <APPID> vap-group <VAPGROUPNAME> stop".

3. Change the Check Point MAC magic variable (sk25977) on the lower version cluster members so that they become a different cluster from CCP perspective and will not interfere with the higher version members. You can verify the current MAC magic values by running:

# fw ctl get int fwha_mac_magic
# fw ctl get int fwha_mac_forward_magic

To change the values:

# fw ctl set int fwha_mac_magic <value1>
# fw ctl set int fwha_mac_forward_magic <value2>

For permanent settings, modify  $FWDIR/boot/modules/fwkern.conf as documented in Check Point SecureKnowledge article sk42096.