Troubleshooting OSPF Adjacency Issues

1. The Foundation: A Systematic Troubleshooting Approach

As a solutions engineer, you know that effective troubleshooting isn't about guesswork; it's about following a logical process. When dealing with OSPF adjacency failures, our process starts with one key command: show ip ospf neighbor. The output—or lack thereof—tells us where in the OSPF state machine the process has failed and guides our next steps.

This flowchart provides an excellent mental model for this process.

The core troubleshooting methodology involves these steps, which we will apply throughout this lesson:

1. Define and Verify the Problem: Confirm which routers are failing to become neighbors and that you can replicate the issue.
2. Gather Information: Use show commands to inspect the configuration and state of the interfaces and OSPF process.
3. Form a Hypothesis: Based on the information, determine the most likely cause (e.g., mismatched timers, MTU issue).
4. Test and Implement a Solution: Apply a configuration change to fix the suspected issue.
5. Verify the Fix: Check if the adjacency is now FULL and routes are being exchanged.

2. The Tools of the Trade: show and debug

We have two primary types of tools at our disposal:

• show commands: These provide a snapshot of the current state of the router. They are safe to use on any production network. Key commands include show ip ospf neighbor, show ip ospf interface, and show run.
• debug commands: These provide real-time reporting of network events as they happen. They are incredibly powerful for diagnosis but can place a high load on a router's CPU. They must be used with extreme caution on production networks.

Before we use any debug commands, it's essential to understand the correct way to use them professionally.

The key takeaways from the video are:

• Always check CPU load first: show processes cpu sorted.
• Use conditional debugs when possible: debug condition interface <interface-name> filters the output to only what's relevant, making it easier to read and safer for the router.
• Always remember to turn them off: undebug all.

3. A Practical Troubleshooting Walkthrough

Now, let's see this methodology in action. The following video presents a troubleshooting lab where OSPF routes are not being learned. The presenter methodically works through several common adjacency issues.

Let's break down the issues discovered in the video, as they represent some of the most common OSPF adjacency problems.

• Problem 1: Incorrect Passive Interface (on R3)

  • Symptom: R3 was not forming an adjacency with R2.
  • Diagnosis: The show run | sec router ospf output on R3 showed passive-interface GigabitEthernet0/1. A passive interface doesn't send or process OSPF Hello packets, so no adjacency can form on it.
  • Fix: The incorrect passive-interface command was removed and applied to the correct interface (the one not connected to an OSPF neighbor).

• Problem 2: OSPF Area ID Mismatch (R2 and R3)

  • Symptom: Even after fixing the passive interface, the adjacency did not form. Syslog messages on R2 indicated a "Mismatched Area ID".
  • Diagnosis: show run | sec router ospf on R3 showed its interface was in area 0, while the topology required it to be in area 1 to match R2.
  • Fix: The network statement on R3 was corrected to use area 1.

• Problem 3: OSPF Hello Timer Mismatch (R1 and R2)

  • Symptom: R1 and R2 were not forming an adjacency.
  • Diagnosis: The show ip ospf interface gigabitEthernet0/1 command on R2 revealed a non-default Hello timer of 20 seconds. OSPF neighbors must have matching Hello and Dead timers to form an adjacency.
  • Fix: The ip ospf hello-interval 20 command was removed from R2's interface configuration, reverting it to the default of 10 seconds to match R1.

• Problem 4: MTU Mismatch (R1 and R2)

  • Symptom: After fixing the timers, the adjacency got stuck in the EXSTART state.
  • Diagnosis: A neighbor stuck in EXSTART or EXCHANGE almost always points to a Maximum Transmission Unit (MTU) mismatch. The show ip interface gigabitEthernet0/2 command on R1 showed a non-default IP MTU of 1478 bytes, while R2 was at the default of 1500.
  • Fix: The MTU on R1's interface was reset to the default value. The adjacency immediately transitioned to FULL.

4. Deep Dive: Correlating States to Problems

The video provided a great practical overview. Let's formalize this by mapping OSPF neighbor states to common problems and the tools used to diagnose them. The official Cisco guide "Troubleshoot OSPF Neighbor Problems" is an excellent reference for this.

Here is a summary of the key troubleshooting paths based on the show ip ospf neighbor output:

Let's look at what the debug output for an MTU mismatch looks like. The router will explicitly tell you what the problem is.

This highlights the power of debug ip ospf adj for issues that occur after the initial Hello exchange.

Conclusion

Troubleshooting OSPF is a process of elimination guided by the OSPF neighbor state machine. By starting with show ip ospf neighbor, you can quickly narrow down the list of potential problems and select the right show and debug commands to find the root cause.

Key Takeaways:

• Follow a systematic approach: Start with show ip ospf neighbor to determine the failure point.
• "No neighbor" is a big clue: If a neighbor doesn't appear at all, the problem is with basic connectivity or a mismatched parameter in the Hello packet (timers, area, subnet, authentication).
• EXSTART state points to MTU: This is the most common cause for an adjacency getting stuck after the 2-Way state. Use debug ip ospf adj to confirm.
• Use debug with caution: Always check CPU load, use conditional debugging where possible, and always disable it when you are finished.

Preview of the Next Lesson:

Establishing a FULL adjacency is only the first half of the battle. Once neighbors are up, they must exchange Link-State Advertisements (LSAs) to build their routing tables. In our next lesson, we will address the learning outcome: Troubleshoot suboptimal OSPF routing paths and LSA propagation issues. We'll investigate scenarios where adjacencies are up, but routes are missing, incorrect, or taking an inefficient path through the network.