VMware NSX Data Center for vSphere (NSX-V) has been able to leverage dynamic routing via Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP) for some time and, in this article, I detail the process of configuring OSPF on both an Edge Services Gateway (ESG) and a downstream Distributed Logical Router (DLR).
OSPF, a Link State Protocol and member of the Interior Gateway Protocol (IGP) family (which also includes Routing Information Protocol (RIP), Intermediate System to Intermediate System (IS-IS), and Enhanced Internal Gateway Routing Protocol (EIGRP)), enables all participating routers to dynamically exchange network topology information to calculate the best shortest path (cost) of a route’s destination.
When a change of network topology is detected by one router (maybe a new subnet/network segment has been added to a router, or even a new router itself is added to the topology), the change is automatically advertised to all routers participating in the OSPF ‘routing area’; think neighbours (routers) in a neighbourhood (routing area). The participating routers then update their Link-State Databases (LSDBs) with the new network topology and adjust their routing tables accordingly.
Please note, this article focuses on VMware NSX Data Center for vSphere (NSX-V). It does not cover OSPF on NSX-T. Furthermore, I do not cover the creation or configuration of either Edge Services Gateway or Distributed Logical Router. For more information on these areas, simply visit the below VMware Docs:
In this article we have a simple network topology (see below) comprising a perimeter ESG (essentially an Area Border Router (ABR) connected to my upstream physical network), a downstream DLR (a neighbouring ABR), two interior network segments represented by two NSX Logical Switches (LS-101-30-DB (10.101.30.0/24) and LS-101-40-HCON (10.101.40.0/24)), and two virtual machines (VGL-SQL-01 (10.101.30.11) and VGL-HCON-01 (10.101.40.11)).
Currently, neither ESG or DLR have OSPF enabled, nor have any static routes been configured. In this scenario, routing from our ESG to either of the downstream VMs fails (evidenced by the below ICMP request). This is to be expected, as the ESG (unaware of the downstream networks) will attempt to route the traffic via its upstream gateway (i.e. – my physical network).
As the DLR is not currently advertising its networks to the upstream ESG, the ESG has no idea that the downstream networks even exist, let alone how to route traffic there. We can confirm this by connecting to the ESG via SSH and by running the command
show ip route. From the below screenshot, we confirm that the ESG is unaware of the network segments 10.101.30.0/24 or 10.101.40.0/24. Again, this is to be expected.
In this article we will configure the ESG and DLR to peer with each other via a Routing Area (aka, Area Definition or Area ID). Once configured, the DLR will be able to advertise its routing information with its new neighbour, the ESG. Consequently, the ESG will be able to see the previously unknown networks and will update its LSDB and routing table. Traffic will then be able to route via the correct IP address, the DLR’s Uplink Logical Interface (10.101.1.11).
To implement the above OSPF design we will peer the ESG and DLR by assigning a Router ID to both devices, enabling OSPF, creating the Area Definition and mapping it to the appropriate Logical Interface, and by enabling the distribution of routes between each of the peered routers.
Edge Services Gateway Configuration
13. The Redistribution Criteria can be seen below. Set the Learner Protocol to OSPF, and configure Allow Learning From based on your requirements. In my case I have no Static Routes configured, so I only need to select Connected.
This concludes the configuration of the Edge Services Gateway.
Distributed Logical Router Configuration
7. Via the OSPF Configuration dialogue box, set the Interface to the Uplink Logical Interface, Enable the Status slider, and assign a Protocol Address.
Note, I see a lot of questions relating to protocol and forwarding address. Specifically, what’s the difference? VMware classifies these as:
- Forwarding Address – ‘…an IP address that is to be used by the router datapath module in the hosts to forward datapath packets.‘ This is the Router ID.
- Protocol Address – ‘The protocol address is used by the protocol to form adjacencies with the peers.‘ This is essentially a proxy address.
13. The Redistribution Criteria can be seen below. Set the Learner Protocol to OSPF, and configure Allow Learning From based on your requirements. Again, in my case I have no Static Routes configured, so I only need to select Connected.
This concludes the configuration of the Distributed Logical Router.
With OSPF now configured on both the ESG and DLR, let’s revisit our earlier issue whereby the ESG was unable to route ICMP traffic to a downstream virtual machine via our DLR.
Connecting to our ESG via SSH, we run the
show ip route command again. We can see that the downstream DLR has now been successful in advertising its networks to the upstream ESG. Consequently, the ESG has updated its LSDB and routing tables and now knows to route traffic to both downstream subnets via the DLR’s Uplink Logical Interface (10.101.1.11).
We can also confirm the OSPF neighbour peered with the ESG by running
show ip ospf neighbor. As you can see via the below screenshot, you’ll note the OSPF neighbour is identified as our DLR via it’s NeighborID (Forwarding Address/RouterID) on 10.101.1.11 and it’s Address (Protocol Address/Proxy) on 10.101.1.12.
Finally, re-running the same ICMP test as earlier is now successful thanks to the updated routing information.
This concludes the configuration of OSPF within an NSX-V environment, however, if you have any queries please feel free to reach out.