I85PREP
⌘ K
CNPA study materials
CNPA study resources

OSPF Neighbour Stuck in EXSTART Across Metro Ethernet

CNPA · Put your knowledge to work in context.

All case studies

OSPF Neighbour Stuck in EXSTART Across Metro Ethernet

Harborline Logistics has just turned up a 1 Gbps Metro Ethernet circuit between HQ router R1 (GigabitEthernet0/1, 192.0.2.1/30) and the new distribution centre router R2 (192.0.2.2/30). The provider presents the circuit as a transparent Layer 2 segment, so both routers see a broadcast network, and OSPF area 0 is configured on both. show ip ospf neighbor on R1 has shown 192.0.2.2 in EXSTART/EXSTART for 40 minutes, briefly reaching EXCHANGE twice before falling back. Hello and dead intervals match at 10/40, area IDs match, authentication is off, and there is no ACL on either interface. The only difference between the two interfaces is MTU: R1 uses 1500 while R2 was set to 9000 when the SAN was extended to that site. OSPF is not the only traffic - a nightly backup and a database replication stream also cross this circuit, and replication has been timing out on large rows.

1. Why does the adjacency stall in EXSTART rather than INIT or 2-WAY, and which field is responsible?

Read the worked answer

The OSPF neighbour state tells you which phase failed.

  • INIT means hellos are being received but the router's own Router ID is not in them - a one-way hello problem.
  • 2-WAY means hellos are mutual but the routers are not forming a full adjacency (DR/BDR non-eligibility, or a duplicate RID).
  • EXSTART is the master/slave negotiation that begins the Database Description (DBD) exchange. Reaching EXSTART and stopping means hellos and the neighbour relationship are fine and the DBD phase is failing.

Each DBD packet carries the sender's interface MTU in a header field. A router that receives a DBD advertising a larger MTU than its own interface discards it without progressing the exchange. R1's interface is 1500, so it throws away R2's DBDs advertising 9000; R2 retries, the relationship falls back, and the cycle repeats - exactly the EXSTART/EXCHANGE flapping described.

debug ip ospf adj would show DBD packets being received and rejected with an MTU mismatch message, which is the definitive confirmation.

2. Give two remediation paths and the consequence of each, given the replication traffic.

Read the worked answer

Path A - align the MTU upward. Set R1 to 9000 as well. This only works if the provider's Layer 2 path carries jumbo frames end to end. Test before trusting it: ping 192.0.2.2 size 8972 df-bit must succeed. If the provider drops or fragments jumbo frames, the adjacency comes up but the replication stream black-holes, which is worse than a down adjacency because it fails silently.

Path B - align the MTU downward. Set R2 back to 1500. The adjacency forms normally and the data plane matches the control plane.

ip ospf mtu-ignore is a third option, but understand what it does: it only tells OSPF to stop checking the MTU field. It fixes the routing protocol and leaves the data plane broken - replication rows larger than 1500 still fail. Use it only as a stopgap while you fix the real MTU, and pair it with ip tcp adjust-mss (for example 1400) so TCP negotiates a segment size that actually fits.

Given the SAN use case, the correct outcome is either a provider-confirmed jumbo path or a separate circuit for replication.

3. The provider confirms jumbo frames are not supported on this circuit. What do you change, and how do you prove the fix?

Read the worked answer

Changes:

  1. On R2, interface Gi0/x then mtu 1500 so both ends agree at the interface level.
  2. Clear the stuck adjacency (clear ip ospf process on one side, after confirming it is safe) or wait out the dead timer.
  3. Fix the data plane, which is the actual business problem: ip tcp adjust-mss 1400 on both WAN interfaces so TCP sessions negotiate segments that fit inside 1500-byte frames.
  4. Consider ip ospf network point-to-point on this link. With exactly two routers on a broadcast segment, point-to-point skips DR/BDR election and converges faster; confirm nothing else relies on the broadcast network type.

Proof:

  • show ip ospf neighbor shows FULL/ - for 192.0.2.2, and show ip ospf interface confirms MTU value and network type.
  • show interface Gi0/x shows 1500/1500 on both ends.
  • ping 192.0.2.2 size 1472 df-bit succeeds and a 1500-byte DF ping fails, confirming the path MTU.
  • Replication completes without timeouts and the nightly backup finishes inside its window.
  • show ip ospf database shows consistent LSAs and no repeated flooding.