CP Cluster ConnectivityUpgrade BestPractices

2 April 2019
CONNECTIVITY UPGRADE
R77.X AND R80.X VERSIONS
Best Practices
Classification: [Protected]
CHAPTE R 1
2019 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 https://www.checkpoint.com/copyright/ for a list of our trademarks.
Refer to the Third Party copyright notices
https://www.checkpoint.com/about-us/third-party-trademarks-and-copyrights/ for a list of
relevant copyrights and third-party licenses.
Important Information
Latest Software
We recommend that you install the most recent software release to stay up-to-date
with the latest functional improvements, stability fixes, security enhancements and
protection against new and evolving attacks.
Certifications
For third party independent certification of Check Point products, see the Check
Point Certifications page.
More Information
Visit the Check Point Support Center.
Latest Version of this Document

Open the latest version of this document in a Web browser.
Download the latest version of this document in PDF format.
Feedback
Check Point is engaged in a continuous effort to improve its documentation.
Please help us by sending your comments.
Revision History
Date Description
02 April 2019 Improved formatting and document layout
28 March 2019 Updated:
• Connectivity Upgrade of a VSX Cluster (on page 20) - removed the
step "Stop the SecureXL"
• Connectivity Upgrade of a VRRP Cluster (on page 30) - removed the
step "Stop the SecureXL"
10 October 2018 Updated:
• Connectivity Upgrade Limitations (on page 10) - added "VPN
connections that originate from a DAIP Gateway, do not survive the
Connectivity Upgrade."
26 September 2018 Added:
• Support for R80.20
Updated:
• Connectivity Upgrade of a VSX Cluster (on page 20) - added the
"cphacu stop" command
27 August 2018 General Updates
05 August 2018 Updated:
• Other Upgrade Methods (on page 43)
19 July 2018 Updated:
• Upgrading a Security Gateway ClusterXL with 2 Members - improved
instructions
• Upgrading a Security Gateway ClusterXL with More Than 2 Members
(on page 12) - improved instructions
• Upgrading a VSX Cluster with 2 Members - instead of upgrade with a
clean install, use CPUSE
• Upgrading a VSX Cluster with More Than 2 Members (on page 20) -
instead of upgrade with a clean install, use CPUSE
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 ................................................................................................................... 6
Connectivity Upgrade Prerequisites.............................................................................. 7
Supported Versions for Connectivity Upgrade .............................................................. 8
Connectivity Upgrade Limitations ............................................................................... 10
Connectivity Upgrade of a Security Gateway Cluster .................................................. 12
Connectivity Upgrade of a VSX Cluster ........................................................................ 20
Connectivity Upgrade of a VRRP Cluster ..................................................................... 30
Troubleshooting the Connectivity Upgrade ................................................................. 40
Connectivity Upgrade Error Messages ........................................................................ 41
Other Cluster Upgrade Methods ................................................................................. 43
Backing Up and Restoring ........................................................................................... 44
CHAPTE R 2
Introduction
Important - Starting from R80.20, this guide is a part of the Installation and Upgrade Guide.
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 supports Dynamic Routing Synchronization when you upgrade to:
• R80.10 and above
• R77.30DR (R77.30 Jumbo Hotfix Take 198 and above)
• R77.20DR (R77.20 Jumbo Hotfix Take 198 and above)
Connectivity Upgrade Best Practices R77.x and R80.x Versions | 6

Connectivity Upgrade Prerequisites
Connectivity Upgrade Prerequisites

Important - Before you upgrade a cluster:
Step Description
1 Make sure that the cluster is configured in High Availability mode.
Make sure that one cluster member is in the Active state, and all other cluster members
are in the Standby state.
Run this command on each cluster member:
cphaprob state
2 Back up your current configuration (on page 44).

Important - If you upgrade a VSX cluster, then back up both the Management Server and
the VSX Cluster Members.
3 Upgrade the Management Server and Log Servers to the same version or above, to which
you wish to upgrade your cluster.
4 Schedule a full maintenance window to make sure you can make all the desired custom
configurations again after the upgrade.

Supported Versions for Connectivity Upgrade
Supported Versions for Connectivity

Upgrade
Check Point Connectivity Upgrade (CU) synchronizes existing connections to maintain connectivity
during cluster upgrades.
Connectivity Upgrade supports these releases:
Upgrade to version
Upgrade from version R77.20 R77.20DR R77.30 R77.30DR R80.10 R80.20 (*)
CU with
R80.10 x x x x x
DR
CU with CU with
R77.30DR x x x x
DR DR
CU with CU with
R77.30 x x x x
DR DR
CU with CU with CU with
R77.20DR x x CU
DR DR DR
R77.20 x x CU
DR DR DR
R77.10 x x CU
DR DR DR
R77 x x CU
DR DR DR
CU with CU with CU with CU with
R76 CU CU
DR DR DR DR
R75.47 CU CU
DR DR DR DR
R75.46 CU CU
DR DR DR DR
R75.40VS CU CU
DR DR DR DR

