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 neighborship configuration and communications between devices.
From the perspective of OSPF, there are a couple of things that must match for a OSPF neighborship to establish; these include:
Starting from the top of the list, the interfaces connecting devices must be on the same area. To display the various commands and what to look for, Figure 1 shows a simple lab has been setup with two devices that are connected together via an Ethernet connection.
Figure 1 – Simple Lab
The first thing that is going to be checked by the OSPF device is whether the remote device is in the same area. No other processing will occur on the device until both devices have been configured with the same area. Figure 2 shows an example of the message given by the debug ip ospf adj command when the remote device is not in the same area. As can be seen from the figure, the remote device is configured into area 1 (notated as 0.0.0.1) while the local device is configured for area 2 (notated as 0.0.0.2).
Figure 2 – Mismatched Areas
The second entry on the list was that each device must have matching authentication configuration; before any other information is exchanged between the devices they must agree on an authentication type (if any is configured). If the parameters are not the same on both sides, the neighborship process will never progress. Figure 3 shows the error message that will be displayed (from the debug ip ospf adj command) when an authentication mismatch occurs.
Figure 3 – Authentication Mismatch
Another valuable command to use when troubleshooting OSPF is debug ip ospf hello. As the name suggests, this command shows debugging information for the hello event s between devices. Since a neighborship starts with a hello exchange, this is a valuable command to use.
The third entry on the list was that each device must be in the same subnet. Figure 4 shows an example of a message that shows the engineer that a mismatch exists between devices and upon closer inspection it shows that the subnet mask is configured differently on each device. In this case the remote device was configured in the 10.10.10.0/25 subnet while the local (connected) device was configured in the 10.10.10.0/24 subnet.
Figure 4 – Subnet Mismatch
The fourth entry on the list is matching hello and dead intervals. When configuring the hello interval on an interface, the device (With Cisco equipment) will automatically adjust the dead interval; Figure 5 shows a case where the remote device was configured with a hello interval of 8 (Seconds) while the local device uses the default setting of 10.
Figure 5 – OSPF hello and dead interval mismatch
The final entry on the list was that the device must agree on whether the area is a stub or not. Figure 6 shows an example of a message where the devices disagree on whether the area is a stub area or not.
Figure 6 – Stub Flag Mismatch
While it can be often overlooked, a neighborship is the first thing that must be established before any communication will happen between devices. Each of the different routing protocols has their own requirements that must be met before this neighborship will establish. This article takes a look at the elements that must match for OSPF neighborships to establish and what commands to use to troubleshoot which misconfiguration potentially exists. Hopefully, the information in this article, when committed to memory, will help in future OSPF configuration endeavors.