VSX upgrade from 2.6 to 3.10 (R80.40) kernel experiences

[Kaspars_Zibarts]

Hi!

Those who have upgraded your VSX already to 3.10 kernel (R80.40) - any tips or what to watch out for? We have CP 23800 appliances

If I chose to upgrade instead of clean install and re-configure, does that mean we keep the old filesystem ext3 instead of getting xfs? Has anyone tried CPUSE CLI upgrade with VSX?

Same time changing file system means that rollback will get more complex as you cannot roll back snapshot that was made in different FS, so you would have to re-install 2.6 before being able to restore snapshot.

Anything else? @Magnus-Holmberg  @JasonMcAllister 

[Magnus-Holmberg]

We installed from scratch on new hardware when we did start on R80.30 3.10
We haven't done any upgrade on these boxes to R80.40 yet, am still waiting for HFA to be over 100 🙂


When we upgraded before CPUSE via CLI is the way we go for, and we use it regularly for HFA upgrades.
Issue with VSX is if you need to rollback, we used the downgrade for vsx provisioning tool even that is has not been supported untill R81. 

[Kaspars_Zibarts]

I can see that CPUSE upgrade is available and in all honesty if the only difference is filesystem, then I'm not too worried on GWs as FS performance isn't that big of an issue compare to MGMT. Upgrade saves me a lot of time restoring all "small" things like IA tweaks, dynamic objects scripts etc. Plus the benefit of easy rollback with snapshot 🙂

vsxs2-ext:0> installer verify 7
Info: Initiating verify of Check_Point_R80.40_T294_Fresh_Install_and_Upgrade.tgz...
Interactive mode is enabled. Press CTRL + C to exit (this will not stop the operation)
Result: Verifier results Package: Check Point R80.40 Gaia Fresh Install and upgrade Clean Install: Installation is allowed. Upgrade: Upgrade is allowed.

[Kaspars_Zibarts]

One thing I am worried about (we do not have a lab to verify...) is the fact that right now 23800 VSX cluster on R80.30 is NOT hyperthreaded and upgrade will force it to change. Wonder if it will affect synchronisation somehow

[Magnus-Holmberg]

I wouldn´t care about the filesystem as its a GW and not MGMT, i dont think it gives any benefits that are noticeable on a GW.

Are you guys using VSLS so you can move one VS at the time just for verification etc?
Am using open servers so HT is turned off in BIOS for me so havn´t experience that issue.

Regarding easy rollback, i dont agree really,
As its VSX you are F* as soon as you change the mgmt to the new version.
Then you need to do vsx downgrade (not supported but works 🙂 )
or snapshot back the mgmt server together with the gw.

But i would go for upgarde, with CPUSE as its easiest 🙂

[Kaspars_Zibarts]

By easy I meant that I'm on the right SW level with all my tweaks, keys and scripts on the gw instead of doing that all over again 🙂

[JasonMcAllister]

My OpenServers had HT turned on in BIOS, although I hadn't checked this and historically lead to believe HT wasn't enabled - Alas it was.

However, synchronization didn't seem to complain about the mismatch and MVC worked quite nicely.

My only query was in a thread about the licensing surrounding that.

I agree with @Magnus-Holmberg you're probably going to have an easier time with CPUSE method.

I would also avoid using vsx_util downgrade to rollback unless TAC specifically told me to.

Instead my roll back (as my MDSM is on VMWare) is a snapshot prior to upgrade where the VSX database is on the original versions.

Any & all operations performed via vsx_util come with that recommendation to backup first.

[JasonMcAllister]

Hi @Kaspars_Zibarts 

I have just finished upgrading 6 member VSLS OpenServer clusters (two of them) from R80.10 to R80.40 and we had decided to go with clean install and reconfigure, although it does take considerably longer.

If I chose to upgrade instead of clean install and re-configure, does that mean we keep the old filesystem ext3 instead of getting xfs?
Yes, you would retain ext3 currently.
CPUSE upgrades are not currently performing the replacement of filesystems to xfs and will retain your ext3 filesystem formats until you perform a clean installation.

Whilst I'm not certain, I suspect that typically this procedure during CPUSE upgrade isn't available as the 2.6 kernel used perhaps doesn't have xfs merged in and therefore fresh installs prepare volumes using 3.10.
I'd be interested to know how that applies if you went from 3.10/ext3 to 3.10 again using CPUSE though, so that'd be interesting to know - But I've never hit a scenario to try.

Has anyone tried CPUSE CLI upgrade with VSX?
Only in lab environments, just to see the results and they meet my previous answer. ‌‌

Same time changing file system means that rollback will get more complex as you cannot roll back snapshot that was made in different FS, so you would have to re-install 2.6 before being able to restore snapshot.
If you're doing a CPUSE upgrade, the filesystem will not be changing and so your snapshots will be the same ext3 formatting.
Unless you mean to revert to a snapshot that has been exported before upgrade and imported back onto the appliance after upgrade, which in itself sounds like it may have more complications than just the filesystem discrepancy.

Other thoughts
The transition from ext3 to xfs operationally has been smooth - I've not encountered issues directly as a result of it but I do not believe there to be a gain on GWs as there is on Management.
Personally, I'm more of a fan of xfs on the whole anyway. I've been accustom to using it outside of Check Point for quite a number of years.

Kind regards,

Jason

[Wille010]

Hi Jason,

We did the same scenario(vsx_util reconfigure) on 23800 2 node VSLS cluster R80.20 T118 to R80.40 T120. It was a disaster. Lots of dynamic routing issues but also during the reconfigure(clean install(reconfigure) not working without any JHF take due to MTU bug and also not working with latest T120 due to driver issue) stage. Eventually with did a complete roll-back and opened a bunch of SR's to get this issues enlightened. How was your experience and also @Kaspars_Zibarts ?

Cheerz,

Lesley

[Kaspars_Zibarts]

Hi @Wille010 - all our latest upgrades have been fairly "pain-free". Bear in mind:

• we upgraded from R80.30
• we do not run dynamic routing

My latest upgrade summary is here: VSX-appliance-upgrade-to-R80-40-T118-second-attempt 

[Wille010]

Thank you!

[Naama_Specktor]

Hi Jason,

we are not familiar with this issue and would like to review the SR ,

it will be great if you can send it to me offline .

thanks, 

Naama Specktor 

[CPRQ]

We have vsx 23800 running R80.20 cluster-xl and dynamic routing.

Linux fwg-inet-a 2.6.18-92cpx86_64 #1 SMP Tue May 25 17:28:11 IDT 2021 x86_64 x86_64 x86_64 GNU/Linux

If we upgrade to R80.40, will it change the file system or required to change the file system? Do we need to do fresh install and run "vsx_util upgrade" on management server.

[Wille010]

Yes file system will change. We tried the fresh install(vsx_util reconfigure) because that is what Check Point had advised but that was specifically for our customer environment. Yes you need upgrade the vsx cluster objects with "vsx_util upgrade". Take 120 destroyed a lot of dynamic routing(OSPF).

[Kaspars_Zibarts]

It's all described step by step in installation and upgrade admin guide. For fresh install + vsx_util reconfigure and direct CPUSE upgrade cases. But yes - it is mandatory to to run VSX object upgrade in mgmt before you start with gateways.

File system - it will change but you should not worry about that as long as you have done snapshot and taken it off the box in case you need to roll back.