QoS Queuing – CBWFQ, LLQ & WFQ

1. Why Queuing Matters — The Congestion Problem

Queuing is the QoS mechanism that determines the order in which packets are transmitted when an interface cannot send them all immediately. Congestion occurs whenever packets arrive at an interface faster than the interface can transmit them — the excess packets must wait in a queue. Without intelligent queuing, a single large file transfer can flood the transmit queue and force every other packet — including a real-time voice call — to wait its turn.

Different types of traffic have radically different tolerance for delay and packet loss:

Traffic Type	Delay Sensitivity	Loss Sensitivity	Bandwidth Need
VoIP (voice)	Extreme — <150 ms one-way; >150 ms causes noticeable degradation	Low — a few lost packets cause brief clicks; recoverable	Low — 8–100 kbps per call depending on codec
Video conferencing	High — <150 ms preferred; jitter must be minimal	Medium — loss causes pixelation or freeze-frames	Medium — 384 kbps to several Mbps
Interactive data (SSH, Citrix)	Medium — users notice >200 ms response time	Low — TCP retransmits handle loss	Very low — small packets, bursty
Transactional data (ERP, databases)	Low-medium — batch queries tolerate moderate delay	Low — TCP handles retransmission	Medium — variable
Bulk data (file transfer, backup)	Low — throughput matters more than latency	Very low — TCP retransmits transparently	High — can fill a link if unconstrained

The goal of queuing is to ensure high-priority, delay-sensitive traffic (voice, video) is transmitted first and given guaranteed bandwidth, while lower-priority bulk traffic uses whatever capacity remains.

2. FIFO — First In, First Out (Baseline)

FIFO (First In, First Out) is the simplest queuing method and the default on high-speed interfaces (>2 Mbps) in Cisco IOS. Packets are placed in a single queue in the order they arrive and transmitted in exactly that order — no packet receives priority treatment of any kind.

  FIFO Queue — single queue, strictly ordered:

  Arriving packets (mixed traffic):
  [Voice] [FTP data] [HTTP] [Voice] [Backup] [Voice] [HTTP]
      │         │        │      │        │       │       │
      └─────────┴────────┴──────┴────────┴───────┴───────┘
                              │
                         Single FIFO Queue
                         ──────────────────────────────────►
                         [Voice][FTP][HTTP][Voice][Backup][Voice][HTTP]
                              Transmitted in arrival order

  Problem: A large FTP or backup burst fills the queue.
  Voice packets arrive and must wait behind megabytes of bulk data.
  Result: voice delay (latency) → jitter → call quality degradation.

  FIFO is appropriate only when:
  - Interface speed is so high that congestion rarely occurs
  - All traffic is equally important
  - Simplicity is the priority over QoS differentiation

FIFO Limitations

Limitation	Impact
No traffic differentiation	Voice and bulk data compete equally for queue space — bulk wins by volume
Head-of-line blocking	A single large flow (FTP, backup) can monopolise the queue and starve all other traffic
Unpredictable latency	Delay depends entirely on what happens to be queued ahead — voice latency can spike during data bursts
No bandwidth guarantees	Any class of traffic can consume all available bandwidth

3. WFQ — Weighted Fair Queuing

WFQ (Weighted Fair Queuing) is the default queuing method on serial interfaces with bandwidth <2 Mbps in Cisco IOS. WFQ automatically creates separate queues for each traffic flow (identified by source/destination IP, protocol, and port) and allocates bandwidth fairly between them. Flows with higher IP Precedence values receive proportionally more bandwidth.

  WFQ — automatic per-flow queuing:

  Arriving packets — 3 concurrent flows:
  Flow A (FTP):     large packets, high volume
  Flow B (HTTP):    medium packets, moderate volume
  Flow C (Voice):   small packets, low volume, IP Prec = 5

  WFQ creates a separate queue per flow:
  ┌─────────────────────────────────────────────────────────────┐
  │  Queue A (FTP):   [pkt][pkt][pkt][pkt][pkt][pkt]           │
  │  Queue B (HTTP):  [pkt][pkt][pkt]                           │
  │  Queue C (Voice): [pkt][pkt]  ← higher weight (IP Prec=5)  │
  └─────────────────────────────────────────────────────────────┘
                              │
                         WFQ Scheduler
                         Round-robin with weighting by IP Precedence
                              │
                              ▼ Transmitted
  [C][C][A][B][A][C][A][B][A][C][A][B]...
   ▲
   Voice gets served more frequently (higher precedence weight)

  Key WFQ behaviours:
  - Low-volume flows (voice) are never starved by high-volume flows (FTP)
  - Higher IP Precedence = larger weight = more bandwidth share
  - Works automatically — no manual class definition required
  - BUT: does not provide hard bandwidth GUARANTEES per class
  - Does not provide a strict-priority queue for voice

WFQ Limitations

