New Customer Deployment: R82.10 versus R82.20 Production Best Practice

[yeruel]

Hi everyone

I am setting up a brand- Check Point environment for a customer.

As a practice for a stable production environment I plan to use R82.10 along with the latest Recommended Jumbo Hotfix because that is the official production release that is recommended.. Since R82.20 is now available I want to make sure with the community before I decide on the final setup. The deployment mode is ElasticXL with VSNext

Can you please let me know if using R82.10 is still the practice for long-term stability and easier support for a customer build right now?

Thanks, for your time and help!

[Martijn]

Hi,

Had the same discussion with the local Check Point team last week. We need to upgrade a customer from 81.20 to R82.x and what would be the best version? Also ElasticXL.

We have decided to upgrade to the recommended version with the latest available hotfix. As far as we know, R82.20 does not contain features for ElasticXL and VSNext you would miss if you go to R82.10. And R82.20 does not have a hotfix yet.

Unless you really need and want the R82.20 features, I would go for a recommended version with avaiblable hotfixes.

Regards,
Martijn

[Wolfgang]

I support like @Martijn wrote stay with a recommended version in a production environment. We started ElasticXL with VSNext in a really early state and had a lot of trouble with bugs and limited features, but now with the latest hotfix running R82.10 is a stable release.

[ccsjnw]

I would only ever deploy the Recommended product release (which is R82.10 with the latest Jumbo Hotfix Accumulator) for any customer. CheckPoint always prioritise the Recommended Release when targeting bugfixes etc. R82.20 is very, very new and not mature enough for customer deployment. 

[genisis__]

I will be upgrading some R81.10 VSX clusters to R82.10; R82.20, even though its tempting is just not viable at this stage.  
I plan to do a clean rebuild, apply the latest "wide adoption" Jumbo and then 'vsx_reconfigure'.  I personally find this a more predictable path then conducting an in-place upgrade.

[Alex-]

I had one instance, a couple of years ago, where I was called to troubleshoot an application going through VSX R81.10. The application owner was certain that the issue was because the firewall wasn't running R81.20 with its patch, the then recommended version. The IT director sided with the application owner and asked that I do the upgrade right now, on the spot, middle of the day, no questions asked.

Customer is king so I went ahead with CPUSE telling them to get ready, while still ensuring MVC and whatnot were working.

Actually it went smoothly, cutover was transparent and so on. As for the application, it turned out that It Was Not The Firewall (TM) but it's another story we're all familiar with.

Other VSX upgrades went R81.10 - R81.20 - R82 each with Blink and MVC, without any issues. So I reconsidered the "format the box whenever it's VSX" from there. R82.10 is another story with UPPAK unconditionally on, but I didn't try it yet on VSX.

[Alex-]

I have some installations coming up, Maestro + VSNext and I'm asking myself the same questions.

I'm considering starting with the R82.20 console so that is done, then MHO with R82.20 because upgrading them is always a challenge because of their limited disk space, but still the gateways with R82.10.

I'll discuss this probably with our SE. Installation is still some weeks off so there might be the first R82.20 JHF at that time.