Support Center > Search Results > SecureKnowledge Details
ClusterXL upgrade methods and paths Technical Level
Solution

Table of Contents:

  • Upgrade methods
  • Upgrade paths without Dynamic Routing synchronization
  • Upgrade paths with Dynamic Routing synchronization
  • Limitations
  • Related documentation

 

Upgrade methods

Upgrade Method Description Network Impact Duration of Upgrade Limitations
Multi-Version Cluster Upgrade (MVC)

also refer to

Installation and Upgrade Guide
Upgrade of Security Gateways and Clusters > Multi-Version Cluster (MVC) Upgrade

The Multi-Version Cluster (MVC) mechanism lets you synchronize connections between Cluster Members that run different versions.

This lets you upgrade to a newer version without a loss in connectivity and lets you test the new version on some of the Cluster Members before you decide to upgrade the rest of the Cluster Members.

Important - The Multi-Version Cluster Upgrade replaced the Connectivity Upgrade.

No connections are dropped.

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

Short
  • While the cluster contains Cluster Members that run different software versions (Multi-Version Cluster), it is not supported to change specific settings of the cluster object in SmartConsole.
    • You cannot change the cluster mode. For example, from High Availability to Load Sharing.
    • In the High Availability mode, you cannot change the recovery mode. For example, from Maintain current active Cluster Member to Switch to higher priority Cluster Member.
    • You cannot change the cluster topology. Do not add, remove, or edit settings of cluster interfaces (IP addresses, Network Objectives, and so on).  In a VSX Cluster object, do not add, remove, or edit static routes. Note - You can change these settings either before or after you upgrade all the Cluster Members.
  • While the cluster contains Cluster Members that run different software versions (Multi-Version Cluster), you must install the policy two times.


These connections do not survive failover between Cluster Members with different versions:

  • VPN:
    • During a cluster failover from an R80.40 Cluster Member to an R77.30 Cluster Member, all VPN connections on an R80.40 Cluster Member that are inspected on CoreXL Firewall instances #1 and higher, are lost.
    • Mobile Access VPN connections.
    • Remote Access VPN connections.
    • VPN Traditional Mode connections.
  • Static NAT connections are cut off during a cluster failover from an R80.40 Cluster Member to an R80.10 or R77.30 Cluster Member, if VMAC mode is enabled in this cluster.
  • Identity Awareness connections.
  • Data Loss Prevention (DLP) connections.
  • IPv6 connections.
  • Threat Emulation connections.
  • PSL connections that are open during fail-over and then fail-back.
Connectivity
Upgrade (CU)


also refer to

Connectivity
Upgrade (CU)
Best Practices
Guide

Cluster members can be upgraded to R77.20 and above according to the "Upgrade paths" table below.

Connection failover is guaranteed.
The procedure is very similar to "Zero Downtime" with the addition of synchronizing the connections to the upgraded cluster members.

 

Important Note for VSX Cluster:
Before upgrading the last non-upgraded VSX cluster member, you must run the "cphacu stop" command on the upgraded VSX cluster member, on which you have previously run the "cphacu start" command.

No connections are dropped.

Requires no maintenance window.
Short. The following features do not survive after failover to upgraded cluster member:
  • Security Servers
  • Connections that are handled by the services that are marked as non-synced
  • Connections initiated by the cluster member itself
  • TCP connections that are TCP streamed
  • Mobile Access VPN connections
  • Remote Access VPN connections
  • VPN Traditional Mode connections
  • Data Leak Prevention (DLP) connections
  • Dynamic Routing connections (refer to this section)
  • FTP Control connections with NAT
  • Session authenticated with Identity Awareness
  • Software Blade information is not synchronized. If the Software Blade is configured in SmartDashboard to Prefer Connectivity Over Security, then the connection is accepted without the inspection. Otherwise, the connection is dropped.
Optimal Service
Upgrade (OSU)

Cluster members can be upgraded according to the "Upgrade paths" table below.

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.

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

Requires a very short maintenance window for old connections to be dropped.

Long.

The nature of this upgrade procedure requires time for old connections to be closed while newly established connections are transferred to the upgrade cluster members for inspection.
  • Upgrade procedure should be implemented during the time of low network traffic.
  • OSU procedure does not provide redundancy if a cluster member fails.
  • Configuration changes should not be performed during the OSU procedure.
  • Complex connections are not supported. Examples:
    • DHCP
    • DCE RPC
    • SUN RPC
    • Back Web
    • llOP
    • FreeTel
    • WinFrame
    • NCP
  • OSU procedure does not support the following:
    • VPN traffic
    • Dynamic Routing
    • Layer2 configuration
Minimal Effort
(Simple Upgrade)

Cluster members can be upgraded to any version.

Each cluster member is upgraded as an independent Security Gateway.
Existing connections are disrupted.

No connectivity as all cluster members are out of for maintenance.

Requires a substantial maintenance window.
As long as it takes to upgrade all cluster members. none
Zero
Downtime