Limitation	Why It Matters
No administrator-defined classes	WFQ classifies by flow automatically — you cannot define custom classes or assign specific bandwidth guarantees
No strict-priority queue	Voice is weighted higher but still shares the scheduler — absolute minimum latency cannot be guaranteed
Does not scale with many flows	With hundreds of concurrent flows, the scheduling overhead increases and per-flow differentiation weakens
Cannot allocate by percentage or kbps	Bandwidth allocation is proportional to weight only — not expressible as "allocate 128 kbps to voice"

4. CBWFQ — Class-Based Weighted Fair Queuing

CBWFQ (Class-Based Weighted Fair Queuing) extends WFQ by allowing administrators to define explicit traffic classes and assign each class a guaranteed minimum bandwidth. Each class gets its own queue. When the link is congested, each class is guaranteed at least its configured bandwidth share — and may use more if other classes are idle. Any traffic that does not match a defined class falls into the class-default queue.

CBWFQ Architecture

  CBWFQ Queue Structure (example: 10 Mbps WAN link):

  ┌──────────────────────────────────────────────────────────────────┐
  │  Class VOICE    (DSCP EF)        → bandwidth 2 Mbps   (20%)     │
  │  Class VIDEO    (DSCP AF41)      → bandwidth 3 Mbps   (30%)     │
  │  Class CRITICAL (DSCP AF31)      → bandwidth 2 Mbps   (20%)     │
  │  Class BULK     (DSCP CS1)       → bandwidth 1 Mbps   (10%)     │
  │  class-default  (all other)      → bandwidth 2 Mbps   (20%)     │
  └──────────────────────────────────────────────────────────────────┘
  Total guaranteed:  10 Mbps = 100%
  ── Link congested ──────────────────────────────────────────────────
  Each class is served in proportion to its bandwidth weight.
  An idle class's share is redistributed to active classes.

  ── Link not congested ──────────────────────────────────────────────
  Queuing is not needed — all packets are transmitted immediately.
  Class definitions have no effect until congestion occurs.

CBWFQ Bandwidth Allocation Methods

Method	Command	Notes
Absolute kbps	`bandwidth <kbps>`	Reserves a fixed number of kilobits per second for this class. The total of all class bandwidth values must not exceed 75% of the interface bandwidth (25% reserved for overhead and routing protocol traffic).
Percentage	`bandwidth percent <pct>`	Allocates a percentage of the interface bandwidth. All class percentages must not exceed 100% (practical max ~75% for user traffic). More portable — does not need recalculation if interface bandwidth changes.
Remaining percentage	`bandwidth remaining percent <pct>`	Allocates a share of whatever bandwidth remains after absolute/priority allocations are satisfied. Useful for lower-priority best-effort classes.

CBWFQ Limitation — The Voice Problem

  CBWFQ guarantees MINIMUM bandwidth but does NOT guarantee maximum delay.

  Example: Voice class configured with bandwidth 2 Mbps.
  When congested, voice packets queue behind other voice packets already waiting.
  If a large voice burst fills the voice queue, new voice packets experience
  queuing delay — even though bandwidth is guaranteed.

  For voice:
  - Maximum one-way delay must be <150 ms (ITU G.114)
  - Queuing delay caused by other voice packets in the same class queue
    violates this requirement under high voice load

  CBWFQ alone is NOT sufficient for voice. Voice needs a STRICT PRIORITY queue
  that always transmits the next voice packet immediately — regardless of other
  queues. This is what LLQ adds.

5. LLQ — Low Latency Queuing

LLQ (Low Latency Queuing) is CBWFQ with the addition of a strict-priority queue. LLQ adds a priority command to one or more traffic classes. The strict-priority queue is always serviced first — before any other queue — regardless of how much data other queues have waiting. This guarantees the absolute minimum possible queuing delay for the prioritised class (typically voice).

LLQ Architecture

  LLQ Queue Structure (example: 10 Mbps WAN link):

  ┌──────────────────────────────────────────────────────────────────┐
  │  ★ PRIORITY Queue (VOICE, DSCP EF) → priority 2000 kbps        │
  │    ↑ Served FIRST — immediately, before all other queues        │
  │    ↑ Strict priority — no waiting                               │
  ├──────────────────────────────────────────────────────────────────┤
  │  Class VIDEO    (DSCP AF41)      → bandwidth 3000 kbps          │
  │  Class CRITICAL (DSCP AF31)      → bandwidth 2000 kbps          │
  │  Class BULK     (DSCP CS1)       → bandwidth 500 kbps           │
  │  class-default  (all other)      → bandwidth remaining 25%      │
  └──────────────────────────────────────────────────────────────────┘

  Scheduler behaviour during congestion:

  Step 1: Is anything in the PRIORITY queue?
          YES → transmit priority packet immediately
          NO  → proceed to CBWFQ scheduler

  Step 2 (CBWFQ): Serve remaining classes in proportion to bandwidth weights.

  The priority queue "jumps the line" — voice packets never wait behind
  data packets. As long as the priority queue has data, it is served first.

