This blog post provides following about Cross vCenter NSX
  1. Overview
  2. Use Cases
  3. How Cross vCenter NSX works
  4. Sample Topology
  5. Installation and Configuration
  6. Validation


Pre-NSX 6.2, although NSX provides the flexibility, agility, efficiency and other benefits of network virtualization, the logical networking and security was constrained to the boundaries of one vCenter domain
The Cross-VC NSX feature introduced in VMware NSX 6.2, allows for NSX networking and security support across multiple vCenters. Logical switches (LS), distributed logical routers (DLR) and distributed firewall (DFW) can now be deployed across multiple vCenter domains.
These Cross-VC NSX objects are called Universal objects. The universal objects are similar to local objects such as distributed logical switches, routers, and firewall except they have universal scope, meaning they can span multiple vCenter instances.
With Cross-VC NSX functionality, in addition to the prior local-site scope objects, users can implement universal objects such as Universal Logical Switches, Universal Logical Routers, and Universal DFW across a multi-vCenter environment that can be within a single data center site or across multiple data center sites.

Use Cases

Cross-VC NSX enables following key use cases .  For detailed information please refer the Cross VC NSX Design Guide (Link provided in the References section)
  • Work Load Mobility
  • Resource Pooling
  • Unified Logical Networking and Security Policy
  • Disaster Recovery

How Cross vCenter NSX works

In a cross-vCenter NSX environment, you can have multiple vCenter Servers, each of which must be paired with its own NSX Manager. One NSX Manager is assigned the role of primary NSX Manager, and the others are assigned the role of secondary NSX Manager.
The primary NSX Manager is used to deploy a universal controller cluster that provides the control plane for the cross-vCenter NSX environment. The secondary NSX Managers do not have their own controller clusters.
The primary NSX Manager can create universal objects, such as universal logical switches. These objects are synchronized to the secondary NSX Managers by the NSX Universal Synchronization Service. You can view these objects from the secondary NSX Managers, but you cannot edit them there. You must use the primary NSX Manager to manage universal objects. The primary NSX Manager can be used to configure any of the secondary NSX Managers in the environment.
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.

Sample Topology

Installation and Configuration

Key here is that you can start of deploying NSX Managers as standalone and later assign them specific roles i.e. Primary or Secondary
In this blog I will only include details which are specific to Cross VC NSX. I have written detailed blog for standard standalone NSX Setup. You can refer the same
Also in my setup I have both vCenters in Linked Mode. It is not mandatory to have vCenter’s in linked mode however it gives us option to manage it from single pane of glass and linked mode has its own benefits/use cases which can be researched


Assign Primary NSX Manger Role

Navigate to Networking and Security via Site A (PROD) vCenter
Click Actions and Select “Assign Primary Role “
NSX Universal Synchronization Service will change status to Running in PROD NSX Manager

Add Secondary Manager

Click Actions and Select “Add Secondary Manager”
It will prompt you for credentials. Please ensure to specify “admin” credentials and Accept the Certificate
You can observe the Role Column added under NSX Managers

Configuring Primary NSX Manager

Following steps needs to be configured on Primary NSX Manager

Adding Universal Controller(s)

You can add controller(s) while it is in standalone role and then later update the controller state after the roles have been assigned so that it replicates Secondary NSX Manager

Segment ID for Primary NSX Manager

Navigate to Segment ID under “Logical Network Preparation”
Notice the Universal Segment ID section

Universal Transport Zone on the Primary NSX Manager

In my lab I only have “Single Cluster” which I will be using hence i will creating single Universal Transport Zone. In Production, you may have multiple Transport Zones and you can have multiple combination of Universal and Local Transport Zones
Please ensure to Check Box where it says \”Mark this object for Universal Synchronization\”

Universal Logical Switch on the Primary NSX Manager

We need to ensure Logical Switch we create we have to ensure we connect to Universal Transport Zone we created earlier
I will be creating 2 Universal Logical Switches
  1. Universal Transit LS ( DLR will be attached to ESGs which will be deployed 1 per Site)
  2. Universal App LS (VMs will be attached to this)

Universal Logical (Distributed) Router on the Primary NSX Manager

Now we will deploy UDLR and connect it to the Universal Switch we created earlier.
Navigate to NSX Edges section and click “+”  If you have deployed NSX Edge on Standalone NSX Manager you would have only seen 2 options
Edge Services Gateway and Logical (Distributed) Router.
After you have enabled Primary for the NSX Manager you can now deploy Universal Logical (Distributed) Router  
One key item which I want to highlight is “Enable Local Egress”
Local Egress can be enable on UDLR at the time of deployment only hence it is key to Check or Uncheck as per your design.  You can read more about Local Egress
Rest of the steps is pretty much same as standard DLR
Once it is successfully deployed you can see the Universal Distributed Logical Router in both Primary and Secondary NSX Managers

Configuring Secondary NSX Manager

Following steps needs to be configured on Secondary NSX Manager

Segment ID for Secondary NSX Manager

Navigate to Segment ID under “Logical Network Preparation”
This would be local Segment IDs for local Site and standard configuration. You will already see the Universal Segment IDs on the screen for Secondary Manager

Universal Transport Zone on the Secondary NSX Manager

Universal Transport Zone will already be prepopulated on Secondary NSX Manager however we will need to add Clusters specify to Site B (DR)
If you notice the option to \”Mark Universal Transport Zone as Universal Synchronization\” is already greyed out as this is Secondary NSX Manager
As soon as you add the Clusters it will automatically create the Port Group for Universal Logical Switch we already created on Primary NSX Manager
With this we finished configuration specific to Cross VC NSX .


I performed following steps to perform validation to ensure Cross VC NSX Networking works as per Sample Topology mentioned earlier
  • Created Universal Logical Switch named “ Universal App LS”
  • Added “Internal” interface in Universal Distributed Logical Router and connected to “Universal App LS” with IP as
  • In Site A(PROD)  – Deployed Linux VM with IP & Gateway and attached it to “Universal App LS”
  • In Site B (DR)  – Deployed Linux VM with IP & Gateway and attached it to “Universal App LS”
  • Verified following from PROD Linux VM
  • Able to ping Gateway (UDLR) IP i.e.
  • Able to ping DR Linux VM i.e.
  • Verified following from DR Linux VM
  • Able to ping Gateway (UDLR) IP i.e.
  • Able to ping PROD Linux VM i.e.

As the both VMs are part of same Universal Logical Switch they are able to reach each other via standard VXLAN to VXLAN communication
Traffic gets encapsulated in VXLAN headers and travels between sites via VTEPs


Following are the references I used to setup my infrastructure and write this blog. You can refer them for more information which might be specific to your design

3 thoughts on “Cross vCenter NSX

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: