An airport authority hub must stop one chatty library spoke from consuming the entire hub uplink on a DMVPN WAN. Which QoS approach directly addresses that risk?
Select an answer to reveal the explanation.
Short Explanation
One chatty spoke can eat the whole hub uplink like one gate hogging the airport road. Per-tunnel QoS shapes each spoke’s tunnel so fairness returns. Turning off shortcuts or stripping IPsec does not fix hub uplink starvation.
Full Explanation
DMVPN hub uplinks are often oversubscribed relative to aggregated spoke access rates. Per-tunnel QoS on the airport-authority hub applies shaping or hierarchical policy per spoke tunnel so one chatty library spoke cannot monopolize the hub’s WAN capacity. Fairness returns without disabling useful Phase 3 behavior.
Disabling NHRP shortcut so all traffic hair-pins into a single global policer worsens hub load and abandons shortcuts. Mapping every spoke to the same MPLS RT so QoS is inherited from L3VPN EXP invents an MPLS dependency DMVPN does not use that way. Removing IPsec profiles so encryption CPU no longer competes with queueing sacrifices confidentiality instead of fixing uplink fairness.
Exam caveat: per-tunnel QoS is the hub fairness tool—do not “fix” chatter by turning off shortcuts or IPsec.
Operational check: deploy per-tunnel shaping on the hub, generate a noisy spoke transfer, confirm other spokes retain bandwidth, and tune rates to the airport uplink contract. 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. Re-validate after the next platform or policy change.