Support Center > Search Results > SecureKnowledge Details
ClusterXL upgrade methods and paths
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
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
R77.30 X X X X X X OSU, or CU
R77.20 X X X X X OSU, or CU OSU, or CU
R77.10 X X X X OSU OSU, or CU OSU, or CU
R77 X X X OSU OSU OSU, or CU OSU, or CU
R76 X X OSU OSU OSU, or CU OSU, or CU OSU, or CU
R75.47 X X X X CU CU CU
R75.46 X X X X CU CU CU
R75.40VS X OSU OSU OSU OSU, or CU OSU, or CU OSU, or CU
VSX R67.10 OSU OSU OSU OSU OSU OSU OSU, or CU

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

 

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
"R77.30DR" X X Yes (5)
R77.30 X Yes (2) Yes (6)
"R77.20DR" X Yes (3) Yes (5)
R77.20 X Yes (4) Yes (6)
R77.10 X Yes (4) Yes (6)
R77 X Yes (4) Yes (6)
R76 Yes (1) Yes (4) Yes (6)
R75.47 Yes (1) Yes (4) Yes (6)
R75.46 Yes (1) Yes (4) Yes (6)
R75.40VS Yes (1) Yes (4) 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:

    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