Hands-On Lab: Configuring Low Latency Queuing (LLQ)

Lab Objective

Configure a single policy-map combining a strict priority queue for voice traffic with the CBWFQ bandwidth-guaranteed classes from the previous lab, verify voice traffic experiences minimal latency even during congestion, and confirm the priority queue's implicit policing prevents it from starving the other classes.

Lab Purpose

The earlier basic QoS lab configured strict priority queuing alone, and the previous lab configured CBWFQ alone. LLQ is simply the combination of both within one policy-map — a priority class for latency-sensitive traffic like voice, alongside CBWFQ classes for everything else — representing the queuing strategy actually deployed in the overwhelming majority of real production networks.

Lab Topology

R1 ---- Gi0/1 (100 Mbps link, same
               congestion scenario as the
               previous CBWFQ lab, now with
               voice traffic added)

VOICE-TRAFFIC: strict priority, policed at 10 Mbps
CRITICAL-DATA: 40% guaranteed
BULK-DATA: 20% guaranteed
class-default: remainder

Task 1: Create a Class-Map for Voice Traffic

Define a class-map matching DSCP EF (voice traffic).

Task 2: Configure the LLQ Policy Combining Priority and CBWFQ

Add the voice class using the priority command with an explicit bandwidth cap, alongside the existing CRITICAL-DATA, BULK-DATA, and class-default configuration from the previous lab.

Task 3: Apply the Combined Policy Outbound

Apply the updated policy-map to the congested interface.

Task 4: Generate Voice Traffic Alongside the Existing Data Congestion

Generate voice traffic simultaneously with the CRITICAL-DATA, BULK-DATA, and default traffic from the previous lab's congestion scenario.

Task 5: Verify Voice Receives Minimal Latency Despite Congestion

Confirm voice traffic experiences near-zero delay and drops, while the other classes still maintain their CBWFQ guarantees.

Solution and Verification

R1(config)# class-map match-all VOICE-TRAFFIC
R1(config-cmap)# match dscp ef

R1(config)# policy-map CBWFQ-POLICY
R1(config-pmap)# class VOICE-TRAFFIC
R1(config-pmap-c)# priority 10000

-- The priority command creates a strict
-- priority queue serviced ahead of every
-- other class, but with an implicit
-- policer capping it at the specified
-- 10 Mbps -- this policing is what
-- prevents the priority queue from
-- starving CRITICAL-DATA and BULK-DATA
-- entirely, since without a cap, a
-- misbehaving or overwhelming volume of
-- "voice" traffic could otherwise consume
-- the entire link

-- The rest of the policy-map (CRITICAL-DATA,
-- BULK-DATA, class-default) remains
-- unchanged from the previous CBWFQ lab

R1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output CBWFQ-POLICY
-- (already applied from the previous lab;
--  the updated policy-map definition
--  applies automatically)

TrafficGen> [generates 8 Mbps voice traffic
             alongside the same 50/40/30
             Mbps CRITICAL/BULK/default
             traffic mix from the previous
             lab -- 128 Mbps combined
             toward a 100 Mbps link]

R1# show policy-map interface gigabitethernet0/1

  Service-policy output: CBWFQ-POLICY

    Class-map: VOICE-TRAFFIC
      Strict Priority
      Bandwidth 10000 (kbps) Burst 250000 (Bytes)
      (pkts matched/bytes matched) 42106/...
      (total drops) 0
-- Zero drops for voice, confirming it is
-- serviced immediately ahead of every
-- other class regardless of their own
-- congestion state

    Class-map: CRITICAL-DATA
      Bandwidth 40% (40000 kbps)
      (queue depth/total drops/no-buffer drops) 4/145/0

    Class-map: BULK-DATA
      Bandwidth 20% (20000 kbps)
      (queue depth/total drops/no-buffer drops) 9/580/0
-- CRITICAL-DATA and BULK-DATA continue
-- receiving approximately their guaranteed
-- shares of the REMAINING bandwidth after
-- voice's 10 Mbps is set aside first --
-- neither guarantee was meaningfully
-- disrupted by adding voice into the mix

VoiceClient> [measures call quality]

Jitter: 2ms, Packet loss: 0%
-- Voice call quality remains excellent
-- despite the interface being significantly
-- oversubscribed overall

Key Takeaway

LLQ is not a separate mechanism from priority queuing and CBWFQ — it is simply the standard practice of combining both within a single policy-map, using strict priority for the handful of traffic types genuinely sensitive to latency and jitter (voice, video) while using CBWFQ's bandwidth guarantees for everything else that needs fairness but can tolerate some queuing delay; the mandatory bandwidth cap on the priority class is what keeps this combination stable, ensuring the latency-sensitive traffic cannot inadvertently consume the entire link at the expense of every other class's guarantees.