Version mismatch on Check Point cluster members may cause traffic loss during an upgrade
Article ID: 167999
Updated On:
Products
XOS
Issue/Introduction
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.
Master chassis: upgraded XOS version, upgraded Check Point version
Backup chassis: original XOS version, original Check Point version
Backup chassis: original XOS version, original Check Point version
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.
Cause
Goal: Describe Check Point cluster behavior when members run different version within one cluster.
Resolution
N/A
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:
To change the values:
For permanent settings, modify $FWDIR/boot/modules/fwkern.conf as documented in Check Point SecureKnowledge article sk42096.
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_magicTo 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.
Feedback
Powered by
