OSPF Adjacency Flaps Between EXSTART and FULL Across a Pseudowire
HQ-DIST and BR-EDGE are OSPFv2 neighbors over a 50 Mbps provider pseudowire in area 0, subnet 10.12.0.0/30. The adjacency has flapped between FULL and EXSTART roughly every four hours for a week; show ip ospf neighbor sometimes shows EXSTART/EXCHANGE with the dead timer counting down. Hello and dead intervals match at 10/40, area IDs match, MD5 keys match, and both interfaces are up/up. HQ-DIST Gi0/0/1 has MTU 1500; BR-EDGE Gi0/0/0 was set to 1400 to accommodate the provider's imposed overhead. The provider confirms no loss but reports occasional micro-outages under 200 ms. BR-EDGE also injects 900 redistributed static routes as Type-5 LSAs into area 0, and 40 downstream branch routers behind BR-EDGE need only a default route. HQ-DIST currently runs both default-information originate and a static 0.0.0.0/0 pointing at the provider.
1. Why does the adjacency stall in EXSTART rather than going to DOWN, and what is the correct fix?
Read the worked answer
OSPF reaches EXSTART once it has exchanged hellos and elected master/slave. In EXSTART the neighbors send Database Description packets, and the DBD header carries the sender's interface MTU. A router that receives a DBD whose MTU is larger than its own interface MTU refuses to proceed and stays in EXSTART, retransmitting DBDs. Hellos continue to be exchanged, so the dead timer keeps being refreshed and the neighbor never falls to DOWN - this is why the state oscillates between EXSTART and FULL as the link bounces instead of showing a clean failure.
Correct fix: align the MTU. Set HQ-DIST Gi0/0/1 to 1400 (and clamp TCP MSS on the path) so both interfaces advertise the same value and the path can actually carry it. Use ip ospf mtu-ignore only as a temporary, documented workaround: it lets the adjacency form while the MTU mismatch remains, so full-size LSAs and data can still be dropped or fragmented, hiding a real fault.
Also correlate with the provider's sub-200 ms micro-outages and consider BFD with a suitable multiplier plus SPF throttling, so short drops are detected deliberately rather than causing repeated full reconvergence.
2. How would you reduce the LSA flooding and SPF churn caused by the 900 redistributed statics, given that the 40 downstream routers only need a default route?
Read the worked answer
The 900 Type-5 LSAs are flooded through area 0 and re-flooded into any normal area, and each change triggers SPF work on every router. Two levers apply: area type and summarization.
If the downstream branches genuinely need only a default, put them in a stub or totally stubby area: the ABR blocks Type-5 (and Type-3 with no-summary) LSAs and injects a default via area x stub no-summary. That removes the 900 LSAs from those routers immediately. If any branch must import external routes, use NSSA instead, since stub areas cannot carry Type-5.
For area 0 itself, summarize at the ABR with area 1 range (inter-area) - remember Type-5 externals cannot be summarized by area range; they need summary-address on the ASBR. Also filter with distribute-list or route tags so only the necessary statics are redistributed, rather than all 900.
Do not simply raise SPF timers to hide the churn: that slows legitimate reconvergence. Fix the flooding domain first, then tune timers if needed.
3. HQ-DIST has both an OSPF-injected default and a static default. Explain what the branch routers will install and how you would design a backup LTE path without creating a loop or a black hole.
Read the worked answer
A static 0.0.0.0/0 has administrative distance 1; an OSPF default (E2, AD 110) or E1 is far less preferred. So HQ-DIST installs and uses its static default. default-information originate without the always keyword only injects the default if a default already exists in HQ-DIST's routing table - which it does here, so branches learn an OSPF default pointing back at HQ-DIST.
For a backup LTE path, put a floating static default on the branch router with AD 250 (higher than 110) pointing at the LTE next hop, and use reliable static routing or object tracking (track 1 ip sla 1) so it is installed only when the primary path fails. Do not run two equal-cost defaults with the same AD: you get per-flow load sharing and asymmetric return paths, and any stateful device in the path breaks.
Also verify the LTE router performs NAT and that the branch does not advertise the LTE link into OSPF as a transit path, which would pull traffic through the low-bandwidth link. Confirm the failover with a controlled test: shut the primary, watch the tracked static install, then confirm the OSPF default is withdrawn at the branch.