OSPF MTU Mismatch Causing Stuck in EXSTART
Presenting Symptom
OSPF neighbors are stuck in EXSTART state and cannot form full adjacency.
Network Context
Two Cisco routers (R1 and R2) are directly connected via GigabitEthernet interfaces in a small branch office. Both run IOS 15.x. The link is a point-to-point Ethernet segment. The OSPF adjacency fails to reach FULL state, remaining in EXSTART.
Diagnostic Steps
Check OSPF neighbor state
show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 192.168.1.2 1 EXSTART/DR 00:00:32 10.0.0.2 GigabitEthernet0/0
If neighbor is stuck in EXSTART, it indicates a problem during the database exchange phase. Common causes include MTU mismatch or mismatched OSPF options.
Verify interface MTU on both routers
show interfaces GigabitEthernet0/0 | include MTUMTU 1500 bytes (R1) vs MTU 1400 bytes (R2)
Compare MTU values. If they differ, OSPF packets larger than the smaller MTU will be dropped, causing the adjacency to stall in EXSTART.
Check OSPF database exchange details
debug ip ospf adjOSPF: Rcv pkt from 10.0.0.2, GigabitEthernet0/0 : Mismatched OSPF packet type: dbd OSPF: Send pkt to 10.0.0.2, GigabitEthernet0/0: Invalid MTU
The debug output shows MTU mismatch errors. OSPF Database Description (DBD) packets are dropped because they exceed the smaller MTU.
Confirm MTU mismatch root cause
show running-config interface GigabitEthernet0/0interface GigabitEthernet0/0 ip address 10.0.0.1 255.255.255.252 ip ospf mtu-ignore ! (R2 has no mtu-ignore and a different MTU)
If one router has 'ip ospf mtu-ignore' and the other does not, or if interface MTU values differ, the mismatch is confirmed.
Root Cause
The MTU size on the two routers' connecting interfaces is mismatched (e.g., 1500 vs 1400). OSPF DBD packets are larger than the smaller MTU and are silently dropped, preventing the routers from completing the database exchange and moving out of EXSTART state.
Resolution
Verification
show ip ospf neighbor Expected output: Neighbor state changes to FULL. Example: Neighbor ID Pri State Dead Time Address Interface 192.168.1.2 1 FULL/DR 00:00:36 10.0.0.2 GigabitEthernet0/0
Prevention
1. Ensure consistent MTU configuration across all OSPF interfaces in the network. 2. Use 'ip ospf mtu-ignore' only when necessary and consistently on both ends. 3. Document MTU settings in network design to avoid mismatches.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario may appear as a troubleshooting question where you must identify why OSPF neighbors are stuck in EXSTART. The exam tests understanding of OSPF adjacency states and the impact of MTU mismatch. Key fact: OSPF DBD packets must not exceed the interface MTU; otherwise, they are dropped.
Exam Tips
Remember that EXSTART state indicates a problem during database description packet exchange; MTU mismatch is a common cause.
The command 'show ip ospf neighbor' is essential to identify the stuck state; 'debug ip ospf adj' can confirm MTU errors.
Know that 'ip ospf mtu-ignore' disables MTU checking for OSPF, but it is not a best practice; consistent MTU is preferred.
Commands Used in This Scenario
debug ip ospf adj
Use this command to debug OSPF adjacency events in real-time, helping to troubleshoot why OSPF neighbors are not forming or are flapping.
show interfaces
Displays detailed status and statistics for all interfaces or a specific interface, used to verify interface operational state, errors, and performance.
show ip ospf neighbor
Displays OSPF neighbor information to verify adjacency formation and troubleshoot OSPF neighbor relationships.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions