When setting up dynamic routing protocols, there are certainly a number of things that need to be configured correctly for everything to end up working as planned. On top of this, each of the different routing protocols has different elements that they expect to be configured first for each of them to operate correctly. This article takes a look at these requirements from the perspective of OSPF and shows the different commands that can be used to ensure proper OSPF area configuration and display the different messages that occur when misconfiguration exist.
It’s time to ditch your spreadsheets & evolve your IP infrastructure.
Learn how to make the switch in just 5 minutes with SolarWinds IP Address Manager. Otherwise….bad things can happen – like living in the woods with bears!
What are OSPF Areas?
Before an engineer is able to effectively troubleshoot OSPF areas they must be familiar with what an OSPF area is and how it is used. An OSPF area (also referred to as an OSPF domain) is created to logically group together networks and the hosts that are connected to them (including the routers). The specific design of OSPF areas is outside the scope of this article, but they can be very simple with a single area (area 0) or very complex with several areas connecting together thousands of routers.
There are a couple of different OSPF area types, these include:
- Backbone – The backbone area must be implemented when configuring OSPF and all areas must connect through it (area 0).
- Normal – A normal area is an area that has no constraints, the backbone area is a special normal area.
- Stubby – A stubby area is an area that is not able to accept routes from outside the OSPF domain (Redistributed into OSPF), these are also referred to as external routes. Traffic that is destined for a location outside of the OSPF network is only able to exit the area via a default route.
- Totally stubby – A totally stubby area is an area that is not able to accept routes from outside the OSPF domain AND is not able to accept non-default summary routes from outside the area; traffic is only able to exit the area via a default route.
- Not-so-stubby – A not-so-stubby area (NSSA) is an area that acts the same as a stubby area with one exception, while a stubby area is not able to connect directly to an external routing domain and NSSA network, it is able to by using a special type of Link State Advertisement (LSA). The routes to this external routing domain are then injected into the backbone (and from there to other areas). This area is still not able to accept routes from external domains not directly connected to it.
- Totally NSSA – A totally NSSA is an area that acts the same as a totally stubby area but with the same abilities as a normal NSSA area. As with a normal totally stubby area, a totally NSSA is not able to accept summary routes from other areas or external routes from other areas.
OSPF Area Configuration Verification and Troubleshooting
In a typical OSPF configuration, it is common for a backbone to exist with many different normal areas connected to it. The special area types (stubby, totally stubby…) can be used depending on the specific situation. Common normal area configuration problems come when OSPF areas are configured without a direct connection to the backbone area. This is a requirement of OSPF and will cause routing issues. Figure 1 shows an example of what happens when an OSPF area is configured without a direct connection into the backbone area.
Ensure that when designing and/or configuring an OSPF network that all areas have a direct connection to the backbone. Keep in mind that this direct connection does not have to be physical; OSPF also provides the ability to logically connect to the backbone area through another area using virtual links. When virtual links are configured, communication between the area and the backbone is sent through but not to the devices in an intermediary area, this meets the OSPF requirement of direct connection to the backbone.
To verify the OSPF configuration on a device either display the running configuration (using the show running-config) or by using show ip ospf or show ip protocols as shown in Figure 2 and 3.
A more detailed look at the operation of stub area types will be covered in a later article.
OSPF is certainly a beast and can be quite intimidating to tackle both when configuring it and when attempting to troubleshoot it. To make it a little easier, the OSPF troubleshooting articles have been separated so that the reader can digest a little bit of OSPF at a time. Hopefully the content of this article has been helpful when attempting to troubleshoot normal OSPF areas.