Cross Vcenter NSX with OSPF

Cross Vcenter NSX Design Guide
Intra area routes versus inter area routes

In one of the earlier posts, we have covered running OSPF in NSX domain.

Here we try to cover running OSPF in a Cross Vcenter NSX setup.

In the above topology:
1. There are two NSX managers.
Primary NSX manager in site 1
And secondary NSX manager in site 2
This is a Active/Passive model.

2. One vcenter in site 1 and the other in site 2

3. Universal Distributed Logical Router UDLR is connected to edges in primary & secondary site using a single Transit logical switch.

4. There are two edges in site 1 and additional two edges in site 2

5. The edges are connected to physical routers as shown above.

6. The physical routers are OSPF Area Border Routers interfacing with OSPF backbone area 0.

7. Totally NSSA area configuration is applied in this setup.
The Area Border Routers are injecting a default route automatically into the NSX domain.

8. Only one Universal Transport Zone can be created to span both the sites.

9. Universal Distributed Logical Router UDLR spans both the sites and allows connecting workloads from both the sites.
The status of UDLR in primary site is ‘deployed’ while in the secondary site it is ‘active’.

10. Universal Distributed Firewall spans both the sites.

11. Universal Controller Cluster is deployed in Site 1

12. Universal objects can be created only from the Primary NSX Manager.
If there is a need to deploy additional UDLR, then this has to be done from Primary NSX Manager only. In this case the UDLR will consume resources (compute, memory and storage) of Site 1

13. UDLR control VM will reside in Site 1 and will establish OSPF peering with NSX edges from both sites 1 and 2.

14. Site 1 is preferred for ingress/egress traffic because the OSPF cost is increased for links between Site 2 physical routers and Site 2 NSX edges.

More traffic flows are discussed in traffic flow section below.


Let’s map this NSX topology with Cisco routers and explore the routing tables on devices.

Subnet is connected to router UDLR.

And we check the route lookup for on routers:
1. Core2
2. Core1
3. Physical Router 1 of Site 2
4. Edges of site 1 and site 2

Note the route lookup for on Site 2 router 1 prefers the route towards NSX edges in the same site, site 2.
This is despite increasing the OSPF cost on the links connecting Site 2 physical routers and Site 2 NSX edges.
This is because OSPF prefers intra area routes as compared to inter area routes.

Above output shows that OSPF metric is increased to 120 via Site 2 physical routers.

Route for on Core2

 Next hop from Core 2 for subnet is Core 1 because of lower OSPF cost between site 1 physical routers and Site 1 NSX edges.

Route for on Core 1


Route for on Site2 Router 1


Route for on Site 1 Edge


Route for on Site2 Edge


Default route on UDLR
Traffic flows


UDLR follows the default route


If there are other services/customers connected to the physical routers of Site 2, then such traffic will not go via Site 1. Instead be routed towards local NSX edges in Site 2 because intra area routes are preferred as compared to inter area routes.



Ingress from Core WAN to App Tier LS


One thought on “Cross Vcenter NSX with OSPF

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