CCNP Practice Question: Is troubleshooting voice quality issues on a WAN…

Answer analysis

Option-by-option breakdown

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

• ✗

  The priority queue is not configured with a bandwidth statement.

  Why it's wrong here

  This is incorrect because, in LLQ, the priority queue is always configured with a bandwidth statement via the `priority` command. A missing bandwidth statement would make the configuration invalid or cause the class to be treated as a normal class, not a priority queue. The drops in question are due to the implicit policer that is activated when the priority bandwidth is assigned, not because of a missing statement. Thus, the problem is traffic exceeding the configured bandwidth, not the absence of a bandwidth value.

• ✓

  The priority queue has a built-in policer that drops traffic exceeding the configured bandwidth.

  Why this is correct

  This is correct. In Low Latency Queuing (LLQ), the `priority` command with a bandwidth value creates both a strict priority queue and an implicit policer. This policer strictly limits the traffic served from the priority queue to the configured bandwidth; any voice traffic exceeding that rate is immediately dropped, rather than being queued. This mechanism prevents the priority queue from starving other queues, but it requires that the bandwidth be sized to handle voice bursts. Therefore, the drops are the expected behavior of the policer when the configured rate is too low for the incoming voice traffic.

• ✗

  The class-map is not matching voice traffic correctly.

  Why it's wrong here

  This is not the cause. The scenario explicitly states that drops are occurring in the priority queue, which proves that voice traffic is being matched and placed into that queue. If the class-map were misconfigured, voice traffic would be classified into a different queue (such as the default class) and would not experience policer drops. The fact that the drops happen at the priority queue indicates the matching is working correctly; the issue lies in the policer's configured bandwidth threshold.

• ✗

  The router is using FIFO queuing instead of LLQ.

  Why it's wrong here

  This is incorrect because LLQ is indeed in operation, as evidenced by the policer dropping excess traffic. FIFO queuing has no built-in policer; drops under FIFO occur only through tail drop when the interface buffer is full, not based on a configured bandwidth. The scenario describes drops specifically due to policing, which is a signature feature of LLQ's priority queue. Therefore, the queuing mechanism is correctly identified as LLQ, and the drops are not caused by using FIFO instead.