Supported Versions for Connectivity Upgrade
Notes:
• For supported upgrade paths, see the Release Notes for the version, to which you wish to
upgrade.
• For upgrade action plans, during which the Dynamic Routing information is synchronized, see
sk107042.
• "R77.20DR" denotes R77.20 with Take 200 (or higher) of R77.20 Jumbo Hotfix Accumulator.
• "R77.30DR" denotes R77.30 with Take 198 (or higher) of R77.30 Jumbo Hotfix Accumulator.
• "x" denotes that such upgrade path is not supported.
• "CU" denotes Connectivity Upgrade, during which the Dynamic Routing information is not
synchronized.
• "CU with DR" denotes Connectivity Upgrade, during which the Dynamic Routing information is
synchronized.
• Notes for VRRP Clusters on Gaia:
• To upgrade a VRRP Cluster to R80.20 with the Connectivity Upgrade, you must install the
R80.20 Jumbo Hotfix Accumulator - Take 17 and above (to resolve PMTR-23850)
• Connectivity Upgrade without Dynamic Routing synchronization supports:
 upgrades to R80.20 and above
 upgrades to R80.10
 upgrades to "R77.30DR"
 upgrades to "R77.20DR"
• Connectivity Upgrade with Dynamic Routing synchronization supports only:
 upgrades from R80.10 to R80.20, and above
 upgrades from R77.30 to R80.10, and above

Connectivity Upgrade Limitations

Some connections and features do not survive after failover to an upgraded Cluster Member.
General Failover Limitations

• Security Servers do not survive failover.
• Connections that are handled by the Check Point services, in which the option Synchronize
connections on cluster is disabled, do not survive failover.
• Connections initiated by the Cluster Member itself, do not survive failover.
• TCP connections handled by the Check Point Active Streaming (CPAS) or Passive Streaming
Layer (PSL) mechanism do not survive failover.
• Connectivity Upgrade and connections handled by Software Blades:
• If IPS Software Blade in the cluster object (R77.X and lower) is configured to Prefer
connectivity, and the Cluster Member that owns the connections is Down, then the
connection is accepted without inspection. Otherwise, the Cluster Members drop the
connection.
• For all other Software Blades:
 If the destination Cluster Member is available, the connection is forwarded to the
Cluster Member that owns the connection.
 If the destination Cluster Member is not available, the Cluster Members drop the
connection.
• Connectivity Upgrade and CoreXL:
• CU to R80.10 or above: It is supported to perform CU with an upgraded Cluster Member
that has more CoreXL Firewall instances.
• CU to R77.30 or below: All Cluster Members must have the same number of CoreXL
Firewall instances.
• Connectivity Upgrade and Gaia kernel editions (32-bit and 64-bit):
• CU to R80.10 or above: It is supported to perform CU between Cluster Members with
different Gaia kernel editions (32-bit and 64-bit).
• CU to R77.30 or below: All Cluster Members must run the same 32-bit or 64-bit kernel
edition.
For additional limitations related to general failover, see the section Check Point Software
Compatibility in the ClusterXL Administration Guide.

Limitations for Failover during the Connectivity Upgrade

• Connectivity Upgrade is supported only when CPU utilization on Cluster Members is below
50%.
• Connectivity Upgrade to R77.20 or R77.30 only: Dynamic Routing connections do not survive
the Connectivity Upgrade.
• Mobile Access VPN connections do not survive the Connectivity Upgrade.
• Remote Access VPN connections do not survive the Connectivity Upgrade.
• VPN Traditional Mode connections do not survive the Connectivity Upgrade.
• Data Loss Prevention (DLP) connections do not survive the Connectivity Upgrade.
• FTP Control connections with NAT do not survive the Connectivity Upgrade.
• IPv6 connections do not survive the Connectivity Upgrade.
• Threat Emulation connections do not survive the Connectivity Upgrade.
• VPN connections that originate from a DAIP Gateway, do not survive the Connectivity Upgrade.
• When traffic passes through a VSX Cluster in Bridge mode, a connection might fail after the
cluster failover to an upgraded VSX Cluster Member.
Workaround: Set the value of the Forward Delay parameter for Bridge interface to 1 (one). See
sk66531.
• If a session that is authenticated with the Identity Awareness Software Blade is open when you
start the Connectivity Upgrade, the session is terminated.
• To upgrade a VRRP Cluster to R80.20 with the Connectivity Upgrade, you must install the
R80.20 Jumbo Hotfix Accumulator - Take 17 and above (to resolve PMTR-23850).
• In the Connectivity Upgrade with Dynamic Routing synchronization:
• CU to R77.20DR, R77.30DR, R80.10 or above: Dynamic Routing synchronization is available
only for cluster-supported protocols. For detailed information, refer to sk98226: Dynamic
Routing and VRRP Features on Gaia OS.
• Configure BGP graceful restart to keep BGP routes during failover.
• For VRRP Clusters, Dynamic Routing synchronization is supported only:
 from R80.10 to next versions
 from R77.30 to R80.10, and above
• For VRRP Clusters, configure OSPF Graceful Restart to keep dynamic routes during the
failover.

Connectivity Upgrade of a Security Gateway Cluster
Connectivity Upgrade of a Security

Gateway Cluster
Warning - The R80.20 ClusterXL does not support the Load Sharing mode (R80.20 Known
Limitation MB-30). If your ClusterXL R80.10 and lower works in the Load Sharing mode, then
before you upgrade it to R80.20, change the configuration to the High Availability mode and make
sure it works correctly.
The procedure below describes an example High Availability cluster with three members M1, M2
and M3. However, it can be used for clusters that consist of two or more members.
Cluster States General Upgrade Workflow