Cluster members can be upgraded to any version.

During this type of upgrade, there is always at least one Active cluster member that handles the traffic.
Connections are not synchronized between cluster members running different Check Point software versions.
Upgraded cluster members are in "Ready" state until the cluster members running the previous version are stopped (with cphastop, or cpstop command).

Connections that were initiated on a cluster members running the previous version are dropped when the cluster member is upgraded to a new version.

Requires a relatively short maintenance window for old connections to be dropped.
Relatively short. Dynamic Routing connections are not supported.
Full Connectivity
Upgrade (FCU)
This upgrade method is considered obsolete and not supported since R75 GA.

 

Upgrade paths without Dynamic Routing synchronization

Explanation:

  • This section shows that supported upgrade paths, during which the Dynamic Routing information is not synchronized
  • The leftmost column shows the versions, from which you upgrade
  • The top row shows the final versions, to which you upgrade
  • The table shows which upgrade paths and methods are supported (if any)
  Upgrade to
version
Upgrade from
version
R75.40VS R76 R77 R77.10 R77.20 R77.30 R80.10 R80.20 R80.30 R80.40
R80.30 X X X X X X X X X MVC
R80.20 X X X X X X X X OSU, or CU MVC
R80.10 X X X X X X X OSU, or CU OSU, or CU MVC
R77.30 X X X X X X OSU, or CU OSU, or CU OSU, or CU MVC
R77.20 X X X X X OSU, or CU OSU, or CU OSU, or CU OSU, or CU X
R77.10 X X X X OSU OSU, or CU OSU, or CU OSU, or CU OSU, or CU X
R77 X X X OSU OSU OSU, or CU OSU, or CU OSU, or CU OSU, or CU X
R76 X X OSU OSU OSU, or CU OSU, or CU OSU, or CU OSU, or CU OSU, or CU X
R75.47 X X X X CU CU CU CU CU X
R75.46 X X X X CU CU CU CU CU X
R75.40VS X OSU OSU OSU OSU, or CU OSU, or CU OSU, or CU OSU, or CU OSU, or CU X
VSX R67.10 OSU OSU OSU OSU OSU OSU OSU, or CU OSU, or CU OSU, or CU X

Legend:

  • [X] - such upgrade is not supported
  • [OSU] - only Optimal Service Upgrade is supported
  • [OSU, or CU] - either Optimal Service Upgrade, or Connectivity Upgrade is supported

Notes:

  • CU upgrade to R80.30 with kernel 3.10 is not supported.
  • In R80.40 running CU will turn MVC on.

 

Upgrade paths with Dynamic Routing synchronization

Explanation:

  • This section shows that supported upgrade paths, during which the Dynamic Routing information is synchronized.
  • Connectivity Upgrade supports Dynamic Routing synchronization in the following scenarios:
    • when upgrading to R80.10
    • when upgrading to R77.30 with Take_198 and higher of R77.30 Jumbo Hotfix (denoted as "R77.30DR" below)
    • when upgrading to R77.20 with Take_200 and higher of R77.20 Jumbo Hotfix (denoted as "R77.20DR" below)
    Note: These "R77.30DR" / "R77.20DR" Takes of Jumbo Hotfix Accumulators can be installed over the lower Takes. In VRRP clusters, such CU upgrade with Dynamic Routing synchronization is supported only when upgrading from R77.30 version to R80.10 version.
  • The leftmost column shows the versions, from which you upgrade.
  • The top row shows the final versions, to which you upgrade.
  • The table shows which upgrade paths are supported (if any).
  • Upgrade action plans are described under the table.
  Upgrade to
version
Upgrade from
version
"R77.20DR" "R77.30DR" R80.10 R80.20 R80.30
R80.20 X X X X Yes (6)
R80.10 X X X Yes (6) Yes (6)
"R77.30DR" X X Yes (5) Yes (5) Yes (5)
R77.30 X Yes (2) Yes (6) Yes (6) Yes (6)
"R77.20DR" X Yes (3) Yes (5) Yes (5) Yes (5)
R77.20 X Yes (4) Yes (6) Yes (6) Yes (6)
R77.10 X Yes (4) Yes (6) Yes (6) Yes (6)
R77 X Yes (4) Yes (6) Yes (6) Yes (6)
R76 Yes (1) Yes (4) Yes (6) Yes (6) Yes (6)
R75.47 Yes (1) Yes (4) Yes (6) Yes (6) Yes (6)
R75.46 Yes (1) Yes (4) Yes (6) Yes (6) Yes (6)
R75.40VS Yes (1) Yes (4) Yes (6) Yes (6) Yes (6)

 

Legend:

  • [X] - such upgrade is not supported
  • [Yes] - Connectivity Upgrade with Dynamic Routing synchronization is supported

Upgrade action plans:

