OSPF stuck in EXSTART/EXCHANGE? It is almost always MTU

Two routers, matching areas, correct timers, interfaces up — and the OSPF neighbor still refuses to reach FULL, cycling between EXSTART and EXCHANGE. Before you tear the config apart, check the MTU. This single mismatch accounts for the large majority of stuck OSPF adjacencies.

Why MTU breaks the adjacency

OSPF neighbors climb through a sequence of states: Down, Init, 2-Way, ExStart, Exchange, Loading, Full. In ExStart the routers elect a master and agree on a DBD sequence number. In Exchange they send Database Description packets describing their link-state databases. Those DBD packets can be large — and OSPF checks that both interfaces agree on IP MTU. If one side is 1500 and the other is 9000 (or a sub-interface adds a tag), the oversized packets are dropped, the exchange never completes, and the neighbor falls back to ExStart and tries again. Forever.

How to confirm it

R1# show ip ospf neighbor
Neighbor ID     State            Interface
10.0.0.2        EXSTART/DR        GigabitEthernet0/0

R1# show interface Gig0/0 | include MTU
  MTU 1500 bytes ...
R2# show interface Gig0/0 | include MTU
  MTU 9000 bytes ...

A state stuck at ExStart or Exchange is the tell. Compare the IP MTU on both ends — including any tunnel or 802.1Q sub-interface overhead. Area, hello/dead timer, and authentication mismatches all fail earlier (the neighbor never leaves Init or 2-Way), so ExStart/Exchange specifically points the finger at MTU.

The fix

• →Best: make the IP MTU identical on both interfaces.
• →Workaround: if you genuinely cannot match them, tell OSPF to skip the check with ip ospf mtu-ignore on the interface. It masks the symptom rather than curing it — packets can still be dropped elsewhere.

If a tunnel is involved, the real MTU is smaller than the physical interface suggests — work out the effective value before you set it.