The cluster 1. Upgrade, or Clean Install the Standby cluster members M2 and M3.
member M1 is The cluster members M2 and M3 change their cluster state to Ready.
the Active The cluster member M1 changes its cluster state to Active(!).
member.
2. In SmartConsole, change the version of the cluster object to R80.20.
The cluster 3. Install the Access Control Policy on the upgraded cluster members M2 and
members M2 M3.
and M3 are
4. Stop all the upgraded cluster members (for example, M3), except one (for
Standby.
example, M2).
5. Start and finish the Connectivity Upgrade on the working upgraded cluster
member M2.
6. Perform a controlled cluster failover from the Active old cluster member M1
to the upgraded and synchronized cluster member M2.
7. The upgraded cluster member M2 changes its cluster state to Active.
8. Start the upgraded cluster members that were stopped (M3).
9. Upgrade, or Clean Install the old cluster member M1.
10. Install the Access Control Policy on the cluster object.
11. Cluster states of the members are: one is Active, others are Standby.
12. On each cluster member, change the CCP mode to Auto.

Step 1 of 19: Get the R80.20 image

Download the applicable R80.20 image from the R80.20 Home Page SK - CPUSE upgrade image,
or Clean Install image.
• If you plan to perform the upgrade in Gaia Portal, use this upgrade image from the computer,
on which you connect to Gaia Portal.
• If you plan to perform the upgrade in Gaia Clish, then transfer the upgrade image to the
current cluster members to some directory (for example,
/var/log/path_to_upgrade_image/). Make sure to transfer the file in the binary mode.
Step 2 of 19: On the Standby cluster member M2 - Upgrade to R80.20 with CPUSE, or
perform a Clean Install of R80.20
See these sections in the R80.20 Installation and Upgrade Guide:
• For upgrade instructions, see Upgrading a Security Gateway with CPUSE.
• For clean install instructions, see Installing a ClusterXL Cluster, or Installing a VRRP Cluster.
Notes:
• You must reboot the cluster member after the upgrade or clean install.
• Configure dynamic routing based on the Connectivity Upgrade Known Limitations (on page 10).
Step 3 of 19: On the Standby cluster member M3 - Upgrade to R80.20 with CPUSE, or
Notes:

Step 4 of 19: In SmartConsole - Modify the Cluster object and install the Access Control
Policy
Step Description
1 Connect with SmartConsole to the R80.20 Security Management Server or Domain
Management Server that manages this cluster.
2 From the left navigation panel, click Gateways & Servers.
3 Open the Cluster object.
4 From the left navigation tree, click the General Properties page.
5 In the Platform section > Version field, select R80.20.
6 Click OK.
7 Click Install Policy.
8 In the Install Policy window:

a) In the Policy field, select the applicable Access Control Policy
b) In the Install Mode section, configure these two options:
 Select Install on each selected gateway independently.
 Clear For gateway clusters, if installation on a cluster member fails, do not
install on that cluster.
c) Click Install.
9 The Access Control Policy successfully installs on the upgraded cluster members M2 and
M3.
The Access Control Policy installation fails on the old cluster member M1 with a warning.
Ignore this warning.
Step 5 of 19: On each cluster member - Examine the cluster state

Step Description
1 Connect to the command line on each cluster member.
2 Examine the cluster state:

• In Gaia Clish (R80.20 and above), run:
show cluster state
• In Expert mode, run:
cphaprob state
Notes:
• The cluster states of the upgraded members M2 and M3 are Ready.
• The cluster state of the old member M1 is Active(!).

Step 6 of 19: Stop all, except one, of the upgraded Standby cluster members
Step Description
1 Connect to the command line on all the upgraded cluster members (for example, M3),
except one (for example, M2).
2 Stop all Check Point services on all the upgraded members (for example, M3), except one
(for example, M2):
cpstop

Step Description

show cluster state
cphaprob state
Notes:
• The cluster state of the working upgraded member (M2) is Ready.
• The cluster state of the stopped upgraded members (M3) is HA not started.
Step 8 of 19: On the working upgraded cluster member - Start the Connectivity Upgrade
Step Description
1 Connect to the command line on the working upgraded cluster member M2.
2 Log in to the Expert mode.
3 Start the Connectivity Upgrade:

• If you wish to synchronize the dynamic routing information during the upgrade:
cphacu start
• If you do not wish to synchronize the dynamic routing information during the upgrade:
cphacu start no_dr

Step 9 of 19: On the old cluster member - Make sure it handles the traffic
Step Description
1 Connect to the command line on the Active old cluster member M1.
3 Make sure it handles the traffic:

cphacu stat
Step 10 of 19: On the working upgraded cluster member - Make sure the Connectivity
Upgrade is complete
Step Description
1 When the Connectivity Upgrade finishes on the working upgraded cluster member M2, this
message shows:
Connectivity upgrade status: Ready for Failover
2 If you synchronized the Dynamic Routing information:

a) Connect to the command line on both the working upgraded cluster member M2
and on the Active old cluster member M1.
b) Log in to Gaia Clish.
c) Examine the routes:
show route summary
Make sure that the dynamic routes on the working upgraded cluster member M2 match
the dynamic routes on the Active old cluster member M1.
Step 11 of 19: On the stopped upgraded cluster member - Start all Check Point services
Step Description
1 Connect to the command line on the stopped upgraded cluster members (in our example,
M3).
2 Start all Check Point services:

cpstart


Step Description

show cluster state
cphaprob state
Notes:
• The cluster states of the upgraded members M2 and M3 are Down.
Step 13 of 19: On the Active old cluster member - Stop all Check Point services
Step Description
1 Connect to the command line on the Active old cluster member M1.
2 Stop all Check Point services:

cpstop
Important - At this moment, the connections fail over from the old cluster member M1 to
the Active upgraded cluster member (M2 or M3).
Step 14 of 19: On the upgraded cluster members - Examine the cluster state and make
sure the Active handles the traffic
Step Description
1 Connect to the command line on the upgraded cluster members M2 and M3.

