Troubleshooting OSPF Neighbor Stuck in ExStart/Exchange State: Configuration, Compatibility & Error Resolving

Overview & Thematic Scope

In OSPF, when two routers reach the ExStart or Exchange state and stall, the culprit is frequently an MTU mismatch on the link. The OSPF Database Description (DBD) packet carries an Interface MTU value, and a receiving router drops the DBD when its own IP MTU is larger than the advertised value—halting adjacency establishment. This FAQ provides practical, vendor-agnostic troubleshooting guidance for network engineers facing this issue in B2B telecom and datacenter deployments.

Frequently Asked Questions

Q1: What causes an OSPF neighbor to get stuck in ExStart or Exchange state?

The most common cause is an MTU mismatch between directly connected OSPF interfaces on the same subnet. If the two routers advertise different IP MTU values in their DBD packets, the larger-MTU router rejects the smaller one’s DBD, and the adjacency never progresses past ExStart/Exchange. Other causes include duplicate router IDs, ACL filtering OSPF multicast (224.0.0.5/224.0.0.6), or mismatched area/subnet parameters—but MTU is the leading suspect when the state is specifically ExStart/Exchange.

Q2: How does MTU mismatch actually break OSPF DBD exchange?

A router drops an incoming DBD packet if its interface MTU is larger than the Interface MTU field advertised by the neighbor. Because DBD packets exchange master/slave negotiation and summary information, this drop prevents the routers from agreeing on the DBD sequence, leaving the adjacency stuck. The reverse mismatch—where the local MTU is smaller—also causes failures because the neighbor’s larger MTU causes oversized DBD handling and retransmission loops.

Q3: What CLI commands quickly confirm an MTU mismatch on a stalled OSPF adjacency?

Run show ip ospf neighbor to verify the ExStart/Exchange state, then compare show interfaces (or show ip interface brief) on both ends for the IP MTU and L2 MTU values. Additionally, enable debug ip ospf adjacency or equivalent logging to see DBD rejection messages that explicitly cite the MTU mismatch. On Cisco, expect messages like ‘MTU mismatch’ in the debug output.

Q4: How do I resolve the OSPF ExStart/Exchange stall without a maintenance window?

If you cannot change the underlying MTU, configure OSPF MTU ignore (Cisco: ip ospf mtu-ignore under the interface) or the equivalent vendor command to skip MTU validation during DBD exchange. This is a workaround, not a fix—it risks silent packet drops if jumbo frames or inconsistent fragmentation occur. The proper fix is aligning the IP MTU on both interfaces (e.g., 1500 to 1500 or 9000 to 9000).

Q5: What are best practices for MTU and jumbo frame configuration when deploying OSPF in datacenters?

Standardize the IP MTU across all links in the same OSPF area and document it in your network design. If jumbo frames (typically 9000 bytes) are used, ensure every switch and router in the path supports and is configured for the same MTU, including L2 MTU on switch ports. Many carriers’ OSPF peers enforce 1500 MTU, so negotiate MTU requirements during link provisioning rather than discovering mismatches at adjacency bring-up.

Q6: Can an MTU mismatch cause intermittent rather than total OSPF adjacency failures?

Yes—if the mismatch affects only certain links or occurs after a firmware upgrade or configuration change, adjacencies may form, flap, and re-stall intermittently. Such flapping is often misdiagnosed as a routing issue; check interface MTU logs and change history. Persistent ExStart/Exchange with no flapping strongly indicates a static MTU misconfiguration.

Q7: What troubleshooting steps should I follow to isolate a suspected MTU mismatch in a multi-vendor OSPF network?

First, document the IP MTU on every interface along the adjacency path on both ends, including transit switches. Second, capture DBD packets and verify the Interface MTU field values differ. Third, temporarily enable MTU-ignore to confirm the diagnosis, then align MTU settings and disable the workaround. Finally, re-verify adjacency formation and run a full OSPF neighbor check across the area.

Q8: How do I prevent OSPF MTU mismatch issues during network upgrades or migrations?

Include MTU values in your configuration templates and change checklists, and validate MTU consistency as part of pre-deployment testing. Automate configuration auditing with scripts or NMS tools that flag mismatched MTU settings on OSPF-enabled interfaces. When migrating to jumbo-frame fabrics, roll out MTU changes link-by-link during maintenance windows and monitor OSPF adjacency state throughout.