Important:

• Load Sharing modes are only supported with the required R80.20 Jumbo Hotfix Accumulator. For instructions, see sk162637.
• To upgrade a ClusterXL that works in a Load Sharing mode from a lower version to R80.20, follow these steps in the same maintenance window:
  1. Upgrade the ClusterXL to R80.20.
  2. Install the required R80.20 Jumbo Hotfix Accumulator. For instructions, see sk162637.

1

Back up your current configuration.

2

See the Upgrade Options and Prerequisites.

3

Upgrade the Management Server and Log Servers to R80.20 version.

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, upgrade the configuration of the VSX Cluster object to R80.20.

6

Schedule a full maintenance window to make sure you can make all the desired 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.

Note - For more information, see sk25977.

• On Security Gateway R80.10:

  # cphaprob mmagic

  Examine the value in the MAC magic field

  Examine the value in the MAC forward magic field

• On VSX Gateway R80.10:

  # 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

• On Security Gateway R77.30:

  # cphaconf cluster_id get

  Examine the value of the cluster_id

• On VSX Gateway R77.30:

  # 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

• On Security Gateway and VSX Gateway R75.40 - R77.20:

  # 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

Connectivity Upgrade (CU)

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.

This upgrade method supports cluster members in High Availability mode only.

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).

Note - The CU procedure is very similar to the Zero Downtime procedure with the addition of synchronizing the connections to the upgraded cluster members.

This upgrade method does not require a maintenance 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 sk107042.

Optimal Service Upgrade (OSU)

Select this method, if security is of utmost concern.

During this type of upgrade, all Cluster Members process the network traffic.

Connections that are initiated during the upgrade stay up through the upgrade. A minimal number of connections that were initiated before the upgrade and were not closed during the upgrade procedure, are dropped after the upgrade.

Newly established connections are forwarded to the upgraded cluster members while the cluster members running the previous version continue to inspect the old existing connections. The more time the upgrade procedure takes, the less old connections exist, and upon stopping the cluster members running the previous version, the connection drop is minimal. Despite long duration of this upgrade procedure, security and connectivity are fully maintained.

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

This method does not support a 3rd party cluster (VRRP on Gaia).

This upgrade method requires a very short maintenance window for old connections to be dropped.

Duration of this upgrade is long.

This upgrade method supports only specific upgrade paths.

This upgrade method does not support some types of connections.

See sk107042.

Minimal 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 maintenance window.

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

None

Zero Downtime Upgrade

Select this method, if you cannot have any network downtime and need to complete the upgrade quickly, with a minimal 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 maintenance window to drop old connections.

Duration of this upgrade is relatively short.

This upgrade method does not support Dynamic Routing connections.

1

Perform these steps:

1. Connect over the console to the Cluster Member.
2. Physically disconnect the Cluster Member from the network (unplug 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 <Interface_Name> state off