CCNP Architecture 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.

• ✗

  Random Early Detection (RED)

  Why it's wrong here

  RED (Random Early Detection) is a congestion avoidance mechanism that monitors the average queue depth and probabilistically drops packets before the queue overflows. It does not classify traffic or reserve bandwidth, and voice packets are dropped just as readily as data packets when congestion develops, which directly degrades voice quality. RED is therefore a drop policy, not a queuing or scheduling mechanism, so it cannot provide the strict delay and loss guarantees that voice needs.

• ✓

  Low Latency Queuing (LLQ)

  Why this is correct

  LLQ (Low Latency Queuing) combines a strict-priority queue with CBWFQ: the priority queue is serviced first on every scheduling cycle, before any CBWFQ class queues, so voice is dequeued with minimal and deterministic delay. The priority queue can be policed to a configured rate to prevent a flood of priority traffic from starving the non-priority classes, but within the committed rate voice effectively experiences 'express lane' treatment. This strict-priority scheduling is exactly what makes LLQ the standard QoS queueing strategy for real-time voice traffic in an enterprise.

• ✗

  First In First Out (FIFO)

  Why it's wrong here

  FIFO (First In First Out) creates a single shared queue and transmits packets in arrival order, applying no classification or differentiation whatsoever. Voice packets are therefore placed behind whatever bulk data, transactions, or overhead traffic arrived earlier; during congestion, latency and jitter grow unpredictably and the voice stream can be starved. Since FIFO cannot offer any priority or bandwidth guarantee to real-time flows, it is unsuitable for voice deployments that need consistent low-latency treatment.

• ✗

  Class-Based Weighted Fair Queuing (CBWFQ)

  Why it's wrong here

  CBWFQ (Class-Based Weighted Fair Queuing) allocates a proportionate weight/bandwidth to each configured traffic class and schedules them fairly according to those weights, so it cannot guarantee a voice class an immediate service advantage. A voice class in CBWFQ still has to 'take its turn' alongside other classes' queues based on the weighted fair scheduler, and under overload the voice queue can experience queuing delay. It provides per-class bandwidth management but lacks the strict priority scheduling that real-time audio needs, which is why LLQ extends CBWFQ with an explicit priority queue.