When network congestion hits, not all packets are created equal. Voice and video traffic must get through while bulk file transfers can wait. QoS queuing mechanisms are the tools that make this possible, and Cisco's 200-301 exam expects you to understand the four main queuing algorithms: FIFO, PQ, CQ, and WFQ/CBWFQ. This chapter covers how each works, when to use them, and how to configure and verify them on Cisco IOS routers.
Jump to a section
Imagine a highway with a single toll booth plaza. Cars arrive at different times and have different urgency: ambulances (voice traffic) need to get through immediately, delivery trucks (data traffic) can wait a bit, and tourist buses (bulk traffic) can wait the longest. FIFO (First In, First Out) is like a single lane where cars are processed in order of arrival — simple, but if a tourist bus arrives first, the ambulance behind it is stuck. Priority Queuing (PQ) creates express lanes: the ambulance always goes first, then delivery trucks, then buses. But if too many ambulances arrive, delivery trucks and buses may never get through — this is starvation. Custom Queuing (CQ) is like reserving a certain number of green lights per hour for each type: 10 ambulances, 5 trucks, 2 buses per cycle. This guarantees each type gets some service, but it's rigid — if no ambulances are present, the green light for them is wasted. Weighted Fair Queuing (WFQ) is like a smart toll system that tracks how many vehicles of each type have passed and dynamically adjusts to give each a fair share, with higher priority to low-volume flows like voice. Class-Based Weighted Fair Queuing (CBWFQ) extends this by letting you define custom classes (e.g., 'gold', 'silver', 'bronze') with specific bandwidth guarantees. Low Latency Queuing (LLQ) adds a strict priority queue inside CBWFQ for real-time traffic, ensuring voice and video never wait in line behind other traffic.
What is Queuing and Why Do We Need It?
Queuing is the process of temporarily storing packets in buffers when the output interface is busy transmitting. When a router receives packets faster than it can send them out an interface, they must be queued. Without queuing, packets would be dropped indiscriminately. QoS queuing mechanisms decide the *order* in which packets are transmitted from the queue, allowing you to prioritize certain traffic types.
FIFO Queuing (First In, First Out)
FIFO is the default queuing method on most Cisco interfaces. Packets are transmitted in the exact order they arrive. No classification or prioritization occurs. It's simple and requires no configuration, but it provides no QoS differentiation. If the queue fills up, tail drop occurs — all arriving packets are dropped until space frees up. FIFO is suitable for interfaces with low utilization or where all traffic is equally important.
Priority Queuing (PQ)
PQ has four queues: high, medium, normal, and low. The router always services the high queue first, then medium, then normal, then low. If a packet arrives in a higher-priority queue while a lower-priority queue is being serviced, the lower-priority queue is preempted. PQ guarantees that high-priority traffic gets through immediately, but it can starve lower-priority queues if high-priority traffic is excessive. Configuration involves defining a priority list that maps traffic to a queue, then applying it to an interface.
Custom Queuing (CQ)
CQ has up to 16 queues (0-15), with queue 0 reserved for system traffic (keepalives, etc.). Each queue is serviced in round-robin fashion, but each queue is allocated a *byte count* — the maximum number of bytes transmitted from that queue before moving to the next. This provides a guaranteed minimum bandwidth for each queue. However, if a queue is empty, its byte allocation is wasted. CQ avoids starvation but is more complex to configure. The total bandwidth allocation must sum to the interface bandwidth.
Weighted Fair Queuing (WFQ)
WFQ is the default on serial interfaces below E1 speed (2.048 Mbps). It classifies traffic into flows based on source/destination IP, port numbers, protocol, and ToS. Each flow gets its own queue. WFQ schedules packets based on a weight derived from the IP Precedence value (or DSCP). Low-volume, interactive traffic (like Telnet) gets priority over high-volume flows (like FTP). WFQ is automatic and requires no classification configuration. However, it does not support user-defined classes and can be unfair if many flows compete.
Class-Based Weighted Fair Queuing (CBWFQ)
CBWFQ allows you to define traffic classes using class maps and policy maps. Each class can be assigned a guaranteed bandwidth (in kbps or percentage), a queue limit, and a drop policy (tail drop or WRED). CBWFQ provides per-class fair queuing. It does not include a strict priority queue — that's where LLQ comes in.
Low Latency Queuing (LLQ)
LLQ is an extension of CBWFQ that adds a strict priority queue (PQ) for real-time traffic. You configure a class as priority, and that traffic is always serviced first. To prevent starvation of other classes, LLQ enforces a policer on the priority class — traffic exceeding the configured bandwidth is dropped (or optionally remarked). LLQ is the recommended queuing strategy for voice and video.
Configuration Example: CBWFQ with LLQ
! Define class maps
class-map match-any VOICE
match ip dscp ef
class-map match-any VIDEO
match ip dscp af41
class-map match-any CRITICAL-DATA
match ip dscp af21
!
! Define policy map
policy-map QOS-POLICY
class VOICE
priority percent 10
class VIDEO
bandwidth percent 20
class CRITICAL-DATA
bandwidth percent 30
queue-limit 64 packets
class class-default
fair-queue
queue-limit 40 packets
!
! Apply to interface
interface Serial0/0/0
service-policy output QOS-POLICYVerification Commands
show policy-map interface Serial0/0/0
show queueing interface Serial0/0/0
show class-map
show running-config | section policy-mapExample output:
Router# show policy-map interface Serial0/0/0
Serial0/0/0
Service-policy output: QOS-POLICY
Class-map: VOICE (match-any)
30 packets, 3000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
Priority: Strict, 10% bandwidth, 1000 kbps
Class-map: VIDEO (match-any)
20 packets, 4000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af41 (34)
Bandwidth: 20% (2000 kbps)
Queue limit: 64 packets
Class-map: class-default (match-any)
10 packets, 1000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queue depth: 0 packets
Fair-queue: per-flow queue limit 16Queuing Defaults
Serial interfaces below 2.048 Mbps: WFQ is default.
All other interfaces: FIFO is default.
WFQ uses 256 dynamic queues by default.
Each queue has a default hold-queue limit of 64 packets (can be changed with hold-queue).
Interaction with Shaping and Policing
Queuing works after policing and shaping. Policing drops or remarks packets that exceed a rate; shaping buffers them. The shaped or policed traffic then enters the queuing system. On Cisco routers, shaping uses a separate buffer (shaping queue) before the output queue. Understanding this interaction is key for exam scenarios.
Identify Traffic Classes
Determine which traffic types need QoS treatment: voice (DSCP EF), video (DSCP AF41), critical data (DSCP AF21), and best-effort (default). Use class maps to match based on DSCP, IP precedence, ACLs, or NBAR. Example: `class-map match-any VOICE` then `match ip dscp ef`. Each class map can have multiple match statements (match-any or match-all).
Create Policy Map with Classes
Define a policy map that references the class maps. For each class, specify the queuing action: `priority` for LLQ, `bandwidth` for CBWFQ guaranteed bandwidth, `fair-queue` for WFQ in the default class. Example: `policy-map QOS-POLICY` then `class VOICE` then `priority percent 10`. Bandwidth can be in kbps or percent. Ensure total bandwidth does not exceed 75% of interface bandwidth (the remaining is reserved for overhead).
Configure Queue Limits and Drop Policy
Set queue limits with `queue-limit <packets>` to control maximum depth. For drop policy, use `random-detect` to enable WRED (Weighted Random Early Detection) for congestion avoidance. WRED drops packets probabilistically before the queue is full, preventing TCP global synchronization. Example: `class CRITICAL-DATA` then `queue-limit 64 packets` then `random-detect dscp-based`.
Apply Policy to Interface
Apply the policy map to the output interface using `service-policy output QOS-POLICY`. Only one service policy can be applied per direction per interface. Verify with `show policy-map interface`. The policy will affect all outbound traffic on that interface. For input policies, use `service-policy input`, but queuing is typically output-only.
Verify Queuing Behavior
Use `show policy-map interface` to see packet counts, drop counts, and bandwidth usage per class. Use `show queueing interface` to see the number of packets in each queue. Example: `Router# show queueing interface Serial0/0/0` shows output queue size and drops. Check for excessive drops in priority class, which indicates the policer is dropping traffic.
Fine-Tune Parameters
Adjust bandwidth percentages based on traffic analysis. Monitor with SNMP or `show policy-map interface` over time. If priority class is dropping, increase priority bandwidth or reduce offered load. If best-effort queue is growing, consider adding more classes or increasing queue limits. Use `debug policy-map` (with caution) to see real-time classification.
In a typical enterprise WAN, voice and video traffic must be prioritized over data to ensure call quality. A network engineer would configure LLQ on the WAN router's serial interface (e.g., T1) with a priority queue for voice (10% bandwidth) and video (20%), and CBWFQ for critical data (30%). The remaining 40% is for best-effort traffic with fair-queue. This ensures that during congestion, voice packets are never delayed behind a large FTP transfer.
Another scenario: a data center with multiple server VLANs. The engineer might use CBWFQ on the uplink to guarantee bandwidth for backup traffic (e.g., 50%) and limit less important traffic like software updates (30%) while default class (20%) handles everything else. Queue limits are set high (e.g., 128 packets) for backup to avoid drops during peak backup windows.
A common misconfiguration is forgetting to reserve bandwidth for Layer 2 overhead. On a T1 (1.544 Mbps), the actual usable bandwidth is about 1.536 Mbps after framing overhead. If you allocate 100% of 1.544 Mbps, you oversubscribe and cause drops. Always leave 25% overhead headroom. Another mistake is using PQ instead of LLQ for voice — PQ can starve other traffic, while LLQ has a policer that prevents starvation by dropping excess priority traffic.
Performance considerations: On high-speed interfaces (Gigabit+), queuing becomes less critical because congestion is rare. However, on low-speed links (256 kbps), queuing is essential. The number of queues also matters — WFQ's 256 queues work well for many flows, but CBWFQ with many classes can consume memory. Always test with representative traffic before deploying.
CCNA 200-301 exam objective 4.8 covers 'Configure and verify QoS queuing mechanisms'. You must know the differences between FIFO, PQ, CQ, WFQ, CBWFQ, and LLQ. Expect scenario-based questions: 'Which queuing method should you use for voice traffic to ensure low latency while preventing starvation?' Answer: LLQ (not PQ).
Common wrong answers and why: 1. Choosing PQ for voice because it offers strict priority — but candidates forget starvation. LLQ is correct because it polices the priority queue. 2. Thinking WFQ is the default on all interfaces — it's only default on serial below 2.048 Mbps. 3. Confusing 'bandwidth' command with 'priority' — bandwidth guarantees a minimum, priority gives strict priority with policing. 4. Assuming queue-limit is in bytes — it's in packets by default.
Specific values to memorize:
Default WFQ number of queues: 256
Default hold-queue limit: 64 packets (can be changed with hold-queue <size> out)
LLQ priority policing: drops traffic exceeding configured bandwidth (or remarks if configured)
CBWFQ total bandwidth cannot exceed 75% of interface bandwidth (Layer 2 overhead reserved)
Calculation traps: On a 1.544 Mbps T1, if you allocate 75% to CBWFQ, that's 1.158 Mbps. If voice priority is 10%, that's 115.8 kbps. Ensure your calculations match.
Decision rule for scenario questions:
If traffic requires low latency AND jitter (voice/video) → use LLQ (priority class).
If you need guaranteed minimum bandwidth for multiple classes → use CBWFQ.
If you need simple per-flow fairness without classification → use WFQ (default on slow serial).
If you need to prevent any single flow from dominating → use WFQ or CBWFQ with fair-queue.
If you have no QoS requirements → FIFO is fine.
FIFO is default on most interfaces; WFQ is default on serial interfaces below 2.048 Mbps.
PQ has four queues (high, medium, normal, low) and services higher queues first, causing potential starvation.
CQ uses up to 16 queues with byte-count round-robin to guarantee minimum bandwidth but wastes unused slots.
WFQ automatically classifies flows by IP/port/protocol and gives priority to low-volume flows.
CBWFQ allows user-defined classes with guaranteed bandwidth using the 'bandwidth' command.
LLQ adds a strict priority queue to CBWFQ with policing to prevent starvation.
Total bandwidth allocated to classes should not exceed 75% of interface bandwidth.
Use 'show policy-map interface' to verify queuing statistics and drops.
Queue-limit default is 64 packets; can be changed per class.
WRED (random-detect) can be used for congestion avoidance in CBWFQ classes.
These come up on the exam all the time. Here's how to tell them apart.
Priority Queuing (PQ)
Four strict priority queues (high, medium, normal, low).
Higher queues always serviced first; can starve lower queues.
No policing on priority queues; unlimited priority traffic can monopolize bandwidth.
Configuration uses priority-list and priority-group.
Not recommended for real-time traffic due to starvation risk.
Low Latency Queuing (LLQ)
Uses CBWFQ classes with one strict priority queue (LLQ).
Priority queue is policed; excess priority traffic is dropped.
Non-priority classes get guaranteed bandwidth via CBWFQ.
Configuration uses class-map, policy-map, and service-policy.
Recommended for voice and video; prevents starvation.
Mistake
PQ is the best choice for voice because it offers strict priority.
Correct
LLQ is preferred because it includes a policer that prevents starvation of other queues, whereas PQ can starve lower-priority queues if high-priority traffic is excessive.
Candidates focus on the need for low latency without considering the risk of starvation.
Mistake
WFQ is the default queuing method on all Cisco router interfaces.
Correct
WFQ is the default only on serial interfaces with bandwidth below 2.048 Mbps. On Ethernet and faster serial interfaces, FIFO is the default.
Many study materials highlight WFQ without clarifying its default scope.
Mistake
The 'bandwidth' command in CBWFQ gives strict priority to that class.
Correct
The 'bandwidth' command guarantees a minimum bandwidth during congestion but does not provide strict priority. Strict priority is only achieved with the 'priority' command (LLQ).
Candidates confuse bandwidth guarantee with priority scheduling.
Mistake
Queue-limit is measured in bytes.
Correct
Queue-limit is measured in packets by default. On some platforms, it can be configured in bytes using the 'queue-limit bytes' option.
Candidates assume it's bytes because packets vary in size.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CBWFQ (Class-Based Weighted Fair Queuing) allows you to define classes and assign guaranteed bandwidth using the 'bandwidth' command. However, CBWFQ does not provide a strict priority queue. LLQ (Low Latency Queuing) extends CBWFQ by adding a strict priority queue (using the 'priority' command) that is serviced first. LLQ also polices the priority queue to prevent starvation. For voice and video, LLQ is the recommended choice.
FIFO (First In, First Out) transmits packets in the order they arrive, with no differentiation. During congestion, all packets experience the same delay, and important traffic like voice can be delayed behind bulk data transfers. FIFO also uses tail drop, which can cause TCP global synchronization. For QoS, you need mechanisms that prioritize critical traffic.
Use `show policy-map interface <interface>` to see per-class packet counts, drops, and bandwidth usage. For WFQ, use `show queueing interface <interface>` to see the number of queues and packets in each. Example: `Router# show policy-map interface Serial0/0/0` displays detailed statistics for the applied service policy.
The default queue limit is 64 packets per class. You can change it with the `queue-limit` command under the class in the policy map. For example: `class DATA` then `queue-limit 128 packets`. This sets the maximum number of packets that can be queued for that class.
No, a class can have either the 'bandwidth' command (for guaranteed minimum) or the 'priority' command (for strict priority with policing), but not both. If you need both features, you must create separate classes.
The LLQ policer drops excess priority packets. By default, the policer uses tail drop. Optionally, you can configure the policer to remark the packets (e.g., to a lower DSCP) instead of dropping them. This is configured with the `police` command under the priority class.
WFQ uses 256 dynamic queues by default. The number of queues can be configured with the `fair-queue` command on the interface, e.g., `fair-queue 512` to increase to 512 queues. Each flow is assigned to a queue based on a hash of source/destination IP, ports, protocol, and ToS.
You've just covered QoS Queuing Mechanisms — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?