Hands-On Lab: Configuring Class-Based Weighted Fair Queuing (CBWFQ)

Lab Objective

Configure CBWFQ with three named classes, each guaranteed a specific minimum bandwidth percentage, apply the policy to a congested outbound interface, and verify each class receives at least its configured allocation during sustained congestion from all classes simultaneously.

Lab Purpose

The earlier QoS lab configured strict priority queuing for voice specifically, and shaping/policing labs addressed rate limiting, but neither addressed the common need to guarantee minimum bandwidth shares across multiple non-voice traffic types competing for the same link — CBWFQ solves this by allocating a minimum bandwidth guarantee to each defined class.

Lab Topology

R1 ---- Gi0/1 (100 Mbps link, congested by
               simultaneous traffic from
               all three classes)

Traffic classes:
CRITICAL-DATA (should get 40% minimum)
BULK-DATA (should get 20% minimum)
DEFAULT traffic (remainder, class-default)

Task 1: Create Class-Maps for Each Traffic Type

Define class-maps matching CRITICAL-DATA (by DSCP AF41) and BULK-DATA (by DSCP AF11).

Task 2: Configure the CBWFQ Policy-Map

Configure bandwidth percentage guarantees for each class, plus fair-queue handling for class-default.

Task 3: Apply the Policy Outbound

Apply the CBWFQ policy to the congested interface.

Task 4: Generate Simultaneous Traffic From All Classes Exceeding Link Capacity

Generate enough traffic from all three categories combined to exceed the link's 100 Mbps capacity.

Task 5: Verify Each Class Receives at Least Its Guaranteed Bandwidth

Confirm CRITICAL-DATA and BULK-DATA each receive at least their configured minimum share during the congestion period.

Solution and Verification

R1(config)# class-map match-all CRITICAL-DATA
R1(config-cmap)# match dscp af41
R1(config-cmap)# exit
R1(config)# class-map match-all BULK-DATA
R1(config-cmap)# match dscp af11

R1(config)# policy-map CBWFQ-POLICY
R1(config-pmap)# class CRITICAL-DATA
R1(config-pmap-c)# bandwidth percent 40
R1(config-pmap)# class BULK-DATA
R1(config-pmap-c)# bandwidth percent 20
R1(config-pmap)# class class-default
R1(config-pmap-c)# fair-queue

-- 40% + 20% = 60% explicitly reserved,
-- leaving 40% for class-default and any
-- protocol control-plane traffic overhead
-- -- CBWFQ never allows total reservations
-- to exceed 75% of interface bandwidth by
-- default, protecting against
-- over-subscription

R1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output CBWFQ-POLICY

TrafficGen> [generates 50 Mbps CRITICAL-DATA,
             40 Mbps BULK-DATA, and 30 Mbps
             unmarked default traffic --
             120 Mbps combined toward a
             100 Mbps link, guaranteeing
             sustained congestion]

R1# show policy-map interface gigabitethernet0/1

  Service-policy output: CBWFQ-POLICY

    Class-map: CRITICAL-DATA
      Bandwidth 40% (40000 kbps)
      Queueing
      (queue depth/total drops/no-buffer drops) 3/128/0
      (pkts output/bytes output) 284213/...

    Class-map: BULK-DATA
      Bandwidth 20% (20000 kbps)
      Queueing
      (queue depth/total drops/no-buffer drops) 8/512/0
      (pkts output/bytes output) 142106/...

    Class-map: class-default
      Flow Based Fair Queueing
      (queue depth/total drops/no-buffer drops) 15/890/0
      (pkts output/bytes output) 71053/...
-- Despite far more traffic being offered
-- than the link can carry, CRITICAL-DATA's
-- actual throughput approximates its
-- guaranteed 40 Mbps and BULK-DATA
-- approximates its guaranteed 20 Mbps --
-- both maintained their minimum share even
-- under sustained oversubscription, with
-- the excess appropriately dropped rather
-- than allowed to starve the guarantees

R1# show policy-map interface gigabitethernet0/1 | include Bandwidth

Bandwidth 40% (40000 kbps)
Bandwidth 20% (20000 kbps)
-- Confirms the configured guarantees
-- remain active and enforced throughout
-- the congestion period

Key Takeaway

CBWFQ's bandwidth percent command establishes a guaranteed minimum, not a hard maximum — a class can still receive more than its configured percentage if spare capacity exists, but during genuine congestion (as demonstrated here with traffic exceeding total link capacity), each class is protected from being starved below its configured guarantee, which is precisely the problem simple FIFO queuing or unweighted fair-queuing alone cannot solve when multiple important traffic types compete for the same congested link.