Hub-and-Spoke Sizing for a New Retail WAN
A retailer is replacing 140 MPLS-connected stores with an SD-WAN overlay. Each store runs a 200 Mbps fiber primary and an LTE backup at 40 Mbps. The two regional hubs aggregate all store traffic and also host a firewall for internet breakout. Peak-hour telemetry from the pilot shows each store pushing 60 Mbps average toward the hubs, with a 3x burst factor at month-end batch uploads. The hubs currently have 10 Gbps of WAN capacity and 2 Gbps of firewall throughput. The customer wants active/active hubs with sub-second failover and no store-to-store hairpinning through a third site.
1. Compute the aggregate hub-facing bandwidth requirement at peak and at month-end burst, and state whether the existing hub WAN and firewall capacity are sufficient. Show your arithmetic.
Read the worked answer
Average per store: 60 Mbps. 140 stores × 60 Mbps = 8.4 Gbps aggregate average.
Month-end burst at 3x: 140 × 180 Mbps = 25.2 Gbps offered, but each store is capped by its 200 Mbps fiber, so the practical ceiling is 140 × 200 Mbps = 28 Gbps.
Existing hub WAN: 10 Gbps → insufficient at average peak (8.4 Gbps is already 84% utilized) and grossly insufficient at burst.
Firewall: 2 Gbps → the binding constraint. Even the average 8.4 Gbps exceeds it 4x. If breakout is via the hubs, the firewall must be sized for the breakout fraction, not total WAN.
Conclusion: neither hub WAN nor firewall is sufficient. Recommend either (a) upsizing hub WAN to ≥ 2× 25 Gbps with firewall ≥ 10 Gbps, or (b) shifting internet breakout to the stores with local DIA so only trusted SaaS and inter-store traffic crosses the hub.
2. The customer insists on active/active hubs with sub-second failover and no third-site hairpinning. Describe the overlay design elements that make this work and the failure modes you must test.
Read the worked answer
Design elements:
- Full-mesh tunnels between hub pair so each hub has a direct path to the other; store spokes build tunnels to both hubs simultaneously (not primary/backup).
- BFD on every tunnel with sub-second timers (e.g., 300ms × 3) to detect path loss faster than routing protocol hellos.
- Dynamic routing (BGP or OSPF) over the overlay so a hub failure withdraws routes and stores reconverge via the surviving hub without manual intervention.
- ECMP across the two hub tunnels from each store, with per-flow hashing to avoid reordering.
- Asymmetric return path handling: ensure stateful firewall inspection is either symmetric (via tunnel affinity) or state is synchronized between hubs.
Failure modes to test:
- Hub WAN link down (single link) - does BFD withdraw and does ECMP rehash in <1s?
- Whole hub down - does store-to-store traffic still work via the surviving hub?
- Hub-to-hub link down - do stores still reach both hubs directly, and does the control plane converge without loops?
- Firewall HA failover - does the overlay tunnel survive the state sync gap?
3. A store's LTE backup is 40 Mbps. A month-end batch upload is in progress when fiber drops. What happens to the upload and how should the design mitigate it?
Read the worked answer
The batch upload was flowing at up to 200 Mbps on fiber. On failover to 40 Mbps LTE, the flow is throttled by the tunnel's egress shaper. TCP will back off and re-converge, but the batch job may time out or take 5x longer. If the overlay does not shape LTE to ~35 Mbps (leaving headroom for control traffic), the tunnel will queue-drop and BFD may flap.
Mitigations:
- Per-tunnel QoS/shaper on LTE set to ~90% of line rate.
- Application-aware steering: classify month-end batch traffic and pin it to fiber only; on failover, either queue it or fail it fast rather than letting it crawl.
- Forward error correction and per-packet load balancing off on LTE to avoid reordering.
- Alerting when a store is on backup during a known batch window so ops can pause the job.