In plain English: Two routers are trying to become partners and swap routes, but they freeze at the handshake. Most of the time they simply disagree about how big a packet the link is allowed to carry — like two people passing boxes through a door, each sure the door is a different size. Match the sizes and the conversation starts.
The symptom
Two routers that should exchange routes sit forever in the state EXSTART (or bounce between EXSTART and DOWN). The routing table never learns the routes behind the neighbor, so part of the network is unreachable — even though the link is up and both routers can ping each other.
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 EXSTART/DR 00:00:38 10.12.0.2 Gi0/1
Log: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.2 on Gi0/1 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
Check first — in this order
show ip ospf neighborConfirm the state is EXSTART or EXCHANGE, not INIT or 2-WAY. Each stuck state has a different cause list — this case is only for EXSTART/EXCHANGE.
show interfaces Gi0/1 — on BOTH routersRead the MTU line on each side. If they differ (1500 on one side, 9000 or 9216 on the other), you have almost certainly found it. Stop and go to the fix.
ping 10.12.0.2 size 1500 df-bit — then ping size 9000 df-bitSmall pings succeed and large ones fail when something between the routers (or one interface) cannot carry big packets. That pattern confirms a size problem.
show ip ospf interface Gi0/1Rule out the other quick killers while you are here: area number, network type, and hello/dead timers must match on both sides.
Test only: add 'ip ospf mtu-ignore' on one side, watch the neighborIf the adjacency jumps to FULL within seconds, MTU mismatch is proven. This command is a diagnostic, not the fix — remove it when you are done testing.
What the evidence means
EXSTART is the moment the two routers start swapping their route summaries (database description packets). Those packets carry each side's interface MTU, and a router refuses a partner whose MTU does not match its own — so the conversation stalls at the handshake, forever retrying. That is why the ping works and the link looks fine: small hello packets pass, the big database packets do not get accepted.
Root causes, ranked
Root cause
How you recognize it
MTU mismatch between the two interfaces
One side shows 1500, the other 9000/9216. The classic story: jumbo frames were enabled on one router during an upgrade and never matched on the other.
Something in the middle drops large packets
A tunnel, a WAN device, or an old link with a smaller MTU silently discarding the big database packets. The large-ping test fails even though interface MTUs match.
Duplicate OSPF router IDs
Both routers using the same router ID confuses the master/slave negotiation that happens in EXSTART. Check 'show ip ospf' on both sides.
One-way unicast reachability
After EXSTART the exchange uses unicast packets. An ACL or a broken return path that passes multicast hellos but blocks unicast produces exactly this picture.
Before you touch production: Changing MTU on a live interface drops and rebuilds the OSPF adjacency — expect a short routing blip on that link. If the link carries production traffic, do it in a change window.
The fix
Set the SAME MTU on both interfaces — either both at the standard 1500, or both at the jumbo value your design uses ('mtu 9000' / 'ip mtu 9000' on the interface, both sides).
If a middle device is the limit, either raise its MTU or lower both router interfaces to match the path.
Remove the 'ip ospf mtu-ignore' test command if you added it — leaving it hides the mismatch instead of fixing it, and it will bite again on the next link.
Avoid 'clear ip ospf process' unless nothing else works: it resets every OSPF adjacency on that router, not just this one.
Verify it worked
show ip ospf neighborState reads FULL on both routers, and stays FULL for several minutes.
show ip route ospfThe routes behind the neighbor are present in the table.
ping across the link at full interface MTU with df-bit setReplies succeed — the large-packet path is proven, not assumed.
Did this fix it for you? One tap — anonymous, nothing to type, and nothing you send is ever published.
Which cause was yours?
Thanks — your tap helps the next engineer. A run of "still broken" reports sends this page back to the top of our re-check list.
Going deeper — production notes
Swipe sideways to see the full diagram →
Why the neighbor looks half-alive: hellos are small and sail through, database packets are full-size and hit the MTU wall. The retransmission counter is the fingerprint.
EXSTART is not EXCHANGE
EXSTART versus EXCHANGE matters. EXSTART is only the opening handshake, where the two routers elect a master and exchange the first database summary. If the neighbor reaches EXCHANGE and stalls there instead, the opening worked and the failure is mid-conversation — almost always the larger database packets being dropped on the path, which the big-ping test exposes.
The retransmission fingerprint
Read the detail view before changing anything: 'show ip ospf neighbor detail' shows how many times the database packets have been retransmitted. Retransmissions climbing while hellos flow normally is the fingerprint of the size problem — hellos are small; database packets are as big as the interface allows.
Same fault, other platforms
On other platforms the same fault wears the same face: NX-OS uses 'show ip ospf neighbors' and carries MTU in 'show interface'; IOS XR uses 'show ospf neighbor'; Junos shows the neighbor in ExStart with 'show ospf neighbor' and the interface MTU in 'show ospf interface detail'. On every platform the first comparison is identical: MTU, both ends.
What the capture shows
If you capture traffic, filter on IP protocol 89 (OSPF). In this fault you typically see hellos flowing both ways, then database description packets from one side answered by retransmissions of the same packet — or never answered at all at the larger sizes.
Debug with respect
Debug with respect: 'debug ip ospf adj' on a busy production router generates heavy output. Run it inside a maintenance window, log to buffer rather than console, and 'undebug all' the moment you have the exchange. The debug prints the MTU inside the received database packet next to your own interface value — that one line closes the case.
The TAC bundle
If you hand this to Cisco TAC, send: 'show ip ospf neighbor detail' from both routers, the 'show interfaces' MTU lines from both ends, the big-ping results, and a capture filtered on protocol 89. That bundle answers their first four questions.
The same two checks, on every platform
Platform
See the neighbor
See the interface MTU
Cisco IOS / IOS XE
show ip ospf neighbor
show interfaces
Cisco NX-OS
show ip ospf neighbors
show interface
Cisco IOS XR
show ospf neighbor
show interfaces
Juniper Junos
show ospf neighbor
show ospf interface detail
Reproduce this failure: Packet Path's hands-on labs run this class of fault in a simulated network, so you can break it, run the checks above, and fix it there before touching production. Open the labs.
Prevention
Keep interface MTU in your standard build template, so jumbo changes are applied to both ends of a link in the same change.
Alert on OSPF neighbor state changes — an adjacency sitting in EXSTART pages nobody by itself.
After any MTU or jumbo-frame project, re-check every routing adjacency on the touched links.
Still stuck? Before you open a TAC case
Work this ladder before you open a case. Most EXSTART tickets that reach TAC turn out to be one of these five — and if yours survives all five, you will hand TAC a case they can answer in one reply.
The last checks — the ones that close most "unsolvable" cases
Swap the path, not the config: move the link to a different port, with a known-good cable and optic. A dying optic corrupts large frames first — and looks exactly like an MTU problem.
Compare against a working neighbor on the same router. If other adjacencies on identical settings are Established, your OSPF design is innocent — the fault lives on this link or this peer.
Strip the interface to the bone, inside a window: temporarily remove anything that touches packet size or forwarding on that interface (ACLs, QoS policies, uRPF, tunnel overlays) and retest.
Check the software before the hardware: search your exact IOS version plus 'OSPF EXSTART' in Cisco's bug search and release notes. Known defects break DBD retransmission on specific trains — a bug match ends the troubleshooting on the spot.
Capture at both ends and match packet for packet (protocol 89). If A sends database packets B never receives, it is the path. If B receives them and stays silent, it is B. That one fact halves every case.
It really is a TAC case when
A router crashes, reloads, or logs tracebacks when the adjacency is attempted.
Captures prove both sides send protocol-correct packets, configs are verified line by line, and both sides still refuse — that is defect territory.
The fault follows a line card or supervisor across known-good links and peers. That is hardware confessing.
If you do open one, hand them this bundle
'show ip ospf neighbor detail' and 'show ip ospf interface' from both routers
Interface MTU lines and error counters from both ends
Full-size ping results, both directions, sourced from the adjacency addresses
Captures filtered on protocol 89 from both ends, timestamps aligned
Exact software versions on both routers, and the 'show version' uptime lines
The error message, decoded
%OSPF-5-ADJCHG — what the log line means, in plain English.