Need a bit of clarification/sanity check for my hardware migration plan

[Joe_Kanaszka]

Hey guys.  So as mentioned in a previous post, I'm tasked with migrating a Check Point R81.20 (2) node cluster from 5100s to 9100s.

Both new appliances are racked with their LOM cards activated.

For now I've put IPs on the Mgmt interfaces on both 9100s just to be able to activate the gateways and install the latest JHF (118).

I've exported the configs from both 5100s and copied what I thought were the important pieces over to the 9100s:

• bootp configs
• Interfaces
• Allowed clients
• DNS
• Static routes
• NTP
• SNMP config

The only interface cabled on the 9100s is the temporary management interface.

Using this guide:

-------------------------------------------------------------------------------------------------------------

When you start, the systems should have the following status:

• [5100 A] -> active
• [5100 B] -> standby

1. [5100 B] Power off the R81.20 standby cluster member (5100 B)
2. [9100 B] Connect the new R81.20 member and configure interfaces and routes with the same settings from the old [5100 B]. 
3. Install SIC, add license, change cluster version, fix cluster member topology, install policy on gateway [9100 B] (remove flag "if fails") Note: The member with the lower CCP version (GAIA version) remains active [5100 A]. 
4. [5100 A] Power off the R81.20 appliance (5100 A).  Note: Now you're losing all your sessions and the [9100  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.  (What is FCU?)
5. If possible delete all ARP entries on all participating routers in real time.  
6. (9100 A) Connect the new R81.20 second member and configure interfaces and routes... with the same settings from the old [5100 A] 
7. Install SIC, add license, fix cluster member topology, install policy on both new gateways (add flag "if fails")

----------------------------------------------------------------------------------------------------------------

So just a couple questions:

My interfaces are different on the new 9100s.  I've moved one ISP around and now I have "sync" interfaces on the 9100s.

So now for step 3 & 7, I would need to go into Smart Console "Network Management", select an interface, go to the "Advanced tab" and then choose the new interface name for the new 9100:

Is this correct?

Thank you again!

[Joe_Kanaszka]

• [5100 A] -> active
• [5100 B] -> standby

1. [5100 B] Power off the R81.20 standby cluster member (5100 B)
2. [9100 B] Connect the new R81.20 member and configure interfaces and routes with the same settings from the old [5100 B]. 
3. Install SIC, add license, change cluster version, fix cluster member topology, install policy on gateway [9100 B] (remove flag "if fails") Note: The member with the lower CCP version (GAIA version) remains active [5100 A]. 
4. [5100 A] Power off the R81.20 appliance (5100 A).  Note: Now you're losing all your sessions and the [9100  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.  (What is FCU?)
5. If possible delete all ARP entries on all participating routers in real time.  
6. (9100 A) Connect the new R81.20 second member and configure interfaces and routes... with the same settings from the old [5100 A] 
7. Install SIC, add license, fix cluster member topology, install policy on both new gateways (add flag "if fails")

----------------------------------------------------------------------------------------------------------------

So just a couple questions:

My interfaces are different on the new 9100s.  I've moved one ISP around and now I have "sync" interfaces on the 9100s.

So now for step 3 & 7, I would need to go into Smart Console "Network Management", select an interface, go to the "Advanced tab" and then choose the new interface name for the new 9100:

[Duane_Toler · Accepted solution]

You need to change the name of the interface on the top line (where it shows ETH5 in bold text); that's the name of the interface for the gateway.  Yes, you need to verify this interface name on the advanced section as well.

For Gaia config, you also want the section for user names, RBA roles, expert password hash (but you might want to re-enter this manually so you are certain to get the SHA512 hashes instead).

You may want to check the 5100 and 9100 datasheets carefully; I'm not sure you want to try to cluster mixed appliances with these as they might have different CPU core counts.  You can check yourself with "show asset all" in CLISH.

FCU is "full connectivity upgrade" for clusters.  This is in the ClusterXL Admin Guide, but it's really only relevant for minor version upgrades on existing hardware.  Mismatched hardware isn't going to sync cleanly (or at all).  Since you're doing all-new hardware, you really should plan for full downtime and not expect to maintain any sessions.

