11.3 Low Latency Queuing (LLQ) Configuration on Cisco IOS XE

11.3 Low Latency Queuing (LLQ) Configuration on Cisco IOS XE

Queuing is the congestion management mechanism deployed on router interfaces to determine the order in which packets depart when arrival rates exceed link transmission capacity. Without intelligent queuing, interfaces operate on a First-In, First-Out (FIFO) basis, where delay-sensitive voice packets become trapped behind large bulk data frames. On Cisco IOS XE routers, Low Latency Queuing (LLQ) represents the premier congestion management architecture for real-time collaboration networks. This section covers the Modular QoS CLI (MQC) framework, LLQ scheduling mechanics, policing dynamics, congestion avoidance, and complete configuration templates.

---

1. The Modular QoS CLI (MQC) Framework

Cisco IOS XE structures QoS configuration through the Modular QoS Command-Line Interface (MQC). MQC decouples packet classification from policy actions, establishing a standardized three-step workflow:

+-------------------------------------------------------------------------+
|                   THE THREE-STEP MQC CONFIGURATION MODEL                |
|                                                                         |
|   STEP 1: CLASSIFICATION             STEP 2: POLICY ACTION              |
|   +--------------------------+       +-------------------------------+  |
|   | class-map [all | any]    | ----> | policy-map <name>             |  |
|   |  match ip dscp ...       |       |  class <class-name>           |  |
|   |  match protocol ...      |       |   priority / bandwidth        |  |
|   +--------------------------+       +---------------+---------------+  |
|                                                      |                  |
|                                                      v                  |
|   STEP 3: INTERFACE ATTACHMENT       +-------------------------------+  |
|                                      | interface GigabitEthernet0/0/1|  |
|                                      |  service-policy output <name> |  |
|                                      +-------------------------------+  |
+-------------------------------------------------------------------------+

Step 1: Traffic Classification (class-map)

The class-map construct identifies and groups traffic based on specific packet headers or inspection criteria:

• Matching Operators:
  • class-map match-all <name>: Enforces a logical AND; a packet must satisfy every configured match statement to belong to the class.
  • class-map match-any <name>: Enforces a logical OR; a packet matching any single match statement is admitted to the class.
• Classification Criteria:
  • match ip dscp <value>: Inspects Layer 3 DSCP code points (e.g., ef, af41, cs3).
  • match protocol <protocol>: Utilizes Network-Based Application Recognition (NBAR2) deep packet inspection to classify traffic regardless of Layer 4 ports (e.g., match protocol webex-media).
  • match access-group name <acl>: Evaluates standard or extended Access Control Lists.

Step 2: Policy Map Creation (policy-map)

The policy-map associates QoS actions with previously defined classes. Actions include bandwidth reservations, strict priority queuing, traffic shaping, policing, and remarking.

Step 3: Policy Attachment (service-policy)

The service-policy command applies the policy-map to an interface, subinterface, or tunnel interface in either the input or output direction. Queuing policies (LLQ/CBWFQ) can only be applied in the output (egress) direction because a router cannot queue packets it has not yet received.

2. Low Latency Queuing (LLQ) Scheduling Mechanics

Queuing algorithms have evolved through several generations of router hardware:

1. First-In, First-Out (FIFO): Packets are transmitted strictly in order of arrival. Subject to massive latency and jitter.
2. Priority Queuing (PQ): Multiple strict priority queues. Lower queues receive zero service until higher queues empty, resulting in severe starvation of standard data.
3. Custom Queuing (CQ): Round-robin scheduling with byte-count thresholds. Prevents starvation, but cannot provide low latency guarantees.
4. Weighted Fair Queuing (WFQ): Dynamically divides bandwidth among conversations based on IP Precedence. Cannot guarantee fixed bandwidth ceilings for specific enterprise classes.
5. Class-Based Weighted Fair Queuing (CBWFQ): Allocates guaranteed minimum bandwidth to user-defined classes using a modified deficit round-robin scheduler. Excellent for data and video, but introduces excessive jitter for voice.
6. Low Latency Queuing (LLQ): Combines the strict delay bounds of a Strict Priority Queue (PQ) with the starvation protection of CBWFQ.

