A regional bank plans an on-premises SD-WAN Controller deployment for 1,200 WAN Edges, each with dual transports and full routing tables pushing 180,000 OMP routes fabric-wide. The server team asks what drives vCPU, RAM and scale limits. Which sizing factor should the engineer assess first to size the on-premises controller deployment?
Select an answer to reveal the explanation.
Short Explanation
You're sizing brains, not pipes, so count what controllers hold in memory. OMP scale is your suitcase weight limit for routes and tunnels.
Full Explanation
On-premises Controllers scale on control-plane state, not forwarding, so the number of concurrent devices, the control connections those devices hold (one or more per transport, carrying their TLOCs), and the total OMP routes held in the route table determine vCPU, RAM and sizing for 1,200 dual-transport edges and 180,000 routes. The throughput-focused sizing captures devices but substitutes IPsec tunnels and forwarding capacity: the data tunnels are built between WAN Edges, and bandwidth sizes the Edge data plane, with minimal impact on Controller memory and CPU once control connections are up. The Manager database sizing captures devices and routes but substitutes management-plane storage for backups and images, which sizes the Manager disk and retention rather than the Controller adjacency and route-processing load created by dual transports. The API-polling sizing captures routes but omits concurrent device and control connection scale and substitutes northbound monitoring load, which affects Manager resources rather than Controller OMP limits. Exam caveat is to separate Controller, Manager, Validator and Edge roles and never apply branch throughput, disk retention, or API polling metrics to Controller compute. Practical check is to validate planned scale against the published Cisco Catalyst SD-WAN Controller sizing guidance and live telemetry for control connections and received OMP routes before ordering servers.