hardMultiple Choice
Priority Queue Default Policer: Voice Traffic Drops Explained
A network engineer is troubleshooting QoS on a Cisco Nexus 9000 switch. The switch is configured with a policy map that uses a class-default with a bandwidth remaining percent of 100. However, during congestion, traffic in a priority queue (class-map for EF) is experiencing drops even though the priority queue is not fully utilized. What is the most likely cause?
⚠ Common exam trap
Cisco often tests the misconception that priority queue drops are always due to queue exhaustion or misconfigured bandwidth percentages, when in reality the implicit policer on Nexus platforms is the hidden cause.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The priority queue is implicitly policed to a default rate on Nexus switches
On Cisco Nexus 9000 switches, a priority queue (class-map for EF) is implicitly policed to a default rate of 1 Gbps (or the interface speed, whichever is lower) when no explicit policer is configured. This implicit policing can cause drops in the priority queue even if the queue itself is not fully utilized, because the policer rate limits the traffic before it enters the queue. The class-default bandwidth remaining percent of 100 is unrelated to this issue, as it only affects non-priority queues during congestion.
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 implicitly policed to a default rate on Nexus switches
Why this is correct
On Cisco Nexus switches, the strict priority queue is not left uncapped; NX-OS implicitly applies a default policer to the priority queue (often the interface line rate or a platform-specific default) even when you do not configure a 'police' command. This policer uses a token bucket that drops traffic exceeding the allowed rate, so bursts of high-priority traffic can be dropped. The drops are therefore caused by policing, not by queuing or scheduling, which is why this is the correct diagnosis.
- ✗
The class-default bandwidth remaining percent should be set to 0
Why it's wrong here
The 'bandwidth remaining percent' command only controls how leftover bandwidth is distributed among queues after their guaranteed minimum bandwidths are met; it has no bearing on the priority queue's admission control. Setting class-default's bandwidth remaining percent to zero would deny class-default any excess capacity, potentially starving it further, but it would not remove or alter the implicit policer that is actually dropping the priority traffic. Thus, this change would not fix the drops.
- ✗
The priority queue is not configured with a queue-limit
Why it's wrong here
A queue-limit sizes the buffer depth of a queue and determines when tail-drop occurs under congestion. However, the drops seen in the priority queue are caused by the implicit policer, which applies a token-bucket rate limiter at ingress/classification, before the packet is even enqueued. Even with a very deep queue-limit, the policer would still discard packets that exceed its burst tolerance, so the absence of a queue-limit is not the root cause. The queue-limit only becomes relevant if the queue itself fills, which is a separate mechanism.
- ✗
The switch is using strict priority queuing without any shaping
Why it's wrong here
Strict priority queuing, by itself, is a scheduling mechanism that serves the high-priority queue until empty; it does not implement any rate limiting or dropping logic. The fact that the switch is not configured with shaping means excess priority traffic would simply be sent as fast as the interface permits, unless a separate policer exists. In this scenario, the implicit default policer on Nexus is precisely that separate policing mechanism, and it drops packets to enforce its rate. Therefore, the cause is not a lack of shaping but the hidden application of policing.
About these practice questions
Courseiva writes every 350-401 question from scratch — 1,923 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-401 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 350-401 exam.