OSPF Stuck in EXSTART: IP MTU Mismatch
An adjacency that forms, never reaches FULL, and reports a different state on each end. Diagnose the IP MTU mismatch and fix it yourself, live, right below.
Symptom
The neighbour appears, the link pings, and the adjacency never reaches FULL. Every parameter a Hello carries already matches, so the fault has to be somewhere Hellos never look.
Your mission
Prove the cause, then fix it
Format
Guided CLI investigation
Investigate before you configure.
Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.
Observe the symptom and link state.
Diagnose by comparing the protocol evidence.
Verify the expected device state and confirm the original symptom is resolved.
Console access: R1 · R2
This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.
Need a hint?
Reveal the root cause when you're ready.
Try the investigation first, then use this as your escape hatch, not a dead end.
Lab debrief
Turn the session into a repeatable troubleshooting pattern.
Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.
The problem
R1 and R2 are directly connected on Gi0/0, both in OSPF area 0. They ping each other and each sees the other in the neighbour table, but no routes are exchanged and the console keeps logging adjacency changes. The two routers do not even report the same neighbour state.
What you'll practice
- Tell an EXSTART or EXCHANGE hang apart from a neighbour that never forms
- Rule out every parameter carried in a Hello
- Read the IP MTU with the command that actually shows it
- Match the MTU, and know when ip ospf mtu-ignore is and is not appropriate
1. Why a visible neighbour narrows the search
If the neighbour appears at all, Hellos are flowing and matching. Area, timers, subnet mask and authentication are all carried in a Hello, so all of them are already proven correct. You will learn to use that to eliminate most of the usual checklist in one step.
2. The two ends disagree, and that is a clue
The router with the larger MTU sits in EXCHANGE while the one with the smaller MTU sits in EXSTART, because only the larger side gets far enough to send a Database Description packet the peer then rejects. Seeing two different states across one link is itself diagnostic.
3. The command that shows the MTU, and the one that does not
show interfaces prints the hardware MTU, which reads 1500 on both routers here and hides the fault completely. show ip interface prints the IP MTU, which is the value OSPF actually compares. Knowing which is which saves a long detour.
The topology
R1 and R2 are directly connected on Gi0/0 in OSPF area 0. R2 is the DR on the segment by virtue of its higher router ID.
Commands to run yourself
The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.
show ip ospf neighborshow ip interface GigabitEthernet0/0show loggingTopology diagram
Frequently asked
The neighbour is in the table, so why are no routes appearing?
Appearing in the neighbour table only proves Hellos are being exchanged and accepted. Routes are exchanged later, during the database exchange, and that is the stage failing here. An adjacency has to reach FULL before either router will install anything the other advertises, so a neighbour stuck below FULL is functionally the same as no neighbour at all.
Why do the two routers show different states?
The router with the larger MTU progresses further. It builds and sends a Database Description packet sized for its own MTU, which the router with the smaller MTU cannot accept, so the smaller side rejects it and drops back to EXSTART while the larger side waits in EXCHANGE. That asymmetry is a strong hint that the problem is MTU rather than anything symmetric like a timer.
Should I just use ip ospf mtu-ignore?
Only when you cannot change the MTU, for example across a carrier link that imposes it, and then you must set it on both ends because one-sided ignore still fails. It is the wrong choice when you own both routers: it forms the adjacency while leaving the real mismatch in place, so packets larger than the smaller MTU are still dropped in the data plane. You trade a loud failure now for a silent one later.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.