Cisco OSPF Neighbor Troubleshooting: States and Fixes - 夜莺博客

Cisco OSPF Neighbor Troubleshooting: States and Fixes

When two Cisco routers refuse to form an OSPF adjacency, traffic silently black-holes even though the physical link is perfectly healthy. The classic Cisco troubleshooting document on OSPF neighbor problems teaches a disciplined, state-based approach: identify which OSPF neighbor state the router is stuck in, then work through the handful of parameters that must match — area, timers, subnet, network type, authentication, MTU, and Router ID. This article summarizes that methodology so you can resolve adjacency failures quickly instead of guessing.

Reading the Neighbor State

Start every diagnosis with show ip ospf neighbor. The state you see tells you where the process is failing:

  • No state / nothing — no valid HELLOs received; check interface up/down, IP connectivity, ACLs, passive interfaces, and that OSPF is enabled.
  • Down — usually a manually configured neighbor that never received HELLOs.
  • Init — HELLOs received one way only; your Router ID is not in the neighbor's HELLO.
  • 2-way — normal on broadcast/NBMA networks; both routers see each other.
  • Exstart/Exchange — DBD exchange failing, typically MTU mismatch or unexpected DBD sequence numbers.
  • Loading — corrupted LSAs being exchanged; look for %OSPF-4-BADLSA messages.

Checking the HELLO Parameters

show ip ospf interface GigabitEthernet0/0
show ip ospf
show interface GigabitEthernet0/0

Verify that these match on both neighbors: OSPF area number and area type (stub/NSSA), subnet and subnet mask, HELLO and Dead timers, and network type. Also confirm the routers have different Router IDs — duplicate Router IDs cause HELLOs to be ignored.

Common Failure Checklist

  • OSPF not configured on one side → show ip ospf
  • HELLO/Dead timer mismatch → show ip ospf interface
  • Network-type mismatch → show ip ospf interface
  • MTU mismatch → show interface
  • Passive interface suppressing HELLOs → show ip ospf interface (look for "Hello due")
  • ACL or switch filtering multicast 224.0.0.5 → check access lists
  • Crossed serial cables on parallel links → verify with show cdp neighbor

If everything checks out and the neighbor still does not appear, the problem is uncommon and warrants a TAC case. As a workaround for MTU mismatches you can configure ip ospf mtu-ignore, but Cisco recommends fixing the interface MTU instead of bypassing the check.

Related Articles

For a vendor comparison of this workflow, see our OSPF neighbor stuck in INIT troubleshooting article, the Cisco Nexus vPC failover checklist, and the multi-vendor CLI cheat sheet.

原文链接:https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13699-29.pdf