Short OSPF primer and its use in a NSX environment

25. August 2016 NSX 0

Here’s a topic I did not think I would ever blog about: OSPF. I kind of mentally blocked out most specific details about all dynamic routing protocols after completing the Cisco CCNP Routing exam many, many years ago. Now I am studying for VCIX-NV and al of I sudden I find myself studying Not So Stubby Areas once again. Although I don’t really expect to be challenged on very OSPF specific details during the lab based exam, I decided to pull out the good old Cisco Press books for some background refreshing. Here’s a quick overview of OSPF:

Link state protocol

OSPF – short for Open Shortest Path First –  is a so called link state dynamic routing protocol. This means that every router is responsible for managing and communicating about the state of its links. OSPF uses the famous Dijkstra’s algorithm (proud to be Dutch!) to calculate the shortest path between two endpoints, based on the speed of the link. OSPF uses multicast for sending out updates about link states. These updates – or Link State Advertisements (LSA’s) as they are actually called – are only sent out whenever changes occur. This alone makes OSPF a pretty efficient routing protocol as opposed to deprecated distance vector protocols.

Since we’re just touching the tip of the iceberg here, I won’t go into many more details. Entire books have been written on OSPF! The takeaways are: OSPF uses link speeds to determine the most efficient path for forwarding packets and multicast link state advertisements are sent out whenever changes occur.

OSPF Neighbors, Adjacencies and Designated Routers

OSPF routers send out multicast ‘Hello’ packets on all interfaces configured for OSPF to discover neighbors and periodically check if they are still alive. By exchanging these packets, a neighbor topology is built. Link state protocols synchronize their database (the Link State Database, or LSB) only with direct neighbors. LSA’s are exchanged until a full synchronization is reached. At this point we talk about an adjacency. On multi-access networks (such as Ethernet networks) where multiple OSPF routers are present, this neighboring process must be controlled in order to control traffic flooding. You can imagine the amount of traffic generated when tens or hundreds of routers would start forming neighbor adjacencies and synchronizing databases in a full mesh topology. To prevent this, OSPF selects a Designated Router (DR) and a Backup Designated Router (BDR). All updates are sent only to this DR and it is responsible for sending the updates back out to all other routers within their network. This way traffic is minimized and updates do not flood the network. The BDR also receives these updates but does not send them out by the way. In case the DR fails, the BDR takes over the role of DR and a new BDR is elected.

OSPF Areas

If you have configured OSPF on a NSX Logical Router (LDR) or Edge Service Gateway (ESG) you might have noticed two pre-configured OSPF areas. Area 0 and a spooky Area 51. I have to disappoint you, Area 51 is just an arbitrary number and like lots of nerdy IT folk, VMware engineers choose to preconfigure Area 51. They could have just as well chosen Area 20, 14.568 or any other 32-bit number. OSPF areas are perhaps the biggest concept you should master when configuring OSPF. Let’s start with explaining the different types of areas. If you thought Area 51 was kind of nerdy, wait until you see the names of the special OSPF areas 😉

Backbone Area

This is the core of the OSPF network. The backbone area is always Area 0 and it is mandatory. In smaller networks, you would probably only configure Area 0. If your topology requires additional areas, they must all connect to the backbone area. So how do you interconnect two OSPF areas? By configuring a single OSPF router with one interface in Area 0 and one interface in another area. The router is then called an Area Border Router (ABR). The ABR exchanges routes from one area with routers in the other area.

Stub Areas

A stub area only receives a default route into the backbone area. A stub area has no other possible route to take so filling the LSB with detailed LSA’s is a waste of resources and might strain the router unnecessarily. The stub ABR only needs to know that it needs to send all external traffic to the backbone area.

Not So Stubby Areas

Yep, that’s really what it’s called. Not So Stubby Areas. Awesome, right? The big difference with stub areas is that NSSA’s can receive updates from other Autonomous Systems (an Autonomous System is a group of routers running a routing protocol together) directly connected to them. It does not accept updates from other Autonomous Systems that are connected to other areas. Whenever two Autonomous Systems are interconnected, the router responsible is called an Autonomous System Boundary Router. An ASBR has one interface configured for OSFP and another interface for another routing protocol. NSX only supports the Backbone area and Not So Stubby Areas by the way. A NSSA can import external routes into the OSPF routing domain and provide transit services to routing domains that are not part of the OSPF routing domain.

Totally Stubby Area

This area couldn’t be more stubby. Can’t help but laugh every time I see these names. As the name suggests, this area type works very much the same as a Stub Area. The Stub Area will accept routes from within the autonomous system but will not accept routes from outside the autonomous system. A Totally Stubby Area does not accept any routes except a simple default gateway to Area 0.

Totally Not So Stubby Area

OK, I will stop now. Totally NSSA’s do not accept external routes or inter-area routes but they do allow an ASBR within the area. Enough already…

Why all these different kinds of areas?

Networks have to be lean and mean. Routers have to make routing decisions as fast as possible and forward packets at the highest possible speed. OSPF can be a relatively resource (CPU and RAM) heavy protocol. The size of the Link State Database has a big impact on the performance of OSPF. Smaller routers with less CPU and RAM are typically used on the edges of the network. It would impose a big problem if these smaller routers would have to maintain a huge LSB of the entire network topology. This would also be pretty useless because networks in the edges of (well designed) networks typically have a single path into the backbone of network. They often use a default route or summary routes. Configuring stub areas prevents unnecessary routes being populated in the LSB. So these different types of areas allow network admins to build efficient and highly scalable OSPF networks.

OSPF in NSX

OSPF is supported on both the Logical Distributed Routers and the Edge Services Gateways. You can use OSPF on an ESG and peer it with a physical OSPF router for dynamic routing of north-south traffic and you can configure it on the LDR where it typically peers with a North-South ESG to exchange routes:

NSX Routing

Imagine the external network is already running OSPF. In that case the ESG would be configured as a Area Border Router. One interface would be mapped to the existing Area 0 in the physical network and one interface would map to another Area where the LDR’s uplink interface would also be configured in. In this case the use of the default NSSA 51 would be entirely plausible. From the LDR’s perspective, there is only one possible path to the backbone area. If the external network was running BGP for instance and the ESG would be required to redistribute routing information between the internal OSPF netwerk and the external BGP network, the ESG would have to be configured as an Autonomous System Boundary Router or ASBR.

That’s it for now. I hope I made the most important concepts of OSPF clear. Writing this stuff down once again really helped me in refreshing my OSPF knowledge. I would not dare to claim being a OSPF expert, but I feel pretty confident I can can counter any OSPF task thrown at me during my VCIX-NV exam.

Thanks for reading and wish me luck!


Leave a Reply

Your email address will not be published. Required fields are marked *