Planning a Cluster Upgrade

Important - Before you upgrade Cluster Members:

Step

Instructions

1

Back up your current configuration (see Backing Up and Restoring).

2

See Upgrade Options and Prerequisites.

3

Upgrade the Management Server and Log Servers.

4

Upgrade the licenses on the Cluster Members, if needed.

See Working with Licenses.

5

If you upgrade a VSX Cluster, then on the Management Server you must upgrade the configuration of the VSX Cluster object to R80.40.

6

Schedule a full maintenance window to make sure you can make all the custom configurations again after the upgrade.

The upgrade process replaces all existing files with default files.

If you have custom configurations on the Cluster Members, they are lost during the upgrade.

As a result, different issues can occur in the upgraded cluster.

Cluster Members can stop detecting each other, Cluster Members can move to undesired state, and traffic can be dropped.

7

Make sure the configuration and the values of the required kernel parameters are the same on all Cluster Members.

Log in to the Expert mode on each Cluster Member and run the applicable commands (see below).

Note - For more information, see sk25977.

Applicable commands and required kernel parameters

Version

Mode

Applicable Command and Parameters

R80.10 and higher

Cluster Members

cphaprob mmagic

Examine the value in the "MAC magic" field.

Examine the value in the "MAC forward magic" field.

 

VSX Cluster Members

fw ctl get int fwha_add_vsid_to_ccp_mac

grep fwha_add_vsid_to_ccp_mac $FWDIR/boot/modules/fwkern.conf

Examine the value of the kernel parameter "fwha_add_vsid_to_ccp_mac".

R77.30

Cluster Members

cphaconf cluster_id get

Examine the value of the "cluster_id".

 

VSX Cluster Members

fw ctl get int fwha_add_vsid_to_ccp_mac

grep fwha_add_vsid_to_ccp_mac $FWDIR/boot/modules/fwkern.conf

Examine the value of the kernel parameter "fwha_add_vsid_to_ccp_mac".

R75.40 - R77.20

Cluster Members,

VSX Cluster Members

fw ctl get int fwha_mac_magic

fw ctl get int fwha_mac_forward_magic

Examine the value of the kernel parameter "fwha_mac_magic".

Examine the value of the kernel parameter "fwha_mac_forward_magic".

Available upgrade methods:

Because the upgrade process on Cluster Members stops all Check Point services, it disrupts the cluster's ability to inspect and synchronize the connections that pass through the cluster.

The table below describes the available upgrade methods.

Upgrade
Method

Instructions

Maintenance
Window (downtime)

Limitations

Multi-Version Cluster (MVC) Upgrade

Select this method, if connectivity is of utmost concern.

Connection failover is guaranteed - no connections are dropped.

Connections that were initiated before the upgrade are synchronized with the upgraded Security Gateways and cluster members, so that no connections are dropped.

You can select this method, if you upgrade a ClusterXL or a VSX Cluster.

You can select this method, if you upgrade a 3rd party cluster (VRRP on Gaia).

This upgrade method does not require a downtime window.

Duration of this upgrade is short.

This upgrade method supports only specific upgrade paths.

Many types of connections do not survive after failover to upgraded Cluster Member.

See:

Minimum Effort Upgrade (Simple Upgrade)

Select this method, if you have a period of time, during which network downtime is allowed.

This method is the simplest, because it lets you upgrade each Cluster Member as an independent Security Gateway.

All connections that were initiated before the upgrade, are dropped during the upgrade.

You can select this method, if you upgrade a ClusterXL or a VSX Cluster.

You can select this method, if you upgrade a 3rd party cluster (VRRP on Gaia).

This upgrade method requires a substantial downtime window.

Duration of this upgrade is as long as it takes to upgrade all Cluster Members.

None

Minimum Downtime Upgrade

Select this method, if you cannot have any network downtime and need to complete the upgrade quickly, with a minimum number of dropped connections.

During this type of upgrade, there is always at least one Active Cluster Member in cluster that handles traffic.

All connections that were initiated through a Cluster Member that runs the old version, are dropped when you upgrade that Cluster Member to a new version, because Cluster Members that run different Check Point software versions, cannot synchronize connections.

Network connectivity, however, remains available during the upgrade, and connections initiated through an upgraded cluster member are not dropped.

You can select this method, if you upgrade a ClusterXL or a VSX Cluster.

You can select this method, if you upgrade a 3rd party cluster (VRRP on Gaia).

This upgrade method requires a relatively short downtime window to drop old connections.

Duration of this upgrade is relatively short.

This upgrade method does not support Dynamic Routing connections.

Cluster state "Ready" during a cluster upgrade

Note - This applies only when the Multi-Version Cluster (MVC) Mechanism is disabled (see Multi-Version Cluster (MVC) Upgrade).

When Cluster Members of different versions are on the same network, Cluster Members of the new (upgraded) version remain in the state Ready, and Cluster Members of the previous version remain in state Active Attention.

Cluster Members in the state Ready do not process traffic and do not synchronize with other Cluster Members.

To prevent Cluster Members from being in the state "Ready":

Option

Instructions

1

Perform these steps:

  1. Connect over the console to the Cluster Member.

  2. Physically disconnect the Cluster Member from the network (disconnect all cables).

2

Perform these steps:

  1. Connect over the console to the Cluster Member.

  2. Log in to Gaia Clish..

  3. Shut down all interfaces:

    set interface <Name of Interface> state off

For more information, see sk42096.