OSPF Adjacency Stuck in EXCHANGE and Area 2 Prefixes That Never Arrive
A company is migrating a six-router WAN from static routes to OSPF and then splitting it into areas. HQ-R1 is the intended ABR: Gi0/0 sits in area 0 toward the provider, Gi0/1 sits in area 1 toward branch routers BR1 and BR2. BR1 reaches HQ-R1 over a GRE tunnel carried across the Internet; the tunnel interface has IP MTU 1476, and a TCP MSS adjustment of 1436 is configured only on HQ-R1's tunnel interface. The BR1–HQ-R1 adjacency has sat in EXCHANGE for hours, while BR1's adjacency to BR2 is FULL. Separately, the team adds BR3 behind BR2 on a new link placed in area 2; BR2 has interfaces only in area 1 and area 2. BR3's loopback and LAN prefixes never appear in HQ-R1's routing table even though BR3 learns the whole network, and BR2 shows those area 2 routes as intra-area. No ACL or prefix filter exists anywhere.
1. Diagnose the stuck adjacency and give the fix you would actually deploy, plus the quick workaround and its risk.
Read the worked answer
Diagnosis. During database description exchange the OSPF neighbours negotiate master/slave and swap DBD packets, and those packets are sent with the Don't Fragment bit set. HQ-R1's tunnel is 1476 while BR1's side evidently carries a larger MTU, so BR1's larger DBDs are dropped when they hit the tunnel and never arrive. Both routers keep retransmitting and the state machine never leaves EXCHANGE. The BR1–BR2 adjacency is FULL because that link has symmetric MTU, which confirms the fault is local to the tunnel, not to OSPF itself.
Proper fix. Make the MTU symmetric: set the IP MTU on both tunnel interfaces to the same value (1476 here), and configure TCP MSS adjustment on both ends as well. MSS clamping only takes effect on the SYN as it passes the router, so a one-sided configuration leaves traffic originated on the unconfigured side unprotected.
Workaround. An OSPF MTU-ignore setting on both neighbours will let the adjacency come up. Use it only as a temporary measure: it hides the real MTU difference, and packets larger than the tunnel MTU will still be dropped in transit, producing a black hole that looks like an application problem rather than a routing problem. If you use it, log a follow-up task to remove it.
State the general rule for the candidate: adjacency stuck in EXCHANGE with a tunnel in the path is an MTU problem until proven otherwise - check MTU before touching timers or authentication.
2. Explain why the area 2 prefixes are missing, and compare the two ways of fixing the design.
Read the worked answer
Cause. A router is only an ABR if it has at least one interface in the backbone area 0 and at least one in another area. BR2 has interfaces in area 1 and area 2 but none in area 0, so it is an internal router for both and does not originate type 3 summary LSAs between them. Area 2 routes therefore stay inside area 2 and are never injected into area 1, which is why HQ-R1 has nothing. BR2 shows them as intra-area, not inter-area, because from BR2's point of view they are simply its own area 2 links. Also note that routes flow in the other direction: BR3 learns everything because BR2 floods area 1 LSAs into area 2 as it would for any transit link, which is precisely the asymmetry the symptom describes.
Option A - virtual link. Configure a virtual link on BR2 through transit area 1 to HQ-R1's router ID, with HQ-R1's area 1 interface as the endpoint, and give both routers a stable loopback in area 1. Area 2 then logically hangs off the backbone and summary generation works. Cost: virtual links are operationally fragile, they add a logical dependency on area 1 reachability, and they are easy to forget during troubleshooting.
Option B - restructure. Put BR2 into area 0 (or move the BR3 link into area 0, or promote BR2 to a real ABR with an area 0 uplink). This is the design you would choose for a new build, and it costs a re-addressing or additional-link exercise.
Recommendation: if this is a long-lived topology, restructure; if it is a migration step that will be undone within weeks, a virtual link with documentation is acceptable.
3. The branch links will grow to about 40 prefixes per area. What summarisation and area-type choices would you make, and what could break?
Read the worked answer
Summarise at the ABR, on the boundary facing the backbone, so that area 1 and area 2 each appear as a small number of type 3 LSAs. Allocate branch addressing as contiguous blocks per area so that a single range statement per area is valid; if the current addressing is scattered, summarisation will either be impossible or will black-hole the gaps, so re-addressing is a prerequisite rather than an optional tidy-up.
Use stub or totally-stubby areas for branches that have no external exit of their own: stub removes type 5 LSAs from the area and replaces them with a default, cutting LSDB size and SPF work on small branch routers. Do not make an area stub if it contains a router that must inject external routes - that router would need to be an NSSA, and NSSA translation adds exactly the complexity the branch was supposed to avoid.
What can break:
- Gaps inside a summary range. Traffic for an unassigned subnet inside the range is drawn to the ABR and discarded. Verify by pinging an address in the gap and confirm it fails at the ABR, not silently elsewhere.
- Asymmetric summarisation. If one ABR summarises and its partner does not, return paths can differ; check both ABRs on a redundant pair.
- Default-route dependency in stub areas. A stub branch can only reach the rest of the world through the ABR's default, so loss of that adjacency strands the branch even if another path exists in area 0.
- MTU again. Larger LSDBs mean larger DBD and LSR traffic during a full reload; confirm the tunnel MTU and MSS settings are consistent before summarisation changes force re-adjacency.