Migration from R80.40 to R81.20 on New Nodes

[aeddaoud]

Hi everyone,

I hope you're all doing well. I am currently facing a task to migrate two firewall nodes from R80.40, which is now at its end of life, to two new nodes with R81.20 already installed. I am looking for advice and best practices to ensure this migration is as seamless as possible with minimal downtime.

Here are some details of our current setup and the planned migration:

Current Setup:

Two firewall nodes running Check Point R80.40.
High Availability (HA) cluster configuration. (Cluste-XL)
Nodes are part of a larger network with critical services that require high availability.
New Setup:

Two new firewall nodes with Check Point R81.20 pre-installed.
Planning to replace the old nodes with these new ones while keeping the existing HA setup.
Objectives:

Minimize downtime during the migration.
Ensure a smooth transition with minimal disruption to network services.
Retain as much of the current configuration as possible to avoid reconfiguring from scratch.
Questions:

What is the recommended approach for migrating from R80.40 to R81.20 on new hardware while maintaining the HA configuration?
Are there specific steps or precautions we should take to minimize downtime during this process?
Can we directly export the configuration from the old nodes and import it into the new nodes? If so, what are the best practices for doing this?
Are there any known issues or challenges we should be aware of when performing this upgrade?
How can we verify the new setup is fully functional before decommissioning the old nodes?
Any insights, experiences, or resources you could share would be greatly appreciated. Thank you in advance for your help!

[PhoneBoy]

This is a public forum and it's usually best practice not to post PII.
I've removed this from your post.

What is managing this cluster currently? (Hardware, version/JHF level)
With that, we can provide a little more clarity on steps.
Expect some downtime in this process regardless of the steps involved since you cannot cluster unlike hardware (and thus cannot synchronize connections between them).

[aeddaoud]

Good morning,

The cluster currently manages the traffic of our entire headquarters and the surrounding districts together with libraries etc.
The current cluster is made up of 2 open servers with R80.40 Jumbo Hotfix Take 198 installed
The new cluster will also be made up of 2 higher performing open servers

[Luis_Miguel_Mig]

How does the code evaluate the hardware? I thought that only the count of cpu would matter and perhaps the interfaces card/drivers.
Anyway the reason I am asking is because it would be extremely useful if we could add the new hardware to the existent cluster during the migration especially now with MVC (multi version cluster upgrade) to avoid the big bang.

[PhoneBoy]

You might be able to make it work if the core count and interface names match on the old/new hardware.
However, SecureXL and CoreXL have some hardware dependencies and you may experience issues as a result.
Bottom line: what you are proposing to do is unsupported.

[Luis_Miguel_Mig]

Understood. Thanks so much.

[Martijn]

Hi,

With these kind of migrations, I always built a setup in parallel:

- Install a new SMS server with the latest software and hotfixes on a new IP-address.
- Use the 'migrate_server' tool to migratie the database from the current SMS to the new one.
- Attached the new hardware to the new SMS via SIC. If you can keep the hostname, there is no need to create a new cluster object.
- Change the toplogy on the cluster object if the new hardware has a different setup of the interfaces.
- Make sure licenses and contracts are OK.
- Push policy and you have the same setup on new hardware and new software.

If you cannot change the management IP's of the firewall, try to built the new setup in a dummy VLAN or test network.

In one big bang, you can migratie from old to new. But you will loose connections. Shutdown switch ports to the old setup and enable switch ports to the new setup. Most important in these kind of migrations is a good test-plan from the customer.
Because you do not change anything on the old setup, the roll back is very easy.

Is a big bang is not an option, you can built a completely new cluster with a transit LAN to the old one and migrate to the new cluster in steps. 
With this scenario, you need more services windows and migrating to the new cluster may take some time.

A big bang is the faster option. One service window and a easy roll back. But it always depends on the customer.

Good luck.
Martijn

[aeddaoud]

HI,
the problem is that we cannot replace the management which at the moment are 2 Smart-1 410 and one Smart-1 625 which we are using for the smartevent
I thought I'd start by updating these 3 to 81.20 but I was wondering if having the management at 81.20 and the firewall at 80.40 could create problems
I was also wondering if the update changed anything about VPNs because we are currently using 2FA (saml) access and the customer is a little concerned about this

[Martijn]

Hi, 

A R81.20 SmartCenter can manage a R80.40 cluster. It is best to verify the database on the SmartCenters with the latest version of the 'migrate_server' tool to make sure your configuration is OK to upgrade to R81.20.

You can add the new hardware to the current cluster, but check the ClusterXL requirements.

OS must be the same (Gaia).
Number of CoreXL instances must be the same.

Also nice to keep interfaces the same (eth0, eth1, etc).

With new hardware you might have more power in terms of number of cpu's/cores, so adding new hardware to the cluster might not work.

I do not know your customers setup and configuration, so I can only give advise from own experience. What migration-plan had you in mind for yourself? If you and the customer are concerned and down time is not an option, maybe Check Point Professional Services is an option for you. They have experience with complex migrations and they can tell you what can and cannot be done based on your customer's setup.

Regards,
Martijn