MVC and Hardware Replacement

[RemoteUser]

Hi everyone,

I hope you're all doing well.

I’ll soon be performing a hardware replacement and wanted to ask if it’s necessary to enable MVC  for this type of operation. Have any of you had experience using MVC during a hardware swap?

Also, is there an official Check Point procedure for replacing hardware without incurring downtime?

Thanks in advance for your help!

[PhoneBoy]

Are you merely replacing a failed cluster member or are you upgrading the hardware of an existing cluster?
In the former case, you should not need to do anything special beyond setting up the new member (fresh install, SIC, install policy).
In the latter case, ClusterXL only supports cluster members with identical hardware.
Which means if you're changing the hardware type in a cluster, some sort of outage and/or temporarily reduced security configuration is required (e.g. disabling "Out of State" checks for TCP and UDP). 

MVC is only relevant when upgrading from one version to another.
It's not relevant for hardware replacements.

[RemoteUser]

thank you for your feedback.
This is a hardware upgrade, but the IP address, static routes, and other configurations will remain the same.
So, as you pointed out, using MVC isn't necessary in this case i got it, and thanks again!

Are there any additional recommendations or best practices I should consider?

Thank you!

[PhoneBoy · Accepted solution]

This thread might be helpful: https://community.checkpoint.com/t5/Security-Gateways/Replace-Upgrade-Cluster/m-p/69216/highlight/tr... 

[the_rock · Accepted solution]

I can tell you 100% that link @PhoneBoy provided is your BEST bet to have this completed in most simple and least "painful" way. I had done it probably dozen times and never had an issue.

Now, as far as MVC, have a look at below post, it explains everything very well.

https://community.checkpoint.com/t5/Security-Gateways/Issues-with-MVC-mode-during-R80-40-Take-173-to...

Andy

[the_rock · Accepted solution]

Im actually also helping a hospital currently replacing 6500 with 9300 cluster and I will also end up following same link Phoneboy sent you. For what its worth, way I do this is get show config text file and then copy sections over to new firewalls (we did this today).

K, dont laugh now, but I feel sort of obligated to say EXACTLY how this should be done, as I had people tell me before copying would always fail, so here it comes.

So on current firewalls, from expert mode, run -> clish -c "show configuration" > /var/log/hostname_date.txt

You can give it any name and send to any dir.

Then, once you get file off the fw, copy sectiions over till done (I would SKIP line for mgmt interface IP, since that would probably be different and default gateway line, until cutover time)

so hightlight portion you want to copy, then ctrl+c, then you console into new fw, right click and it will copy it over, do NOT do ctrl+v (believe it or not, then can mess up the process of copying right things)

Just to rest until whole config is copied, verify with show configuration and also web UI.

Also, maybe skip coping line set web ssl-port, as that can lock up console

Do NOT forget to run save config after every copy part.

Good luck and be free to message me if anything not clear.

Cheers mate.

Andy

[RemoteUser]

Hi Andy,

Thank you very much for the exhaustive response.

I skipped this part:
(I would skip the line for the management interface IP, since that would probably be different, and the default gateway line, until cutover time) Could you please explain this part in more detail? 

Also, just to confirm — is the MVC only useful when upgrading the cluster to a major version?

For example, if I have two cluster members running the same version (R81.20) but with different JUMBO hotfixes installed, is the MVC still useful in that case or not?

Thanks again, buddy!

[the_rock]

Yes, sure can explain it : - )

So reason why I said skip the part I mentioned was because guy Im working with, we decided to keep mgmt IP as default for now, 192.168.1.1 and default gateway use different IP, just so we can connect externally from their core router, ie update jumbo hotfix to 99, as fws came with R81.20, thats why...hope it makes sense.

Then, once we do cutover next Tuesday night, we will configure those IPs to match right ones before we plug them into the network.

As far as MVC, its applicable regardless minor or major version. As @emmap brilliantly explained in the post I linked, which I honestly had no clue about either previously, you only enable mvc on higher member version, meaning one you are upgrading.

Its also explained below.

Andy

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Installation_and_Upgrade_Guide/Top...