show cluster state
cphaprob state
Notes:
• The cluster states of the upgraded members M2 and M3 are: one is Active, the other is
Standby.
• The cluster state of the old member M1 is either ClusterXL is inactive, or the machine
is down, or Down.
3 Make sure the Active upgraded member handles the traffic:
cphacu stat

Step 15 of 19: On the former Active old cluster member - Upgrade to R80.20 with
CPUSE, or perform a Clean Install of R80.20
Notes:
Step 16 of 19: In SmartConsole - Install the Access Control Policy

Step Description

b) In the Install Mode section, select these two options:
 Install on each selected gateway independently
 For gateway clusters, if installation on a cluster member fails, do not install
on that cluster
c) Click Install.
5 The Access Control Policy successfully installs on all the cluster members.

Step Description

• In Gaia Clish, run:
show cluster state
cphaprob state
Note - Cluster states of the members are: one is Active, others are Standby.

Step 18 of 19: On each cluster member - Change the CCP mode to Auto
Step Description
2 Change the CCP mode:

set cluster member ccp auto
save config
cphaconf set_ccp auto
Notes:
• This change does not require a reboot.
• This change applies immediately and survives reboot.
3 Make sure the CCP mode is set to Auto:
show cluster members interfaces all
cphaprob -a if
Step 19 of 19: Test the functionality

Step Description
2 From the left navigation panel, click Logs & Monitor > Logs.
3 Examine the logs from this Cluster to make sure it inspects the traffic as expected.
For more information:

See the R80.20 ClusterXL Administration Guide.

Connectivity Upgrade of a VSX Cluster

The procedure below describes an example VSX Cluster with three members M1, M2 and M3.
However, it can be used for clusters that consist of two or more members.

The cluster 1. On the Management Server - upgrade the configuration of the VSX Cluster
member M1 object to R80.20.
has the lowest 2. Upgrade, or Clean Install the Standby VSX Cluster Members M2 and M3.
Cluster The VSX Cluster Members M2 and M3 change their cluster state to Ready.
Member ID and
The VSX Cluster Member M1 changes its cluster state to Active(!).
is the Active
member. 3. From the Management Server, reconfigure the Standby VSX Cluster
Members M2 and M3.
The cluster
4. Stop all the upgraded VSX Cluster Members (for example, M3), except one
members M2
(for example, M2).
and M3 are
Standby. 5. Start and finish the Connectivity Upgrade on the working upgraded VSX
Cluster Member M2.
6. Perform a controlled cluster failover from the Active old VSX Cluster
Member M1 to the upgraded and synchronized VSX Cluster Member M2.
7. The upgraded VSX Cluster Member M2 changes its cluster state to Active.
8. Start the upgraded VSX Cluster Members that were stopped (M3).
9. Upgrade, or Clean Install the old VSX Cluster Member M1.
10. From the Management Server, reconfigure the VSX Cluster Member M1.
11. Cluster states of the members are: one is Active, others are Standby.

Step 1 of 20: On the Management Server - Upgrade the configuration of the VSX Cluster
object to R80.20
Step Description
1 Connect to the command line on the Security Management Server or Multi-Domain Server
that manages this VSX Cluster.
3 On a Multi-Domain Server, switch to the context of the Main Domain Management Server
that manages this VSX Cluster object:
mdsenv <IP Address or Name of Main Domain Management Server>
4 Upgrade the configuration of the VSX Cluster object to R80.20:
4A Run:
vsx_util upgrade
This command is interactive.
4B Enter these details to log in to the management database:

• IP address of the Security Management Server or Main Domain Management Server
that manages this VSX Gateway
• Management Server administrator's username
• Management Server administrator's password
4C Select your VSX Cluster.
4D Select the R80.20.
4E For auditing purposes, save the vsx_util log file:

• On a Security Management Server:
/opt/CPsuite-R80.20/fw1/log/vsx_util_YYYYMMDD_HH_MM.log
• On a Multi-Domain Server:
/opt/CPmds-R80.20/customers/<Name_of_Domain>/CPsuite-R80.20/fw1/l
og/vsx_util_YYYYMMDD_HH_MM.log
5 Connect with SmartConsole to the R80.20 Security Management Server or Main Domain
Management Server that manages this VSX Cluster.
7 Open the VSX Cluster object.
9 Make sure in the Platform section, the Version field shows R80.20.
10 Click Cancel (do not click OK).


Step Description
1 Download the applicable R80.20 image from the R80.20 Home Page SK - CPUSE upgrade
image, or Clean Install image.
2 Transfer the upgrade image to the current VSX Cluster Members to some directory (for
example, /var/log/path_to_upgrade_image/).
Note - Make sure to transfer the file in the binary mode.
Step 3 of 20: On each VSX Cluster Member - Examine the cluster state and get the
Cluster Member IDs
Step Description
1 Connect to the command line on each VSX Cluster Member.

vsenv 0
cphaprob state
Identify the VSX Cluster Member with the lowest Cluster Member ID.
Step 4 of 20: On all VSX Cluster Members with higher Cluster Member IDs - Upgrade to
R80.20 with CPUSE, or perform a Clean Install of R80.20
Upgrade or perform Clean Install on all of the VSX Cluster Members (in our example, M2 and M3),
except for the VSX Cluster Member with the lowest Cluster Member ID (in our example, M1).
• For upgrade instructions (recommended), see Upgrading a VSX Gateway with CPUSE.
Note that you already upgraded the configuration of the VSX Cluster object to R80.20.
• For clean install instructions, see Installing a VSX Cluster.
Notes:
• You must reboot the VSX Cluster Member after the upgrade or clean install.
• Configure dynamic routing based on the Connectivity Upgrade Limitations (on page 10).


