VCAP6-NV (3V0-643) Study Guide – Part 17. NSX Universal Logical Network Objects.

This is part 17 of 20+ blogs I am writing covering the exam prep guide for the VMware Certified Advanced Professional 6 – Network Virtualisation Deployment (3V0-643)  VCAP6-NV certification.

At the time of writing there is no VCAP Design exam stream, thus you’re automatically granted the new VMware Certified Implementation Expert 6 – Network Virtualisation (VCIX6-NV) certification by successfully passing the VCAP6-NV Deploy exam.

For previous blogs in this series please refer to the VCAP6-NV Reference Guide I created. This has all the links to VMware NSX content and lists out each exam objective and the associated blog. Check it out here –>Exam Objective Reference Guide.

This blogs covers:

Section 6 – Configure Cross vCenter Networking and Security
Objective 6.2 – Configure and Manage Universal Logical Network Objects

  • Create/Configure Universal Logical Switches
  • Create/configure Universal Distributed Logical Routers
  • Configure local egress

Create/Configure Universal Logical Switches

For a Logical Switch to become a Universal Logical Switch it needs to be connected to the Universal Transport Zone.

Universal Logical Switches can only be created on the Primary NSX Manager and is the only NSX Manager where you can add Logical Switches to a Universal Transport Zone.

Log into the vSphere Web Client.

Click Networking and Security, then Logical Switches.

Select the Primary NSX Manager from the drop-down menu.

Click the green plus plus sign to Add a New Logical Switch.


You can see the Universal Logical Switch has been created and its scope is Universal. Note the Segment ID used.

log sw.JPG

If I change the drop-down to select the Secondary NSX Manager I can see the Web Tier Universal Logical Switch there.

log swi2.JPG

I can now add VMs to this Logical Switch that spans across both DCs (DC1 & DC2)

Create/Configure Universal Distributed Logical Routers

To read more about Distributed Logical Routers refer to Blog 7.

A Universal Logical Distributed Router (UDLR) can only be configured on the Primary NSX Manager.

To create and configure a Universal Logical Distributed Router.

Log into the vSphere Web Client.

Click Networking and Security, then NSX Edges.

Select the Primary NSX Manager from the drop-down menu.

Click the green plus plus sign to Add a New NSX Edge.

Select Universal Logical Distributed Router. Deploy the Edge Appliance (control VM) if you are going to use Dynamic Routing Protocols).


Note the Enable Local Egress option above. If you do not select this option then all ESXi hosts connected to the Universal Distributed Logical Router will receive the same routes thus all northbound egress traffic for both sites will exit via the same Edge Services Gateway at one site (cover this more in the next section).

Enter the username and password details. SSH etc.


Deploy the Control VMs (appliances) if you are going to use Dynamic Routing Protocols or the DLR Firewall.


Configure the HA interface and interfaces. I am adding my Web Tier Universal Logical Switch. You must have an HA Interface if you are deploying the control VM appliance.


Configure Default Gateway (if applicable).


The UDLR is now deployed and can be seen by both the Primary and Secondary NSX Managers as shown below.



I now have one Universal Distributed Logical Router (UDLR) that spans across two vCenter deployments.

I added a Universal Logical Switch to this UDLR via the Logical Interface (LIF)

I added a second Universal Logical Switch ( to this UDLR with the LIF

I have a VM at DC1 connected to the Universal Logical Switch and a VM at DC2 connected to the Universal Logical Switch. Both of these VMs can ping each other which confirms the UDLR is functioning.

Enable Local Egress

The exam blueprint says ‘enable’, nothing about configuring the whole gamut to make it work. I will go a bit deeper than just enabling the feature.

To use the Local Egress feature you need to enable this at the deployment time of the Universal Logical Distributed Router. You cannot enable post-deployment.

Make sure you tick the box Enable Local Egress.


Complete the deployment as per usual.

Now I have a UDLR deployed and Local Egress is enabled. This will restrict routes advertised to hosts. The high-level steps to get Local Egress functioning are:

Deploy an ESG at each site (DC1 & DC2) and configure the Uplink Interfaces to upstream services (other routers etc).

Configure UDLR Default Gateway (DC1 & DC2).

On the UDLR create two Uplink Interfaces; one to each sites ESG (DC1 & DC2).

Configure OSPF etc for routes to be advertised or static routes.

Once I had done this and played around for awhile I could tracert to external networks and I could see the egress traffic going via the local ESG. Nice.

A VM I had at DC1, running a tracert I could see external traffic going via the DC1 ESG. If I then vMotioned that VM to DC2 and did the tracert again I could see traffic now going via the DC2 ESG – with no change to the OS layer network settings of the VM.

VMware documentation – I had a hard job trying to find any. Have a read of Hany Michael’s blog here, this helped explain some of the local egress stuff.

And that’s it for this blog!

Blog 18 will cover Objective 6.3 – Configure and Manage Universal Logical Security Objects

Universal MAC Sets|Universal IP Sets|Universal Security Groups|Universal Firewall Rules|Universal Services and Service Groups

Follow me on Twitter or LinkedIn.

Be Social; Please Share.

  1. […] Objective 6.2 – Configure and Manage Universal Logical Network Objects […]



  2. […] Blog 17 will cover Objective 6.2 – Configure and Manage Universal Logical Network Objects […]



  3. Very nice article, thank you!
    One question: Is it also possible to deploy this scenario without the UDLRs?
    We currently only have Edges deployed, which are connected to Logical Switches and act as default gateways for the VXLAN-networks.
    My plan was now to deploy Universal Logical Switches and have Edges Deployed on Site B also, and then let dynamic routing do the failover.



    1. I don’t think there is a enough information there for me to make a valid comment. The reason cross-vCenter NSX is a great option is due to removing L2 adjacency issues. VMs at both sites are in the same L2 VXLAN which spans across L3 networks. Happy to put more thought into this if you supply a bit more information.



  4. Thanks for clear blog. i really appreciate your efforts.
    Just want to check on DC-2 “secondary site”, Do we need to deploy another Control VM? Are those VMs are in sync.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: