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: remainderTask 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 efR1(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 labR1(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 mixVoiceClient> [measures call quality]
Jitter: 2ms, Packet loss: 0%
-- Voice call quality remains excellent
-- despite the interface being significantly
-- oversubscribed overallKey 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.