A city IT team documents risks of a single-hub DMVPN connecting remote libraries. What scaling limitation should they acknowledge at ENARSI single-hub depth?
Select an answer to reveal the explanation.
Short Explanation
One hub is like one bridge into town—when every library path leans on it, that hub gets crowded even if spokes later shortcut to each other.
Full Explanation
When a city IT team documents a single-hub DMVPN for remote libraries, ENARSI-depth scaling honesty matters: the hub is the Next Hop Server and the initial concentration point for registration, redirects, and much overlay traffic that has not yet built spoke-to-spoke shortcuts. Even with Phase 3-style shortcuts later, control-plane state, crypto sessions toward the hub, and hairpinned flows during discovery or failure still load that one device. Throughput, CPU, and memory on the hub therefore become practical bottlenecks as more library branches join—exactly the limitation municipal architects should acknowledge before promising unlimited spoke growth on one NHS.
Requiring dual route reflectors and confederations before any spoke can register confuses BGP scale tooling with DMVPN NHS mechanics; single-hub DMVPN does not mandate RR/confederation scaffolding for NHRP registration. Claiming single-hub DMVPN cannot use IPsec is false; IPsec is common on Internet-facing civic hubs. Forcing each spoke to configure static GRE to every other spoke before NHRP starts abandons the dynamic mapping model and recreates a full-mesh provisioning burden DMVPN was meant to avoid.
Exam caveat: single-hub designs are in scope; dual-hub Phase designs and BGP RR folklore are not the required answer for this limitation question. Operational check: baseline hub CPU/crypto/session counts under library peak loads, review show dmvpn and NHRP for spoke count, and plan hub sizing or dual-hub only if measured concentration—not marketing—shows the bottleneck.