Strict Priority — The Starvation Risk

  Risk: If the priority queue is never empty (voice traffic is excessive),
  the CBWFQ classes below it are NEVER served → starvation.

  LLQ polices the priority queue to prevent starvation:
  priority 2000        ! police to 2000 kbps
  If voice traffic exceeds 2000 kbps, excess voice is DROPPED.
  This ensures other classes always get their guaranteed bandwidth.

  This is intentional — voice codecs are designed to operate within a
  fixed bandwidth. An IP phone sending G.711 uses exactly 64 kbps payload
  + overhead. If you configure the priority class for 2000 kbps, you are
  sizing for approximately 20–25 simultaneous G.711 calls.

  What happens to excess priority-queue traffic:
  Within policed rate  → transmitted with strict priority (minimum delay)
  Exceeds policed rate → DROPPED (not queued — dropped immediately)
  Result: other classes always get their share ✓

LLQ vs CBWFQ — Key Differences

Feature	CBWFQ	LLQ (CBWFQ + Priority)
Priority queue	No — all classes share the scheduler fairly	Yes — priority class always served first
Guaranteed bandwidth	Yes — minimum bandwidth per class	Yes — plus absolute priority service for priority class
Latency guarantee	No — queuing delay possible even with bandwidth guarantee	Yes — strict-priority class experiences minimal queuing delay
Starvation risk	Low — fair share scheduling prevents starvation	Mitigated — priority queue is policed to prevent domination
Recommended for voice	No — insufficient latency control	Yes — the gold standard for enterprise voice QoS
IOS command	`bandwidth`	`priority` (one class) + `bandwidth` (all other classes)

6. The Modular QoS CLI (MQC) Framework

CBWFQ and LLQ are configured using the Modular QoS CLI (MQC) framework — a three-part structure consisting of class maps (identify traffic), policy maps (define actions), and service policies (apply to interfaces). MQC is the standard Cisco IOS QoS configuration model used for all modern QoS features.

  MQC three-part structure:

  ┌─────────────────┐     ┌──────────────────┐     ┌───────────────────┐
  │   class-map     │────►│   policy-map      │────►│ service-policy    │
  │                 │     │                   │     │                   │
  │ Identifies      │     │ Defines actions   │     │ Applies the       │
  │ traffic by:     │     │ per class:        │     │ policy to an      │
  │  DSCP value     │     │  bandwidth        │     │ interface or      │
  │  ACL match      │     │  priority         │     │ sub-interface:    │
  │  CoS value      │     │  police           │     │  in or out        │
  │  protocol       │     │  shape            │     │                   │
  │  input interface│     │  set (re-mark)    │     │                   │
  └─────────────────┘     └──────────────────┘     └───────────────────┘

class-map — match Conditions

  ! Match traffic by DSCP value:
  Router(config)# class-map match-any VOICE
  Router(config-cmap)# match dscp ef             ! Expedited Forwarding (voice payload)

  ! Match by DSCP AF (Assured Forwarding) values:
  Router(config)# class-map match-any VIDEO
  Router(config-cmap)# match dscp af41           ! video conferencing

  Router(config)# class-map match-any CRITICAL
  Router(config-cmap)# match dscp af31           ! critical data apps

  Router(config)# class-map match-any BULK
  Router(config-cmap)# match dscp cs1            ! scavenger / bulk (below best effort)

  ! Match by ACL (extended ACL identifies the traffic):
  Router(config)# class-map match-all HTTP_TRAFFIC
  Router(config-cmap)# match access-group name ACL_HTTP

  ! match-all: ALL conditions must match (logical AND)
  ! match-any: ANY condition matches (logical OR)

match-all vs match-any

Keyword	Logic	Use Case
`match-all`	ALL match statements must be true (AND logic)	Use when traffic must satisfy multiple criteria simultaneously (e.g., from a specific source AND marked with a specific DSCP)
`match-any`	ANY one match statement is sufficient (OR logic)	Use when traffic can be identified by multiple independent criteria (e.g., DSCP EF OR CoS 5 are both voice)

7. Full CBWFQ Configuration