Andy

[RemoteUser]

Thanks Andy i got it bro

[the_rock]

Of course man, any time!

Andy

[RemoteUser]

Hi Andy
If the new firewall replacing the old one has more CPU power, do I still need to worry about that? It will synchronize even without MVC, right

[Bob_Zimmerman]

Depending on the exact difference, it probably won’t synchronize at all, and MVC won’t help. CoreXL topology affects sync traffic. If you have a different number of dispatcher or worker cores on each node, they won’t be able to sync. MVC only overcomes sync problems for different releases, not for different topologies.

If the two nodes have the same number of cores, and one node is just a newer processor model or higher clock rate, sync will probably work, but support won’t help you if it doesn’t.

MVC only matters for sync between different releases (e.g, R81.10 on one member and R81.20 on the other member).

[the_rock]

You dont, as long as version is the SAME, MVC is totally irrelevant. Jumbo take can be 10 on one cluster and 99 on the other, thats totally fine. I will give you an update Tuesday night once I do cutover for the hospital.

Andy

[the_rock]

@RemoteUser 

Just finished cutover, all went well. One thing to tremember is when you replace new fw with existing backup, MAKE SURE to connect sync from existing master to new model fw, so it can get to the Internet.

Andy

[Bob_Zimmerman · Accepted solution]

MVC is not relevant for jumbos. Only for full releases. To go from R81.10 to R81.20, you would use MVC. To go from R81.20 jumbo 76 to R81.20 jumbo 92, you don't need MVC.

[RemoteUser]

Yes, I understand that, but my question is: if I have a (hypothetical) cluster with two different Jumbo , and for some reason I need to keep them that way for an extended period, do I need to enable MVC?"

[Bob_Zimmerman]

No. As I said, MVC is not relevant for jumbos.

[RemoteUser]

Thank you very much!

[RemoteUser]

And if I want to do a hardware replacement from R81.10 to R81.20, isn’t it still needed?

[Bob_Zimmerman]

If you're replacing a failed member with exactly the same hardware and upgrading the software at the same time, I would advise you to split this into two windows, but MVC can help.

If you're replacing an old member with new, different hardware and upgrading the software at the same time, and if the new hardware has the same CoreXL topology (same CoreXL config and same number of cores given to CoreXL), MVC can help.

If you're replacing an old member with new, different hardware which has more cores than the old hardware (extremely common if you're using Check Point's branded servers instead of open servers), MVC will not help you. You MUST take an outage.

[the_rock]

Well said! @RemoteUser Bob is 100% right about MVS and new hardware, it would not help, since new hardware would most likely have more cores, so they have to match for cluster to work. Example...when I did cutover for hospital, their 6500 had 6 cores, new one had 14, so we had to reboot to change it.

Andy

[Mattias_Jansson]

I recently had to perform a clean install on one of our R81.20 vsx clusters to resolve an issue with identity portal.
And to my surprise MVC was enabled by default. 
Heads up to anyone else who is planning to do the same.

Found this post from emmap in https://community.checkpoint.com/t5/Security-Gateways/Issues-with-MVC-mode-during-R80-40-Take-173-to...

"The R81.20 JHF from take 14 up will enable MVC when you install it. It's in the Important Notes section of the JHF documentation. Apparently it's required due to one of the changes made in that JHF, but I don't have additional details. GA R81.20 does not have MVC enabled.

I'm not sure of what kind of scenario that statement is talking about, but it might be warning that if MVC is enabled before you do the initial policy install, the gateway will immediately join the cluster and may take over the active rule if the cluster is configured that way. Disabling MVC would prevent this takeover if the other cluster member is still on a lower version."

[the_rock]

I will double check my cluster, but I THINK that it is on by default in R81.20

Andy

[the_rock]

Its 100% right, just checked my R81.20 cluster lab.

Andy

[Expert@CP-FW-01:0]# cphaprob mvc

ON

[Expert@CP-FW-01:0]# fw ver -k
This is Check Point's software version R81.20 - Build 046
kernel: R81.20 - Build 053
[Expert@CP-FW-01:0]#