OSPF Stuck in EXSTART After a 10G Core Cutover, Then a Summary Black Hole
Northgate Data Center replaced the 1 Gbps core link between CORE-A (IOS-XE) and CORE-B (EOS) with 10 Gbps optics during a Saturday window. OSPFv2 area 0 is the IGP; both routers also carry floating static routes that are currently forwarding production traffic, so users see no outage but redundancy is gone. Forty minutes after cutover the adjacency is stuck in EXSTART. Hellos are received in both directions, router IDs are unique, area IDs match, and authentication is correct. Before the window the team enabled MTU 9216 on CORE-B's new port and on the test set for a storage project; CORE-A interfaces, including the new one, remain at 1500. Jumbo frames end to end are planned for Q3. Separately, the NOC reports 10.20.5.0/24 and 10.20.6.0/24 unreachable from area 0 even though a 10.20.0.0/16 summary is present; those two subnets live in area 2 behind ABR-2, while ABR-1 has area 1 range 10.20.0.0 255.255.0.0 configured.
1. The adjacency sits in EXSTART rather than DOWN or INIT, and hellos are exchanged both ways. What does that narrow the fault to, what is the mechanism, and which fix would you apply?
Read the worked answer
What EXSTART narrows down to. Hellos are small (far below 1500 bytes) and are being exchanged, so unicast reachability, area ID, timers and authentication are fine; DOWN or INIT would point at those. EXSTART/EXCHANGE means both routers elected master/slave and are now swapping Database Description packets. DBDs are sent at interface MTU with the DF bit set. With CORE-B at 9216, its DBDs exceed 1500 bytes; CORE-A silently drops them (no usable ICMP signal), DBDs are retransmitted, and the FSM never leaves EXSTART.
Confirm before touching anything.
show ip ospf neighbor <rid> detailshows EXSTART/EXCHANGE;show interface | include MTUshows the mismatch.- DF probe: from CORE-A
ping <CORE-B> size 1500 df-bitfails whilesize 1400succeeds; reverse from CORE-B. - Packet capture on CORE-A shows 9000-byte OSPF packets arriving that never appear in OSPF input counters.
- Check the whole L3 path, not just the physical port: a GRE/IPsec tunnel or a LAG member with a lower MTU caps the real value.
Fix options.
- Align MTU on both ends of the L3 interface (both 9216 or both 1500). Correct fix; it keeps the DBD check meaningful for the data plane.
ip ospf mtu-ignore(or the EOS equivalent) brings the adjacency up in minutes but only hides the mismatch: oversized packets are still dropped or fragmented in the data plane, which is exactly the failure a later jumbo rollout would hit.
Use option 2 only as a tracked temporary unblock. After the fix, verify FULL, re-run DF probes at 8972 across the path, and confirm the floating statics drop out of the RIB. Because the two routers are different vendors, also record the MTU policy in the CMDB so the Q3 jumbo project does not repeat this.
2. After the adjacency is fixed, 10.20.5.0/24 and 10.20.6.0/24 are still unreachable while the /16 summary looks healthy. Explain the mechanism and your remediation options.
Read the worked answer
Mechanism. ABR-1 injects a type-3 summary 10.20.0.0/16 into area 0 because of area 1 range. ABR-2 is the real exit for 10.20.5.0/24 and 10.20.6.0/24 (they sit in area 2). OSPF will not advertise a type-3 LSA for a component prefix already covered by a range learned from another ABR, because that would contradict the summary. Area 0 therefore knows only /16 and forwards all 10.20.x.x traffic to ABR-1. ABR-1 has no area-2 adjacency, no more-specific route, and typically installs a discard route for the range, so both /24s black-hole.
Confirm. On ABR-2, show ip ospf database summary 10.20.5.0 shows no LSA generated toward the backbone while the /24 exists intra-area in area 2. On ABR-1, show ip route 10.20.5.0 resolves to Null0 or has no entry. On a backbone router, only 10.20.0.0/16 appears.
Options, best first.
- Remove the range on ABR-1 (or shrink it so it covers only prefixes genuinely behind ABR-1, e.g. 10.20.0.0/20 for area 1) and let specifics propagate.
- Move the two subnets into area 1 so the summarization is topologically true.
- Keep /16 and rely on a discard route: wrong here, because the components are not reachable through the summarizing ABR.
The general rule to document: a range belongs on the ABR that owns every component prefix, and any summarization change needs a reachability check against at least one address per summarized subnet.
3. The Q3 plan is to enable jumbo frames end to end. What would you require before that change is approved and how would you validate it?
Read the worked answer
Treat 9216 as an end-to-end property, not an interface setting. The effective path MTU is the minimum across every hop: access and core switches, routed links, firewalls, load balancers, GRE or IPsec tunnels, hypervisors and storage NICs. A partial rollout gives no benefit because fragmentation is performed by the hosts, and mixed MTUs are worse than a uniform 1500.
Before approval:
- Inventory current MTU per device and per tunnel, including overhead (24 bytes for GRE, ~50-60 for IPsec), and put the values in the CMDB.
- Define the goal: which traffic actually benefits (backup, storage, replication) and what baseline it has today.
- Build a DF-probe matrix from each server VLAN to each storage VLAN at 8972-byte payload; a failure at 1500 identifies the blocking hop.
Rollout and validation:
- Canary one leaf pair plus two hosts, run backup throughput and latency baselines for a week.
- Then per-site batches with
serial, a change window, and a rollback trigger: any failed DF probe, rising giant/jabber counters, or OSPF adjacency loss on routed links. - After each batch check
show interfaceMTU, giant and CRC counters, adjacencies, and an application-level check.
Record the decision and the per-device values in the change record so the next engineer does not rediscover the EXSTART failure the hard way.