350-401 Network Assurance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Low Latency Queuing (LLQ)

  Why this is correct

  Low Latency Queuing (LLQ) is correct because it integrates a strict priority queue (PQ) with CBWFQ. The LLQ scheduler always empties the priority class before servicing any other CBWFQ class, which guarantees that real-time packets like voice are dequeued first and experience minimal, jitter-free delay. To prevent the PQ from starving other classes, LLQ applies a policer to priority-class traffic, dropping or shaping excess packets while still meeting the latency objective for admitted real-time flows.

• ✗

  Weighted Random Early Detection (WRED)

  Why it's wrong here

  Weighted Random Early Detection (WRED) is a congestion-avoidance mechanism that actively drops packets as queue depth crosses configured thresholds, preferentially marking or dropping lower-priority traffic to prevent TCP global synchronization. It is not a scheduling algorithm and has no concept of a priority queue or a dequeue order that can favor voice packets. In practice, WRED alone would still allow delay-sensitive packets to be dropped or queued arbitrarily, adding jitter and violating the strict latency requirement for real-time traffic.

• ✗

  Class-Based Weighted Fair Queuing (CBWFQ)

  Why it's wrong here

  Class-Based Weighted Fair Queuing (CBWFQ) defines traffic classes and allocates each a guaranteed minimum bandwidth using weighted fair queuing within each class. However, it lacks a strict-priority queue: the scheduler serves classes based on configured weights and bandwidth, so a voice packet cannot be dequeued ahead of all remaining packets in lower-priority classes if its class is not the current user of the scheduler. Because latency and jitter are not bounded and no class gets absolute precedence, CBWFQ alone cannot deliver the lowest, predictable delay that interactive real-time traffic demands.

• ✗

  First-In, First-Out (FIFO)

  Why it's wrong here

  First-In, First-Out (FIFO) places all packets in a single transmit queue and sends them in the exact order they arrive, meaning there is no mechanism to classify or prioritize interactive voice over bulk data. A single burst of file transfers or a greedy TCP stream can fill the queue, causing real-time packets to wait behind earlier arrivals and introducing variable delay and jitter. Consequently, FIFO offers no latency guarantee and is entirely unsuitable for low-latency real-time transport on a WAN link.