Two ClustersVSX withing same mgmt and VSs having Same IP Address

[Oscar_David_Gom]

Hi,

I have a question that I've already asked to AI Copilot but maybe I need some confirmation.

In this moment I have a MGMT with "VSX Cluster A", 2 Cluster Members and 3 VS connected each other by a VSW.

I need to create, in the same MGMT, a second cluster "VSX Cluster B", w/ 2 Cluster members and 3 VS connected each other by a VSW.

The user data interfaces are going to be completely disconnected to avoid duplicated arp on network. The main goal is to migrate ClusterA to B just disconnecting user data interfaces from A and connecting B.

Here is the thing, ClusterB members are going to have different MGMT IP address than ClusterA, different name and different VSX internal network, but every ClusterB's virtual system needs to have the same interfaces ip addresses, routes and main address than the ClusterA ones have, just that instead of eth1, they are going to be all bonds.

So if ClusterA_VS1 main address: 192.168.11.10

                               eth1.3: 192.168.11.10

                               eth2.10: 192.168.10.1

                               eth3.111: 192.168.20.1

                               eth4.212: 192.168.30.1

ClusterA VIP MGMT: 10.10.10.1/24

ClusterA_Member1 MGMT: 10.10.10.2/24

ClusterA_Member2 MGMT: 10.10.10.3/24

Then ClusterB would be: main address: 192.168.11.10

                               bond0.3: 192.168.11.10

                               bond0.10: 192.168.10.1

                               bond1.111: 192.168.20.1

                               bond1.212: 192.168.30.1

ClusterB_Member1 MGMT: 10.10.10.11/24

ClusterB_Member2 MGMT: 10.10.10.12/24

ClusterB VIP MGMT: 10.10.10.10/24

Is this scenario posible?

I hope I'm being clear. Is basically replicate VSs configuration from ClusterA to ClusterB (not the mgmt/sync/internal network configuration/interfaces name).

I know that, when I install policy, mgmt sends them to the cluster members ip addresses and then its being sent to the relevant context. So I think policy installation wouldnt be a problem. Logs can be? VSX Management database could drive crazy w/ this?

Maybe im not seeing another problems that could happen or if the MGMT can say NO even before I start.

(I wish I could use VSNext, but IPv6 its a big You CAN'T in this moment).

Regards. David.

[emmap]

This will work, just make sure if you're using VPN blade, do not have it enabled on both VSs at the same time, as the tunnels will break. 

[Wolfgang]

We did such a change last year. Everything was fine except RemoteAccess VPN. Unexplainable errors after the switch to the new system. Disconnected remote workers, not getting connected .....

The problems are solved after deleting the "old" VS-object. 

[Martijn · Accepted solution]

Hi David,

If you do not have VPN configured, you can create the VS's on the new VSX cluster and when you are ready to migrate, just disable the switchport connecteds to cluster A en enable the switchports connected to cluster B.  If you have a large configuration on the VS's, use the VSX provisioning tool.

But if you have VPN configured, there is a procedure you can use. But be carefull when performing the procedure.

You have the current VS on cluster A called VS-A with VPN configured. And the same new VS on cluster B called VS-B.
When you configure VPN on both and push policy to both, VPN will break. But If you DON'T install policy on VS-A, you can migrate with VPN enabled.

1. Prepare VS-B with the same configuration as VS-A, but do not configure VPN on VS-B yet.
2. When ready to migratie, enable VPN on VS-B. Configure Encryption Domain and Link Selcetion correctly.
3. Replace VS-A for VS-B in the VPN communities.
4. Disable VPN on VS-A.
5. Push policy to VS-B
6. Disable switchports connected to VS-A
7. Enable switchports connected to VS-B

I have tested the procecure in my lab and it works. I suggest you do the same in a lab environment when you have the option before you migrate production.

But again. Do not install policy on VS-A during the procedure or VPN will break!!!

The roll back are the steps in reverse.

Hope this helps and good luck!!

Martijn

[Oscar_David_Gom]

Hi,

I've understood all steps but 4, what do you mean with disable VPN on A? If im not gonna install policy on A, it'll be just, open VS object, disable VPN, push VSX configuration and that's it?

Regards. David.

[Martijn]

Hi David,

Yes, that's it. When installing the policy to VS-B, you also push the object of VS-A without VPN enabled. So there is no conflict with VS-B where VPN is enabled.

I will perform this procedure just minutes before migrating. When changing a VS, you push the VSX configuration to the VSX gateways. Maybe nothing happens because you do not install the policy on VS-A. But I would take no risks.

Martijn