CP CU BestPractices

24 January 2017
Connectivity Upgrade
R77.x and R80.x Versions
Best Practices
Classification: [Protected]
© 2017 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:cp_techpub_feedback@checkpoint.com?subject=Feedback on Connectivity
Upgrade R77.x and R80.x Versions Best Practices.
Revision History
Date Description
24 January 2017 Dynamic Routing support and minor improvements
30 December 2015 First release of this document

Contents
Important Information................................................................................................... 3
Introduction ................................................................................................................... 5
Supported Versions ....................................................................................................... 5
Upgrading a Security Gateway ClusterXL ..................................................................... 6
Upgrading a VSX ClusterXL ........................................................................................... 7
Upgrading a Security Gateway ClusterXL with More Than 2 Members ......................... 8
Upgrading a VSX ClusterXL with More Than 2 Members ............................................ 10
Upgrading a VRRP Cluster .......................................................................................... 11
Making Sure the Upgrade Completed ......................................................................... 13
Troubleshooting the Upgrade ..................................................................................... 13
Connectivity Upgrade Error Messages ........................................................................ 13
Limitations .................................................................................................................. 14
Other Upgrade Methods .............................................................................................. 16
Introduction
Introduction
NEW! Cluster Connectivity Upgrade supports Dynamic Routing Synchronization in R80.10, in
R77.30DR (R77.30 Jumbo Hotfix Take 198 and higher), and in R77.20DR (R77.20 Jumbo Hotfix Take
198 and higher).
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.
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
Note:
• 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 | 5

Upgrading a Security Gateway ClusterXL
Upgrading a Security Gateway

ClusterXL
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 stat 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 gateway after the upgrade.
Note - In upgrades with dynamic routing synchronization, configure dynamic routing based on
the known limitations ("Limitations" on page 14).
2. In SmartDashboard:
a) In the Gateway Cluster General Properties window, change the Cluster version to the
upgraded one.
b) In the Install Policy window, go to the Installation Mode area > select Install on each
selected gateway independently and clear For Gateway Clusters install on all the
members, if it fails do not install at all.
c) 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 the Active cluster member, run: cphaprob stat
Make sure the state 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 .
4. On the upgraded cluster member, run these commands:
a) cphaprob stat
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 handles the traffic.

Upgrading a VSX ClusterXL
5. Make sure that the Connectivity Upgrade is complete. ("Making Sure the Upgrade Completed"
on page 13)
6. On the Active cluster member, run these commands:
a) cphaprob stat
Make sure the local member is in Active or Active Attention state, and the upgraded
member is in Down state.
b) fwaccel off
Disable acceleration in order to synchronize delayed connections (templates).
c) cpstop
The connections fail over to the upgraded cluster member.
7. On the upgraded cluster member, run: cphaprob stat
Make sure that it is now in the Active state.
8. On the new upgraded cluster member, run: cphacu stat
Make sure it handles the traffic.
9. Upgrade the former Active cluster member.
Make sure to reboot it after the upgrade.
10. Install Policy.
After the cluster upgrade is complete, the Cluster Control Protocol works in broadcast mode. To
return it to multicast mode, on all cluster members, run: cphaconf set_ccp multicast
Upgrading a VSX ClusterXL

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.
member ID:
Run the cphaprob stat command on each of the gateways.

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.
2. Reboot the gateway after the upgrade.
3. On the upgraded member, run: cphaprob stat
Make sure the state is Ready.
4. On the non-upgraded member, run: cphaprob stat

Upgrading a Security Gateway ClusterXL with More Than 2 Members
Make sure that the non-upgraded member is in Active or Active Attention state, and that the
upgraded member is in Down state.
5. On the upgraded member, run:
cphacu start <Sync IP of Active_GW> <Member ID of Active_GW>
6. Make sure that the Connectivity Upgrade is complete ("Making Sure the Upgrade Completed"
on page 13).
7. In VS 0, on the non-upgraded member, run:
a) fwaccel off -a
b) cpstop
8. On the upgraded member, run:
a) cphaprob stat
Make sure that it is now in Active state.
b) Run: cphacu stat
Make sure that it handles the traffic.
9. Upgrade the non-upgraded cluster member with a clean install.
Make sure to reboot the gateway after the upgrade.
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.
member ID:
• Run the cphaprob stat command on the cluster member.

1. Upgrade the Standby cluster members based on the Installation and Upgrade Guide for Gaia
Platforms.

Upgrading a VSX ClusterXL with More Than 2 Members
a) In the Gateway Cluster General Properties window, change the Cluster version to the
upgraded one.
b) In the Install Policy window > Installation Mode > select Install on each selected gateway
independently and clear For Gateway Clusters install on all the members, if it fails do not
install at all.
3. Run cpstop on all of the upgraded members except one.
4. On the upgraded member that is not stopped, run: cphaprob stat
Make sure the state is Active or Active Attention, and all upgraded members are in Down
state.
6. On the upgraded member that is not stopped, run:
7. Make sure that the connectivity upgrade is complete. ("Making Sure the Upgrade Completed"
on page 13)
8. On the non-upgraded member, run:
a) fwaccel off
b) cpstop
a) cphaprob stat
b) Run: cphacu stat
Make sure that it monitors the traffic.
10. Run cpstart on the all of the upgraded members that were stopped.
11. Upgrade the remaining members.

Upgrading a VSX ClusterXL with More Than 2 Members
Upgrading a VSX 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.
• 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 stat 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 member with the
lowest ID. For more information about the clean install, see sk97552
2. Run cpstop on all of the upgraded members except one.
3. On the upgraded member that is not stopped, run: cphaprob stat
Make sure it is in Active or Active Attention state, and that all upgraded members are in Down
state.
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 13)
7. In VS 0, on the non-upgraded member, run:
a) fwaccel off -a
b) cpstop
a) cphaprob stat
b) Run: cphacu stat
Make sure that it monitors the traffic.

