A municipal hospital campus plans to add fifty volunteer-fire DMVPN spokes to existing hubs. What capacity concern should sizing review first?
Select an answer to reveal the explanation.
Short Explanation
Every new spoke is another IPsec conversation and another NHRP check-in at the hub. Size the hub’s CPU and crypto engine for that crowd before you celebrate the volunteer fleet.
Full Explanation
DMVPN hubs terminate many IPsec SAs and process NHRP registrations and resolutions proportional to spoke count and traffic patterns. When a municipal hospital campus adds fifty volunteer-fire spokes, sizing review should first ask whether hub CPU and crypto throughput can sustain the added IPsec sessions plus NHRP load. Undersized hubs cause flaps, slow registration, and data-plane loss as the overlay grows.
Whether each spoke needs a full Internet BGP table in hardware TCAM is not the primary hub-scaling limiter for this growth. STP max-age on hospital access rings matching hub count is a LAN timer topic unrelated to WAN crypto scale. VTP version 1 carrying fifty new extended VLANs across the WAN misunderstands both VTP and DMVPN scaling.
Exam caveat: spoke scale hits hub CPU/crypto/NHRP first—size the hub before celebrating fleet growth.
Operational check: measure current hub CPU and SA counts, extrapolate to +50 spokes, load-test registration storms, and upgrade or add hubs before connecting the volunteer-fire fleet. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services.