The following is a complete CBWFQ configuration with four traffic classes on a 10 Mbps WAN interface. No strict-priority queue — this demonstrates pure CBWFQ bandwidth allocation.

  Scenario: 10 Mbps WAN link
  Classes: Video (30%), Critical data (20%), Bulk data (10%), Default (remainder)

  ! ── Step 1: Define class maps ─────────────────────────────────────────────
  Router(config)# class-map match-any CLASS_VIDEO
  Router(config-cmap)# match dscp af41
  Router(config-cmap)# match dscp af42
  Router(config-cmap)# exit

  Router(config)# class-map match-any CLASS_CRITICAL
  Router(config-cmap)# match dscp af31
  Router(config-cmap)# match dscp af32
  Router(config-cmap)# exit

  Router(config)# class-map match-any CLASS_BULK
  Router(config-cmap)# match dscp cs1
  Router(config-cmap)# exit

  ! ── Step 2: Define policy map with bandwidth actions ─────────────────────
  Router(config)# policy-map WAN_CBWFQ
  Router(config-pmap)# class CLASS_VIDEO
  Router(config-pmap-c)# bandwidth percent 30        ! 30% = 3000 kbps
  Router(config-pmap-c)# exit

  Router(config-pmap)# class CLASS_CRITICAL
  Router(config-pmap-c)# bandwidth percent 20        ! 20% = 2000 kbps
  Router(config-pmap-c)# exit

  Router(config-pmap)# class CLASS_BULK
  Router(config-pmap-c)# bandwidth percent 10        ! 10% = 1000 kbps
  Router(config-pmap-c)# exit

  Router(config-pmap)# class class-default
  Router(config-pmap-c)# fair-queue                  ! WFQ within default class
  Router(config-pmap-c)# exit

  ! ── Step 3: Apply the policy map outbound on the WAN interface ───────────
  Router(config)# interface serial 0/0/0
  Router(config-if)# bandwidth 10000                 ! inform IOS of link speed (kbps)
  Router(config-if)# service-policy output WAN_CBWFQ

  ! service-policy output = apply queuing outbound (when interface is transmitting)
  ! Queuing only applies outbound — you cannot queue inbound traffic on a router

8. Full LLQ Configuration

LLQ is the recommended queuing strategy for networks carrying both voice and data. A single class uses the priority command for the strict-priority queue; all other classes use bandwidth. Only one priority class is recommended (though multiple are technically possible in modern IOS).

  Scenario: 10 Mbps WAN link with VoIP, video, critical data, bulk, and default.

  ! ── Step 1: Define class maps ─────────────────────────────────────────────
  Router(config)# class-map match-any CLASS_VOICE
  Router(config-cmap)# match dscp ef                 ! voice payload
  Router(config-cmap)# exit

  Router(config)# class-map match-any CLASS_VIDEO
  Router(config-cmap)# match dscp af41
  Router(config-cmap)# exit

  Router(config)# class-map match-any CLASS_CRITICAL
  Router(config-cmap)# match dscp af31
  Router(config-cmap)# exit

  Router(config)# class-map match-any CLASS_BULK
  Router(config-cmap)# match dscp cs1
  Router(config-cmap)# exit

  ! ── Step 2: Policy map — priority for voice, bandwidth for others ─────────
  Router(config)# policy-map WAN_LLQ
  Router(config-pmap)# class CLASS_VOICE
  Router(config-pmap-c)# priority percent 20         ! strict priority, policed at 20%
  Router(config-pmap-c)# exit                        ! = 2000 kbps on a 10 Mbps link

  Router(config-pmap)# class CLASS_VIDEO
  Router(config-pmap-c)# bandwidth percent 30        ! 3000 kbps guaranteed minimum
  Router(config-pmap-c)# exit

  Router(config-pmap)# class CLASS_CRITICAL
  Router(config-pmap-c)# bandwidth percent 20        ! 2000 kbps guaranteed minimum
  Router(config-pmap-c)# exit

  Router(config-pmap)# class CLASS_BULK
  Router(config-pmap-c)# bandwidth percent 5         ! 500 kbps guaranteed minimum
  Router(config-pmap-c)# exit

  Router(config-pmap)# class class-default
  Router(config-pmap-c)# bandwidth remaining percent 25   ! remaining share
  Router(config-pmap-c)# exit

  ! ── Step 3: Apply outbound on the WAN interface ───────────────────────────
  Router(config)# interface serial 0/0/0
  Router(config-if)# bandwidth 10000
  Router(config-if)# service-policy output WAN_LLQ

priority vs priority percent

  ! Absolute bandwidth (kbps):
  priority 2000       ! strict priority queue policed at 2000 kbps

  ! Percentage of interface bandwidth:
  priority percent 20 ! strict priority policed at 20% of interface BW

  ! Percentage is preferred — portable if the link bandwidth changes.
  ! If the link is upgraded from 10 Mbps to 20 Mbps, "priority percent 20"
  ! automatically adjusts to 4000 kbps without reconfiguration.
  ! "priority 2000" would still police at 2000 kbps on the new 20 Mbps link
  ! (now only 10% — potentially too low for call capacity).

9. class-default — The Catch-All Queue

class-default is a special pre-defined class that automatically matches all traffic not matched by any explicit class-map. It is always present in a policy-map and always evaluated last. Without class-default, unclassified traffic falls into a default FIFO queue outside the policy.

  class-default behaviour:

  - Always matches: any packet that did not match CLASS_VOICE, CLASS_VIDEO, etc.
  - If no action is defined in class-default: unclassified traffic gets FIFO
  - Best practice: define an explicit action in class-default

  Common class-default configurations:

  ! Option 1: Fair-queue (WFQ within the default class):
  class class-default
    fair-queue             ! auto-creates per-flow queues within class-default

  ! Option 2: Remaining bandwidth share:
  class class-default
    bandwidth remaining percent 25   ! 25% of whatever bandwidth is left

  ! Option 3: Hard bandwidth limit for default traffic:
  class class-default
    bandwidth percent 15   ! guarantee 15% to default (best-effort traffic)

  ! What NOT to do:
  ! Do not configure priority for class-default — only one priority class
  ! should exist (typically voice), and it should never be the default class.