+-------------------------------------------------------------------------+
|                   LOW LATENCY QUEUING (LLQ) SCHEDULER                   |
|                                                                         |
|   INGRESS PACKETS                                                       |
|        |                                                                |
|        +---> [Classifier: DSCP / MQC]                                   |
|                   |                                                     |
|                   +---> [Priority Queue: Voice (EF)]                    |
|                   |          | (Serviced FIRST before any other queue)  |
|                   |          v                                          |
|                   +---> [CBWFQ Queue 1: Video (AF41)]                   |
|                   |          |                                          |
|                   +---> [CBWFQ Queue 2: Signaling (CS3)]                |
|                   |          | (Weighted Round-Robin Scheduler)         |
|                   +---> [CBWFQ Queue 3: Critical Data]                  |
|                   |          |                                          |
|                   +---> [Class-Default: Best Effort]                    |
|                              |                                          |
|                              v                                          |
|                   +----------------------+                              |
|                   | HARDWARE TX-RING     |                              |
|                   +----------+-----------+                              |
|                              |                                          |
|                              v                                          |
|                   [PHYSICAL TRANSMISSION WIRE]                          |
+-------------------------------------------------------------------------+

The Scheduler Operation

The LLQ scheduler inspects the Strict Priority Queue first. Whenever a packet resides in the priority queue, the scheduler dequeues it immediately and sends it to the interface hardware transmit ring (Tx-Ring). Only when the priority queue is completely empty does the scheduler service the remaining CBWFQ queues (Video, Signaling, Critical Data, and Class-Default) using weighted round-robin scheduling.

3. Priority Queue Configuration & Policer Dynamics

While strict priority queuing delivers the near-zero delay and jitter required by voice media, it reintroduces the fundamental danger of Priority Queuing: queue starvation. If an unpoliced voice queue were flooded with excess traffic, it would monopolize 100% of interface bandwidth, starving critical signaling, business applications, and routing protocols.

The Built-In LLQ Policer

To eliminate the risk of starvation, Cisco LLQ incorporates an implicit traffic policer directly within the priority command:

• Syntax:
  • priority <bandwidth-kbps>: Allocates a dedicated bandwidth ceiling in kbps.
  • priority percent <percentage>: Allocates a ceiling as a percentage of the total interface or parent shaping bandwidth.
• Non-Congested State: If the physical interface is not congested, voice packets arriving in excess of the configured priority ceiling are transmitted without penalty.
• Congested State: The moment the interface experiences congestion (the software queue engages because the hardware Tx-Ring is full), the built-in policer strictly enforces the configured priority bandwidth limit. Any voice traffic exceeding the allocated kbps or percentage is immediately discarded!

Cisco IOS XE Dual Priority Queuing

Modern Cisco IOS XE releases support Dual LLQ, enabling two distinct strict priority levels:

• priority level 1: Highest strict priority. Serviced ahead of all other queues. Universally reserved for Voice Media (EF).
• priority level 2: Second strict priority. Serviced after Priority Level 1 is empty, but before any CBWFQ queue. Reserved for Interactive Video (AF41).

---

4. CBWFQ & Congestion Avoidance (WRED vs. Tail Drop)

CBWFQ Bandwidth Allocation

Non-priority classes (Video, Signaling, Transactional Data) utilize Class-Based Weighted Fair Queuing:

• bandwidth <kbps>: Guarantees a minimum rate in kilobits per second during congestion.
• bandwidth remaining percent <percentage>: Allocates a percentage of the unreserved bandwidth remaining after priority and absolute bandwidth guarantees have been satisfied. This is the modern Cisco-recommended standard for enterprise WAN edge policies.

Congestion Avoidance: WRED vs. Tail Drop

When a router queue fills to 100% capacity, incoming packets encounter tail drop. In networks carrying thousands of TCP flows, tail drop triggers TCP Global Synchronization:

1. Multiple TCP connections drop packets simultaneously.
2. All TCP endpoints simultaneously back off their transmission windows (multiplicative decrease).
3. Network utilization collapses, causing the queue to empty.
4. All endpoints simultaneously ramp up transmission speeds (slow start), causing the queue to overflow again, repeating the oscillatory saw-tooth cycle.