Upgrading a VRRP Cluster
9. Run cpstart on the all of the upgraded members that were stopped.
10. Upgrade the last cluster member with a clean install.
Make sure to reboot the gateway after the upgrade.
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 members that run R77.30 and
higher.
Before you upgrade:
• Run show vrrp on both members, and make sure that all the interfaces on one member are
in Master state, and all the interfaces on the other member are in Backup state.
• Make sure that the VRRP interface priorities are higher on the Master member than on the
Backup member.
• Run cphaprob list and make sure that there are no pnotes on the Master member.
• Enable the monitor firewall (if not already enabled) on the Master member:
• Run set vrrp monitor firewall on
Or
• In the WebUI, enable Monitor Firewall State
Make sure that this member is still the Master member.

1. Upgrade the standby cluster member (See the Installation and Upgrade Guide for Gaia
Platforms).
Disable preemptive mode (if exists).
Note - In upgrades to R80.10 with dynamic routing synchronization, configure dynamic routing
based on the known limitations ("Limitations" on page 14).
a) In the Gateway Cluster General Properties window, change the cluster version to the
upgraded one.
b) In the Install Policy window > Installation Mode > select Install on each selected gateway
independently and clear For Gateway Clusters install on all the members, if it fails do not
install at all.
3. On the Active cluster member, run:
a) cphaprob stat
Make sure that the active cluster member is in Active or Active Attention state.
b) show vrrp
Making Sure the Upgrade Completed
Make sure that all the interfaces on this member are in Master state.
4. On the upgraded cluster member, run:
a) cphaprob stat
Make sure that the cluster member is in Ready state.
b) show vrrp
Make sure that all the interfaces on this member are in Backup state.
c) cphacu start <no_dr>
Add no_dr to the command only if dynamic routing synchronization is not necessary.
d) cphacu stat
Make sure that the Active cluster member (the peer) monitors the traffic.
5. On the Active cluster member, run:
a) show vrrp
Make sure that the Active cluster member monitors the traffic.
b) fwaccel off
c) cpstop
The connections fail over to the upgraded cluster member.
6. On the upgraded cluster member, run:
a) cphaprob stat
Make sure that the upgraded cluster member is in Active state.
b) show vrrp
Make sure that all the interfaces on this member are in Master state.
7. On the new upgraded cluster member, run:
cphacu stat
Make sure the new upgraded cluster member monitors the traffic.
8. Upgrade the former Active cluster member.
• Reboot the former Active cluster member after the upgrade.
• Make sure that the VRRP interface priorities are lower on this member to prevent the
possibility of unwanted failover.
9. Install Policy.
After the cluster upgrade is complete, the Cluster Control Protocol is in broadcast mode. To
revert it to multicast mode, on all cluster members, run:
cphaconf set_ccp multicast


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). Run: show route summary
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 stat to make sure that the new member is in Ready state. If the new
member is in Active state, then make sure that there is connectivity between the members.
• For upgrades to R77.20 or R77.30: Run cphaprob stat and make sure that the ID of the
member and its IP address match those of the old member.
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 member.
You must specify the Sync IP and the The user did not pass the sync IP and member ID to the
member Id of the old member 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 member ID was passed to the CU script.
Only a single instance of connectivity The CU script is already running and the user is trying to
upgrade can run at a time run CU again. Run ps 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 member.
Run cphaprob on the local member and make sure that
the output shows the state of the local member.

Limitations
Error Description
Connectivity upgrade failed since the CU only runs if the state of the new member is Ready. CU
local member is not in Ready state checks many times if the member is in Ready state, if the
member is still not in Ready state then the CU script will
exit.
Connectivity upgrade failed since For Security Gateways only: CU only runs if the
Synchronization PNote is set to Synchronization PNote is ok. CU checks many times if the
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 because When CU starts, the two members begin to communicate,
CPHAPROB cannot see the old and the new member sees the old member as Active.
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.
This can happen if CU is run on a version that does not
Failed to get fwha_version
support CU.
Failed to get
fwha_cu_override_last_heard_ccp_v
ersion 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, which synchronizes the
###; Connectivity Upgrade failed connections from the old member to the new member.
Failed to run fullsync for VS ###; The full sync was started but did not finish. This means
Connectivity Upgrade failed that some of the connections were not synchronized.
Failed to run cphacu state for VS The script cphacu state failed to show the current state
### of connectivity CU.
Error printing connections table per CU failed to print the connection table summary for each
vs VS.
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.

Limitations
• 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.
• All member gateways must have the same number of CoreXL Firewall instances.
• All member gateways 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 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%.
• 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 - routing enhancements
• 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.

Other Upgrade Methods
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.

CP CU BestPractices

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CP CU BestPractices

Transféré par

Droits d'auteur :

Formats disponibles

24 January 2017

R77.x and R80.x Versions

30 December 2015 First release of this document

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

Upgrading a Security Gateway

To upgrade the cluster:

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

Upgrading a VSX ClusterXL

To upgrade the cluster:

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

Upgrading a Security Gateway

To upgrade the cluster:

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

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

Upgrading a VSX ClusterXL with More

To upgrade a VSX cluster with more than two members:

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

Upgrading a VRRP Cluster

To upgrade the cluster:

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

Making Sure the Upgrade Completed

Troubleshooting the Upgrade

Connectivity Upgrade Error Messages

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

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

General Failover Limitations

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

• Connections initiated by the cluster member itself.

Limitations for Failover with CU

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

Other Upgrade Methods

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

Vous aimerez peut-être aussi