10. Queue Depth — Tail Drop and WRED

When a queue fills to its maximum depth (the queue limit), arriving packets have nowhere to go. The router must discard them. The default discard policy is tail drop — the newest arriving packet is discarded. CBWFQ supports configuring WRED (Weighted Random Early Detection) as a smarter alternative.

Tail Drop

  Tail drop — default queue overflow behaviour:

  Queue: [pkt1][pkt2][pkt3][pkt4][pkt5] ← FULL (queue-limit reached)
                                                │
  New packet arrives ──────────────────────────►│ NO ROOM → DROPPED

  Problem: TCP global synchronisation.
  Multiple TCP flows fill the queue simultaneously → all drop together.
  All TCP senders receive packet loss signal at the same time.
  All reduce their window simultaneously → link utilisation drops sharply.
  All start recovering together → link bursts again → drops again.
  Result: oscillating utilisation instead of smooth sustained throughput.

WRED — Weighted Random Early Detection

  WRED proactively discards packets BEFORE the queue fills completely.
  Discards are randomised — different TCP flows are affected at different
  times, preventing global synchronisation.

  WRED thresholds (per DSCP class):
  ┌─────────────────────────────────────────────────────────────────┐
  │  Queue depth 0% → min-threshold                                 │
  │  Queue depth at min-threshold → begin random early discard      │
  │  (low probability at min, increasing probability toward max)    │
  │  Queue depth at max-threshold → discard all new arrivals        │
  │  Queue depth → 100% (tail drop) → discard all                   │
  └─────────────────────────────────────────────────────────────────┘

  Higher DSCP = higher min/max thresholds = less likely to be dropped early.
  Lower DSCP (best effort) = lower thresholds = more aggressively dropped.

  Enable WRED in a CBWFQ class:
  Router(config-pmap-c)# random-detect dscp-based   ! DSCP-based WRED thresholds
  Router(config-pmap-c)# random-detect dscp ef 40 60 10  ! min 40, max 60, mark 10

WRED and priority queues: WRED should NOT be applied to the LLQ strict-priority class (voice). Voice is loss-sensitive and should not have random early drops applied. WRED is most beneficial for TCP-based data classes where the congestion signal (packet loss) causes TCP to back off — reducing the queue depth organically. UDP traffic (like voice) does not respond to packet loss with a rate reduction.

11. Queuing Only Activates During Congestion

A critically important principle: queuing mechanisms — FIFO, WFQ, CBWFQ, and LLQ — only take effect when an interface is congested. When an interface has spare transmit capacity and the queue is empty, every packet is transmitted immediately regardless of its class. Queuing defines what happens to packets that cannot be transmitted immediately.

  Scenario: 10 Mbps WAN link, current utilisation 3 Mbps (30%)

  ┌──────────────────────────────────────────────────────────┐
  │  Packet arrives → queue is empty → transmitted IMMEDIATELY│
  │  No queuing delay → class priority is irrelevant         │
  │  LLQ and CBWFQ have no effect here                       │
  └──────────────────────────────────────────────────────────┘

  Scenario: Same link, traffic spike to 15 Mbps (150% of capacity)

  ┌──────────────────────────────────────────────────────────┐
  │  Packet arrives → queue has 8 packets waiting → QUEUED   │
  │  LLQ: if this is a voice packet → place in priority queue│
  │        → next transmission slot → minimal delay          │
  │  If this is a bulk packet → place in bulk queue          │
  │        → waits behind video and critical queues          │
  └──────────────────────────────────────────────────────────┘

  Practical implication:
  In a network with headroom (link rarely at capacity), queuing configuration
  has minimal impact. Queuing matters most on WAN links that regularly operate
  at 70–100% utilisation — exactly where enterprise voice and data often compete.

12. Verification and Monitoring Commands

  ! Show policy-map details including class definitions and actions:
  Router# show policy-map WAN_LLQ

  ! Show the policy applied to a specific interface — includes real-time statistics:
  Router# show policy-map interface serial 0/0/0

  ! Show class-map definitions:
  Router# show class-map

  ! Show a specific class-map:
  Router# show class-map CLASS_VOICE

  ! Show QoS queue statistics on an interface:
  Router# show queue serial 0/0/0

  ! Show interface queuing strategy (FIFO, WFQ, custom):
  Router# show interfaces serial 0/0/0 | include Queueing

