Checkpoint Cluster Firmware Upgrade

[ashah]

Hello experts, 

I am in planning of checkpoint cluster (HA) firmware upgrade procedure. We are running version R80.10 and planning to go on R80.30 code version. as this the first time in am doing a firmware upgrade on cluster i need more clarification on what method i should go for. Guide says there are 4 methods for the upgrade:

1)Minimal Effort Upgrade

2)Zero Downtime Upgrade

3)Connectivity Upgrade of a Cluster

4)Optimal Service Upgrade of a Cluster

I am definitely going to have maintenance window for this work. I am more confused between connectivity upgrade and Minimal effort upgrade. Connectivity upgrade lets us upgrade without any Network disruptions and Minimal effort upgrade allows the most simplest way to upgrade which via upgrading each security gateway individually. 

I know, it is totally up to me what method i want to go for, but i really need your recommendations on which path i should go for, in case you guys might have experienced easy going way from above methods. 

Thanks in Advance !!

[genisis__]

Suggest going to R80.40 with JHFA118.

What appliances do you?

are they locally accessible or remote only?

I take it you have an activate standby pair?

Has there been any custom modifications to an files on the appliances you have?

[ashah]

Thank sir for responding, 

What appliances do you? --> 4000 appliances hardware 

are they locally accessible or remote only? --> mostly remotely, i will try to get local access too

I take it you have an activate standby pair? --> yes, correct 

Has there been any custom modifications to an files on the appliances you have? --> i did not get this part, but i am concerned about how checkpoints apply initial policy after the upgrade. can you please throw some light here? 

[Vladimir]

For the "custom modification to the configuration files on the appliances" see sk160392.

Those are relevant if you are performing clean install on your cluster members.

If that is the case, find the files that are present and copy them for references.

If you are performing an upgrade, the policy is loaded on the first upgraded cluster member before you failover to it.

[genisis__]

Here is my suggestion as a guide:
Pre-Req:
Manager must be running R80.30 or Above with latest GA release, ideally manager should be running R80.40 or R81
Manager should have access to the internet.
Ensure you have a local resource to support the activity.
Any customised files should be copied offline and modifications restore on newly built gateway if required (Optional)

- Create snapshot of all appliances and store image offline
- save GAIA configuration and save offline
- Using ISOMorphic tool create a USB image.
https://supportcenter.checkpoint.com/supportcenter/portal/role/supportcenterUser/page/default.psml/m...
https://supportcenter.checkpoint.com/supportcenter/portal/role/supportcenterUser/page/default.psml/m...
- Detach the existing gateway license via SmartUpdate and export this offline, then delete it.
- Do a clean installation of the standby 4600 (assumed you have 4600 and not 4400, but I don't believe the image file would change) appliance and put the GAIA configuration back on.
- Install latest CPUSE agent
https://supportcenter.checkpoint.com/supportcenter/portal/role/supportcenterUser/page/default.psml/m...

- Complete configuration wizard via https

- upload and install latest GA Jumbo release for R80.40 (Take_118) 
https://supportcenter.checkpoint.com/supportcenter/portal/role/supportcenterUser/page/default.psml/m...
- Re-Sic/Push Policy.
- If manager has access to the internet and your running R80.40 or above the license should get installed to the gateway via the manager automatically, if not then of course add the license back in and then push to the Gateway.
- Check HA stat using 'cphaprob state', it should be Active/Ready I believe.
- via clish enter:

'set cluster member mvc on'

'save config'

- Check HA stat using 'cphaprob state', it should be Active/Standby.
failover to the new node and test.

- Once you are happy with everything on the new node, the repeat this process for the remaining member.

- When the remain member is running R80.40 you can turn of mvc "set cluster member mvc off".

Note:

Yes - you could do an in-place upgrade, but I believe it is better (and actually the recommendation from TAC) to do a clean build.

[Boaz_Orshav]

In order to reduce the number of steps it is recommended to use a "Blink" package which includes the GA version and a Jumbo.

Using this package you need only one installation (and one reboot) instead of separately installing the GA and then the Jumbo.

Also - in case you have more then one cluster, I suggest you consider using CDT. It's a central deployment tool that requires short learning curve but in case you will need to upgrade several clusters it worth it.