1 May 2018

CONNECTIVITY UPGRADE

R77.X AND R80.X VERSIONS

Best Practices
Classification: [Protected] OPTIONAL
© 2018 Check Point Software Technologies Ltd.
All rights reserved. This product and related documentation are protected by copyright and
distributed under licensing restricting their use, copying, distribution, and decompilation. No part
of this product or related documentation may be reproduced in any form or by any means without
prior written authorization of Check Point. While every precaution has been taken in the
preparation of this book, Check Point assumes no responsibility for errors or omissions. This
publication and features described herein are subject to change without notice.
RESTRICTED RIGHTS LEGEND:
Use, duplication, or disclosure by the government is subject to restrictions as set forth in
subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS
252.227-7013 and FAR 52.227-19.
TRADEMARKS:
Refer to the Copyright page http://www.checkpoint.com/copyright.html for a list of our
trademarks.
Refer to the Third Party copyright notices http://www.checkpoint.com/3rd_party_copyright.html
for a list of relevant copyrights and third-party licenses.
Important Information
Feedback
Check Point is engaged in a continuous effort to improve its documentation.
Please help us by sending your comments
mailto:[email protected]?subject=Feedback on Connectivity
Upgrade R77.x and R80.x Versions Best Practices.

Revision History
Date Description
01 May 2018 General Updates

14 May 2017 General Updates

09 April 2017 Dynamic Routing support and minor improvements

30 December 2015 First release of this document

Contents
Important Information................................................................................................... 3
Introduction ................................................................................................................... 5
Supported Versions ....................................................................................................... 6
Upgrading a Security Gateway ClusterXL with 2 Members ........................................... 7
Upgrading a Security Gateway ClusterXL with More Than 2 Members ......................... 9
Upgrading a VSX Cluster with 2 Members................................................................... 11
Upgrading a VSX Cluster with More Than 2 Members................................................. 13
Upgrading a VRRP Cluster .......................................................................................... 15
Making Sure the Upgrade Completed ......................................................................... 18
Troubleshooting the Upgrade ..................................................................................... 19
Connectivity Upgrade Error Messages ........................................................................ 20
Known Limitations ...................................................................................................... 22
Other Upgrade Methods .............................................................................................. 24
CHAPTE R 1

Introduction
NEW! Cluster Connectivity Upgrade supports Dynamic Routing Synchronization in R80.10, in
R77.30DR (R77.30 Jumbo Hotfix Take 198 and above), and in R77.20DR (R77.20 Jumbo Hotfix Take
198 and above).
A Connectivity Upgrade (CU) lets you upgrade ClusterXL clusters on live systems without
downtime. In a Connectivity Upgrade:
• Connection failover is guaranteed.
• There is always at least one active cluster member that handles the traffic.
• Connections are synchronized among cluster members which run different Check Point
software versions.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 5

CHAPTE R 2

Supported Versions
Check Point Connectivity Upgrade (CU) synchronizes existing connections to maintain connectivity
during cluster upgrades.
Connectivity Upgrade is supported for these releases:

Upgrade from
R77.20 R77.20DR R77.30 R77.30DR R80.10
Version
R75.40VS CU CU + DR CU CU + DR CU + DR

R75.46 CU CU + DR CU CU + DR CU + DR

R75.47 CU CU + DR CU CU + DR CU + DR

R76 CU CU + DR CU CU + DR CU + DR

R77 - - CU CU + DR CU + DR

R77.10 - - CU CU + DR CU + DR

R77.20 - - CU CU + DR CU + DR

R77.20DR - - CU CU + DR CU + DR

R77.30 - - - - CU + DR

R77.30DR - - - - CU + DR

Notes:
• For upgrade action plans for Dynamic Routing in Connectivity Upgrades see sk107042
http://supportcontent.checkpoint.com/solutions?id=sk107042.
• Dynamic Routing in Connectivity Upgrades for VRRP clusters is supported only in upgrades
from R77.30 to R80.10.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 6

CHAPTE R 3

Upgrading a Security Gateway

ClusterXL with 2 Members
Before you upgrade:
• Make sure that the cluster has 2 members, one of which is the Active member and the other
member is in Standby state.
• For upgrades to R77.20 or R77.30: Get the sync interface IP address and the cluster member
ID of the Active cluster member.

