Migration from model 2200 R77.30 to 3200 R80.20

[amitmsh1995]

Hi Team,

we are going to migrate cluster checkpoint 2200 R77.30 to checkpoint 3200 R80.20, as we have less downtime, we want to do as active/standby migrate

step 1 -----we will first unplug cable from standby gateway of existing and plug to gateway of one of gateway of new firewall

step 2----we will do failover( will it work ?, as hardware model is different)

step 3----and vice versa, will do same for other member

step---if everything goes well, new 3200 model will be in cluster 

Additional step

1) Establist SIC with the new Secondary-FW Gateway.
2) Fetch the interface with Topology table on Secondary Firewall.
3) Check the CCP mode of existing Firewall and keep the same in Secondary New Firewall via CLI
4) Check the Cluster-id of existing Firewall and New Firewall......If cluster unable to form then we have to change Cluster id of New Secondary Firewall.
5) Check the CoreXL status & fwaccel status on new secondary Firewall. If all the parameter are matched as per expextation we should see
"cphaprob stat" in READY state which means FW is ready for Failover

Please suggest, can we go ahead like this?? or its better to migrate as a whole

[PhoneBoy]

You generally can't cluster different hardware models together and have it work.
Not sure you can do this without some minimal downtime.

[Maarten_Sjouw]

Let me comment on the steps below and update where needed:

A) replace backup gateway

1) Establish SIC with the new Secondary-FW Gateway, change the version of the object and push policy with the "If installation fails do not install" option un-ticked.
2) Fetch the interface with Topology table on Secondary Firewall.

      Never ever in a working cluster do this, all you need to do is update the interface names, when you change them, as both FW's use the same naming there should be no need if you move the cables to the same ports on the new gateway.
3) Check the CCP mode of existing Firewall and keep the same in Secondary New Firewall via CLI

      This could help, after the last change of the new members change it to auto or unicast.
4) Check the Cluster-id of existing Firewall and New Firewall......If cluster unable to form then we have to change Cluster id of New Secondary Firewall.

      Cluster will not form period. This is also what @PhoneBoy said, different hardware will not work (unless they accidentally have the same number of cores.
5) Check the CoreXL status & fwaccel status on new secondary Firewall. If all the parameter are matched as per expectation we should see
"cphaprob stat" in READY state which means FW is ready for Failover

      cphacu start - could be your lifesaver when you do get this right.

B) Failover by cpstop on old gateway.

C) Replace old gateway 1

D) Repeat step 1 and change the CCP setting

[Tim_Spencer]

That would be what I would try as well, but only if the number of COREs is the same between the 2200 and 3200 otherwise I do not believe it will work.

[Christopher__C2]

As another users mentioned, manually update the interface names instead of using the fetch option.  You should only need to change the interface name, not the IP address or any other properties. And, switching from a 2200 to 3200, even those interface names *might* be the same and need no changes.

And considering the difference in the number of cores will prevent firewall tables from being synchronized. But depending on your availability requirements this may be a very minor issue.  The firewalls will still failover and the new 3200  with R80.20 become active as soon as the 2200 with R77.30 is stopped.

New connections can be established immediately. Old connections will be dropped and need to be reestablished. But the vast majority of Internet user traffic is HTTP / HTTPS, and the chances of a user noticing a dropped connection is small to begin with, will generally just hit reload and not think about it much when it just works the second time.  If you are supporting users going telnet / ssh sessions through the firewall, they will probably see a disconnect (assuming the number of cores in use prevents syncing) bit should be able to reconnect immediately.

[Maarten_Sjouw]

You could even disable Stateful Inspection when you push the new gateway, thus all connections that were there will continue to be allowed, when they fit the policy. before putting the second new member in you can enable Stateful Inspection again.