Two OSPF routers can discover each other but never reach a full adjacency. The neighbor state remains at EXSTART or repeatedly resets. Many engineers immediately suspect an MTU mismatch, and that is a reasonable check, but it is not the only condition that can interrupt database exchange.
OSPF uses neighbor states to coordinate how routers exchange link-state database information. EXSTART is part of that process, so a stuck state suggests the neighbors are not completing the expected database-description exchange. A mismatch in interface settings, unstable transport, filtering, or duplicate identifiers can produce similar symptoms. Accurate logs and packet evidence help distinguish them.
Record the two router IDs, interface addresses, area, interface MTU, network type, authentication, timers, and neighbor state transitions. Check whether the problem is on one link or several. A single adjacency failure after a change points to a local configuration or path issue; repeated flaps across links may indicate broader control-plane instability.
After correcting the identified mismatch or transport issue, confirm that the neighbor reaches FULL and remains stable. Verify that expected routes appear, next hops are correct, and there is no repeated adjacency churn. Monitor the link long enough to cover normal traffic and confirm the fix did not affect other neighbors.
Neighbor states represent stages of the OSPF relationship, not simply a binary up or down condition. EXSTART indicates that the routers are attempting to establish the master-slave relationship for database exchange. Repeated transitions can reveal whether the exchange begins and then resets.
If you capture OSPF traffic, compare database-description packets in both directions and correlate them with neighbor logs. Packet captures can show retransmissions or missing replies, but they must be interpreted with the platform’s OSPF behavior and network design.
Use consistent interface templates for OSPF links and record MTU, area, network type, timers, and authentication in the design. Validate adjacency after link changes and keep router IDs unique. Include neighbor-state monitoring and alert on repeated transitions rather than only on a complete route loss.
OSPF neighbors exchange database description packets as they move from ExStart into Exchange. Those packets include information that helps the routers agree on the exchange, and the interface MTU is a common reason the exchange can stall when values differ. Still, the state alone does not prove an MTU issue. Check that both sides agree on area, network type, timers, authentication, and IP reachability, and look for repeated neighbor resets or a second router competing for the same router ID.
Compare the configured and operational MTU on both ends of the actual OSPF link, including any subinterfaces, tunnel interfaces, or provider handoff. A physical interface can show one value while an overlay or subinterface uses another. Review logs and packet captures for database description packets, retransmissions, or an MTU-related rejection. Capture on both sides when possible, because a packet may be dropped or altered in transit. Keep the capture narrowly scoped to the affected adjacency and follow your organization’s data-handling rules.
If an MTU mismatch is confirmed, determine why it exists before making the values equal. A larger MTU might be intentional on a backbone or tunnel path, and changing it can affect other traffic. Coordinate the correction at both ends during an approved change window, then verify that the neighbor progresses through the expected states to Full and remains stable. Check the route table as well: a Full adjacency is not enough if the expected OSPF routes are missing or filtered.
Some platforms offer an option to ignore the MTU check in database description exchanges. Treat that as a deliberate compatibility choice, not a general repair. It can allow the neighbor relationship to form while larger data packets still fail elsewhere on the path. If you use such an option under a documented design requirement, verify end-to-end packet handling and record why it is present. Prefer a consistent interface MTU when that matches the network design.
If the MTU values match, continue through the OSPF adjacency checklist rather than repeatedly changing them. Confirm that both routers use compatible area and network type settings, that hello and dead intervals match, and that authentication succeeds. Review the neighbor logs for resets and compare the two routers’ interface addresses and masks. A duplicate router ID or a one-way communication problem can also prevent the database exchange from completing.
Check whether a packet capture shows database description packets in both directions. If one router sends but never receives a response, the issue may lie in a filter or the return path. If packets arrive but are repeatedly rejected or restarted, compare the protocol fields and interface configuration at that exact time. Vendor command output differs, so use the documentation for the router software in production rather than relying on a command copied from another release.
After the adjacency reaches Full, verify that the expected prefixes are installed and that traffic uses the intended next hop. Keep an eye on stability across several dead-intervals and compare interface counters for errors or drops. If the neighbor flaps again, preserve the new logs and packet evidence before changing additional timers or MTU options. One controlled change at a time makes it possible to identify the actual cause.
EXSTART is a clue about database exchange, not a definitive root cause. Check MTU first when the evidence points there, then validate the OSPF parameters and the underlying link before making a change.
Does EXSTART always mean an MTU mismatch?
No. MTU is a common cause, but OSPF settings, authentication, duplicate router IDs, packet loss, or filtering can also prevent the exchange from completing.
What does a healthy OSPF neighbor state look like?
For a normal full adjacency, the expected state is typically FULL. Some network types intentionally form fewer full adjacencies, so compare the state with the platform’s design and documentation.
Can I use an OSPF MTU-ignore setting?
Some platforms offer an option to ignore MTU during adjacency formation, but it can mask a real packet-size problem. Confirm the path MTU and platform guidance before using it.
What should I collect before resetting OSPF?
Capture neighbor detail, interface status and counters, OSPF logs, effective MTU, router IDs, and recent changes. This evidence may disappear when the process is restarted.
Join the discussion: If the MTU values match, what would you investigate next?
For hands-on practice with real network troubleshooting, explore training with Atmic Networks.
SEO title: OSPF Stuck in EXSTART: Is an MTU Mismatch Always the Cause?
Meta description: OSPF stuck in EXSTART? Learn why MTU mismatch is a common cause and what OSPF settings, logs, and link conditions to check next.
Focus keywords: OSPF EXSTART troubleshooting, OSPF MTU mismatch, OSPF adjacency, network troubleshooting
URL slug: ospf-exstart-mtu-mismatch