Sample Output — show policy-map interface

  Router# show policy-map interface serial 0/0/0

  Serial0/0/0
   Service-policy output: WAN_LLQ

    Class-map: CLASS_VOICE (match-any)
      0 packets, 0 bytes
      5 minute offered rate 1856000 bps, drop rate 0 bps
      Match: dscp ef (46)
        0 packets, 0 bytes
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 20% (2000 kbps), burst size 50000
        (pkts matched/bytes matched) 14820/1421720
        (total drops/bytes drops) 0/0           ← 0 drops = voice within budget

    Class-map: CLASS_VIDEO (match-any)
      (pkts matched/bytes matched) 8231/9452340
      (total drops/bytes drops) 143/163560      ← some drops — congestion occurring

    Class-map: CLASS_CRITICAL (match-any)
      (pkts matched/bytes matched) 3420/2134480
      (total drops/bytes drops) 0/0

    Class-map: CLASS_BULK (match-any)
      (pkts matched/bytes matched) 9910/45231600
      (total drops/bytes drops) 2870/13104600   ← bulk traffic heavily dropped (expected)

    Class-map: class-default (match-any)
      (pkts matched/bytes matched) 1231/432100
      (total drops/bytes drops) 0/0

  Key fields to examine:
  - offered rate: how much traffic is arriving for this class
  - drop rate: how much is being dropped (non-zero = congestion in this class)
  - total drops: cumulative drops since last clear
  - Strict Priority: confirms this is the LLQ priority class

Common Troubleshooting Issues

Symptom	Likely Cause	Fix
Voice drops in priority queue	Priority class bandwidth too low — more voice traffic than allocated	Increase `priority percent` or reduce number of simultaneous calls; check codec bandwidth requirements
Policy not taking effect	Service-policy applied in wrong direction (inbound instead of output), or not applied at all	Verify with `show policy-map interface`; queuing must be applied `output`
Class-map matching zero packets	DSCP marking not set on the traffic, or wrong DSCP value in the class-map match	Verify markings with `show policy-map interface` and check upstream marking policy
Bandwidth total exceeds 75%	Sum of all `bandwidth` and `priority` allocations exceeds 75% of link bandwidth	Cisco IOS reserves 25% for overhead; reduce class allocations so total user traffic ≤ 75%

13. Queuing Methods Comparison — Summary

Feature	FIFO	WFQ	CBWFQ	LLQ
Queue type	Single	Per-flow (auto)	Per class (admin-defined)	Priority + per class
Admin-defined classes	No	No	Yes	Yes
Bandwidth guarantee	No	Proportional by weight	Yes — per class	Yes — per class + priority
Latency guarantee	No	No	No	Yes — priority class only
Prevents starvation	No	Yes (per flow)	Yes (per class)	Yes (priority policed)
Suitable for voice	No	Partially	No	Yes
Configuration effort	None (automatic)	None (automatic)	Medium (MQC)	Medium (MQC)
Default on Cisco IOS	High-speed interfaces	Serial <2 Mbps	No (must configure)	No (must configure)

14. QoS Queuing Summary — Key Facts

Topic	Key Fact
FIFO default	Default on interfaces >2 Mbps; single queue; no differentiation; head-of-line blocking risk
WFQ default	Default on serial interfaces <2 Mbps; automatic per-flow queuing; no admin-defined classes
CBWFQ	Admin-defined classes with guaranteed minimum bandwidth; uses `bandwidth` command; no strict-priority queue
LLQ = CBWFQ + priority	Adds a strict-priority queue using `priority` command; priority class served before all others; priority queue is policed to prevent starvation
MQC structure	class-map (match traffic) → policy-map (define actions) → service-policy (apply to interface)
service-policy direction	Always `output` for queuing — queuing applies to outbound transmit queue only
priority command	Creates strict-priority queue; polices to configured rate; excess dropped immediately; use for voice (DSCP EF)
bandwidth command	Guarantees minimum bandwidth for a class during congestion; idle class bandwidth redistributed to active classes
75% rule	Total of all `bandwidth` + `priority` allocations must not exceed 75% of interface bandwidth — 25% reserved for overhead
class-default	Pre-defined catch-all; matches all unclassified traffic; always present; always last
Queuing activates when	Interface is congested — packets queued faster than transmitted; no effect at low utilisation
Voice best practice	LLQ with `priority percent 20` (or appropriate size) for DSCP EF traffic; CBWFQ for all other classes

15. QoS Queuing Quiz

1. What is the default queuing method on a Cisco IOS interface with a bandwidth greater than 2 Mbps, and what is its primary limitation for real-time traffic?

A. WFQ — it provides per-flow fairness but lacks strict-priority capability B. LLQ — it provides priority queuing by default but requires MQC configuration to activate C. FIFO — it processes packets strictly in arrival order with no traffic differentiation. A large bulk data burst fills the single queue and forces voice packets to wait, causing unpredictable and potentially excessive latency. D. CBWFQ — it provides class-based queuing by default with no configuration required

Correct answer is C. FIFO is the default queuing method on high-speed interfaces (>2 Mbps) in Cisco IOS. WFQ is the default on low-speed serial interfaces (<2 Mbps). FIFO maintains a single queue and serves packets in the exact order they arrived — there is no concept of traffic class, priority, or bandwidth guarantee. The core problem for real-time traffic is head-of-line blocking: a flood of bulk data packets ahead of a voice packet forces the voice packet to wait the full serialisation time of every preceding packet, causing latency spikes that degrade call quality.