Step Description

a) In the Policy field, select the applicable Access Control Policy that is called:
<Name_of_VSX_Cluster_object>_VSX
c) Click Install.
5 The Access Control Policy successfully installs on the upgraded VSX Cluster Members M2
and M3.
The Access Control Policy installation fails on the old VSX Cluster Member M1 with a
warning. Ignore this warning.
Step 6 of 20: On each VSX Cluster Member - Examine the cluster state
Step Description

set virtual-system 0
show cluster state
vsenv 0
cphaprob state
Notes:
• The cluster states of the upgraded members M2 and M3 are Ready.

Step 7 of 20: Stop all, except one, of the upgraded VSX Cluster Members
Step Description
1 Connect to the command line on all the upgraded VSX Cluster Members M2 and M3.
2 Stop all Check Point services on all upgraded members (for example, M3), except one (for
example, M2):
cpstop
Step Description

show cluster state
vsenv 0
cphaprob state
Notes:
• The cluster state of the working upgraded member M2 is Ready.
• The cluster state of the stopped upgraded members M3 is HA not started.
Step 9 of 20: On the working upgraded VSX Cluster Member - Start the Connectivity
Upgrade
Step Description
1 Connect to the command line on the working upgraded VSX Cluster Member M2.

cphacu start
cphacu start no_dr

Step 10 of 20: On the old VSX Cluster Member - Make sure it handles the traffic
Step Description
1 Connect to the command line on the Active old VSX Cluster Member M1.

cphacu stat
Step 11 of 20: On the working upgraded VSX Cluster Member - Make sure the
Connectivity Upgrade is complete
Step Description
1 When the Connectivity Upgrade finishes on the working upgraded VSX Cluster Member M2,
this message shows:

a) Connect to the command line on both the working upgraded VSX Cluster Member
M2 and on the Active old VSX Cluster Member M1.
c) Examine the routes in each applicable Virtual System:
set virtual-system <VSID>
show route summary
Make sure that the dynamic routes on the working upgraded VSX Cluster Member M2
match the dynamic routes on the Active old VSX Cluster Member M1.
Step 12 of 20: On the stopped upgraded VSX Cluster Members - Start all Check Point
services
Step Description
1 Connect to the command line on the stopped upgraded VSX Cluster Members (in our
example, M3).
2 Start all Check Point services:

cpstart

Step Description

show cluster state
vsenv 0
cphaprob state
Notes:
• The cluster states of the upgraded members M2 and M3 are Down.
Step 14 of 20: On the Active old VSX Cluster Member - Stop all Check Point services
Step Description
1 Connect to the command line on the Active old VSX Cluster Member M1.

cpstop
Important - At this moment, the connections fail over from the old VSX Cluster Member
M1 to the Active upgraded VSX Cluster Member (M2 or M3).

Step 15 of 20: On the upgraded VSX Cluster Members - Examine the cluster state and
make sure the Active handles the traffic
Step Description
1 Connect to the command line on the upgraded VSX Cluster Members M2 and M3.

show cluster state
vsenv 0
cphaprob state
Notes:
• The cluster states of the upgraded members M2 and M3 are: one is Active, the other is
Standby.
• The cluster state of the old member M1 is either ClusterXL is inactive, or the machine
is down, or Down.
3 Make sure the Active upgraded member handles the traffic:
cphacu stat
Step 16 of 20: On the former Active old VSX Cluster Member - Upgrade to R80.20 with
CPUSE, or perform a Clean Install of R80.20
• For upgrade instructions, see Upgrading a VSX Gateway with CPUSE.
Note that you already upgraded the configuration of the VSX Cluster object to R80.20.
• For clean install instructions, see Installing a Security Gateway.
Notes:
• You must reboot the VSX Cluster Member after the upgrade or clean install.


Step Description

a) In the Policy field, select the applicable Access Control Policy that is called:
<Name_of_VSX_Cluster_object>_VSX
on that cluster
c) Click Install.
5 The Access Control Policy successfully installs on all the VSX Cluster Members.
Step Description

show cluster state
vsenv 0
cphaprob state
Note - Cluster states of the members are: one is Active, others are Standby.

Step 19 of 20: On each VSX Cluster Member - Change the CCP mode to Auto
Step Description

save config
vsenv 0
Notes:
cphaprob -a if

Step Description
3 Examine the logs from Virtual Systems on this VSX Cluster to make sure they inspect the
traffic as expected.
For more information, see the:

• R80.20 ClusterXL Administration Guide.
• R80.20 VSX Administration Guide.

Connectivity Upgrade of a VRRP Cluster

Notes for VRRP Clusters on Gaia:
• VRRP Clusters support only two cluster members.
• Connectivity Upgrade without Dynamic Routing synchronization supports upgrades:
• from R7x to R80.20 and above
• from R7x to R80.10
• from R7x to "R77.30DR"
• from R7x to "R77.20DR"
• Connectivity Upgrade with Dynamic Routing synchronization supports upgrades only:
• from R80.10 to R80.20, and above
• from R77.30 to R80.10, and above
• You must install the R80.20 Jumbo Hotfix Accumulator - Take 17 and above (to resolve
PMTR-23850)
The procedure below describes an example VRRP Cluster with two members M1 and M2.

