Change Gateway in a cluster from ready state to active

[emichalitsis]

Hi to all,

I would like to ask you something regarding the upgrade process of a Cluster Gateways from R80.10 to R80.40.

I upgraded a Checkpoint 5400 from R80.10 to R80.40. The steps that i followed was:

1. I switched the traffic from primary to secondary

2. I upgraded the Primary gateway from R80.10 to R80.40 (clean install)

3. I migrated import the Primary gateway

4. When everything was ok on the Primary gateway and with R80.40 version i switched the traffic to Primary gateway. The procedure was to close all the interfaces from Secondary gateway (with R80.10 version) and to open all the interfaces to Primary gateway (with R80.40)

5. One note: Before the upgrade, the Secondary gateway has higher priority than Primary and i had choose to switch to higher priority in the SmartConsole.

6. From a mistake i plugged in the mgmt interface on the Secondary gateway and because of higher priority it becomed again active and the Primary gateway change his state to "ready"!

7. After that, every time i tried to pass the traffic to R80.40 Primary gateway was unsuccess, because of the "ready" state. So i was unable to switch the traffic to Primary Gateway in order to upgrade the Secondary Gateway to R80.40 without downtime!

I hope to explain the problem fine. So, my question is: Is there a way to change the "ready" state to "active(!)" without  reinstalling the primary gateway to R80.40? Because i can't have large downtime window in order to upgrade the Secondary Gateway to R80.40 and after that Primary Gateway take over.

Regards

[MartinTzvetanov]

Hello, no matter what the priority is set on SmartConsole, if you have 2 gateways with different version/cores, the active one is always the one with lowest version/lowest number of cores. In your case you have 2 GWs 1st R80.40 and 2nd R80.10, R80.10 will be always the active one, R80.40 will show itself as ready. When you shut all the network ports on R80.10, the device with R80.40 will see that there is no active device and will become active. This cause a minimal downtime - all connections are cut and must be reinitiate. You don't have to reinstall your device with R80.40. Just make sure both devices are in a cluster (Active/Ready in your case) and have the same policy installed, shut all the ports on the R80.10 device and the traffic must pass thru R80.40 and after everything is OK, upgrade the R80.10 device.

[emichalitsis]

Martin thank you for your answer, it was very clear!

Regards

[G_W_Albrecht]

This is covered on a step-by-step basis in Installation and Upgrade Guide R80.40 p.194ff - also the Multi-Version Cluster (MVC) Upgrade that i would suggest as appropriate in your case...

[emichalitsis]

G_W_Albrecht thank you!

[genisis__]

I've used MVC when upgrade VSX i.e. R80.20 to R80.40 and found this to work fine, clearly you still need to change the cluster object to R80.40 in order for a policy be to pushed to the R80.40 gateway.

[Scott_Paisley]

This is how I have been doing it. I upgrade (clean install in fact) the secondary, change the policy to R80.40 in the management console and push to that gateway. Then I do a cpstop on the primary forcing the failover. If everything works I upgrade the primary and when I install the policy it fails back. If not I can restart the primary and restore the secondary from the snapshot.

[genisis__]

Agree, I think with R80.40 its best to do a clean install, one key point, do benchmark service testing before an upgrade,  that way you won't get the scope creepers coming out the wood work saying things are not working.

[Scott_Paisley]

Absolutely on the testing. we have calls before and after with all the app owners