OSPF Stuck in EXSTART, Unsummarised Branches and a Static That Never Installed

The OSPF neighbour state narrows the fault. INIT means hellos are arriving but the router does not see its own router ID in them. 2WAY means bidirectional hello exchange succeeded. EXSTART means the routers have agreed to talk and are now negotiating master/slave using Database Description packets. A neighbour that reaches EXSTART and stays there is exchanging hellos and DBDs but failing to make progress on the DBD exchange.

The classic cause is an MTU mismatch. The DBD packet header carries the interface MTU. If the two ends differ, the router with the larger MTU keeps retransmitting its DBD because it never sees an acceptable reply, while the other side either stalls or reports a mismatch. A media converter swap is exactly the kind of event that leaves one side with a leftover mtu 9000 from a jumbo-frame lab while the other side is at 1500.

Checks: show ip ospf neighbor for the state, show ip ospf interface <int> for the MTU and timer values, show interfaces <int> for actual MTU, duplex and late collisions.

Fix, in order of preference:

1. Set both ends to a matching MTU (1500) since jumbo frames are not required here. This resets the adjacency anyway, so schedule it in the window.
2. If the provider equipment cannot be changed inside the window, ip ospf mtu-ignore on both sides clears the symptom. Treat it as temporary: it hides a real PMTU problem for any application that later sends large packets.
3. Do not start with clear ip ospf process on a production ABR; restarting the process on Branch-1 is acceptable, restarting it on HQ-EDGE-1 resets every adjacency on that router.

Summarisation must be configured on the ABR, HQ-EDGE-1, because type-3 summary LSAs are generated by the router that sits between the areas. Configuring a range on Branch-2 does nothing for the HQ routing table.

On HQ-EDGE-1: area 1 range 10.20.0.0 255.255.240.0. The mask /20 covers 10.20.0.0 through 10.20.15.255, which is sixteen /24s and comfortably includes 10.20.0.0 to 10.20.13.0.

What HQ sees: a single inter-area route for 10.20.0.0/20 instead of fourteen entries. The ABR also installs an automatic discard route for the range pointing to Null0, so traffic for the unused addresses in the range (10.20.14.0 and 10.20.15.0 today) is dropped at the ABR rather than looping.

If 10.20.14.0/24 is added later, it already falls inside the /20, so it is hidden by the summary and no HQ change is needed. That is the intended behaviour and also the trap: if a new subnet appears that must be reachable through a different path, the summary will blackhole it until the range is adjusted or the subnet is carved out. A subnet outside the range, for example 10.20.16.0/24, would be advertised individually and would appear in HQ as its own route, which is usually what you want.

Before applying, confirm that none of the fourteen subnets overlaps an address space used in another area, and verify with show ip ospf database summary that only the /20 is advertised into area 0.

The administrative distance logic is correct: 250 is worse than OSPF's 110, so the static only becomes eligible when no OSPF default exists. The failure is in the recursion, not the distance.

A static route needs a resolvable next hop. 10.255.0.1 is reachable only through the OSPF domain, so the moment the OSPF default is withdrawn, the lookup for 10.255.0.1 fails. Cisco IOS does not keep a static route whose next hop cannot be resolved; the route is removed or never installed, which is exactly the four-minute black hole the branch experienced.

Ways to make the backup deterministic, ranked:

1. Point the static at the LTE egress interface rather than a recursive next hop, for example ip route 0.0.0.0 0.0.0.0 Dialer1 250. Interface-based statics do not depend on a recursive lookup.
2. Put the LTE next hop on a directly connected subnet so the adjacency is resolved by the connected route, not by OSPF.
3. Add IP SLA with track to withdraw the LTE route when the probe fails, so a dead LTE link does not silently attract traffic.
4. As a second layer, originate a default on HQ-EDGE-1 with default-information originate plus a static backup at HQ, so branches always receive a default from the ABR and the local static is only the last resort.

Validate with show ip route 10.255.0.1 during a test withdrawal, not during the outage. A backup path that has never been tested is a design assumption, not a backup.