vEnthusiast: Daily experiences from a VMware enthusiasts eye.: How NSX re-route traffic after a Stretched vMotion?

I happen to get in a discussion with a friend who is into Cisco ACI. We both were going into Pro's and Con's of both NSX and Cisco ACI. (No we didn't get into an ugly argument ;) ) but he was curious how would NSX work in an all Software environment.

He then brought in how would NSX re-route traffic once a VM has vMotion'd the vm to secondary data center. I asked back my friend how would Cisco handle this? Cisco takes help of Locator/ID Separation Protocol (LISP) protocol or global site load balancer (GSLB).

But how does NSX takes care of this? I had to do some research of my own and I thought it's better to blog about this for my personal reference and may be I can share it with my friend too ;)

So NSX can be configured for Cross vCenter. As you would might think vCenter's will be running on either site. It has to be paired with its own NSX Managers. One of them will assume the role of being Primary NSX Manager. With the use of Primary NSX Manager we create a Universal Controller Cluster, which assumes the role of the Control Plane. Primary NSX manager is responsible in creating all the universal objects for Cross vCenter NSX to work. We create Universal Logical Switch which spans across data centers. Universal objects are spanned through services called NSX Universal Synchronization Service. You could only edit these objects from Primary NSX Manager and could only be viewed from Secondary NSX Managers.

(Please download these pics for better view)

Detailed View

"On both primary and secondary NSX Managers, you can create objects that are local to that specific vCenter NSX environment, such as logical switches, and logical (distributed) routers. They will exist only within the vCenter NSX environment in which they were created. They will not be visible on the other NSX Managers in the cross-vCenter NSX environment."

Then we create a Universal Logical Distributed Router (UDLR) and enable local egress on it. We need to add the locale ID at both ends on UDLR.

"Locale ID; The value is generated on the individual NSX Managers. To Find the locale ID for a given Manager, migrate to the Manager Status page (Networking and security, NSX Managers, Choose a manger, and on the right, it will show the ID under status)

Once you have your Locale ID for each side, you need to configure your UDLR (Universal Distributed Logical Router), under NSX Edges. (Keep in mind, you must have deployed the UDLR with local egress enabled)

be aware, when you are editing the UDLR, you must select the NSX Manager for which you are editing (Primary / Secondary)

Add in the Locale ID for each Manager (have to edit twice).. and put in your individual gateway IP's for each site (NSX Edge at each site).

Also keep in mind for the IP / subnet you assign to the transport logical switch, needs to be a /29. Need 1 IP each for the edges (Site A, site B), and two IP's for the UDLR interface (IP and protocol IP for OSPF)

Also if you are doing any static routes, the documentation (and indeed the interface) indicates you have to add a locale ID but not quite so. In the same way you are adding different gateways to the UDLR config by entering the config under the context of whichever manager, you simply would add statics the same way (not entering locale ID, just editing under the appropriate side)