To check the cluster member's state and to get its IP address and the cluster
member ID:
Run the cphaprob state command on the cluster member.

To upgrade the cluster:

1. Upgrade the Standby cluster member based on the Installation and Upgrade Guide for (Gaia)
platforms.
Reboot the cluster member after the upgrade.
Note - In upgrades with dynamic routing synchronization, configure dynamic routing based on
the Known Limitations (on page 22).
2. In SmartDashboard:
a) Open the cluster object.
b) Change the Cluster version to the upgraded one.
c) Click OK.
d) Click Install Policy.
e) In the Install Policy > Installation Mode:
(i) Select Install on each selected gateway independently.
(ii) Clear For Gateway Clusters install on all the members, if it fails do not install at all.
f) Install the security policy on this cluster.
Note - The policy successfully installs on the upgraded cluster member and fails to install on
the cluster member that still runs the previous version. This is expected, ignore the warning.
3. On the cluster member that still runs the previous version, run:
cphaprob state
Make sure the state of this cluster member is Active or Active Attention.
For upgrades to R77.20 or R77.30, record the Sync IP and the Member ID of the cluster
member.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 7

 Upgrading a Security Gateway ClusterXL with 2 Members

4. On the upgraded cluster member, run these commands:

a) cphaprob state
Make sure that the cluster member is in Ready state.
b) cphacu start <Sync IP of Active member> <Member ID of Active member>
For R80.10, R77.30DR and R77.20DR, run:
cphacu start [no_dr]
If dynamic routing synchronization is not required, use the no_dr option.
c) cphacu stat
Make sure that the Active cluster member (that still runs the previous version) handles the
traffic.
5. Make sure that the Connectivity Upgrade is complete. ("Making Sure the Upgrade Completed"
on page 18)
6. On the cluster member that still runs the previous version, run these commands:
a) cphaprob state
Make sure the local member is in Active or Active Attention state, and the upgraded
member is in Down state.
b) fwaccel off
c) fwaccel stat
Make sure the SecureXL is disabled (off). This is required to synchronize delayed
connections.
d) cpstop
At this moment, the connections fail over to the upgraded cluster member.
7. On the upgraded cluster member, run:
a) cphaprob state
Make sure that this cluster member is in the Active state.
b) cphacu stat
c) Make sure it handles the traffic.
8. Upgrade the remaining cluster member that still runs the previous version.
Make sure to reboot it after the upgrade.
9. In SmartDashboard, install policy on this cluster.
10. After the cluster upgrade is complete, the Cluster Control Protocol (CCP) works in broadcast
mode.
Change the CCP mode to multicast.
On all cluster members, run:
cphaconf set_ccp multicast
cphaprob state

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 8

CHAPTE R 4

Upgrading a Security Gateway

ClusterXL with More Than 2 Members
Before you upgrade:
• Make sure that the cluster has two or more members, one of which is the Active member and
the other members are in Standby state.
• For upgrades to R77.20 or R77.30: Get the sync interface IP address and the cluster member
ID of the Active cluster member.

To check the cluster member's state and to get its IP address and the cluster
member ID:
• Run the cphaprob state command on the cluster member.

To upgrade the cluster:

1. Upgrade all of the Standby cluster members based on the Installation and Upgrade Guide for
Gaia Platforms.
Reboot the cluster member after the upgrade.
Note - In upgrades with dynamic routing synchronization, configure dynamic routing based on
the known limitations (on page 22).
2. In SmartDashboard:
a) Open the cluster object.
b) Change the Cluster version to the upgraded one.
c) Click OK.
d) Click Install Policy.
e) In the Install Policy window > Installation Mode:
(i) Select Install on each selected gateway independently
(ii) Clear For Gateway Clusters install on all the members, if it fails do not install at all.
f) Install the security policy on the cluster.
Note - The policy successfully installs on the Ready cluster member and fails to install on the
Active cluster member. This is expected, ignore the warning.
3. On all of the upgraded cluster members, except one, run:
cpstop
4. On the one upgraded cluster member that is not stopped, run:
cphaprob state
Make sure this cluster member is in Ready state.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 9

 Upgrading a Security Gateway ClusterXL with More Than 2 Members

