Voice Starvation During Backup Burst
An EX9200 is the campus WAN edge. The provider handoff is a 1 Gbps Layer 2 VPN on xe-0/0/0.0 and honors 802.1p. Voice is VLAN 100 with DSCP EF and 802.1p 5; video is VLAN 200 with AF41 and 802.1p 4; backup is VLAN 300 with default marking. The scheduler map puts voice in queue 5 with transmit-rate percent 10, buffer-size percent 10, and priority low. Queue 0 is best-effort with transmit-rate percent 80 and priority high. There is no policer on the backup VLAN. During a nightly Veeam job, backup bursts to 900 Mbps. Users report one-way audio and about 120 ms jitter. show interfaces xe-0/0/0 queue shows queue 0 at 100% and queue 5 with tail drops. The provider contract allows 1 Gbps and drops excess.
1. Explain why voice drops even though queue 5 has a 10% transmit rate, and recommend a CoS change.
Read the worked answer
Queue 5 has a bandwidth reservation but low scheduling priority. Queue 0 is high priority and its transmit-rate percent 80 is not exact, so during a backup burst it can consume more than 80% of the interface. Voice packets wait behind the high-priority queue and are tail-dropped when queue 5's small buffer fills. The 10% rate is not a latency guarantee; priority determines service order.
Make voice strict-high priority, keep its buffer small to limit jitter, and constrain backup so it cannot consume the whole link:
set class-of-service schedulers voice priority strict-high
set class-of-service schedulers voice buffer-size percent 5
set class-of-service schedulers backup transmit-rate percent 60 exact
set class-of-service schedulers backup buffer-size percent 20
Also apply a policer or shaping rate to the backup VLAN at a contracted rate, for example 500 Mbps, and verify the 802.1p rewrite keeps voice at 5 and backup at 0. Strict-high voice is acceptable here because voice is low volume; monitor to ensure it does not starve control traffic.
2. Why is increasing queue 5 from 10% to 30% not the best solution?
Read the worked answer
The symptom is delay and jitter, not just insufficient average bandwidth. Voice needs priority service and a short queue, not a larger share of a congested link. Increasing queue 5 to 30% leaves queue 0 able to burst and still cause head-of-line waiting if voice remains low priority. It also reduces capacity for other classes and may push the provider's 1 Gbps shaper into drop during backup.
The better fix is to change scheduling behavior-strict-high for voice, exact rate or policer for backup-so voice is not queued behind a high-priority bulk class. If the provider marks or drops differently, increasing local bandwidth can even worsen jitter by creating larger bursts toward the provider.
3. What commands would you use to verify the fix and confirm the provider marking is correct?
Read the worked answer
Verify local scheduling and rewrite behavior:
show class-of-service interface xe-0/0/0
show class-of-service scheduler-map
show interfaces xe-0/0/0 queue
show interfaces xe-0/0/0 statistics
Check that voice packets land in the strict-high queue, queue 5 drops stop, and queue 0 is limited by the exact rate or policer. Use monitor interface xe-0/0/0 during a backup test to see whether the offered rate exceeds 1 Gbps. Capture a small sample with monitor traffic interface xe-0/0/0 matching "vlan 100" no-resolve and confirm the 802.1p value is 5 in the outbound frames. If the provider offers a showcase or test handoff, validate that it preserves 802.1p 5 and drops backup instead of voice.