Troubleshooting OSPF Adjacency Issues

In our last lesson, we successfully configured a single-area OSPF network and celebrated seeing our routers reach the FULL adjacency state. But in the real world, configurations don't always work on the first try. A single mismatched parameter can prevent neighbors from ever talking to each other.

Today, we shift from configuration to investigation. Our goal is to troubleshoot common OSPF adjacency issues such as mismatched timers or area IDs. You will learn to adopt a systematic troubleshooting methodology, identify symptoms of common problems, use verification commands to diagnose the root cause, and apply the correct fix. This is a critical skill for any network engineer.

We'll examine several classic OSPF problems, including:

• Mismatched Area IDs
• Mismatched Hello and Dead timers
• Incorrectly configured passive interfaces
• Mismatched Maximum Transmission Unit (MTU) sizes

Let's dive into the structured process of OSPF troubleshooting.

1. A Systematic Approach to Troubleshooting

When an OSPF network isn't working as expected, it's tempting to start changing the configuration randomly. A more effective method is to follow a logical process. The first question to ask is: "Have the routers formed an adjacency?"

As the flowchart suggests, everything in OSPF starts with the neighbor relationship. If adjacencies don't form, routes will never be exchanged. Your primary tool for this is the command we used for verification in the last lesson: show ip ospf neighbor.

In a healthy network, you expect to see the state as FULL. When things go wrong, you might see nothing at all, or the state might be "stuck" in a transitional phase.

Let's review the key states. In the previous lesson, we saw the OSPF Neighbor States diagram showing the path to a FULL adjacency. Problems arise when routers get stuck in one of the intermediate states:

• Down: No valid Hello packets have been received from the neighbor. This is the starting point.
• Init: Hello packets have been received from the neighbor, but they don't contain your own Router ID. This means one-way communication is happening.
• 2-Way: Two-way communication is established (each router sees itself in the other's Hellos). On broadcast networks like Ethernet, routers will only form a FULL adjacency with the Designated Router (DR) and Backup Designated Router (BDR). Routers that are not the DR or BDR will remain in the 2-WAY state with each other, which is normal.
• Exstart/Exchange: The routers are stuck trying to negotiate the master/slave relationship for exchanging Database Descriptor (DBD) packets. This often points to an MTU mismatch.
• Loading: The routers are exchanging Link-State Request (LSR) and Link-State Update (LSU) packets but are not completing the process. This can indicate corrupted LSAs.

The following Cisco document provides an excellent, detailed breakdown of these states and what to check for each.

2. Live Troubleshooting Demonstrations

Now, let's see how these issues present themselves in a live environment. The following video by Kevin Wallace is a fantastic, structured troubleshooting lab. We'll walk through several of the problems he diagnoses and solves.

We will now work through the issues one by one, using clips from the video to see the problem, diagnosis, and solution in action.

Problem 1: Passive Interface Misconfiguration

A passive interface will not send or receive OSPF Hello packets. If you accidentally set an interface connected to another OSPF router as passive, no adjacency will ever form.

• Symptom: show ip ospf neighbor shows nothing for the link.
• Diagnosis: Use show ip protocols or show running-config | section router ospf to check which interfaces are listed as passive.
• Solution: In router configuration mode, use the no passive-interface <interface-name> command to correct the configuration.

Watch how this is identified and fixed in the lab.

Problem 2: Mismatched Area ID

For two routers to become neighbors, their connecting interfaces must be in the same OSPF area. A mismatch is a common and fundamental configuration error.

• Symptom: Adjacency fails to form. On Cisco routers, you will often see a console message like %OSPF-4-ERRRCV: Received invalid packet: Mismatched area ID....
• Diagnosis: Use show ip ospf interface brief on both routers to compare the area assignments for the connecting interfaces.
• Solution: Correct the network statement or the interface-level OSPF configuration on the misconfigured router to place the interface in the correct area.

Let's see this error get diagnosed.

Problem 3: Mismatched Timers

OSPF routers exchange Hello packets to discover neighbors and act as a keepalive mechanism. The Hello and Dead intervals are included in these packets. If these timer values do not match between two neighbors, they will refuse to form an adjacency.

• Symptom: No adjacency forms. show ip ospf neighbor will be empty. Using debug ip ospf hello would show the received packets being ignored due to the mismatch.
• Diagnosis: Use show ip ospf interface <interface-name> on both routers and compare the lines Timer intervals configured, Hello XX, Dead XX....
• Solution: Reconfigure the timers on one interface to match the other, or remove the custom configuration to revert to the default values (10s Hello, 40s Dead on broadcast networks).

The next segment of the video demonstrates this classic issue.

Problem 4: MTU Mismatch

The Maximum Transmission Unit (MTU) defines the largest packet size an interface can send. During the OSPF Exstart state, routers exchange empty DBD packets to negotiate a master/slave relationship and agree on an initial sequence number. If their interface MTUs do not match, they cannot agree on a common packet size for the subsequent DBD exchange, and the process stalls.

• Symptom: Neighbors are stuck in the EXSTART or EXCHANGE state in the output of show ip ospf neighbor.
• Diagnosis: Use show interface <interface-name> on both routers and compare the MTU value.
• Solution: The best practice is to fix the underlying issue by configuring the interface MTUs to match. Alternatively, you can use the ip ospf mtu-ignore interface command to bypass the MTU check during adjacency formation, although this is generally discouraged as it can hide other network problems.

Let's watch the final troubleshooting step in the lab.

3. A Troubleshooting Checklist

We have now seen four of the most common OSPF adjacency issues in action. To consolidate this knowledge, it's helpful to have a checklist. The Cisco document we looked at earlier contains a very useful table summarizing these and other potential problems.

For your reference, here is a list of essential parameters that must match for an OSPF adjacency to form between two routers on a shared link:

• Area ID
• Area Type (e.g., stub, NSSA)
• Subnet and Subnet Mask
• Hello and Dead Timers
• Authentication (if configured)

The following parameters must be unique:

• Router ID

Conclusion

In this lesson, you've moved beyond simple configuration and into the critical domain of troubleshooting. By learning to recognize the symptoms of common OSPF adjacency problems and applying a systematic diagnostic approach, you are now much better equipped to manage a real-world network.

Key Takeaways:

• Always start OSPF troubleshooting by checking the neighbor table with show ip ospf neighbor.
• The neighbor state (Init, Exstart, etc.) is a crucial clue to the nature of the problem.
• Mismatched Area IDs and Mismatched Timers will prevent an adjacency from forming at all. Use show ip ospf interface to verify them.
• Mismatched MTUs will typically cause the adjacency to get stuck in the EXSTART/EXCHANGE state. Use show interface to check the MTU.
• An incorrectly configured passive interface will prevent the router from sending or receiving Hellos on that link. Use show ip protocols to check for this.

Our exploration of OSPF is now complete. In the next module, we will switch gears and begin our study of network security by looking at Access Control Lists (ACLs). Your first lesson will be to explain how routers process ACLs using top-down logic, including the implicit deny rule.