OSPF Neighborship Troubleshooting


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.

OSPF Neighborship Requirements

From the perspective of OSPF, there are a couple of things that must match for a OSPF neighborship to establish; these include:

  1. The devices must be in the same area
  2. The devices must have the same authentication configuration
  3. The devices must be on the same subnet
  4. The devices hello and dead intervals must match
  5. The devices must have matching stub flags

OSPF Neighborship Configuration Verification and Troubleshooting

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.

OSPF Neighborship Configuration

Sponsored Content

Passwords Haven’t Disappeared Yet

123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?

Figure 1 – Simple Lab

Mismatched Areas

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 while the local device is configured for area 2 (notated as

OSPF Neighborship - Mismatched Areas

Figure 2 – Mismatched Areas

Authentication Mismatch

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

Subnet 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 subnet while the local (connected) device was configured in the subnet.

Figure 4 – Subnet Mismatch

Hello and Dead interval 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

Stub Flag 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.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (2)

2 responses to “OSPF Neighborship Troubleshooting”

  1. <p>Thanks <span style="color: rgb(77, 77, 77);">&nbsp;Sean Wilkins</span> for informative information you shared which will be helpful for may running <a href="; target="_blank">job</a>. I am not clear about stub flag and one important think is figure 1 and figure 2 is not working .</p>

Leave a Reply