OSPF Area Design for a Growing Retail WAN
A retailer has 60 stores, each with a single router connected by dual MPLS circuits to two regional hubs. The network currently runs a single OSPF area 0 across all 62 routers. Store routers have modest CPUs; the oldest models take 400 ms to run SPF. Link-state database size is 1,100 LSAs, and the operations team reports that a flapping circuit at one store causes brief but noticeable CPU spikes at every other store router. The company plans to double to 120 stores within 18 months. The WAN team proposes splitting stores into per-region areas (area 10 through 50) with hub routers as ABRs, keeping hubs in area 0.
1. Assess whether the proposed area split will reduce the observed CPU spikes and DB size, and identify what remains in area 0.
Read the worked answer
The area split addresses the symptom directly. Today, every store router holds all 1,100 LSAs and runs SPF on every topology change, including remote flaps. After the split, a store router in area 10 holds only its area's LSAs plus summary LSAs injected by the ABR. A flap in area 20 no longer triggers an SPF run in area 10 routers; it is summarized as a single type-3 LSA change at the ABR boundary, and only if the summary prefix changes.
DB size per store router drops to roughly its area's LSAs plus summaries (likely a few dozen). SPF cost falls proportionally. Area 0 retains the two hubs and their inter-hub links, plus any summaries; it stays small and stable.
Caveat: an ABR must maintain LSAs for every area it touches. Hub routers now hold area 0 plus their store area, so hub memory grows slightly. Confirm hub CPU headroom before committing.
2. A junior engineer suggests making each store a stub area. Evaluate this for a store with dual MPLS circuits to two different hubs.
Read the worked answer
Stub areas block type-5 external LSAs and replace them with a default route from the ABR. That is attractive for stores that need no external detail. However, a store dual-homed to two hubs has two ABRs. Each ABR injects a default (type-3 summary default for stub), and the store router may load-balance across both defaults. If one hub loses its path to the external network, the store may still send traffic to that hub's default, causing black-holing until the ABR withdraws it.
Mitigation: use totally stubby areas only if a single default path is acceptable, or keep the store in a normal area and filter externals with a distribute-list. Better still, since the stores are dual-homed, consider not using stub at all and relying on prefix summarization at the ABRs.
Also note: stub areas do not reduce intra-area LSAs; they only reduce externals. If the store area has few routers, the gain is modest.
3. The WAN team wants to summarize store routes at each ABR. What summarization pitfalls apply to store subnets?
Read the worked answer
Summarization requires contiguous, aggregatable addressing. If stores are addressed by region with a /16 per region and /24 per store, the ABR can advertise a single /16 summary. If addressing is scattered (e.g., stores numbered by acquisition date), no clean summary exists and the ABR must advertise individual prefixes, negating part of the benefit.
Second pitfall: summary routes can black-hole traffic to subnets that do not yet exist or that fail. If a store link goes down but the summary remains (because other stores in the region are up), traffic to the failed store is routed to the ABR and dropped. This is normal but must be understood; some designs use a discard route to make the behavior explicit.
Third: summarization hides topology changes from other areas, which is the point, but it also hides instability from monitoring. Correlate ABR summary changes with store circuit alarms so operations is not blind.