2. What is the fundamental difference between CBWFQ and LLQ?

A. CBWFQ uses MQC; LLQ uses legacy queue-list commands B. CBWFQ allocates minimum bandwidth guarantees per class but all classes share the scheduler fairly during congestion — no class gets absolute priority. LLQ adds a strict-priority queue (using the priority command) that is always served before all other classes, guaranteeing minimum latency for the priority class. C. LLQ cannot match on DSCP; CBWFQ matches on DSCP only D. CBWFQ is applied inbound; LLQ is applied outbound

Correct answer is B. This is the core CBWFQ vs LLQ distinction. CBWFQ guarantees minimum bandwidth per class — during congestion, each class is served in proportion to its bandwidth weight. However, a voice class with "bandwidth percent 20" still competes with other classes for scheduler turns — a burst of video traffic could delay voice packets even though voice has a bandwidth guarantee. LLQ solves this by introducing a strict-priority queue (the priority command): the scheduler checks the priority queue first every cycle. As long as the priority queue has data, it is transmitted immediately — no other class can delay it. This is why LLQ is the standard recommendation for voice.

3. Why is the LLQ priority queue policed to a configured bandwidth limit, and what happens to priority traffic that exceeds this limit?

A. Policing is optional in LLQ — the priority queue can grow unbounded if no police rate is set B. The priority queue is policed to prevent packets from being delayed; excess is queued in class-default C. Policing converts the strict-priority queue into a WFQ queue when the limit is reached D. Because the priority queue is always served first, an unbounded priority queue could starve all other classes. The policing rate caps the priority class at its configured bandwidth. Traffic exceeding the cap is immediately DROPPED — not queued — ensuring other classes always receive their guaranteed bandwidth.

Correct answer is D. Without policing, the strict-priority queue could monopolise the entire link — since it always goes first, if it is never empty the CBWFQ classes below it starve completely. The priority <bandwidth> command implicitly includes a policer: traffic arriving at the priority queue within the configured rate is transmitted immediately with strict priority. Traffic arriving in excess of the configured rate is dropped on the spot — it is not placed in another queue. This design is intentional: voice codecs have a fixed bandwidth requirement, so properly sized voice traffic never exceeds the limit, and the other classes are protected.

4. In the MQC framework, what are the three components and their correct order of dependency?

A. class-map (identifies traffic) → policy-map (defines the action per class) → service-policy (applies the policy to an interface). The policy-map references the class-map; the service-policy references the policy-map. B. policy-map → class-map → service-policy C. service-policy → policy-map → class-map D. access-list → class-map → policy-map (service-policy is not part of MQC)

Correct answer is A. MQC uses three components in a strict dependency chain. First, a class-map is defined — it identifies which packets belong to a class, using match criteria like DSCP values, ACLs, or CoS. Second, a policy-map is created — it references the class-maps and assigns an action to each class (bandwidth, priority, police, shape). Third, a service-policy command is entered under a specific interface — it links the policy-map to that interface in a direction (input or output). Queuing always applies output (outbound transmit queue).

5. An LLQ policy-map is configured with these allocations on a 10 Mbps interface: voice priority 20%, video bandwidth 35%, data bandwidth 25%. When the engineer tries to apply it, IOS rejects it with an error. Why?

A. LLQ does not support percentage-based bandwidth — only absolute kbps values are allowed B. Only one class-map can be referenced per policy-map C. The total allocated bandwidth (20% + 35% + 25% = 80%) exceeds Cisco IOS's 75% limit. IOS reserves 25% of interface bandwidth for overhead and routing protocol traffic — user traffic classes must not exceed 75% total. D. Priority and bandwidth commands cannot be mixed in the same policy-map

Correct answer is C. Cisco IOS enforces a rule that the total of all bandwidth and priority allocations in a policy-map cannot exceed 75% of the interface bandwidth. The remaining 25% is implicitly reserved for network overhead — routing protocol hellos (OSPF, EIGRP), management traffic, and link-layer overhead. In this example: 20% (priority) + 35% (bandwidth) + 25% (bandwidth) = 80%, which exceeds 75%. The fix is to reduce one or more allocations so the total is ≤ 75%, then assign the remaining bandwidth to class-default using bandwidth remaining percent.

6. What is the difference between `match-all` and `match-any` in a class-map definition?

A. match-all is used for DSCP matching; match-any is used for ACL matching B. match-all requires ALL match statements in the class-map to be true simultaneously (AND logic) before a packet is classified into that class. match-any classifies a packet if ANY single match statement is true (OR logic). C. They are identical — both apply logical AND to all match conditions D. match-any matches the first packet of each new flow; match-all matches every packet of every flow

Correct answer is B. The match-all keyword (the default if not specified) means a packet must satisfy ALL of the match conditions in the class-map — logical AND. For example, a class-map with match-all, match dscp ef, and match access-group ACL_VOICE classifies only packets that are BOTH marked DSCP EF AND match the ACL. The match-any keyword means a packet satisfying ANY one of the match conditions is classified into that class — logical OR. For example, voice traffic might be DSCP EF on some paths and CoS 5 on others — match-any with both conditions catches all of it.

