Dynamic Routing with NSX
Today I’d like to walk through the process of configuring dynamic routing between an NSX distributed logical router and an NSX edge. We will be using OSPF to advertise routes owned by the distributed logical router (DLR) to the edge device.
In a previous post I discussed the advantages of leveraging the DLR to optimize East/West traffic. We will now be attaching an NSX edge device to provide North/South connectivity into the environment. In this design, all of your East/West traffic is handled by the DLR, and only ingress/egress traffic will be traversing the edge virtual appliance.
It should become quite clear by this example exactly how well NSX can scale, and how it can be customized to support literally any network design.
First lets start with a logical diagram of what this will look like when complete:
As you can see, we have a typical three-tier app design (web, app, and DB) attached to logical switches (VXLAN virtual wires) that then connect to the DLR. We have also deployed an edge device north of the DLR and attached the inside interface of the Edge, and external interface of the DLR to the same transit network. We will be establishing an OSPF route peer between the two devices on that transit network. This will allow the edge to pass traffic to the VMs on the DLR.
I will assume that the DLR and Edge have already been created and are appropriately connected on the transit logical switch.
At this point, we really just have to enable OSPF and route redistribution on both the DLR and Edge.
The first step is to navigate to Manage > Routing > Global Configuration on the distributed router.
Next, you simply need to select “Edit” under Dynamic Routing Configuration and accept the default Router ID. Check “Enable OSPF,” then hit the “Save and Publish” button.
When complete, it should look like this:
Now we need to go to the OSPF sub-menu and click “Edit.”
You will want to make sure that “Enable OSPF” is selected, and that you enter both a protocol address and forwarding address. The protocol address is needed because the routing stack is managed by the DLR control VM, and the IP it will be using for the protocol updates will need to be local to that control VM. The forwarding address is the IP address that you assigned to the uplink interface out of the DLR (facing the Edge).
Here is what that looks like:
Go ahead and publish changes again after configuring this.
Now we need to set a new OSPF Area Definition (I just selected the default area ID of 10), and publish changes again.
Lastly, on this page we simply need to map the area ID to the proper interface (the transit uplink to the edge). Make sure you select the proper interface, and use the area ID you created in the previous step. Finally publish changes.
When complete, your screen should look something like this:
Lastly, we need to enable Route Redistribution for connected routes, so go ahead and select that sub-menu.
All we need to do here is enable route Redistribution for OSPF (If OSPF is greyed out here, then you forgot to enable it on the OSPF screen above).
On the Route Redistribution table, click the plus icon and then the check box for “Connected”. And publish changes one more time.
This screen should end up looking like this:
Thats about it for the DLR. We can log into the CLI and verify that OSPF is functioning by typing:
show ip ospf statistics
The result should look something like this:
The edge configuration process is very similar to the DLR.
Under Manage > Routing > Global Configuration, enable OSPF.
Select OSPF sub-menu, and Make sure you map the Transport network (on the internal side of the Edge) to the same area ID that you used when configuring the DLR (10 in this case). Note that the option to enable OSPF looks a bit different on the Edge. Its a on/off push button in the upper right.
When complete, the screen should look something like this:
Now we just need to enable Route Redistribution. Select that sub-menu.
This process is exactly the same as before (on the DLR). Simply add a new entry to the route redistribution table, and select OSPF as the learner protocol, and the “Connected” check box.
When complete, it will look like this:
The last step is to verify that OSPF is working between the two routers. We can do this by running the following command on the edge router:
show ip ospf neighbor
The result should look like this:
Another cool thing to do is to actually watch OSPF come online by using ping. In the following screen cap I am pinging a VM that is attached to the DLR from a device outside of the NSX Edge router. You can see that it takes a few seconds before OSPF is negotiated and starts distributing the routes. Once it does, the pings start replying:
We have now successfully established connectivity between the VMs located on the DLR and the NSX edge.
Again, with this configuration, the only traffic that will pass through the edge device is ingress/egress into the virtual network. All East/West remains on the DLR and will never touch the edge.
NSX is extremely scalable. It is also able to be configured in any number of ways to meet essentially any network design requirement. In future posts I intend to cover things like one-arm and inline load balancing, edge and distributed firewalls, layer-2 VPN, and other advanced features of this product.
Feel free to comment! Thanks for reading.