In VRRP cluster, IPSO-390 Voyager and 5600 Gaia R77.30 appliances together

[Myo_Min_Zaw]

Hi,

In VRRP cluster, IPSO-390 Voyager and 5600 Gaia R77.30 appliances together? Initial setup is both of IPSO-390 appliances are VRRP cluster? During migration, take out one IPSO-390 appliances and connect with ne 5600 Gaia R77.30 gateway and form for VRRP cluster, that is possible approach?

Thanks.

[PhoneBoy]

Only identical hardware may be used in a cluster.

The IP390 and 5600 are NOT identical hardware.

[Myo_Min_Zaw]

Dameon, Thanks a lot for your confirmation. 

[Maarten_Sjouw]

that is to say the cluster itself will work, vrrp will work between different OS's even. Your scenario to replace the IP390's by 5600's will work just fine. The only thing is when you switch from the 390 to the 5600 you will not have session table synchronization, therefore you will loose all running connections.

VRRP will just do what you need it to do, keep the downtime to a bare minimum.

Clustering on the Checkpoint level is not available in this case, but is not really required, you just want be sure to be able to move the IP's over to the new member as soon as you change the priority.

One advise, make use of the command set vrrp disable-all-routers on on the new members during the migration so they will not take over until you are ready.

[Myo_Min_Zaw]

Dear Maarten,

Thanks a lot for your input and great explanation also. Well noted with thanks.

[Myo_Min_Zaw]

Hi All,

Migration is successful.

Steps are as per below:

1. Disconnection the network cables from Backup VRRP cluster in IPSO-390 appliance.

2. Connect the cables to Backup VRRP cluster at 5600 - Gaia appliance.

3. Reset SIC and fw unloadlocal and SIC is established at backup VRRP cluster.

4.  And, perform above 1-3 steps in Master VRRP cluster at 5600 - Gaia.

5.  And then, Get topology, version at cluster object.

6.  Push down the policies to Cluster object. but Push policies is failed.

7. But, manage to resolve the issue after follow-up as per below kb. And, all of VRRP cluster are up and running and policies are able to push down the cluster object also.

VRRP cluster members are in "Backup/Backup" state 

Thank you, everyone in this post!

[Maarten_Sjouw]

cpconfig should have been run directly after the FTW and make sure clustering is enabled.

Also make sure that the priority is lower than the current active member and vrrp disable-all-virtual-routers is set to on.

Step 4 Get topology for the replaced member

Step 5 Push policy (uncheck the box for all members to install or not install at all) 

Step 6 issue: set vrrp disable-all-virtual-routers off on the new member and check state of VRRP (all backup) and cphaprob stat (active/active) to see how clustering is doing

If all is well continue:

Step 7 Switch over to the other member by raising priority on the 5600

Step 8 Check state of VRRP and cphaprob stat to see how clustering is doing

If all is well repeat step 1 to 6 on the other member.

This will give you a minimal downtime (sort-of zero downtime)

[Myo_Min_Zaw]

Dear Maarten,

Well noted with thanks. Thanks great for your tips also.

Thanks and regards,

Myo Min Zaw

[Hugo_vd_Kooij]

We strongly prefer ClusterXL in HA mode over VRRP.

So in that case you would have a big bang moment in your transition.