Upgrade R80.30 to R81

[charlie]

I'm planning to upgrade my checkpoint devices from R80.30 to R81.

I have 2 MDS with some CMAs and every CMA manage 2+ gateway.

Before upgrade the Firewall to R81 I need to upgrade the MDS device right?

Someone told me that the R80.30 MDS manage the R81 devices but normaly the MGMT should be at the same version or more of the managed device.

Can I jump directly from 80.30 to 81 or 81.10?

The upgrade should be

1° Upgrade MDS  to R81.X

2° Upgrade Firewalls to R81.x with the usual plan: first the Secondary(standby) node, failover, test and upgrade the Primary node.

Regards

[the_rock]

According to below, yes, you can do direct upgrade:

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_RN/Topics-RN/Supported-Upgrade-Pat...

 As far as mgmt and what it can manage, its strongly recommended to have management at least same OR higher than gateways.

[charlie]

Hello,

I agree that the management should be at the same version or more, normaly it's not a recommendation but a requirement to allow the mgmt to manage the devices. For example you cannot manage a R80.30 firewall with a R77.x CMA

I would like to know if we MUST upgrade the MDS or not. I'm quite sure that they are asking to upgrade only the Firewall because approval process for the firewall only it's easier if we don't have to upgrade the entire MDS.

Regards

[Tomer_Noy · Accepted solution]

Short answer: Yes, you need to upgrade the MDM to R81 in order to manage R81 gateways.

Longer answer: We strive to maintain forward compatibility between minor versions. That means that R80.30 management can manage R80.40 gateways. This usually requires a minimal JHF on the Management that is released shortly after a new version.
Since R81 is a major version, R80.x management cannot manage R81 gateways.

Although we have forward compatibility, we do recommend upgrading the Management to be at least the version of the gateway, so that you can leverage all the new gateway features that might require configuration. Also, this setup gets the most QA testing and lowers potential for hitting edge cases.

[charlie]

Many thanks for the confimation. As I know the Mgmt need to be the same version or more.

Have a nice day.

Regards,

Christian

[RamGuy239]

If you are going to R81 or R81.10 you will have to move the MDS server to R81/R81.10. It happens that Check Point backports the capability of managing newer versions using older management installations but currently R80.30 only have the capability of managing R80.40 gateways. It was added with Jumbo Hotfix Take 166 and Smart Console Build 62.

R80.30 Jumbo HotFix - Ongoing Take 166 (11 March 2020)
PRJ-9461 Security Management NEW: Added ability for R80.30 Security Management or Multi-Domain Server to manage R80.40 Security gateway. Refer to sk164652.
Requires R80.30 SmartConsole Build 62 (or higher).

One must also remember that managing newer versions on gateways using an older version on the management installation often results in a lot of the new features not becoming available. Most new features require that both the management and the gateway is running the new version so not upgrading the management defeats the purpose.

So in your scenario when moving to R81 or R81.10 on the gateways you will have to move the MDS as well. The recommendation when moving the management is to do an "advanced upgrade". This means you take a copy of the running Gaia configuration, and a export of the management database using the new upgrade tools ($MDS_FWDIR/scripts/migrate_server) and import them on a fresh installation of R81/R81.10.

You can find all the steps detailed within the install and upgrade guide:
https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Installation_and_Upgrade_Gui...

I'm not sure how your MDS got moved to R80.30? You have to utilise the advanced upgrade option in order to get the new XFS filesystem that was introduced along with 3.10 kernel for management installations on R80.20+. You can verify this by the following commands via console/SSH in expert mode:

cat /etc/fstab
df -hT

And verify if your partitions are EXT3 (old) or XFS (new).

[Tomer_Noy]

Thanks for the detailed answer @RamGuy239.

The point on recommending the "Advanced Upgrade" option (export+ clean install + import) is not so clear cut and might add unnecessary complexity to many customers.

Over the last few years, we've invested a lot in the CPUSE upgrade flow in order to make it stable and simple. Some are not aware, but an in-place CPUSE upgrade actually creates a new partition, exports the configuration and imports it. The installation does not happen into the same partition, so you get a relatively "fresh" system without leftovers. Also, in case of crisis, it will revert to the previous partition and version. The flow is very similar to "advanced upgrade", except that the software does all the manual steps for the user. Another benefit is that retaining the traffic logs is automatic.

In many cases, I would recommend going with the simpler in-place CPUSE upgrade. The statistics from the field also show that most customers choose this option.

There are a few cases where advanced upgrade makes more sense:

• Moving to new Management hardware
• The server was originally installed before R80.20 and you'd like to get the new XFS filesystem. For this, the clean install needs to be done from ISO.
• You need upgrade related fixes that were released in JHF after the GA. Advanced upgrade lets you install JHF before the import, so you can enjoy some more fixes. In some past versions, this was very important (R80.10, R80.20), but R81 and R81.10 are relatively new and there are not many such fixes yet. In some cases with a known and relevant fix, TAC might recommend an advanced upgrade with JHF.

[RamGuy239]

Hi, @Tomer_Noy.

In-place upgrades are going to be simpler. But I would argue that going the advanced upgrade route isn't all that difficult either and considering this is an MDS deployment one could argue that if you find the advanced upgrade to be difficult one might considering getting some with experience involved.

Personally doing in-place upgrades on management installations is something I rarely do. The reason for this is that almost all management installations I'm dealing with for the last few years are running virtually. Most common is VMware ESXi, some Hyper-V and recently there's been some using KVM and Nutanix AHV.

Doing advanced upgrades makes rollbacks easier. As we are not touching the existing host. So if something happens you simply turn off the new host and turn the old one back on. Gaia is taking a Check Point snapshot in case of major upgrades, so you will normally not end up in huge trouble regardless. But not touching the original installation at all is always the safer option. It happens from time to time that the upgrade itself goes just fine, but you run into some unexpected issues running the new version. Going via the advanced upgrade making you have one host running the old version untouched, and a new one running the new version allows for you to test the new version in production for a time while still retaining a very fast and easy way to go back to the old one if needed.

Personally, I prefer to utilise the images from sk158292 over the use of ISO for virtual deployments, making it even easier to simply create a new host running the new version and deploying a copy of the Gaia configuration and doing a migrate_server import on this new host.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...


I would still recommend utilising the advanced upgrade if @charlie does not have the new XFS filesystem in place on the current installation as this will be the only way for him to not be stuck with EXT3.

[charlie]

Hi @RamGuy239 ,

For the MDS We have two smart-1 5200 series not ESXi VM istance.

Regards