5. On the remaining cluster member that still runs the previous version, run:
a) cphaprob state
Make sure this cluster member is in Active or Active Attention state, and all the upgraded
cluster members are in Down state.
b) cphacu start <Sync IP of Active_GW> <Member ID of Active_GW>
For R80.10, R77.30DR and R77.20DR, run:
cphacu start [no_dr]
If dynamic routing synchronization is not required, use the no_dr option.
6. Make sure that the connectivity upgrade is complete. ("Making Sure the Upgrade Completed"
on page 18)
7. On the remaining cluster member that still runs the previous version, run:
a) fwaccel off
b) fwaccel stat
Make sure SecureXL is disabled (off). This is required to synchronize delayed connections.
c) cpstop
8. On the one upgraded cluster member that is not stopped, run:
a) cphaprob state
Make sure this cluster member is in Active state.
b) cphacu stat
Make sure this cluster member monitors the traffic.
9. On all of the upgraded cluster members that were stopped, run:
cpstart
10. Upgrade the remaining cluster member that still runs the previous version.
Reboot the cluster member after the upgrade.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 10

CHAPTE R 5

Upgrading a VSX Cluster with 2

Members
Before you upgrade:
• Make sure that the cluster has 2 members, one of which is the Active member and the other
member is in Standby.
• For upgrades to R77.20 or R77.30: Get the sync interface IP address and the cluster member
ID of the Active cluster member.

To check the cluster member's state and to get its IP address and the cluster
member ID:
Run the cphaprob state command on each of the cluster members.

To upgrade the cluster:

1. Upgrade the Standby cluster member with a clean install.
For more information about the clean install, see sk97552
http://supportcontent.checkpoint.com/solutions?id=sk97552.
Reboot the upgrade cluster member after the upgrade.
Note - In upgrades with dynamic routing synchronization, configure dynamic routing based on
the Known Limitations (on page 22).
2. On the upgraded member, run:
cphaprob state
Make sure that this cluster member is in the Ready state.
3. On the cluster member that still runs the previous version, run:
cphaprob state
Make sure that this cluster member is in Active or Active Attention state, and that the
upgraded member is in Down state.
4. On the upgraded member, run:
cphacu start <Sync IP of Active member> <Member ID of Active member>
For R80.10, R77.30DR and R77.20DR, run:
cphacu start [no_dr]
If dynamic routing synchronization is not required, use the no_dr option.
5. Make sure that the Connectivity Upgrade is complete ("Making Sure the Upgrade Completed"
on page 18).
6. On the cluster member that still runs the previous version, run:
a) vsenv 0
b) fwaccel off -a
c) fwaccel stat -a
Make sure the SecureXL is disabled (off). This is required to synchronize delayed
connections.
d) cpstop

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 11

 Upgrading a VSX Cluster with 2 Members

7. On the upgraded cluster member, run:

a) cphaprob state
Make sure this cluster member is in Active state.
b) cphacu stat
Make sure this cluster member handles the traffic.
c) cphacu stop
8. Upgrade the remaining cluster member that still runs the previous version with a clean install.
For more information about the clean install, see sk97552
http://supportcontent.checkpoint.com/solutions?id=sk97552.
Reboot the upgrade cluster member after the upgrade.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 12

CHAPTE R 6

Upgrading a VSX Cluster with More

Than 2 Members
Before you upgrade:
• Make sure that the cluster has two or more members, one of which is the Active member and
the other members are in Standby.
• For upgrade to R77.20 or R77.30: Get the sync interface IP address and the cluster member ID
of the Active cluster member.
To check the cluster member's state and to get its IP address and the cluster member ID:
Run the cphaprob state command on the cluster member.

To upgrade a VSX cluster with more than two members:

1. Upgrade all of the cluster members with a clean install, except for the cluster member with
the lowest ID.
For more information about the clean install, see sk97552
http://supportcontent.checkpoint.com/solutions?id=sk97552.
Reboot the cluster members after the upgrade.
Note - In upgrades with dynamic routing synchronization, configure dynamic routing based on
the Known Limitations (on page 22).
2. On all of the upgraded cluster members, except one, run:
cpstop
3. On the one upgraded cluster member that is not stopped, run:
cphaprob state
Make sure this cluster member is in Ready state.
4. On the remaining cluster member that still runs the previous version, run:
cphaprob state
Make sure this cluster member is in Active or Active Attention state, and that all upgraded
members are in Down state.
5. On the one upgraded cluster member that is not stopped, run:
cphacu start <Sync IP of Active member> <Member ID of Active member>
For R80.10, R77.30DR and R77.20DR, run:
cphacu start [no_dr]
If dynamic routing synchronization is not required, use the no_dr option.
6. Make sure that the Connectivity Upgrade is complete. ("Making Sure the Upgrade Completed"
on page 18)

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 13

 Upgrading a VSX Cluster with More Than 2 Members

