topic Re: Upgrade Cluster in Firewall and Security Management

Upgrade Cluster

velo — Wed, 27 Nov 2024 15:53:33 GMT

I want to upgrade my pair of 6200s. They are currently running 81.10 and I want to upgrade to 81.20.

I have completed upgrades before but only upgrading the HF version. Previously my steps for upgrading HF version were in summary:

• Upgrade Node2 standby node using CPUSE and reboot

• Failover traffic to Node2 standby node (now upgraded) to make it active. (Using clusterXL_admin down down on primary node)

• Let the Node2 firewall process traffic for a while. Once happy proceed

• Upgrade Node1 using CPUSE and reboot

• Fail traffic back to Node 1

My understanding is that when you upgrade a major version e.g. 81.10 to 81.20, the firewall will come up with a default policy after the upgrade. Is that correct? If so, I would adjust my steps accordingly as follows:

• Upgrade Node2 standby node using CPUSE and reboot

• Push policy to both firewalls in the cluster [New step]

• Failover traffic to Node2 standby node (now upgraded) to make it active. (Using clusterXL_admin down down on primary node)

• Let the Node2 firewall process traffic for a while. Once happy proceed

• Upgrade Node1 using CPUSE and reboot

• Push policy to both firewalls in the cluster [New step]

• Fail traffic back to Node 1

Thanks

Re: Upgrade Cluster

the_rock — Wed, 27 Nov 2024 16:07:20 GMT

I would agree, but keep in mind, R81.20 is not a major version compared to R81.10. Hopefully below link with steps I gave helps, but you got it.

Andy

https://community.checkpoint.com/t5/General-Topics/Upgrading-form-R81-10-to-R81-20/m-p/177310#M29547

Re: Upgrade Cluster

the_rock — Wed, 27 Nov 2024 16:07:00 GMT

@velo

IMPORTANT:

DO NOT install policy to both members when you upgrade backup member (just make sure to set option I mentioned in the link) and also, BEFORE you upgrade backup, run cphaconf mvc on (its to ensure higher version member can sync with the other after the upgrade). Once all done, turn it off when both are on R81.20.

Personally, I run that command on both members before any upgrade, but below doc states to do it one at the time (I find works either way, just make sure to disable it when all done)

Ping me if any issues.

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Installation_and_Upgrade_Guide/Topics-IUG/MVC-Upgrade-of-ClusterXL-GW-mode.htm?tocpath=Upgrade%20of%20Security%20Gateways%20and%20Clusters%7CUpgrading%20ClusterXL%252C%20VSX%20Cluster%252C%20or%20VRRP%20Cluster%7CMulti-Version%20Cluster%20(MVC)%20Upgrade%7C_____4

Re: Upgrade Cluster

velo — Wed, 27 Nov 2024 16:46:31 GMT

Thanks Andy

A few queries.

This step:

-once rebooted, change cluster version in dashboard to R81.20 and uncheck that option for cluster "dont install policy..." and once policy is done, it will ONLY apply on upgraded member

Will this step fail the install on the primary unit because it will still be 81.10 and the 81.20 member is correct version as specified in Smart Console? (Expected)

You've more or less answered this but do you just set "cphaconf mvc on" on both units before starting?

Re: Upgrade Cluster

the_rock — Wed, 27 Nov 2024 16:48:24 GMT

For policy question, yes, it will fail on current master, as it would be on R81.10, thus the reason why you ONLY install it on upgraded member.

For mvc, do one at the time, run on backup, upgrade, leave setting on, then run on current master, upgrade, re0check policy option i mentioned, push policy, turn off mvc on both members.

Enjoy the success 🙂

Andy

Re: Upgrade Cluster

velo — Wed, 27 Nov 2024 16:50:27 GMT

Haha, thanks!

Makes sense yes.

Re: Upgrade Cluster

the_rock — Wed, 27 Nov 2024 16:51:10 GMT

Happy to help you when you do this, just message me, as long as its not too too late. Im in Canada EST, not an issue.

Andy

Re: Upgrade Cluster

velo — Wed, 27 Nov 2024 16:52:01 GMT

Very kind of you, thanks Andy.

Re: Upgrade Cluster

the_rock — Wed, 27 Nov 2024 17:12:44 GMT

You got it! Just message me directly and we can connect. Btw, I was wrong about one thing (and it will NOT be first or last time im wrong haha).

Anyway, you only need to enable mvc on member thats upgraded, so in this case first one (meaning backup member), as point is to enable higher version to sync with lower version member.

So here it is....

-enable mvc on backup member

-upgrade it

-install policy ONLY to upgraded member with that option unchecked (one I mentioned from the link for the policy)

-do NOT rutn off mvc yet

-do NOT enable it on master

-upgrade master

-re-check that option for policy install and push policy to R81.20 cluster