The cluster 1. Make sure the VRRP states are correct.
member M1 is 2. On the VRRP Master cluster member M1, enable the Monitor Firewall State
the VRRP feature.
Master. 3. Upgrade, or Clean Install the VRRP Backup cluster member M2.
The cluster The upgraded VRRP Cluster Member M2 changes its cluster state to Ready.
member M2 is The old cluster member M1 (VRRP Master) changes its cluster state to
the VRRP Active(!).
Backup.
4. Install the R80.20 Jumbo Hotfix Accumulator on the upgraded VRRP Cluster
Member M2.
5. In SmartConsole, change the version of the VRRP Cluster object to R80.20.
6. Install the Access Control Policy on the upgraded VRRP Cluster Member M2.
7. Start and finish the Connectivity Upgrade on the upgraded VRRP Cluster
Member M2.
8. Perform a controlled cluster failover from the old VRRP Cluster Member M1
(VRRP Master) to the upgraded and synchronized VRRP Cluster Member M2.
9. The upgraded VRRP Cluster Member M2 changes its cluster state to Active.
10. Upgrade, or Clean Install the old VRRP Cluster Member M1.
11. Install the R80.20 Jumbo Hotfix Accumulator on the upgraded VRRP Cluster
Member M1.
12. Install the Access Control Policy on the VRRP Cluster object.
13. Cluster states of the members are: one is VRRP Master, the other is VRRP
Backup.

Step 1 of 24: On each VRRP Cluster Member - Examine the VRRP state
Step Description
1 Connect to the command line on each VRRP Cluster Member.
2 Log in to Gaia Clish.
3 Examine the VRRP state:

show vrrp
Notes:
• Make sure that all the interfaces on one member are in the VRRP Master state.
• Make sure that all the interfaces on the other member are in the VRRP Backup state.
• Make sure that the VRRP interface priorities are higher on the VRRP Master member
than on the VRRP Backup member.
Step 2 of 24: On the VRRP Master cluster member M1 - Examine the Critical Devices
Step Description
2 Log in to Gaia Clish, or Expert mode.
3 Examine the Critical Devices:

cphaprob list
Make sure there are no Critical Devices that report their state as problem.
Step 3 of 24: On the VRRP Master cluster member M1 - Enable the Monitor Firewall
State feature
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 Portal Perform these steps:

1. From the left navigation tree, click High Availability > VRRP.
2. In the VRRP Global Settings section, enable Monitor Firewall State.
3. Click Apply Global Settings.

Step 4 of 24: On the VRRP Master cluster member M1 - Make sure it is still the VRRP
Master:
Where Instructions
In Gaia Clish Run:
show vrrp summary
Gaia Portal Perform these steps:

1. From the left navigation tree, click 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.

Download the applicable R80.20 image from the R80.20 Home Page SK - CPUSE upgrade image,
or Clean Install image.
• If you plan to perform the upgrade in Gaia Portal, use this upgrade image from the computer,
on which you connect to Gaia Portal.
• If you plan to perform the upgrade in Gaia Clish, then transfer the upgrade image to the
current cluster members to some directory (for example,
/var/log/path_to_upgrade_image/). Make sure to transfer the file in the binary mode.
Step 6 of 24: On the VRRP Backup cluster member M2 - Upgrade to R80.20 with CPUSE,
or perform a Clean Install of R80.20
• For upgrade instructions, see Upgrading a Security Gateway with CPUSE
• For clean install instructions, see Installing a VRRP Cluster.
Notes:
• You must disable the preemptive mode (if it is enabled).
Step 7 of 24: On the upgraded VRRP Cluster Member M2 - Install the R80.20 Jumbo
Hotfix Accumulator
You must install Take 17 and above. Follow the instructions in sk137592.

Step 8 of 24: In SmartConsole - Modify the Cluster object and install the Access Control
Policy
Step Description
Management Server that manages this VRRP Cluster.
3 Open the VRRP Cluster object.
5 In the Platform section > Version field, select R80.20.
6 Click OK.

c) Click Install.
9 The Access Control Policy successfully installs on the upgraded cluster member M2.
The Access Control Policy installation fails on the old cluster member M1 with a warning.
Ignore this warning.
Step 9 of 24: On each VRRP Cluster Member - Examine the cluster state
Step Description

show cluster state
cphaprob state
Notes:
• The cluster state of the upgraded VRRP Cluster Member M2 is Ready.
• The cluster state of the old VRRP Cluster Member M1 is Active(!).

Step Description

show vrrp
Notes:
• Make sure that all the interfaces on the old VRRP Cluster Member are in the VRRP
Master state.
• Make sure that all the interfaces on the upgraded VRRP Cluster Member are in the
VRRP Backup state.
Step 11 of 24: On the upgraded VRRP Cluster Member M2 - Start the Connectivity
Upgrade
Step Description
1 Connect to the command line on the upgraded VRRP Cluster Member M2.

cphacu start
cphacu start no_dr
Step 12 of 24: On the old VRRP Cluster Member M1 - Make sure it handles the traffic
Step Description
1 Connect to the command line on the old VRRP Cluster Member M1.

cphacu stat

Step 13 of 24: On the upgraded VRRP Cluster Member M2 - Make sure the Connectivity
Upgrade is complete
Step Description
1 When the Connectivity Upgrade finishes on the upgraded VRRP Cluster Member M2, this
message shows:

a) Connect to the command line on both the upgraded VRRP Cluster Member M2 and
on the old VRRP Cluster Member M1.
c) Examine the routes:
show route summary
Make sure that the dynamic routes on the upgraded VRRP Cluster Member M2 match the
dynamic routes on the old VRRP Cluster Member M1.
Step Description

show cluster state
cphaprob state
Notes:
• The cluster state of the upgraded VRRP Cluster Member M2 is Down.
• The cluster state of the old VRRP Cluster Member M1 is Active(!).

Step Description

show vrrp
Notes:
• Make sure that all the interfaces on the upgraded VRRP Cluster Member are in the
VRRP Master state.
• Make sure that all the interfaces on the old VRRP Cluster Member are in the VRRP
Backup state.
• Make sure that the VRRP interface priorities on the old VRRP Cluster Member are
lower than on the upgraded VRRP Cluster Member. This helps prevent the possibility of
unwanted failover.
Step 16 of 24: On the old VRRP Cluster Member M1 - Stop all Check Point services
Step Description
1 Connect to the command line on the old VRRP Cluster Member M1.

cpstop
Important - At this moment, the connections fail over from the old VRRP Cluster Member
M1 to the upgraded VRRP Cluster Member M2.
Step 17 of 24: On the upgraded VRRP Cluster Member M2 - Examine the cluster state
and make sure it handles the traffic
Step Description
1 Connect to the command line on the upgraded VRRP Cluster Member M2.

show cluster state
cphaprob state
Notes:
• The cluster state of the upgraded VRRP Cluster Member M2 is Active.
• The cluster state of the old VRRP Cluster Member M1 is either ClusterXL is inactive,
or the machine is down, or Down.
3 Make sure the upgraded VRRP Cluster Member handles the traffic:
cphacu stat

Step 18 of 24: On the old VRRP Cluster Member M1 - Upgrade to R80.20 with CPUSE, or
• For clean install instructions, see Installing a VRRP Cluster.
Notes:
Step 19 of 24: On the upgraded VRRP Cluster Member M1 - Install the R80.20 Jumbo
Hotfix Accumulator
You must install Take 17 and above.
You must install the same Take you installed on the VRRP Cluster Member M2.
Follow the instructions in sk137592.

Step Description

on that cluster
c) Click Install.
5 The Access Control Policy successfully installs on all the cluster members.

Step Description

show cluster state
cphaprob state
Note - Cluster states of the VRRP Cluster Members are: one is Active, the other is
Standby.
Step Description

show vrrp
Notes:
• Make sure that all the interfaces on one VRRP Cluster Member are in the VRRP Master
state.
• Make sure that all the interfaces on the other VRRP Cluster Member are in the VRRP
Backup state.

Step 23 of 24: On each VRRP Cluster Member - Change the CCP mode to Auto
Step Description

save config
Notes:
cphaprob -a if

Step Description
3 Examine the logs from this VRRP Cluster to make sure it inspects the traffic as expected.
For more information:

See the R80.20 ClusterXL Administration Guide.

Troubleshooting the Connectivity Upgrade
Troubleshooting the Connectivity

Upgrade
Run the cphacu stat command in the Expert mode to get more information after the CU is
finished.
If the script cphacu fails, run the cphaprob state command. Make sure that the upgraded
Cluster Members are in the Ready state. If the upgraded Cluster Members are in the Active state,
make sure that there is a physical connectivity and traffic (for example, pings) can pass between
the Cluster Members.

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 parameter ### CU could not retrieve the kernel parameter,
which can happen if CU is on the old Cluster
Member.
You must specify the Sync IP and the The user did not pass the sync IP and Cluster
member Id of the old member Member ID to the CU script.
Invalid IP address The IP address passed to the CU script is not in
valid format.
The member Id must be between 1-4 An invalid Cluster Member ID was passed to the
CU script.
Only a single instance of The CU script is already running, and the user
connectivity upgrade can run at a time is trying to run CU again.
Run the ps auxw | cphacu command to make
sure that the CU script is running and wait until
CU finishes running.
Failed to get member state CU could not get the cluster state of the local
Cluster Member.
Run cphaprob state command on the local
Cluster Member and make sure that the output
shows the state of the local Cluster Member.
Connectivity upgrade failed since the CU only runs, if the state of the new Cluster
local member is not in Ready state Member is in the Ready state.
CU examines many times, if the Cluster
Member is in the Ready state.
If the Cluster Member is still not in the Ready
state, then the CU script exits.
Connectivity upgrade failed since For Security Gateways only: CU only runs, if the
Synchronization PNote is set to Critical Device Synchronization reports its state
problem
as OK.
CU examines many times, if the Critical Device
Synchronization reports its state as OK.
If the Critical Device Synchronization reports
its state as PROBLEM, then the CU script exits.
If you get this error, install policy on this cluster
and run the cphacu script again.

Error Description
Connectivity upgrade failed because When CU starts, the two Cluster Members
CPHAPROB cannot see the old member's begin to communicate, and the new Cluster
state. Member sees the old Cluster Member as
Active.
Check communication on the Sync interface,
and make sure that the MAC Magic
Configuration is correct.
Failed to enable Connectivity Upgrade CU could not update the kernel about the status
of this kernel parameter.
Failed to get fwha_version
Failed to get This can happen, if you run CU on a version that
fwha_cu_override_last_heard_ccp_ver does not support CU.
sion of the other member
Failed to get
fwha_cu_last_heard_ccp_version of
the other member
Failed to initialize full sync for VS CU failed to start a Full Sync for this Virtual
###; Connectivity Upgrade failed System, which synchronizes the connections
from the old Cluster Member to the new
Cluster Member.
Failed to run fullsync for VS ###; The Full Sync started, but did not finish for this
Connectivity Upgrade failed Virtual System.
This means that some of the connections were
not synchronized.
Failed to run cphacu state for VS ### The script cphacu state failed to show the
current CU state for this Virtual System.
Error printing connections table per CU failed to print the connection table summary
vs for each Virtual System.

