Migrating FWs to new boxes - Same management IPs

[Flashy]

Hello Guys

I am having following situation:

R77.30 mgmt and GW. Physical FW cluster of 2 fws is being migrated to newer boxes (from old HP proliant to CPSG 4800). As it is complex legacy network environment, we need to go with same IPs on all interfaces, including MGMT.

Also, we are using same CMA which is managing old boxes to manage new boxes. - Never done this before, but I will need to create another cluster object on CMA and configure it with same IPs on all interfaces - I assume CMA will have some reservations about such step as it is clear conflict right?.

I am trying to prepare this migration where new boxes will be configured ready as much as possible via LOM, and when migration day comes we will re-tag vlans on surrounding switches to direct the traffic flows to new boxes. From this moment for the first time I should have access to management and CMA should be able to establish SIC and push the policy.

But can such new cluster on CMA with same IPs as one already configured there coexist? It would be nice to have as simple rollback as possible, but not sure what are the options.

Can somebody share what would be the best approach step by step ?

[_Val_]

You do not need to create a new cluster object. In fact, you cannot have two different FW obejcts with the same IP in the same security domain. Use the old object, reset sic on MGMT side for it and create new SIC with the new FWs during the migration window. You will have some traffic cut when switching, and before SIC is established, and new policy is installed.

[Bob_Zimmerman]

The most straightforward method is probably to treat it like replacing a failed cluster member twice. This method depends on keeping the same version. You will also keep the same cluster object.

1. Make a management backup.
2. Shut down old member 1 or otherwise disconnect it from the world.
3. Bring up new member 1. Give it the same IPs and so on as the old member 1. IMPORTANT: Check Point branded boxes have udev rules causing them to have weird interface names. Your old member 1 will probably have names like "eth1". While your new box will have a few of those, anything in the card slot will have names like "eth1-03" which don't match the names of interfaces on open servers. Create an old-interface-name-to-new-interface-name mapping ahead of time.
4. In the management, reestablish SIC with the new member 1. IMPORTANT: Edit the cluster interfaces to use the new interface names as needed.
5. Push policy. Check the new member 1's cluster status for any issues.
6. If none are found, force a failover to the new member 1 and test traffic.
7. If traffic is good and you want to keep going, shut down old member 2 or otherwise disconnect it from the world.
8. Bring up new member 2. Give it the same IPs and so on as the old member 2. IMPORTANT: Remap interfaces as needed as above.
9. In the management, reestablish SIC with the new member 2. IMPORTANT: Edit the cluster interfaces in the object as above.
10. Push policy. Check the new member 2's cluster status for any issues.
11. Test failover and traffic to taste.

Rollback is as simple as powering off any new members, powering on the old members (the old members will still have their local copy of the policy, so they should be able to pass traffic as soon as they finish booting), restoring the management backup, and pushing policy.

Again, if at all possible, a version upgrade should be separate from a hardware swap. Changing the cluster object during all this (for example, if you put the hardware model in the name) is possible, but will require an outage (you can't sync between two cluster members which don't belong to the same cluster).

If you don't actually NEED to use separate IP addresses, it would be much easier and safer to just set up the new members as members 3 and 4 in the cluster, then remove the two old members.

ethtool -p <interface> can help you confirm which interface name is which physical port on your old servers.