7. A network engineer configures an LLQ policy-map but notices that the `show policy-map interface` output shows zero packets matching the CLASS_VOICE class. VoIP calls are active. What is the most likely cause?

A. The service-policy is applied in the wrong direction (input instead of output) B. Voice traffic does not arrive during periods of low congestion C. The class-map name must match the DSCP value name exactly D. The voice traffic is not marked with DSCP EF before reaching this router — the class-map match condition (match dscp ef) finds no matching packets. Verify the DSCP marking upstream with a packet capture or show policy-map interface on the ingress device.

Correct answer is D. A zero match count on the voice class while VoIP calls are active almost always means the traffic is not marked with the expected DSCP value. QoS queuing depends entirely on traffic being correctly marked before it reaches the queuing policy. If IP phones are sending traffic but it arrives unmarked (DSCP 0 — best effort) or marked with the wrong value, it will fall into class-default rather than CLASS_VOICE. Check: (1) Is the IP phone configured to mark at DSCP EF? (2) Is there a marking policy upstream that should be re-marking voice to EF? (3) Is a QoS trust boundary configured on the access switch accepting the phone's CoS marking? See: QoS Marking

8. Why does queuing configuration have minimal effect when a WAN link is operating at 30% utilisation, but significant effect at 95% utilisation?

A. Queuing only activates when an interface is congested — when packets arrive faster than they can be transmitted. At 30% utilisation, all packets transmit immediately (queue is empty). At 95%, packets queue up and the queuing algorithm determines which packets transmit first, providing real differentiation. B. Queuing only processes packets larger than 1000 bytes; at low utilisation, most packets are small C. QoS policies are disabled by IOS when link utilisation is below 50% D. At low utilisation, CBWFQ converts to FIFO automatically to save CPU

Correct answer is A. This is one of the most important QoS principles for the CCNA exam. Queuing mechanisms — CBWFQ, LLQ, WFQ — only matter when there is more traffic arriving than the interface can transmit instantaneously. When the interface has spare capacity, every packet goes straight out — there is nothing to queue, nothing to prioritise, and the queuing configuration does nothing. Queuing becomes critically important at high utilisation (typically 70%+) where multiple traffic types compete for limited transmit capacity. This is why QoS is especially valuable on WAN links that regularly operate near capacity.

9. An enterprise network uses LLQ with the voice class configured as `priority 2000` on a 10 Mbps serial link. Call quality complaints increase when more than 25 simultaneous G.711 calls are active. What is the explanation?

A. LLQ can only support 20 simultaneous calls regardless of configuration B. G.711 requires 2000 kbps per call — 25 calls is within the limit C. G.711 requires approximately 80–87 kbps per call (64 kbps payload + RTP/UDP/IP headers). 25 calls ≈ 25 × 87 kbps = 2175 kbps, exceeding the 2000 kbps priority police rate. Excess voice traffic is dropped by the policer, causing packet loss and degraded quality. Fix: increase priority to accommodate expected call capacity, or implement call admission control. D. Voice class must use bandwidth percent, not absolute kbps values

Correct answer is C. G.711 (uncompressed voice codec at 64 kbps) consumes approximately 64 kbps payload + approximately 20 kbps of RTP/UDP/IP overhead = roughly 80–87 kbps per call. With 25 calls: 25 × 87 kbps ≈ 2175 kbps. The priority queue is policed at 2000 kbps. When total voice traffic exceeds 2000 kbps, the policer drops the excess — those dropped voice packets appear as clicks, gaps, or call quality degradation. The fix is to size the priority allocation for the expected maximum call count plus headroom: for 30 G.711 calls, configure at least priority 2700 (30 × 90 kbps). Alternatively, implement call admission control to prevent more calls than the link can support.

10. What is the role of `class class-default` in a CBWFQ or LLQ policy-map, and what happens if no action is defined for it?

A. class-default matches only management traffic; undefined = management traffic is dropped B. class-default is the catch-all class that matches all traffic not classified by any explicit class-map. It is always present and always evaluated last. If no action is configured for it, unclassified traffic receives basic FIFO treatment — it enters a default FIFO queue outside the MQC scheduling, which may not provide any bandwidth guarantee. C. class-default must always be assigned the priority command — it is the default strict-priority queue D. class-default automatically receives all remaining bandwidth — no action configuration is needed

Correct answer is B. class-default is a special pre-defined class built into every MQC policy-map. It automatically matches any packet that did not match any of the explicitly defined classes — it is the "everything else" bucket. It is always present and always evaluated last (after all explicit classes). If you do not configure an action for class-default, unclassified traffic falls into a best-effort FIFO queue. Best practice is to explicitly configure an action for class-default: typically fair-queue (for automatic per-flow fairness within the default class) or bandwidth remaining percent <pct> (to give the default class a defined share of remaining bandwidth after guaranteed classes are satisfied). Never assign priority to class-default.

← Back to Home