Upgrade Cluster

[velo]

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

[the_rock · Accepted solution]

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

[the_rock]

@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/Top...

[velo]

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?

[the_rock]

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

[velo]

Haha, thanks! 

Makes sense yes.

[the_rock]

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

[velo]

Very kind of you, thanks Andy.

[the_rock]

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 🙂

[velo]

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. 

[the_rock]

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

⚽

[velo]

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.

[the_rock]

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

[velo]

Haha thanks Andy 🙂 Appreciate that.

[Oliver_Fink]

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…

[the_rock]

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

[the_rock]

@Oliver_Fink 

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

Andy

 

[the_rock]

@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

[Oliver_Fink]

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…

[the_rock]

Lets see if someone can confirm for sure. I still have hard time believing say R81.10 or R81.20 are major releases if R81 would be major as well, makes no sense to me.

Sorry, not trying to give you hard time @Oliver_Fink , you sent the official links and thats indeed what it does show, I just cant understand the logic behind it.

Andy

[Oliver_Fink]

That numbering scheme makes no sense at all. I have talked about this with customers for many times now and still cannot explain that in a way, customers understand. In a normal world with Rxx.yy, xx is major and yy minor version.

And I still not have begun to write about versioning and hotfixes in Embedded Gaia compared to ordinary Gaia.

Inconsistency, "Check Point" may be your name! 😉

[the_rock]

You said -> In a normal world with Rxx.yy, xx is major and yy minor version.

I say -> YES, I AGREE 🙂

Andy

[PhoneBoy]

To be fair, that answer was not from @CheckMatesAI.
What you were quoting from there was from a public GPT implementation that we are trialing.

Having said that, I understand the confusion with major/minor releases.
Release and Version are synonymous, to the best of my knowledge.

[_Val_]

To make sure, that was not @CheckMatesAI answer. We used to have an OpenAI-based bot, which will be decommissioned this week for not being up to the task. What you are showing is one of the reasons for this decision.

[Bob_Zimmerman]

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.

[velo]

Hi Bob, this makes a lot of sense now thanks. So do you think I just have to accept that behaviour, or should I change the version to 81.20 in Smart Console BEFORE I do the upgrade on the first node? Or, will it still fail because you're saying you need to PUSH it at least once?

[the_rock]

Hey brother,

Yes, you can do that as well, not an issue.

Andy

[Bob_Zimmerman]

Personally, I just use CDT for my firewall upgrades. Right-click on the cluster object in SmartConsole, pick Actions > Version Upgrade, and specify the version you want to upgrade to. Give it about an hour to cook, and out pops an upgraded cluster. It handles updating CPUSE, updating the cluster object, building policy, pushing the upgrade package to the cluster members, upgrading the first member, pushing policy, enabling MVC, failing over, and upgrading the second member. No interaction needed once you kick off the process, and no chance to forget a step.

If you really want to do it manually, you can update the cluster object to the new version and try to push policy. That will build the policy for the new target version and store it on the management server. The first upgraded member should then be able to fetch that policy.

[the_rock]

@velo 

I would use method @Bob_Zimmerman described, though personally, I never use it for major upgrades (say R80.40 to R81.10 or R91.20). For you, since its R81.10 ro R81.20, there would be no issues, tested that in the lab many times.

Andy

[velo]

Hi Bob and Andy.

FYI, I tried changing the version to 81.20 now in my lab before the upgrade and it still ended up with initial policy. So I think Bob is right, you need to push at least once from SMS before it can pull down the new version. I mean, this way still works, you just have to push the policy to the first upgraded firewall only. 

I am going to try and lab the CDT and see if it works OK.

I will let you guys know.

Thanks