See the Installation and Upgrade Guide R81.10 > Chapter "Upgrade of Security Gateways and Clusters" > Section "Upgrading ClusterXL, VSX Cluster, or VRRP Cluster" > Section "Multi-Version Cluster (MVC) Upgrade"
The Multi-Version Cluster (MVC) mechanism lets you synchronize connections between Cluster Members that run different versions.
MVC 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 starting from R80.40.
The Multi-Version Cluster Upgrade is intended only to test the current configuration in the newer version. It is not intended for changing the Security Policy and installing it on cluster members with different software versions.
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 and higher Cluster Member to an R77.30 Cluster Member, all VPN connections on an R80.40 and higher 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 and higher 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.
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
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
Explanation:
This section shows the supported upgrade paths
All CU and MVC supported paths support Dynamic Routing Synchronization
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
R80.10
R80.20
R80.30
R80.40
R81
R81.10
R81.20
R81.10
X
X
X
X
MVC
MVC
MVC
R81
X
X
X
X
MVC
MVC
MVC
R80.40
X
X
X
X
MVC
MVC
MVC
R80.30
X
X
X
MVC
MVC
MVC
MVC
R80.20
X
X
OSU, or CU
MVC
MVC
MVC
MVC
R80.10
X
OSU, or CU
OSU, or CU
MVC
MVC
MVC
MVC
R77.30
OSU, or CU
OSU, or CU
OSU, or CU
MVC
MVC
MVC
MVC
R77.20
OSU, or CU
OSU, or CU
OSU, or CU
X
X
X
X
R77.10
OSU, or CU
OSU, or CU
OSU, or CU
X
X
X
X
R77
OSU, or CU
OSU, or CU
OSU, or CU
X
X
X
X
R76
OSU, or CU
OSU, or CU
OSU, or CU
X
X
X
X
R75.47
CU
CU
CU
X
X
X
X
R75.46
CU
CU
CU
X
X
X
X
R75.40VS
OSU, or CU
OSU, or CU
OSU, or CU
X
X
X
X
VSX R67.10
OSU, or CU
OSU, or CU
OSU, or CU
X
X
X
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 and higher versions running CU will turn MVC on.
Limitations
VRRP cluster is supported by Connectivity Upgrade (CU) starting in the following versions:
R77.30 with Take_198 and higher of R77.30 Jumbo Hotfix (denoted as "R77.30DR" above)
R77.20 with Take_200 and higher of R77.20 Jumbo Hotfix (denoted as "R77.20DR" above)
And MVC upgrade in R80.40 and higher versions.
In VRRP cluster, Connectivity Upgrade is supported only when upgrading: from R77.30 with Take_198 (and higher) of R77.30 Jumbo Hotfix to R80.10
Traffic from a Site-to-Site VPN peer that is configured with a Dynamically Assigned IP Address (DAIP) to the cluster does not survive the Connectivity Upgrade (CU).
