Zero Downtime Upgrade From R77.30 to R80.20

[Jain_Raj]

As this is a season of R80 Upgrade, just sharing my experience of recent upgrades in the live environment from R77.30 to R80.20 without any service down

1.Upgrade the DA Agent to the latest version
2.Upload the R80.20 Image through CPUSE and verify for any errors
3. In CMA cluster Properties, Select Maintain current cluster Active member
4.Upgrade on the current standby FW(CPUSE) and let it Reboot
5. Once rebooted, Change the Gateway Object to R80.20 version(It will change for all 3 objects)
6.Install policy(Uncheck the option- For gateway clusters, if installation on a cluster member fails, do not install on that cluster)
7. Check the HA in new version FW,(HA module will be Ready)
8. Now do the upgrade in another gateway, During a reboot, the other pair on HA-Ready will become Active
9.No service Interruption and the other FW will take HA Active(Few Packet Drops-2 to 3 RTO)

Now verify both status and do a final Policy Installation by "Keep Check" the actions

10. Now Install the Hotfix.R80.20 Jumbo Hotfix Accumulator General Availability(Take 87)

[PhoneBoy]

Hi, thanks for sharing your experience.
Glad it was a successful one 🙂

[JozkoMrkvicka]

This is more-or-less the shorten version of Connectivity Upgrade of a Security Gateway Cluster from R77.x to R80.x

[Jain_Raj]

Thanks for sharing the detailed one and it will help for beginners.

[G_W_Albrecht]

I can not see when you initiate the first failover - after step 6 ?

[Jain_Raj]

I didn't do a Failover after step 6. Just went to Upgrade the other FW and during reboot, this Firewall to take Active

[G_W_Albrecht]

Interesting ! In the original document i read:

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).

[lullejd]

Before the upgrade, also you have to change the ccp to broadcast and after the upgrade, change ccp to auto.

[Noel_Rodriguez]

Does this mean that you already had upgraded the rules set to R80?

[HelioLeite]

This steps works very well in all environments but we need pay attention because some connections and features do not survive after failover to an upgraded Cluster Member.

Failover Limitations
- 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. This can affect many blades as like DLP, IPS, Threat Emulation, VPN. To get more information you can see Connectivity Upgrade Limitations
- Connectivity Upgrade is supported only when CPU utilization on Cluster Members is below 50%.
- If a session that is authenticated with the Identity Awareness Software Blade is open when you start the Connectivity Upgrade, the session is terminated.
- IPv6 connections do not survive the Connectivity Upgrade.

For additional limitations related to general failover, see the section Check Point Software Compatibility in the ClusterXL Administration Guide.

sk107042 - ClusterXL upgrade methods and paths

[Kamiar_Sh]

Hi All,

I have upgraded my cluster R77.30 to R80.20 last week and I faced an issue after upgrading as follow:

Unix server couldn`t send files to FTP server via FTP passive mode and after 2, 3 hours troubleshooting I disabled the SecureXL and issue resolved so do you have any suggestion or thought?

Thanks

[peter_schumache]

If the R77.30 cluster runs in 32 bit mode and is upgraded to R80.20, I'm pretty sure that the state table is NOT synced at failover. This implies that the upgrade is zero downtime, but existing sessions do NOT survive.

Correct?

[Ila]

We are not having the HA for our R77.30 management server. Can some one help us on the steps to be followed  to migrate  from R77.30 to R80.20 withoout any impact.

[peter_schumache]

Hopefully your management server is implemented as a virtual machine. Then ist gets quite easy.
1. Use the migrte tools from R80.20 on your R77.30 server to if the DB is clean.
2. Do a migrate_export on your R77.30 mgmt server
3. Perform a new R80.20 installation from scratch on a new virtual machine with same IP-address as R77.30 Mgmt server, but on another vlan.
4. Perform the migrate_import on the new R80.20 Mgmt Server.
5. Do the necessary checks on the new Mgmt server.
6. lift your old R77.30 mgmt server from themgmt vlan and connect your new mgmt server to it.
7. Check if yout get the logs and can reach your gateways.
In case you notice any issus, yu can easily switch back to your old R77.30 mgmt server