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.
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:
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.
Figure 1 – Area with Direct Connection to Backbone
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.
Figure 2 – show ip ospf
Figure 3 – show ip protocols
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.