7. On the cluster member that still runs the previous version, run:
a) vsenv 0
b) fwaccel off -a
c) fwaccel stat -a
Make sure SecureXL is disabled (off). This is required to synchronize delayed connections.
d) cpstop
8. On the one upgraded cluster member that is not stopped, run
a) cphaprob state
Make sure this cluster member is in Active state.
b) cphacu stat
Make sure this cluster member monitors the traffic.
c) cphacu stop
9. On all the upgraded cluster members that were stopped, run:
cpstart
10. Upgrade the remaining cluster member that still runs the previous version with a clean install.
For more information about the clean install, see sk97552
http://supportcontent.checkpoint.com/solutions?id=sk97552.
Reboot the cluster members after the upgrade.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 14

CHAPTE R 7

Upgrading a VRRP Cluster

Connectivity Upgrade for VRRP clusters is supported for R80.10, R77.30DR and R77.20DR.
Dynamic Routing synchronization for VRRP is supported only on cluster members that run R77.30
and above.
Before you upgrade:
1. On both cluster members, in Gaia clish, run the show vrrp command.
Make sure that all the interfaces on one member are in VRRP Master state.
Make sure that all the interfaces on the other member are in VRRP Backup state.
2. Make sure that the VRRP interface priorities are higher on the VRRP Master member than on
the VRRP Backup member.
3. On the VRRP Master member, run the cphaprob list command.
Make sure there are no Critical Devices that report their state as problem.
4. On the VRRP Master member, enable the Monitor Firewall State feature (if not already
enabled) in one of these ways:
Where Instructions
In Gaia clish Run:
1. set vrrp monitor-firewall on
2. save config

Gaia WebUI Perform these steps:

1. Go to High Availability > VRRP page.
2. In the VRRP Global Settings section, enable Monitor
Firewall State.
3. Click Apply Global Settings.

Make sure that this cluster member is still the VRRP Master:

Where Instructions
In Gaia clish Run:
show vrrp summary

Gaia WebUI Perform these steps:

1. Go to High Availability > VRRP page.
2. In the upper right corner, click Monitoring.
3. In the VRRP Monitor section, select Summary.
4. Click Reload.
5. In the VRRP Summary section, examine the VRRP Router
State.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 15

 Upgrading a VRRP Cluster

To upgrade the VRRP cluster:

1. Upgrade the VRRP Backup member (See the Installation and Upgrade Guide for Gaia
Platforms).
Disable the preemptive mode (if it is enabled).
Reboot the cluster member after the upgrade.
Note - In upgrades to R80.10 with dynamic routing synchronization, configure the dynamic
routing based on the Known Limitations (on page 22).
2. In SmartDashboard:
a) Open the VRRP cluster object.
b) Change the cluster version to the upgraded one.
c) Click OK.
d) Click Install Policy.
e) In the Install Policy window > Installation Mode:
(i) Select Install on each selected gateway independently
(ii) Clear For Gateway Clusters install on all the members, if it fails do not install at all.
f) Install the security policy on this cluster.
Note - The policy successfully installs on the upgraded cluster member and fails to install on
the cluster member that still runs the previous version. This is expected, ignore the warning.
3. On the cluster member that still runs the previous version, run in Expert mode:
a) cphaprob state
Make sure that this cluster member is in Active or Active Attention state.
b) clish -c "show vrrp"
Make sure that all the interfaces on this cluster member are in VRRP Master state.
4. On the upgraded cluster member, run in Expert mode:
a) cphaprob state
Make sure that the cluster member is in Ready state.
b) clish -c "show vrrp"
Make sure that all the interfaces on this cluster member are in VRRP Backup state.
c) cphacu start [no_dr]
Add the no_dr to the command syntax only if dynamic routing synchronization is not
necessary.
d) cphacu stat
Make sure that the cluster member that still runs the previous version monitors the traffic.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 16

 Upgrading a VRRP Cluster