Other Cluster Upgrade Methods
Other Cluster Upgrade Methods

Additional cluster upgrade methods are:
Upgrade Method Description

Minimal Effort Select this method, if you have a period of time, during which network
Upgrade 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).
Zero Downtime 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 3rd party cluster (VRRP on Gaia).
Optimal Service Select this method, if security is of utmost concern.
Upgrade (OSU) 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.
This method does not support a 3rd party cluster (VRRP on Gaia).
For more information, see the Installation and Upgrade Guide for the version, to which you wish
to upgrade.

Backing Up and Restoring

Best Practices:
Step Description
1 Before the upgrade:
• Save a snapshot of your source system.
This backs up the entire configuration.
• Save a backup of your source system.
This file lets you extract the most important configuration easily.
• Collect the CPinfo file from your source system (see sk92739).
This file lets you see the most important configuration easily with the DiagnosticsView
tool (see sk125092).
2 Immediately after the Pre-Upgrade Verifier (PUV) finishes successfully and does not show
you further suggestions:
• Save a second snapshot of your source system.
• Save a second backup of your source system.
• Collect a second CPinfo file from your source system.
3 Transfer the CPinfo file, snapshot, backup files, and exported database files to external
storage devices. Make sure to transfer the files in the binary mode.
For more information, see:

1. sk108902: Best Practices - Backup on Gaia OS
2. Gaia Administration Guide (see the Documentation section in the Home Page SK for your
current version)
3. sk54100: How to back up your system on SecurePlatform
4. SecurePlatform Administration Guide (see the Documentation section in the Home Page SK
for your current version)
5. Multi-Domain Security Management Administration Guide (see the Documentation section in
the Home Page SK for your current version) - Chapter Command Line Reference - Section
mds_backup
6. Command Line Interface Reference Guide (R77 versions, R80.20) - migrate command.
7. sk110173: How to migrate the events database from SmartEvent server R7x to SmartEvent
R80 and above server.
8. sk100395: How to backup and restore VSX gateway.

To back up a Security Management Server:

Operating Backup Recommendations
System
Gaia 1. Take the Gaia snapshot.
2. Collect the backup with the migrate export command.
SecurePlatfor 1. Take the SecurePlatform snapshot.

m 2. Collect the backup with the migrate export command.
Linux Collect the backup with the migrate export command.
Windows Collect the backup with the migrate export command.
To back up a Multi-Domain Server:

System
Gaia 1. Take the Gaia snapshot.
2. Collect the full backup with the mds_backup command.
SecurePlatfor 1. Take the SecurePlatform snapshot.

m 2. Collect the full backup with the mds_backup command.
Linux Collect the full backup with the mds_backup command.
To back up a Security Gateway or a Cluster Member:

System
Gaia Take the Gaia snapshot.
To back up a VSX environment:

Follow sk100395: How to backup and restore VSX gateway.

CP Cluster ConnectivityUpgrade BestPractices

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CP Cluster ConnectivityUpgrade BestPractices

Caricato da

Copyright:

Formati disponibili

2 April 2019

R77.X AND R80.X VERSIONS

2019 Check Point Software Technologies Ltd.

Latest Version of this Document

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

Connectivity Upgrade Prerequisites

2 Back up your current configuration (on page 44).

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

Supported Versions for Connectivity

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

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

Connectivity Upgrade Limitations

General Failover Limitations

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

Limitations for Failover during the Connectivity Upgrade

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

Connectivity Upgrade of a Security

Cluster States General Upgrade Workflow

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

Step 1 of 19: Get the R80.20 image

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

2 From the left navigation panel, click Gateways & Servers.

3 Open the Cluster object.

5 In the Platform section > Version field, select R80.20.

7 Click Install Policy.

8 In the Install Policy window:

Step 5 of 19: On each cluster member - Examine the cluster state

2 Examine the cluster state:

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

Step 7 of 19: On each cluster member - Examine the cluster state

2 Examine the cluster state:

2 Log in to the Expert mode.

3 Start the Connectivity Upgrade:

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

2 Log in to the Expert mode.

3 Make sure it handles the traffic:

2 If you synchronized the Dynamic Routing information:

2 Start all Check Point services:

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

Step 12 of 19: On each cluster member - Examine the cluster state

2 Examine the cluster state:

2 Stop all Check Point services:

2 Examine the cluster state:

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

Step 16 of 19: In SmartConsole - Install the Access Control Policy

2 From the left navigation panel, click Gateways & Servers.

3 Click Install Policy.

4 In the Install Policy window:

Step 17 of 19: On each cluster member - Examine the cluster state

2 Examine the cluster state:

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

2 Change the CCP mode:

Step 19 of 19: Test the functionality

For more information:

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

Connectivity Upgrade of a VSX Cluster

Cluster States General Upgrade Workflow

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

2 Log in to the Expert mode.

4 Upgrade the configuration of the VSX Cluster object to R80.20:

4B Enter these details to log in to the management database:

4D Select the R80.20.

4E For auditing purposes, save the vsx_util log file:

6 From the left navigation panel, click Gateways & Servers.