A municipal library consortium needs voice queues to survive last-mile congestion on each WAN Edge. Which policy scope applies QoS scheduling and queuing on the box locally?
Select an answer to reveal the explanation.
Short Explanation
When the last mile clogs, the Edge itself has to run the queue—localized QoS is the on-box traffic cop. Centralized AAR can pick a better color, but it does not replace local schedulers when that circuit is simply full. Controllers do not forward your library voice packets through their own queues.
Full Explanation
A municipal library consortium needing voice queues to survive last-mile congestion should use localized policies on the WAN Edge—QoS maps, ACLs, and route policies enforced on-box—for scheduling and queuing. Local QoS is where packets are ordered under congestion on each civic last mile.
Only a centralized AAR policy with no local scheduler configuration can steer paths but does not replace on-box queuing when a single circuit congests.
vSmart data-plane forwarding queues hosted in the controller cluster misplace queuing; vSmart is not the user data-plane forwarder.
OMP attribute changes alone without any MQC or qos-map on the Edge alter routing preference, not scheduler behavior under congestion.
Exam caveat: classify voice consistently (DSCP/app lists) end-to-end so local QoS and AAR see the same traffic.
Operational check: apply localized QoS on a library Edge, congest a test class, and confirm voice queue latency stays within target. Record QoS maps in the consortium UC WAN standard. In municipal operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the platform code and policy revisions used by the civic network team.