-disable mvc on the initial member where its enabled

Done 🙂

Re: Upgrade Cluster

velo — Wed, 04 Dec 2024 17:43:01 GMT

Hey Andy

I took all the info from your original post, and this post and I made a new combined guide. I labbed up a cluster on 81.10 and used this to go to 81.20 and it seemed to go well.

I'm doing live next week so hopefully all goes fine. 🤞

There was one thing I found strange. When I upgraded the standby node, as expected it came up with initial policy. I changed the version and unticked the "don't insall...." box, pushed the policy. I then failed over to FW2 (now on 81.20 and MVC) I then proceeded to upgrade FW01 (now disabled on haprob stat, and on 81.10) The strange thing is when I rebooted this firewall, it didn't come up with initial policy, it had the correct one.

Any idea why there is a difference in behaviour there?

Thanks a lot for your pointers.

Re: Upgrade Cluster

the_rock — Wed, 04 Dec 2024 17:48:42 GMT

Thats totally normal brother and here is why. Technically, R81.20 is NOT major version, its considered minor in this context. R82 would definitely be major one.

Trivial (basic) example:

Lets take old school version. R77, for example:

R77 is major version...R77.10, .20 and .30 would have been minor

R80 is major, R80.10, .20, .30 and .40 are minor

R81 is major, R81.10, .20 are minor

Makes sense? 🙂

Anywho, if you need more explanation, we can have a call, let me know.

Andy

⚽

Re: Upgrade Cluster

velo — Wed, 04 Dec 2024 17:56:25 GMT

Ah ok thanks! Any idea why the first one came up with initial policy but the second one didn't? Just a glitch in the matrix?

Thanks! We should be ok for the call but if I get stuck I will be sure to take you up on that.

Re: Upgrade Cluster

the_rock — Wed, 04 Dec 2024 17:59:04 GMT

Thats totally valid question. I only had that happen once out of who knows how many times, so did not pay much attention to it. I figured it must have been a glitch, as you said. I messaged you directly with my cell number, so you viber, whatsapp me, whatever works, just let me know who it is, so I dont block you thinking its a scam, too much of that these days LOL

Andy

Re: Upgrade Cluster

velo — Wed, 04 Dec 2024 18:01:36 GMT

Haha thanks Andy 🙂 Appreciate that.

Re: Upgrade Cluster

Oliver_Fink — Thu, 05 Dec 2024 13:58:30 GMT

I wish it would be so simple, because everyone expects it this way. Following Support Life Cycle Policy for Software these are Major Versions:

R77 (R77, R77.10, R77.20)
R77.30
R80 (R80, R80.10)
R80.30
R80.40
R81
R81.10
R81.20
R82

No reliable connection between numbering and major / minor releases. You have to learn by mind…

Re: Upgrade Cluster

the_rock — Thu, 05 Dec 2024 14:02:37 GMT

Funny enough, I was looking at that same link yesterday and then I thought to myself afterwards...this cant be true, because based on that, EVERY version out there is major? lol

Andy

Re: Upgrade Cluster

the_rock — Thu, 05 Dec 2024 14:06:45 GMT

@Oliver_Fink

I believe my initial response was indeed correct. See below what @CheckMatesAI came back with 🙂

Andy

Re: Upgrade Cluster

Bob_Zimmerman — Thu, 05 Dec 2024 14:28:08 GMT

When you have upgraded a cluster member, it tries to connect to the management and fetch its policy. Until you change the cluster object's version and push the policy at least once, the management only has the policy built for the old version. This causes the first upgraded member to fail to fetch its policy in most upgrades. Meanwhile, the second upgraded member is able to fetch the policy because you built it for the new version when you pushed to the first upgraded member.

Re: Upgrade Cluster

the_rock — Thu, 05 Dec 2024 14:51:13 GMT

@Oliver_Fink

Though having read that screenshot twice, its even more confusing LOL. So, if you look at the bottom section about upgrading, it says when upgrading from one major version to another (eg R81.10 to R81.20)....HOW IN THE WORLD can those be major when literally in the table before that it states those are minor versions lol

Andy

Re: Upgrade Cluster

Oliver_Fink — Thu, 05 Dec 2024 15:12:20 GMT

I do not believe what @CheckMatesAI is telling you, @the_rock. This is from sk95746 – Check Point Recommended Version and Release Terminology:

Major release

Introduces new functionalities and cutting edge innovative technologies to the market while maintaining high product quality. Major release is supported by Check Point for four years according to Support Lifecycle Policy.
In the past few years Check Point has released Major releases every 1-2 years. Some examples of major releases would be: R81.10 , R81.20.

(Fat font by me…)

Another inconsistency is that Check Point is talking about Major Releases, but also of Recommended Versions. I cannot find explained in this SK what the difference between Release and Version is. Maybe, someone else knows…