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. It also explains the full state machine, decodes what each state actually means on the wire, and walks through the two or three states where real-world failures almost always stall.

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.

The OSPF Neighbor State Machine, In Order

OSPF adjacency is a negotiated handshake, not a simple up/down. Each state corresponds to a specific packet exchange, and knowing the order narrows the fault dramatically.

• Down — the initial state; nothing has been heard from the neighbor. On point-to-multipoint or NBMA networks the router may show ATTEMPT instead, meaning it is actively sending HELLOs to a manually configured neighbor that is not answering.
• Init — a valid HELLO has been received from the neighbor, but that HELLO did not list this router's own Router ID in its neighbor field. That one fact is the key: HELLO reception works in one direction only.
• 2-Way — bi-directional communication is confirmed; the neighbor's HELLO lists this router's Router ID. On broadcast and NBMA segments this is the steady state for routers that are neither DR nor BDR, and it is perfectly healthy. Only non-DR/BDR routers legitimately stop here.
• ExStart — master/slave negotiation begins. The router with the higher Router ID becomes master and sets the DBD sequence number. Failure to agree on the master, or a sequence-number disagreement, leaves the adjacency parked here.
• Exchange — both routers send Database Description packets describing their link-state databases, followed by Link State Requests for anything missing.
• Loading — the routers are exchanging the actual LSAs requested; this is where corrupted or retransmitted LSAs show up.
• Full — the databases are synchronized and the adjacency is established. Full is the only state at which the two routers can be considered neighbors for routing purposes.

What Must Match Before Any Adjacency Forms

The HELLO packet itself is the gatekeeper. Two routers will not progress past Init unless their HELLO packets agree, and HELLO carries these fields:

• Area ID — must match exactly, including stub/NSSA area type. A number mismatch or an area-type mismatch is a silent adjacency killer.
• Hello interval and Dead interval — 10/40 seconds on broadcast and point-to-point, 30/120 on NBMA. Any mismatch drops the packet.
• Network mask — must match on broadcast and NBMA networks (it is not checked on point-to-point).
• Authentication — type and key must agree; a router expecting MD5 will simply discard a plaintext HELLO.
• Options (E-bit) — the external-routing capability bit must be consistent, which is how stub and normal areas get separated.
• Router ID — must be unique. Duplicate Router IDs cause HELLOs to be ignored, and the symptom is an adjacency that flaps or never leaves Init.
• MTU — not carried in HELLO, but enforced later in the DBD exchange, which is why MTU failures show up at Exstart rather than Init.

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.

State-by-State Troubleshooting

Match the stuck state to the most probable cause and go straight to the check that proves it.

• No neighbors at all — verify OSPF is enabled on the interface (show ip ospf interface brief), the interface is up/up, the subnet is reachable, and that no ACL blocks multicast 224.0.0.5/224.0.0.6. A passive-interface under the router process is the classic culprit: the network is advertised but no HELLOs leave.
• Stuck in Init — HELLOs are arriving from the neighbor but the neighbor is not hearing ours. Check for a one-way ACL, a broken return path, an authentication mismatch on one side only, or duplicate Router IDs. A device such as a firewall or a Layer 2 filter dropping multicast in one direction produces exactly this signature.
• Stuck in ExStart / Exchange — almost always an MTU mismatch. Confirm with show interface on both ends and compare the IP MTU. Unexpected DBD sequence numbers caused by duplicate Router IDs or a flapping link look the same, so check both.
• Stuck in Loading — the routers cannot complete the LSA exchange. Look for %OSPF-4-BADLSA messages, mismatched MTUs on one path, or a corrupted link-state database; clearing the process with clear ip ospf process is the last resort before a TAC case.
• 2-Way on a point-to-point link — on broadcast networks 2-Way is normal for non-DR/BDR routers, but on a point-to-point link the adjacency should reach Full. A 2-Way stall there means the network type is mismatched on one side.
• Flapping adjacency — repeated Up/Down with Full reachable briefly points to a physical or timing problem: a bad cable, a duplex mismatch, or a Dead interval too short for the path.

MTU Mismatch: The Classic Exstart Failure

MTU is the single most common reason a healthy-looking link never reaches Full. A router configured with jumbo frames on one interface and a default 1500-byte IP MTU on the other will build a database-description packet larger than the neighbor can accept, so the exchange stalls before any routing information moves. The fix Cisco recommends is to correct the interface MTU on both sides. If you genuinely cannot align them, the workaround is to tell OSPF to skip the check:

interface GigabitEthernet0/0
 ip ospf mtu-ignore
show interface GigabitEthernet0/0 | include MTU

Use ip ospf mtu-ignore as a temporary measure only. It hides a real path-MTU problem that can break data traffic independently of OSPF, so align the MTUs and then remove the command.

Authentication Mismatch

Authentication failures are silent by design — the receiving router drops the HELLO without an obvious error, so the adjacency simply never forms or never leaves Init. Verify the authentication type and key are identical on both ends, and remember that changing authentication requires the routers to be reconfigured on both sides before the adjacency can return:

show ip ospf interface GigabitEthernet0/0 | include authentication
show running-config | include message-digest-key

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

Reading show ip ospf neighbor Output

The output columns are worth knowing cold. Neighbor ID is the remote Router ID, Pri is its OSPF priority (0 means it can never be DR), State is either FULL/DR, FULL/BDR, FULL/DROTHER or 2WAY/DROTHER, Dead Time counts down from the Dead interval towards zero, and Address is the neighbor interface address on the shared segment. A dead time that resets instead of counting down means HELLOs are arriving normally; a dead time racing to zero means they are not, and the adjacency is about to be torn down.

Router# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2          1   FULL/BDR        00:00:34    10.1.1.2        GigabitEthernet0/0
10.0.0.3          1   INIT/DROTHER    00:00:31    10.1.1.3        GigabitEthernet0/0

In this example the second neighbor is one-way: the router hears its HELLOs but the neighbor is not hearing ours, which sends you straight to the Init troubleshooting branch above and away from timers or MTU.

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.

Timer and Network-Type Mismatches

The HELLO and Dead intervals must match exactly on both routers, and the defaults vary by network type: 10 and 40 seconds on broadcast and point-to-point, 30 and 120 seconds on NBMA and point-to-multipoint. A router that has been tuned for fast convergence on one side while the other still runs the defaults will drop every HELLO it receives, and the neighbor will never leave Down. Network type itself is the subtler problem: if one interface is treated as broadcast and the other as point-to-point, the two sides disagree about whether a DR/BDR election is required, and the adjacency either stalls short of Full or oscillates. Check both neighbours with show ip ospf interface and align the network type explicitly rather than letting the defaults decide — a tunnel or a Frame Relay subinterface inherits the wrong type more often than people expect.

interface GigabitEthernet0/0
 ip ospf network point-to-point
 ip ospf hello-interval 10
 ip ospf dead-interval 40
show ip ospf interface GigabitEthernet0/0 | include Timer|Network Type

Why a Flapping Physical Link Breaks the Exchange

OSPF cannot form a stable adjacency over an unstable link, and the symptom is a neighbor that repeatedly reaches Exchange or Loading and then falls back. A duplex mismatch, a failing optic, or a cable with intermittent contact produces errors that corrupt database-description packets, so the routers retransmit, the sequence numbers drift out of step, and the process starts again. Before you go looking for a configuration bug, confirm the physical layer is clean:

show interface GigabitEthernet0/0 | include error|drops|duplex
show controllers GigabitEthernet0/0

An interface reporting input errors, CRC or late collisions alongside a flapping OSPF adjacency is a physical problem, not a protocol one, and no amount of parameter tuning will fix it.

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