Solution: OSPF Adjacency Stuck in ExStart/Exchange State¶

Triage¶

Confirm OSPF neighbor state on both routers:
```
show ip ospf neighbor
```
Look for the neighbor stuck in EXSTART or EXCHANGE.
Review OSPF interface parameters on both sides:
```
show ip ospf interface <intf>
```
Compare hello/dead timers, area, network type, and crucially, MTU.
Check interface MTU on both ends:
```
show interface <intf> | include MTU
```
Compare values -- they must match for OSPF DBD exchange.
Enable OSPF adjacency debug to observe the failure:
```
debug ip ospf adj
```
Look for "Nbr has larger interface MTU" messages.
Verify basic connectivity is fine (ping, Layer 2 errors).

Root Cause¶

OSPF includes the interface MTU in Database Description (DBD) packets during the ExStart/Exchange phase. If the MTU advertised by a neighbor does not match the local interface MTU, the router rejects the DBD packet and the adjacency cannot progress to Loading/Full.

In this case, a firmware upgrade on one router changed the default interface MTU from 1500 to 9000 (or vice versa), creating a mismatch. Ping works because ICMP echo packets are small, but OSPF DBD packets carry the MTU value and enforce a match.

Fix¶

Option A -- Match MTU (Preferred): On the router with the incorrect MTU, set it to match the other side:

interface GigabitEthernet0/1
  mtu 1500

Option B -- Ignore MTU in OSPF (Workaround): On both routers (must be both), configure:

interface GigabitEthernet0/1
  ip ospf mtu-ignore

This tells OSPF to skip the MTU check in DBD exchange.

After applying either fix, the adjacency should transition through Loading to Full within seconds. Verify:

show ip ospf neighbor
show ip route ospf

Rollback / Safety¶

If using Option A, ensure the MTU change does not break other services on that interface (e.g., jumbo frame traffic that needs MTU 9000).
If using Option B, be aware that actual MTU mismatches can still cause fragmentation or drops for OSPF LSA flooding if large LSAs exceed the smaller MTU.
Schedule the change during a maintenance window if traffic is sensitive.
Keep the old MTU value documented for quick rollback.

Common Traps¶

Assuming ping success means the link is healthy -- ping packets are small and do not exercise the MTU path.
Applying ip ospf mtu-ignore on only one side -- it must be on both to work.
Confusing ExStart/Exchange stuck state with Init or 2-Way issues, which have different root causes (hello problems, not DBD problems).
Forgetting to check if the firmware upgrade changed other OSPF defaults besides MTU (e.g., network type, cost).
Not verifying that OSPF routes are fully restored after the adjacency comes up.