A service provider plans an on-premises deployment for 1800 WAN Edges, dual transports per site, and 120k OMP routes with headroom for 30% growth and controller failover. The design must account for control load, tunnel scale and route capacity together. Which sizing approach correctly factors devices, tunnels and OMP routes for controllers?
Select an answer to reveal the explanation.
Short Explanation
Counting boxes alone leaves you short when routes and tunnels pile up. You sized for scale across all three dimensions with room to grow.
Full Explanation
The correct approach is right because on-premises controllers must be sized jointly on Edge count for control connections, tunnels per Edge for session state from dual transports, and OMP route scale for RIB capacity, all at projected load with spare for failures. Sizing for dual-transport tunnels and current OMP routes with failover fails on capacity planning because it validates steady-state tables and ignores the stated 30% headroom, so controllers that pass today exceed limits after growth to 156k and force disruptive expansion. Sizing for Edge device count alone with growth and failover fails on control scaling because it ignores that dual transports multiply per-Edge connections and that 120k OMP routes drive memory and update load, materially understating the load on each Controller. Sizing clusters for projected routes optimized for full active utilization fails on resiliency because operating without standby capacity leaves no room to absorb a node failure without dropped connections or route churn during convergence. The exam caveat is to distinguish per-instance versus fleet-wide validated limits and present versus projected numbers, since mixing them is a classic trap. The practical check is to map total connections and 156k routes against the version-specific validated scale matrix and simulate one controller failure while monitoring CPU, memory and sessions.