Checkpoint Hardware migration with minimal downtime

[Ramasubramaniya]

Hi team,

We are going to migrate the MDS management from one open server to another.

The current open server is running on R80.10 and we are planning to install the new  open server with the R81 and migrate the backup to it(with same management IP address)

The query now is after migration in case if the SIC breaks between new Management and firewall what is the best way to reestablish with the minimum/no impact. Currently out firewalls are running on the Active/Standby cluster.

Please advise the best way to avoid downtime while resetting the SIC on the gateways

[PhoneBoy]

There is no direct upgrade path to R81 from R80.10.
You have to upgrade to R80.40 first, then upgrade to R81.
But in general, SIC should not break since the migration process should bring this across.
That said, if you need to reset SIC on gateways without downtime, there’s: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Ramasubramaniya]

Thanks for the response
But the procedure mentioned in the SK will restart the checkpoint services, so it will break the cluster
Once the gateway comes back it will be on default policy.
What will happen when I install the policy from new management server using independent gateway install option
Both the boxes will stay in cluster? Or it will break and both will go into the active/active state?
We need to achieve the SIC reset with no downtime
Please advise
Also one query after SIC password reset in gateway what will happen if try fw fetch local command
Will it fetch the last known policy locally and join back to the cluster?

[PhoneBoy]

This procedure only restarts cpd, which is not a full restart of all Check Point services.
I can confirm through personal experience the procedure does not change the active policy (i.e. does not load InitialPolicy).
It should not break the cluster either, though I haven't personally tested this.

There's a note in the SK that says if you power off the gateway before you complete resetting, the gateway will load InitialPolicy when it reboots.
An fw fetchlocal prior to completing the re-SIC process and installing the policy from the new manager will likely result in similar behavior.

[Ramasubramaniya]

I see this in the SK notes

Notes:

• The Security Gateway will run the default policy until a policy is installed. It is recommended to install policy as soon as the SIC has been reset on your Management Server.

That's why I worried if it will break the cluster

[RamGuy239]

As long as the MDS is keeping its IP address and hostname the migration will keep all SIC certificates intact so there is no reason for you to reset or break SIC.

[RamGuy239]

You can't move directly from R80.10 to R81. So you will have to do a middle-step via R80.40. From what I understand you are switching to different hardware as a part of the process so doing a simple in-place upgrade to R80.40 is out of the question?

This one is rather difficult. R80.20+ introduces 3.10 kernel and the XFS filesystem on management installation. You'd want to get this XFS filesystem on your MDS installation. If you do a mds_backup in order to replicate your MDS as-is on R80.10 on the new hardware you could do an in-place upgrade to R80.40 and then do another in-place upgrade to R81/R81.10. But then you will be stuck with EXT3 filesystem and not get the XFS filesystem.

The only way for you to get the XFS filesystem is by doing an advanced upgrade of the MDS. Meaning that you will move the configuration and MDS database from one installation to another. Your old will have EXT3, but your new will have XFS.


You have three options:

#1:
- Do a mds_backup of your existing MDS. Replicate the MDS on the new hardware.
- Once replicated and verified to be working you do an in-place upgrading though cpuse to have this MDS upgraded to R80.40.
- Do an advanced upgrade from R80.40 to R81/R81.10. This means that you take a copy of the gaia configuration and you utilise the new migrate_server script ($MDS_FWDIR/scripts/migrate_server) to get a R81/R81.10 version of the database.
- Do a fresh install of R81/R81.10 and import the gaia configuration and database. Now you are running R81/R81.10 and you have the XFS filesystem.

#2:
- Do an in-place upgrade from R80.10 to R80.40 on your existing MDS.
- Do an advanced upgrade migration from R80.40 to R81/R81.10 installed on the new hardware. This means that you take a copy of the gaia configuration and you utilise the new migrate_server script ($MDS_FWDIR/scripts/migrate_server) to get a R81/R81.10 version of the database.
- Do a fresh install of R81/R81.10 on the new hardware and import the gaia configuration and database. Now you are running R81/R81.10 and you have the XFS filesystem.

#3:
- Do a mds_backup of your existing MDS. Replicate the MDS on the new hardware.
- Once replicated and verified to be working you do an in-place upgrading though cpuse to have this MDS upgraded to R80.40.
- Once upgraded to R80.40 do the same for upgrading it to R81/R81.10.


All of these options are viable, but option 3 is not recommended as you will end up with not having the XFS filesystem. Option 2 will be the fastest, but I would argue that option 1 is the best one as you will have your existing MDS installation intact and this might be preferable as it gives you a very easy and efficient rollback plan. If something happens you could turn on the old hardware again and it will be just the same as it was previously running R80.10.


All three options should keep the gaia configuration and database the same. So there should be no reason to expect SIC to break. So having to break and re-configure SIC shouldn't be something you have to do.

[Ramasubramaniya]

Thanks for the suggestions

I will try out and let you know in case of more queries