5. On the cluster member that still runs the previous version, run in Expert mode:
a) clish -c "show vrrp"
Make sure that this cluster member is in Active or Active Attention state.
b) fwaccel off
c) fwaccel stat
Make sure the SecureXL is disabled (off). This is required to synchronize delayed
connections.
d) cpstop
At this moment, the connections fail over to the upgraded cluster member.
6. On the upgraded cluster member, run in Expert mode:
a) cphaprob state
Make sure that the upgraded cluster member is in Active state.
b) clish -c "show vrrp"
Make sure that all the interfaces on this cluster member are in VRRP Master state.
c) cphacu stat
Make sure this cluster member monitors the traffic.
7. Upgrade the remaining cluster member that still runs the previous version.
• Reboot the cluster member after the upgrade.
• Make sure that the VRRP interface priorities are lower on this cluster that on the VRRP
Master member to prevent the possibility of unwanted failover.
8. In SmartDashboard, install policy on this cluster.
In the Install Policy window > Installation Mode, select Install on all selected gateways. If
installation fails. do not install on all gateways of the same version.
9. After the cluster upgrade is complete, the Cluster Control Protocol (CCP) runs is in broadcast
mode.
Change the CCP mode to multicast.
On all cluster members, run in Expert mode:
a) cphaconf set_ccp multicast
b) cphaprob state

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 17

CHAPTE R 8

Making Sure the Upgrade Completed

When the upgrade finishes, make sure that the CU script did not return errors, and that this
message shows:
Connectivity upgrade status: Ready for Failover

For Dynamic Routing synchronization on R80.10, R77.30DR, and R77.20DR: Make sure that the
dynamic routes on the new member (the upgraded cluster member) are similar to the routes on
the old member (the cluster member before the upgrade).
In Gaia clish, run: show route summary

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 18

CHAPTE R 9

Troubleshooting the Upgrade

Run cphacu stat to get more information after the CU is finished. See the Installation and
Upgrade Guide for Gaia Platforms for details.
If the script cphacu fails to run:
• Run cphaprob state to make sure that the new cluster member is in Ready state. If the
new cluster member is in Active state, then make sure that there is connectivity between
the cluster members.
• For upgrades to R77.20 or R77.30: Run cphaprob state and make sure that the ID of the
cluster member and its IP address match those of the old member.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 19

CHAPTE R 10

Connectivity Upgrade Error Messages

If any of these error messages are displayed in the connectivity upgrade script, contact Check
Point support and do not continue the CU.

Error Description
Failed to get kernel CU could not retrieve the kernel parameter, which can
parameter ### happen if CU is on the old member.

You must specify the Sync IP The user did not pass the sync IP and member ID to the
and the member Id of the old CU script.
member

Invalid IP address The IP address passed to the CU script is not in valid

format.

The member Id must be between An invalid member ID was passed to the CU script.
1-4

Only a single instance of The CU script is already running and the user is trying to
connectivity upgrade can run run CU again. Run ps to make sure that the CU script is
at a time
running and wait until CU finishes running.

Failed to get member state CU could not get the cluster state of the local member.
Run cphaprob on the local member and make sure that
the output shows the state of the local member.

Connectivity upgrade failed CU only runs if the state of the new member is Ready. CU
since the local member is not checks many times if the member is in Ready state, if the
in Ready state member is still not in Ready state then the CU script will
exit.

Connectivity upgrade failed For Security Gateways only: CU only runs if the
since Synchronization PNote Synchronization PNote is ok. CU checks many times if the
is set to problem Synchronization PNote is ok, and if not, the CU script will
exit. If you get this error, install policy and run the cphacu
script again.

Connectivity upgrade failed When CU starts, the two members begin to communicate,
because CPHAPROB cannot see and the new member sees the old member as Active.
the old member's state. Check communication on the sync interface, and make
sure that the MAC Magic Configuration is correct.

Failed to enable Connectivity CU could not update the kernel about the status of this
Upgrade kernel parameter.

Failed to get fwha_version This can happen if CU is run on a version that does not

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 20

 Connectivity Upgrade Error Messages

