Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Replace/Upgrade Cluster

Jump to solution

I currently have two 4800s in a cluster on R80.10. I am looking to utilize the same cluster name/configuration and replace these gateways with two 6500s on R80.30. I just wanted to brain storm on the easiest way to accomplish this. 

Also, seems like this should be a common ask. Are there any Check Point guides for something like this?

1 Solution

Accepted Solutions
Highlighted
When you start, the systems should have the following status:

[4800 A] -> active

[4800 B] -> standby

 

1. [4800 B] Poweroff the R80.10 the standby cluster member (4800 B)

2. [6500 B] Connect to R80.30 new member and configure interfaces and routes,... with the same settings from the old [4800 B]. 

3. Install SIC, add license, change cluster version, fix cluster member topology, install policy on gateway [6500 B] (remove flag "if fails") 

     Note: The member with the lower CCP version (GAIA version) remains active [4800 A]. 

4. [4800 A] Poweroff the R80.10 appliance (4800 A)

     Note: Now you're losing all your sessions and the [6500  B] should become active. If the number of cores (under CoreXL) is the same, you can do a fcu if necessary. This   synchronized the sessions on both gateways.

5. If possible delete all ARP entries on all participating routers in real time.

6. (6500 A) Connect to R80.30 new second member and configure interfaces and routes,... with the same settings from the old [4800 A] 

7. Install SIC, add license, fix cluster member topology, install policy on both new gateways (add flag "if fails")

View solution in original post

Tags (1)
17 Replies
Highlighted

Can you tolerate downtime?

If so, shut down old gateways, move name's/IP's to new ones, re-SIC, change your hardware and OS version/type and push policy.  Throw in a ARP table clear command as necessary.

 

If you can't tolerate downtime, then maybe a Connectivity Upgrade?  Though, the document doesn't note that a 80.10->80.30 upgrade is possible, yet.

https://dl3.checkpoint.com/paid/c8/c87af75dc02bd9852017cdfc763b923f/CP_Cluster_ConnectivityUpgrade_B...

 

0 Kudos
Highlighted
When you start, the systems should have the following status:

[4800 A] -> active

[4800 B] -> standby

 

1. [4800 B] Poweroff the R80.10 the standby cluster member (4800 B)

2. [6500 B] Connect to R80.30 new member and configure interfaces and routes,... with the same settings from the old [4800 B]. 

3. Install SIC, add license, change cluster version, fix cluster member topology, install policy on gateway [6500 B] (remove flag "if fails") 

     Note: The member with the lower CCP version (GAIA version) remains active [4800 A]. 

4. [4800 A] Poweroff the R80.10 appliance (4800 A)

     Note: Now you're losing all your sessions and the [6500  B] should become active. If the number of cores (under CoreXL) is the same, you can do a fcu if necessary. This   synchronized the sessions on both gateways.

5. If possible delete all ARP entries on all participating routers in real time.

6. (6500 A) Connect to R80.30 new second member and configure interfaces and routes,... with the same settings from the old [4800 A] 

7. Install SIC, add license, fix cluster member topology, install policy on both new gateways (add flag "if fails")

View solution in original post

Tags (1)
Highlighted
Thanks for all the replies. What exactly do you mean about the "fix cluster member topology" step?
0 Kudos
Highlighted
Silver

Interface names may not match between the 4800 and the 6000 Appliance so will need to update the Interface Names on the Cluster and Member so that match the name of the interface on the 6000 appliance as opposed to what named on the 4800.

Highlighted
Gotcha.
0 Kudos
Highlighted
Could I restore a backup of each 4800 into the 6500s? Just checking for faster configuration. Since this is a cluster, the current 4800s are in a cloning group too. Or should I look at using the "Load configuration" CLI utility?

As mentioned in a previous post, the only difference I see in interface name/topology is the 6500s have a new interface named "sync".
0 Kudos
Highlighted
Silver

Backups are for restoration to the same model appliance, ie 4800 to 4800.

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

From SK

Restore is only allowed using the same appliance model on the source and target computers.

 

Providing you make sure that is on the same version of code ie not upgrading

then you could save a config file on the 4800 and import onto the 6500 but should be the same version.

This will get the Gaia OS config only.  Any Check Point tweaks will still have to do manually.

 

 

0 Kudos
Highlighted
Gold

Kevin,

like Tommy mentioned, preconfigure the new nodes with the same configuration ( IPs, VLANs, routing etc. )

Maybee you can too preconfigure new switchports, connect the new gateways and have ports shutdown.

In a maintenance schedule you have to disable the old switchports, enable the new one, reset SIC and change version and appliance type in the cluster object.

I think a zero downtime upgrade is not possible, because of the different architecture and CPU of 4800 and 6xxx appliances.

Wolfgang

0 Kudos
Highlighted
Is management on the gateways or do you have a separate management server?
The installation and upgrade guide from Check Point, per version, is a very comprehensive and complete guide.
Regards, Maarten
0 Kudos
Highlighted

Separate management. Unless I missed something, I don't really see something that covers the scenario I described.

0 Kudos
Highlighted

All in one (management+gw) or dist. installation?

0 Kudos
Highlighted
Distributed.
0 Kudos
Highlighted
Changing the topic a little bit. The only other hiccup I can think of is this cluster has Remote Access VPN using the SSL Network Extender, primarily. Does anyone have any experience on how this kind of HW replacement will access Remote Access? Anything to look out for?
0 Kudos
Highlighted
Silver

Providing using the same Certificates for VPN and ICA etc then should be good to go still.  If using the same Object then these should all remain the same.

0 Kudos
Highlighted
OK, that's what I figured. Yah, that's all staying the same.
0 Kudos
Highlighted
Can anyone speak to their experience with this type of replacement and upgrading the SNX client? If force update is off, would the R80.10 client connect to an R80.30 gateway? Would you just grab the .msi files off the R80.30 gateway to push out to clients?
0 Kudos
Highlighted

Thanks so much for all the replies to my question! My replacement went very well!

0 Kudos