A stormwater bureau needs low-latency treatment for voice while bulk backup flows share remaining bandwidth fairly on the same uplink. Which congestion-management approach fits?
Select an answer to reveal the explanation.
Short Explanation
Voice wants the express lane; backups can share the regular lanes fairly. LLQ gives voice the priority queue, and CBWFQ divvies leftover bandwidth so bulk jobs do not starve each other. One FIFO for everyone is how softphones start sounding like walkie-talkies.
Full Explanation
Stormwater uplink design needs low latency for voice and fair sharing of leftover bandwidth among bulk backups. Placing voice in a priority (LLQ) queue and allocating remaining bandwidth with CBWFQ-style classes delivers that mix: expedited forwarding for voice, and weighted fairness for bulk. That congestion-management pattern is the classic IOS XE answer for mixed real-time and elastic traffic.
A single FIFO queue with random early discard only on voice fails to isolate voice and may drop the wrong packets. Policing voice to line rate and WRED-dropping all other traffic without bandwidth guarantees neither protects voice latency properly nor gives bulk classes fair shares. Disabling queuing and stuffing the interface with no class differentiation abandons PHB treatment entirely.
Exam caveat: LLQ must be policed/shaped to a limit so priority traffic cannot starve other classes—unlimited priority is a common exam trap. Operational check: place voice in LLQ with a suitable priority rate, assign bandwidth statements to bulk classes, congest the uplink in a lab, and measure voice latency while confirming bulk flows share residual capacity. Stormwater change windows should include a congestion test that proves LLQ delay targets while bulk classes still receive their configured shares.