+-------------------------------------------------------------------------+
|                    DSCP-BASED WRED DISCARD PROFILES                     |
|                                                                         |
|   DISCARD PROBABILITY                                                   |
|   100% |                                                                |
|        |                              /|  AF43 (Drop 3 - Discard First) |
|        |                             / |                                |
|        |                     /|     /  |  AF42 (Drop 2 - Medium Drop)   |
|        |                    / |    /   |                                |
|        |            /|     /  |   /    |  AF41 (Drop 1 - Discard Last)  |
|        |           / |    /   |  /     |                                |
|     0% +----------+--+---+----+--+-----+------------------------        |
|                  Min1    Min2   Min3  Max Threshold                    |
|                             AVERAGE QUEUE DEPTH                         |
+-------------------------------------------------------------------------+

DSCP-Based Weighted Random Early Detection (WRED)

Weighted Random Early Detection (WRED) prevents TCP global synchronization by randomly discarding packets before the buffer fills. By dropping individual packets from random TCP sessions, WRED causes distinct TCP flows to back off at staggered intervals, maintaining smooth, continuous 100% link utilization.

• DSCP-Based WRED (random-detect dscp-based): Differentiates discard thresholds based on the packet's Assured Forwarding drop precedence. Packets marked AF43 (High Drop) are dropped at a lower queue threshold than AF42 (Medium Drop), while AF41 (Low Drop) packets are protected until queue depth nears capacity.
• Crucial Rule: WRED must NEVER be applied to the Voice Priority Queue. Voice uses UDP, which does not have TCP congestion window mechanics. Dropping voice packets degrades MOS quality without causing the sender to throttle back. Priority queues rely strictly on policing or tail drop.

5. Enterprise WAN Edge MQC Configuration Template

The following complete, production-grade configuration demonstrates a hierarchical MQC policy applied to a Gigabit WAN edge interface on a Cisco Catalyst 8300 / ISR 4000 running Cisco IOS XE.

! =========================================================================
! 1. CLASSIFICATION: CLASS-MAPS FOR ENTERPRISE COLLABORATION TRAFFIC
! =========================================================================
class-map match-any CM-VOICE-MEDIA
 match ip dscp ef

class-map match-any CM-INTERACTIVE-VIDEO
 match ip dscp af41
 match ip dscp af42

class-map match-any CM-CALL-SIGNALING
 match ip dscp cs3
 match ip dscp af31

class-map match-any CM-CRITICAL-DATA
 match ip dscp af21
 match ip dscp af22

! =========================================================================
! 2. QUEUING POLICY: CHILD POLICY-MAP (LLQ + CBWFQ + WRED)
! =========================================================================
policy-map PM-WAN-QUEUING-CHILD
 class CM-VOICE-MEDIA
  ! Strict Priority Queue: 1,000 kbps reserved; policed during congestion
  priority 1000

 class CM-INTERACTIVE-VIDEO
  ! Guaranteed bandwidth for 2-way Webex/SIP Video
  bandwidth remaining percent 30
  ! DSCP-based WRED to manage video burst congestion
  random-detect dscp-based

 class CM-CALL-SIGNALING
  ! Guaranteed bandwidth to prevent SIP keepalive/INVITE drops
  bandwidth remaining percent 5

 class CM-CRITICAL-DATA
  ! Transactional ERP / Enterprise database traffic
  bandwidth remaining percent 35
  random-detect dscp-based

 class class-default
  ! Remaining bandwidth allocated to general best-effort data
  bandwidth remaining percent 30
  fair-queue

! =========================================================================
! 3. TRAFFIC SHAPING: PARENT POLICY-MAP (HIERARCHICAL MQC / H-QoS)
! =========================================================================
policy-map PM-WAN-EDGE-PARENT
 class class-default
  ! Shape to committed sub-line rate (e.g., 100 Mbps on a 1 Gbps physical handoff)
  shape average 100000000
  service-policy PM-WAN-QUEUING-CHILD

! =========================================================================
! 4. INTERFACE ATTACHMENT
! =========================================================================
interface GigabitEthernet0/0/1
 description Primary WAN Uplink to Carrier MPLS Fabric
 ip address 198.51.100.2 255.255.255.252
 service-policy output PM-WAN-EDGE-PARENT

Key Verification Commands

• show policy-map interface <interface-name>: Displays real-time queuing statistics, packet counts, offered rates, and tail drop / policer drop counters for each configured class.
• show class-map: Validates match criteria and syntax for configured class-maps.
• show policy-map: Displays configured policy-map parameters and queuing allocations.