Error Description
Failed to get support CU.
fwha_cu_override_last_heard
_ccp_version of the other
member

Failed to get
fwha_cu_last_heard_ccp_vers
ion of the other member

Failed to initialize full CU failed to start a full sync, which synchronizes the
sync for VS ###; Connectivity connections from the old member to the new member.
Upgrade failed

Failed to run fullsync for VS The full sync was started but did not finish. This means
###; Connectivity Upgrade that some of the connections were not synchronized.
failed

Failed to run cphacu state for The script cphacu state failed to show the current state
VS ### of connectivity CU.

Error printing connections CU failed to print the connection table summary for each
table per vs VS.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 21

CHAPTE R 11

Known Limitations
Some features do not survive after failover to an upgraded cluster member:

General Failover Limitations

• Security Servers.
• Connections that are handled by the services that are marked as non-synced.
• Connections initiated by the cluster member itself.
• TCP connections with CPAS or PSL.
• If IPS is configured in SmartDashboard to Prefer Connectivity Over Security and the member
that owns the connections is down, then the connection is accepted without inspection.
Otherwise, the connection is dropped.
• For all other Software Blades, if the destination member is available, the connection is
forwarded to the member that owns the connection. If the destination member is not available,
the connection is dropped.
• In R77.30 and below: All member gateways must have the same number of CoreXL Firewall
instances. In R80.10: CU to a new member with a higher number of CoreXL Firewall instances
is supported.
• In R77.30 and below: All member gateway must run the same 32-bit or 64-bit kernel edition. In
R80.10: CU between member gateways with different kernel editions (32/64-bit) is supported.
For additional limitations related to general failover, see the section Check Point Software
Compatibility in the ClusterXL Administration Guide.

Limitations for Failover with CU

• Mobile Access VPN connections.
• Remote Access VPN connections.
• VPN Traditional Mode connections.
• Data Leak Prevention (DLP) connections.
• In upgrades to R77.20 or R77.30: Dynamic Routing connections.
• FTP Control connections with NAT.
• IPv6.
• Threat Emulation.
• When traffic passes through a VSX in Bridge mode, a connection might fail after the failover to
an upgraded member. Workaround: Set the value of Forward Delay parameter for Bridge
interface to 1 (one). See sk66531 https://supportcenter.checkpoint.com/solution?id=sk66531.
• If a session authenticated with Identity Awareness is open when you start Connectivity
Upgrade, the session is terminated.
• Connectivity Upgrade is supported only when CPU utilization is below 50%.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 22

 Known Limitations

• In upgrades to R80.10, R77.30DR and R77.20DR with dynamic routing synchronization:

• Dynamic routing synchronization is available only for cluster supported protocols. For
detailed information, refer to sk98226: Dynamic Routing and VRRP Features on Gaia OS
http://supportcontent.checkpoint.com/solutions?id=sk98226.
• For VRRP clusters, dynamic routing synchronization is supported for R77.30 versions and
higher.
• For VRRP clusters, configure OSPF Graceful Restart to keep dynamic routes during the
failover.
• Configure BGP graceful restart to keep BGP routes during failover.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 23

CHAPTE R 12

Other Upgrade Methods

Additional Cluster Upgrade methods:
• Simple Upgrade (with downtime) - This method is the simplest, because each cluster member
is upgraded as an independent Gateway. Select this option, if you have a period of time during
which network downtime is allowed.
• Zero Downtime - In this method there is always at least one active member that handles
traffic, keeping network connectivity during the upgrade. Connections that were initiated on a
cluster member running the old version are dropped, while connections initiated on an
upgraded cluster member remain active. Select this option if you cannot have any network
downtime, and need to complete the upgrade quickly, with a minimal number of dropped
connections.
• Optimal Service Upgrade (OSU) - During this type of upgrade, two cluster members process
network traffic. Connections that are initiated during the upgrade remain active throughout the
upgrade. A minimal number of connections that were initiated before the upgrade, get dropped
after the upgrade completes. Select this option, if security is of utmost concern.
For more information, see Upgrading ClusterXL Deployments in the Installation and Upgrade
Guide for Gaia Platforms.

Connectivity Upgrade Best Practices R77.x and R80.x Versions | 24