You're asking for more trouble than it's really worth to do the "monkey-bar" kind of switch, and of course it'll take more time.  If you're having interface name changes on clusters, and you are with new hardware, then you're inviting trouble with trying to cluster two different pieces of hardware with different interface names.

Make the switch all at once and you'll have better luck, and not be distracted with troubleshooting the wrong thing mid-way through it.

[Joe_Kanaszka]

Good morning Duane and thank you for your response.  It makes total sense.  One question though then.  What is the best way to get my policy on the new appliances?  Just disconnect the old 5100s and reconnect the new 9100s and push policy?

[Duane_Toler]

If your management server is not directly connected to a local LAN segment of one firewall interface, then you will need to clear the ARP on your layer-3 next-hop gateway (layer3 switch or router). If your management server is connected to a local LAN segment, then you likely will need to delete the ARP entry on the management server (arp -d ...).  From the new appliances, test ping your management server before trying to install policy.  If your management server is not yet R82, and the management server is behind a 3rd party NAT gateway (e.g.: CloudGuard), then you will need to set the $FWDIR/conf/masters file with the IP of your management server.

Assuming you got the interfaces and return routes back to the management server (wherever that may be), then in SmartConsole you will need to reset SIC for each gateway, check/verify the interfaces, make sure the Version drop-down box is updated (or just click "Get" for product/version info).  When you reset SIC, SmartConsole will automatically do an interface fetch for you (this is sometimes un-helpful, but sometimes it is useful), so verify (or fix) whatever it generates for you.

If test ping works from the new gateways to the management server, then you're clear to install policy to the new gateways.

[the_rock]

EXCELLENT points Duane.

[Bob_Zimmerman · Accepted solution]

The interface name at the top of a cluster interface is actually free text. It can have parentheses, spaces, and so on. When you create a new cluster interface, the name you provide sets both that free text string and the interface names in the Advanced section. Changes to the cluster interface name don't propagate to the Advanced section. The names in the Advanced section are what actually matter. They must match the name of the interface on the firewall, otherwise you get some weird behavior. You can specify a totally different interface on each member (like eth5 on one member and bond2.845 on the other member), and it will work properly as long as the specified interface on each member actually goes to the same network.

You're right about the core counts: the 5100 has two cores, while the 9100 has four cores plus hyperthreading for eight effective cores presented to the OS. This probably won't sync. I did learn something interesting when upgrading a 16200 to R82, though: apparently it's sometimes possible to sync fewer cores to a greater number of cores. I wouldn't count on that here, but it's worth testing for the future.

[the_rock · Accepted solution]

Hey brother,

@Duane_Toler is 100% right, cluster interface has to show right name. Just remember, all smart console will do is FETCH the information it gets from the fw OS level, and afterwards, you can edit it they way you wish to reflect correct anti spoofing settings.

If you allow remote, message me directly, we can connect and go through it together.

[Joe_Kanaszka]

Thank you Andy.  I may take you up on this!  

[the_rock]

Please do, I always love to help, not an issue.

[the_rock · Accepted solution]

Hey brother,

Here is something else to consider as well, but please be free to message me offline, happy to do remote, would just need to be either when Im taking a break or after hours, if okay with you.

*******************************

Since your new 9100s have different NIC layout (e.g. one ISP moved, new dedicated sync interface), yes — you’ll need to update the interface mappings in SmartConsole.

Here’s what to do:

1. Keep the same IP addresses and subnets that the old 5100 interfaces had (to avoid topology mismatches and policy issues).

2. In SmartConsole → Gateway Properties → Network Management:

   • Click each interface.

   • On the Advanced tab, check the Interface Name dropdown.

   • Choose the new interface name as it appears on the 9100 (e.g. eth1-01 instead of eth2).

   • Verify the topology and anti-spoofing settings are correct.

3. Make sure your Cluster Topology (under Cluster Object → Topology) reflects the correct network mapping for both new members:

   • Each member’s interface names should match what’s on the appliance.

   • Double-check your Sync interface — it must be the same subnet on both members and marked as "Cluster Synchronization".

4. Install policy after fixing all of that (with the “if fails” box unchecked for the first new member you bring in).

That’s the correct and clean way to handle the physical NIC name changes.