Click here to Show / Hide this section
  1. How to upgrade from R75.40VS, R75.46, R75.47, R76 to "R77.20DR" (R77.20 with Take_200 and higher of R77.20 Jumbo Hotfix):

    1. Upgrade the Standby cluster member to R77.20
    2. Reboot the upgraded Standby cluster member
    3. Install Take_200 and higher of R77.20 Jumbo Hotfix on the upgraded Standby cluster member
    4. Reboot the upgraded Standby cluster member
    5. Initiate the Connectivity Upgrade (CU) per Connectivity Upgrade (CU) Best Practices Guide on the upgraded Standby cluster member
    6. Initiate the failover on the Active cluster member (to the upgraded Standby cluster member)
    7. Repeat Steps A-E on the Active cluster member
  2. How to upgrade from R77.30 GA to "R77.30DR" (R77.30 with Take_198 and higher of R77.30 Jumbo Hotfix):

    1. Install Take_198 and higher of R77.30 Jumbo Hotfix on the Standby cluster member
    2. Reboot the upgraded Standby cluster member
    3. Initiate the Connectivity Upgrade (CU) per Connectivity Upgrade (CU) Best Practices Guide on the upgraded Standby cluster member
    4. Initiate the failover on the Active cluster member (to the upgraded Standby cluster member)
    5. Repeat Steps A-C on the Active cluster member
  3. How to upgrade from "R77.20DR" (R77.20 with Take_200 and higher of R77.20 Jumbo Hotfix) to "R77.30DR" (R77.30 with Take_198 and higher of R77.30 Jumbo Hotfix):

    As described in the R77.20 Jumbo Hotfix, direct upgrade to R77.30 is not supported from these Takes.

    1. Uninstall the current Take of R77.20 Jumbo Hotfix from the Standby cluster member
    2. Reboot the downgraded Standby cluster member
    3. Upgrade the Standby cluster member to R77.30
    4. Reboot the upgraded Standby cluster member
    5. Install Take_198 and higher of R77.30 Jumbo Hotfix on the upgraded Standby cluster member
    6. Reboot the upgraded Standby cluster member
    7. Initiate the Connectivity Upgrade (CU) per Connectivity Upgrade (CU) Best Practices Guide on the upgraded Standby cluster member
    8. Initiate the failover on the Active cluster member (to the upgraded Standby cluster member)
    9. Repeat Steps A-G on the Active cluster member
  4. How to upgrade to "R77.30DR" (R77.30 with Take_198 and higher of R77.30 Jumbo Hotfix):

    1. Upgrade the Standby cluster member to R77.30 on the Standby cluster member
    2. Reboot the upgraded Standby cluster member
    3. Install Take_198 and higher of R77.30 Jumbo Hotfix on the upgraded Standby cluster member
    4. Reboot the upgraded Standby cluster member
    5. Initiate the Connectivity Upgrade (CU) per Connectivity Upgrade (CU) Best Practices Guide on the upgraded Standby cluster member
    6. Initiate the failover on the Active cluster member (to the upgraded Standby cluster member)
    7. Repeat Steps A-E on the Active cluster member
  5. How to upgrade from "R77.20DR" (R77.20 with Take_200 and higher of R77.20 Jumbo Hotfix), or from "R77.30DR" (R77.30 with Take_198 and higher of R77.30 Jumbo Hotfix) to R80.10:

    1. Uninstall the current Take of Jumbo Hotfix from the Standby cluster member
    2. Reboot the downgraded Standby cluster member
    3. Upgrade the Standby cluster member to R80.10
    4. Reboot the upgraded Standby cluster member
    5. Initiate the Connectivity Upgrade (CU) per Connectivity Upgrade (CU) Best Practices Guide on the upgraded Standby cluster member
    6. Initiate the failover on the Active cluster member (to the upgraded Standby cluster member)
    7. Repeat Steps A-E on the Active cluster member
  6. How to upgrade from R75.40VS, R75.46, R75.47, R76, R77, R77.10, R77.20, R77.30 to R80.10/R80.20/R80.30:

    1. Upgrade the Standby cluster member to R80.10
    2. Reboot the upgraded Standby cluster member
    3. Initiate the Connectivity Upgrade (CU) per Connectivity Upgrade (CU) Best Practices Guide on the upgraded Standby cluster member
    4. Initiate the failover on the Active cluster member (to the upgraded Standby cluster member)
    5. Repeat Steps A-C on the Active cluster member

 

Limitations

  • VRRP cluster is supported only by Connectivity Upgrade (CU) and only starting in the following versions:
  • In VRRP cluster, Connectivity Upgrade with Dynamic Routing synchronization is supported only when upgrading:
    from R77.30 with Take_198 (and higher) of R77.30 Jumbo Hotfix to R80.10
  • In VSX VSLS Cluster, Connectivity Upgrade is not supported when upgrading to the following versions:
    • When upgrading to R77.30 with take from Take_198 to Take_288 of R77.30 Jumbo Hotfix (denoted as "R77.30DR" above)
    • When upgrading to R77.20 with Take_200 and higher of R77.20 Jumbo Hotfix (denoted as "R77.20DR" above)


Applies To:
  • This SK replaces sk98184

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment