A neighbor that won't come up, stalls at a specific state, or a route that keeps flapping — all of it looks mysterious until you place it on the OSPF neighbor state machine. Here's how to read it, the display commands for each state, and the root causes that account for most of these faults.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
OSPF neighbor problems look intimidating from the outside — Init, ExStart, 2-Way — until you realize each stuck state maps to a short, specific list of causes.
An OSPF neighbor that won't come up, gets stuck at a particular state, or a route that keeps flapping for no obvious reason — these all look like deep protocol mysteries at first glance. In practice, once you know which state the adjacency is actually stuck at, the list of plausible causes narrows down fast, because each state in the OSPF neighbor state machine corresponds to a specific step in the negotiation, and only a handful of things can break that specific step.
What follows is the state machine itself, what getting stuck at each state actually implies, the display commands to check at each one, the root causes that show up again and again, and a real convergence case with actual show output from the field.
Seven states between Down and Full — and three of them are where an adjacency stalls almost every time.
Before running any command, place the symptom on this chain. It tells you exactly which section below to read next.
Diagram labels are kept in English for engineering clarity.
Start with whether the neighbor shows up at all — then read the specific state it's stuck at.
If the neighbor never appears, or appears and then drops to Down, check the log keyword before guessing at a cause.
<Huawei> display ospf interface
OSPF Process 1 with Router ID 1.1.1.1
Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 1 192.168.1.1 0.0.0.0
<Huawei> display ospf error
General packet errors:
0 : Bad authentication type 0 : Bad authentication key
HELLO packet errors:
0 : Hello timer mismatch 0 : Dead timer mismatch
// counters climbing here point straight at the mismatched parameterOnce a neighbor is visible, the state it's frozen at narrows the cause list down even further.
<Huawei> display ospf interface
IP Address Type State Cost Pri DR BDR
1.1.1.1 Broadcast DROther 1 0 1.1.1.2 0.0.0.0
// Pri 0 + DROther = expected 2-Way, not a fault
<Huawei> ping -s 1500 -a 1.1.1.1 1.1.1.2
// tests whether oversized packets survive the path -- common ExStart causeOnce you know the state, these five account for most of what's actually wrong underneath it.
SYMPTOMThe neighbor never gets past Down or Init even though the interfaces are up and the link is fine — and there's no single obvious error anywhere.
CAUSESeveral independent parameters have to match exactly for a neighbor to form at all: the OSPF Area ID on both ends, the subnet and mask for broadcast/NBMA/P2MP networks (P2P has no such requirement), and the hello/dead timer intervals. None of these produce a dramatic error — they just quietly prevent the adjacency from ever forming.
FIXCompare display ospf interface's Area field on both ends first. Then run display ospf error every 10 seconds for about 5 minutes — a climbing Hello timer mismatch or Dead timer mismatch counter tells you exactly which timer to align with ospf timer hello or ospf timer dead.
<Huawei> display ospf interface
OSPF Process 1 with Router ID 10.1.1.1
Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
10.1.1.1 Broadcast BDR 1 1 10.1.1.2 10.1.1.1
// compare Area against the peer's own display ospf interface outputSYMPTOMThe neighbor state is frozen at ExStart — DD packets keep going back and forth but database description never synchronizes.
CAUSEWhen ospf mtu-enable is configured, the two interfaces' MTU values are required to be equal, or DD synchronization can't complete. Separately, oversized packets being silently dropped somewhere on the path produces the exact same symptom.
FIXRun ping -s 1500 neighbor-address to check whether large packets survive the path. If they don't, fix the link. If they do, compare and equalize both ends' interface MTU with the mtu command.
<Huawei> ping -s 1500 -a 1.1.1.1 1.1.1.2
[Huawei-GigabitEthernet1/0/0] mtu 1500SYMPTOMA neighbor relationship never forms with one specific third-party router, even though the same local router interoperates fine with every other OSPF neighbor on the network.
CAUSEOSPF requires the interface network type to match on both ends of a link — Broadcast, NBMA, P2P and P2MP are the four standard types, and broadcast/NBMA/P2MP additionally require both ends to share the same subnet and mask (P2P doesn't). In one real interoperability case, a third-party router's interface was set to a vendor-specific "point-to-multipoint non-broadcast" mode — which behaves like P2MP NBMA on paper but actually runs a proprietary, non-standard protocol underneath. The two sides were never actually speaking the same OSPF dialect, and the neighbor relationship failed outright.
FIXCheck the network type on both ends with the equivalent of ospf network-type and force them to one of the four standard OSPF types. Don't accept a peer's non-standard or vendor-proprietary variant just because its name sounds similar.
SYMPTOMA neighbor either never shows up at all, or the network behaves inconsistently in ways that don't trace back to any single link — routes or adjacencies that seem to work in one place and not another.
CAUSETwo routers in the same OSPF domain are configured with the same Router ID. Because Router ID is supposed to be unique across the whole autonomous system, a collision produces confusing, inconsistent symptoms rather than one clean error.
FIXCompare display ospf brief's Router ID on both ends, and reassign a unique one with ospf router-id.
<Huawei> display ospf brief
OSPF Process 1 with Router ID 1.1.1.1
OSPF Protocol Information
[Huawei] ospf router-id 1.1.1.2SYMPTOMThe neighbor never forms, and every other check — interface, subnet, MTU, timers — comes back clean.
CAUSEThe two routers building the adjacency have different OSPF authentication types configured for the area.
FIXRun display ospf error every 10 seconds for about 5 minutes. If the Bad authentication type counter keeps climbing, that confirms the mismatch — configure the same authentication type on both ends with area-authentication-mode.
<Huawei> display ospf error
General packet errors:
0 : Bad authentication type 0 : Bad authentication key
// a climbing Bad authentication type counter confirms the mismatch
[Huawei-ospf-1-area-0.0.0.0] area-authentication-mode md5Four switches, one broken link, and the difference network type makes to how fast — and how — OSPF actually notices.
The network: four routers running OSPF area 0, with SW2 and SW4 sharing a segment where SW4 is the DR. Normal traffic between SW2 and a loopback on SW4 (4.4.4.4) transits a third router, SW3. The test: keep a continuous ping from SW2 to 4.4.4.4 running, then physically disconnect SW2's link to SW4, and watch what each router's own LSAs actually do.
With the SW2–SW4 link set to the default broadcast network type, disconnecting it doesn't clear the adjacency immediately. SW2 notices right away and reissues its own router-LSA without the shared network in it, and recomputes its own routes quickly. But SW4's router-LSA and its network-LSA for that segment don't change yet — SW4 is still waiting for its dead timer to expire. When SW4 recomputes its own SPF tree in the meantime, it has to check SW2's router-LSA for a link back to the shared network to validate that path; since SW2's new LSA no longer lists it, SW4 correctly refuses to use that path, but the segment doesn't fully clear from the topology until SW4's own dead timer runs out.
SW4#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/BDR 00:00:37 1.1.24.2 GigabitEthernet0/24
1.1.1.1 1 FULL/DR 00:00:39 1.1.14.1 GigabitEthernet0/1
// after SW4's dead timer actually expires:
*Mar 1 01:18:54.681: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on GigabitEthernet0/24
from FULL to DOWN, Neighbor Down: Dead timer expired
SW4#show ip ospf database router self-originate
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.1.24.0
(Link Data) Network Mask: 255.255.255.0
// the segment only changes from Transit to Stub -- and the matching
// network-lsa is only withdrawn -- once SW4's own dead timer expiresSwitching that same SW2–SW4 link to point-to-point network type changes the outcome, not just the timing. On a P2P link, pulling the cable (or shutting the interface) drops the neighbor immediately on both sides — there's no DR/BDR relationship and no network-LSA layer to wait on. SW2 stops advertising the link the instant its own interface goes down; SW4 does the same the moment its neighbor relationship breaks, because a P2P router-LSA only carries the neighbor-describing link entry while the adjacency is actually Full. Neither side is stuck waiting on the other's dead timer for the network to fully reconverge.
The practical lesson isn't "P2P is always better" — it's that network type isn't just a configuration detail, it changes how failure actually propagates through the link-state database, and worth knowing deliberately rather than by accident when convergence speed matters.
This note is built around the Huawei AR-series router's OSPF neighbor-state diagnostic flow (display ospf interface / display ospf error / display logbuffer) plus one real multi-vendor convergence case. It doesn't cover NSSA-specific behavior, virtual links, OSPFv3 differences, or multi-area ABR summarization issues in depth — those each have their own failure modes worth a separate look.
Tell us which state it's frozen at and send the display ospf interface / display ospf error output — we'll help you read it.