ClusterXL – Changing MGMT and eth2 from 1Gb to 10Gb

[jennyado]

Hi all,

I need assistance with upgrading the physical interfaces on a Check Point 9300 ClusterXL. The customer wants to change the mgmt and eth2interfaces from 1 Gbps to 10 Gbps. Below is the current scenario and my concerns—could you please guide me on the exact steps to perform this upgrade safely?

These are the actual interfaces:

The goal is migrate mgmt to a 10 Gbps port (e.g., eth1-01) and eth2 to another 10 Gbps port (e.g., eth1-02), replacing the 1 Gbps interfaces.

The plan is perform the change on the passive member first, configure the new interfaces, migrate the proxy ARP for eth2, and then failover to the passive member.

Concerns

1. Since this is a cluster, hardware must be identical. Will a temporary mismatch (one member with 10G, the other with 1G) cause a failover or break ClusterXL?

2. What happens to the proxy ARP on eth2 during migration? Do I need to manually update ARP entries?

3. Is it safe to proceed by powering down the passive member, connecting the 10G cables, configuring the new interfaces, and then rejoining the cluster? Will this disrupt the active member?

4. After failover, how do I ensure the cluster stabilizes with both members using 10G interfaces?

Looking for guidance from anyone who has performed a similar upgrade.

Thanks!

[the_rock · Accepted solution]

Last time I did this with a customer, we followed these steps:

backup member first:

set desires interface to off

change the speed

set it back on

did not need to update arp entries

followed same on master, got interfaces without topology in cluster object, installed policy

there was no failover

Andy

[emmap · Accepted solution]

The safest and simplest way is just to take the outage while changing the interfaces to what you want them to be (make sure you have LOM/console access if you normally log on to the appliances through one of the interfaces you are touching), fix the topology in SmartConsole, unload the policy from the gateways and then push the updated policy out. 

You'll have to fix any manual proxy ARP configuration and any other configuration specific to interface names (DHCP, management interface, like that) so make sure you thoroughly check the existing config first to find all that. Automatic proxy ARP will update when you push the updated policy out.

[Bob_Zimmerman]

In SmartConsole, open the cluster, go to Network Management, open one of the interfaces, and go to the Advanced section. You can back the virtual interface with one interface name on one member and another name on the other member. That enables the process my team uses:

1. Pick a member to work on first. Pin it Down using 'clusterXL_admin down'.
2. Build a bond with the new interface in it. If you only intend to have one interface, just leave it with the default bonding mode. This doesn't require any configuration on the switch side for a single interface. Optionally add subinterfaces to the bond if you need the interfaces to have VLAN tags.
3. Remove the address from the old interface. Add the address to the bond or subinterface.
4. In SmartConsole, edit the cluster interface object and update the name of the interface for the member you have modified. Be aware the members may not be in the order you expect! Hover over each member to view its full name!
5. Repeat steps 2-4 for each interface you want to move.
6. Push policy.
7. Use 'clusterXL_admin up' on the member you have modified to let it go back to Standby. If it stays Down, troubleshoot. Check the physical interface, check to be sure the other side has all the necessary VLANs, and so on.
8. Fail over ('clusterXL_admin down' on the active member to move traffic to the member you've modified), then repeat steps 2-7 on the next member of the cluster.

Proxy ARP entries will need to be updated to the new interface. That's easy enough, though. Just 'delete arp proxy ...' then 'add arp proxy ...' using the same command with the new interface name.

It gets a little more complicated if you have three or more members in the cluster, but not much. You just have to keep track of which members have been modified and take them one at a time.

Note that the interface named Mgmt is not special in any way other than its name. There is, however, a 'set management-interface' command in clish. The member must have one interface listed as the "management interface" in that command. All it does is prevent you from removing the IP, shutting down the interface, and other things which would likely break your ability to connect to the system. If the interface named Mgmt is set as your management interface, you will need to use 'set management-interface' to set it to some other interface before you will be able to remove the IP and stick it on the new bond.

Once your interfaces are moved to bonds, it's a lot easier to do this kind of thing in the future. For example, moving from 10g to 25g is purely command line: add the 25g interface to the bond, remove the 10g interface from the bond, done.