In the previous post Part 7: NSX Edge Gateway we’ve seen what the Edge GW can do and how to install it. In this post I’m covering how to get OSPF up and running between the DLR and the Edge Gateway.
NOTE: it is possible to use just static routes (as with any other router) instead of dynamic routing protocols, that said within the OSPF configuration I still have static routes propagating from the Edge to the DLR.
So let’s get started.
Some OSPF concepts
Open Shortest Path First is a link-state dynamic routing protocol typically used within a single routing domain. Routers establish peering with each other and become neighbors, after which they start exchanging their routing table so that the topology information – Link State DataBase (aka LSDB) – is the same between neighbors.
OSPF areas break up the network so that routers in one area know less topology information about the subnets in the other area and they do not know about the routers in the other area at all. Why doing this? To have smaller routing tables therefore less cpu and memory processing is required.
In NSX we have only 2 types of Area: Normal and NSSA. Please refer to this Cisco article for details on Areas as this is not NSX specific protocol.
An OSPF Router ID (RID) is selected automatically by picking the highest IP address of a logical interface (loopback interface) or the highest IP address of an active interface. If desired it’s possible to change the RID but a reload (or clear) of the OSPF process ID is required.
I will not go any deeper in this article about how OSPF works because it’s completely out of scope for my NSX Series however a good starting point is this Wikipedia article on OSPF if you like to understand more.
NSX Edge OSPF Configuration
On the Edge GW Manage > Routing tab > OSPF > Edit and Enable OSPF
If you want to advertise the Edge default gateway to the DLR then Enable Default Originate
so it should look like this
Select the interface to use to distribute link state updates, which in my scenario is the Uplink interface for the Edge Gateway.
This interface ip address is going to be used as Router-ID.
The OSPF Router-ID is used to identify a specific device within an OSPF database. Router ID’s must be unique to prevent unintended OSPF database problems.
Whenever you make a change, it needs to to be published, as per this screenshot.
Create a new OSPF area, as Normal for now, with an ID of your choice. I’m not using authentication in my lab. And again, publish the changes.
Next, we need to map the interface to the Area it connects to. From high level this is how the topology looks like:
Under Area to Interface Mapping add two mappings:
- the Uplink interface connects to Area 0
- the Transit interface connects to Area 84
Publish the changes.
Next, we need to tell OSPF which routes it should redistribute. Under Routing tab > Route Redistribution > Route Redistribution table we need to tell the OSPF process which routes can be learnt (and therefore advertised) by the OSPF process.
First enable the redistribution
Secondly, decide which routes (or subnets) to redistribute:
Remove Static Route on Control VM (optional)
If you had static routes configured on the Control VM you can now remove them as they’ll be propagated from the NSX Edge.
Configure OSPF on the Control VM (DLR)
First we need to select the interface to be used as Router-ID, again for the Control VM we need this interface to be the Transit going northbound.
Under Routing > OSPF > Edit OSPF and select
- Forwarding Address: an IP address that is to be used by the router datapath module in the hosts to forward data path packets.
- Protocol Address: a unique IP address within the same subnet as the forwarding address, is used by the OSPF process to form adjacencies with the peers (neighbors)
But who is 192.168.10.3 effectively? The protocol address is assigned to the LR Control VM and it advertises OSPF routes; the forwarding address is in fact 192.168.10.2, which is the Transit dLR LIF interface. In other words 192.168.10.3 is “spoofing” (or rather proxying) the DLR interfaces.
Define the area Routing > OSPF > Area Definitions and Publish changes
Map the area just defined to the Transit Interface and again Publish Changes
Now we need to tell the dLR which subnets need redistribution, in our scenario these are all the Connected interfaces
Troubleshooting
Sometimes things get stuck and break (still too easily I should add) on NSX. In this example the dLR Control VM for some reasons failed to initialise.
I couldn’t really figure out what went wrong but knowing that it’s just the control plane I decided to redeploy (Actions > Redeploy)
and after few minutes, bang! all back to business 🙂
Checking DLR routes from the data plane (ESXi)
1 ) Find out all logical router instances
net-vdr -l -I
2) Given a DLR instance, list the routing table installed in the hypervisor
net-vdr -l --route CloudLab+edge-6
As you can see, the OSPF has learnt two routes:
- 192.168.100.0/24 because it’s an interface direcly connected to the NSX Edge Gateway
- 192.168.110.0/24 because it’s been added as Static Route again on the NSX Edge Gateway
That’s it for now, I welcome any comment and advise 🙂
16 Trackbacks