Upgrade Experience: Log Server & Management Server from 81.20 → R82.00

[Fabien88920]

Hi everyone,
We recently upgraded our Log Server and Management Server from 81.20 to R82.00.
Has anyone else done this upgrade? Any issues or best practices to share? 

Anyone Upgraded to R82.00? Looking for Feedback

[the_rock]

I did that in the lab few months ago. Did not see any issues at all, went very smooth, no problems. I did generate show config and backup prior, yes, took some time for the upgrade, because after reboot, it still needed to "reimport" all the database etc, so whole process can take 2-3 hours, so you would need to be patient. I recommend to do it either on the weekend or later at night, just to be on the safe side.

Otherwise, just install recommended jumbo as well.

Thats my honest advice.

[Bob_Zimmerman]

I personally do management upgrades and updates during the business day. I want them stable on weekends and at night in case I get paged to deal with some weird issue, but my team is usually fine being unable to stage new changes for a few hours. 😉

And yeah, management updates (installing a jumbo) are normally very fast, but management upgrades (like R81.20 to R82) take a long time. I've had an MDS take over six hours to upgrade before.

[the_rock]

I get your logic...its just sometimes even though its management, better be safe than sorry 🙂

[Bob_Zimmerman]

From my perspective, doing the upgrade during the day is the safer option.

We even do some firewall upgrades during the day. The logic there is the upgrades are too important to do while sleep-deprived. We want everybody sharp so any issues are noticed quickly and we can figure out what's going on. Sleep deprivation affects thinking and judgement on par with being drunk. We would never consider requiring admins liquor up before a change, so why would we require people to be up for >20 hours straight before changes?

Doesn't work for everybody, but it sure works for us.

[the_rock]

In my experience, it really depends on the customer. Just to always be on a cautious side, we always recommend doing this after hours.

[Vincent_Bacher]

We are an end customer, and we are not allowed to upgrade our environment (which includes 4 MDS and 9 MLM) on a weekday — nor would we do so even if it were allowed. 🙂
We usually do that on weekends. First weekend MDS and weekend after MLM.

[Alex-]

Totally. And you get direct feedback from the business and can direct resources where needed more easily than calling on-duty teams left and right, or finding out the next working day.

[Duane_Toler]

There is one issue on a management server I have encountered several times now:

You need to make sure you have the IPS CRC marker file.  If this isn't present, the pre-upgrade verifier will tell you in the report, but if you are doing a Blink upgrade then you might not find out until it's too late.  The file is $FWDIR/conf/SMC_Files/asm/crc_marker_db.fws.  This is (now) covered in sk175089: https://support.checkpoint.com/results/sk/sk175089

If the file does not yet exist for some reason, you can create the zero-byte file as discussed in the SK.  If you ignore the verifier warning and proceed with the upgrade, the database import will fail and your R82 server will be destroyed; you will have to start over with the R81.20 source.  Be warned!  (i had this happen to a management server, learned the hard way)

Otherwise, gateway upgrades have gone well thus far, and other management servers have also gone well (after accounting for the above warning).  Post-upgrade, R82 has thus far performed rather well, which is what I expected.  Kudos to R&D on this one!

[the_rock]

Definitely good advice...personally, never had that issue myself.

[Duane_Toler]

Good!  You don't want to endure that. 🙂 Thankfully I was doing the advanced migration for the customer, moving to a new Azure CloudGuard server, so I had the original source host still available.

[the_rock]

Yea, guess depends on the actual process 🙂

[Bob_Zimmerman]

We upgraded all of our managements and log servers from R81.20 to R82 about a week after it became the generally recommended version. A few false starts with Blink cost us several hours. When we switched to a two-step upgrade (upgrade to the major version, then update to the jumbo as a separate step), it worked. Our management environment is four MDSs (two HA pairs), four MLMs, four SmartCenters, and two log servers (two of the SmartCenters aren't big enough to need separate log servers).

We've also upgraded eight clusters to R82 with a ninth in a few days. Those have gone smoothly.

[Tomer_Noy]

@Bob_Zimmerman - can you please share what issues you encountered with Blink?

I'm glad that eventually the upgrade worked for you in two steps, but I want to make sure that the Blink option will work as well.

[Bob_Zimmerman]

It just failed with no message. I tried it on three managements: a SmartCenter+log server, a SmartCenter which doesn't handle logs, and a log server with no policy management. No secondary managements in either environment. All three ground for an hour, then failed and took me back to R81.20.

[Gregory_Azratz]

Hi @Bob_Zimmerman ,

if by any chance you have the logs from the failed attempts or a way to reproduce it - it will be great
We would like to investigate this and hopefully find the root cause which caused this bad experience.

Gregory

[Alex-]

On top of what was already said, if you use VMWare, you might consider an advanced upgrade on a new virtual system. You can then define it as RH8 with Paravirtual which sensibly improve I/O compared to previous versions.

Edit: it's really easy, you disconnected the network to the R81.20 one, create a new VM with these settings, stage it with the same IP, FTW, JHF, import and you're set with better performance.

[the_rock]

Excellent advice Alex.

[Chris_Atkinson]

Further to this please ensure you pay attention to the vNIC type, avoid "flexible" also E1000 support will be ending.

[the_rock]

I always use xmxnet3 in eve-ng.