Lab Objective
Configure WRED on an outbound interface with different minimum and maximum thresholds for two DSCP values, generate traffic approaching queue capacity, and verify lower-priority traffic experiences drops earlier and more gradually than higher-priority traffic as the queue fills.
Lab Purpose
Without WRED, a full queue results in tail drop — the queue simply rejects every new packet once completely full, regardless of priority, and multiple TCP flows can synchronize their retransmission timing in response, causing traffic to oscillate in waves. WRED addresses this by dropping packets probabilistically before the queue completely fills, and doing so preferentially based on marking, avoiding both the synchronization problem and treating all traffic identically regardless of importance.
Lab Topology
R1 ---- Gi0/1 (WAN-facing, congestion point)
Traffic marked with two DSCP values:
AF11 (lower priority, should drop earlier)
AF31 (higher priority, should drop later)Task 1: Configure a Policy-Map Applying WRED
Configure class-based WRED with distinct thresholds for AF11 and AF31 traffic.
Task 2: Apply the Policy Outbound
Apply the WRED policy to Gi0/1, the congestion point.
Task 3: Generate Traffic Approaching Queue Capacity
Generate a mix of AF11 and AF31 traffic sufficient to approach the interface's queue capacity.
Task 4: Verify AF11 Experiences Earlier Drops
Confirm AF11 traffic shows drop activity while queue depth is still moderate.
Task 5: Verify AF31 Is Preserved Longer
Confirm AF31 traffic continues passing with minimal or no drops until queue depth approaches the higher threshold configured for it.
Solution and Verification
R1(config)# policy-map WRED-POLICY
R1(config-pmap)# class class-default
R1(config-pmap-c)# random-detect dscp-based
R1(config-pmap-c)# random-detect dscp 10 20 40 10
R1(config-pmap-c)# random-detect dscp 26 35 40 10
-- AF11 (dscp 10): min threshold 20 packets,
-- max threshold 40, drop probability
-- denominator 10 -- starts dropping
-- earlier and more aggressively
-- AF31 (dscp 26): min threshold 35, max
-- threshold 40 -- a much narrower window
-- before reaching max, meaning it survives
-- much closer to full queue depth before
-- any drops begin at allR1(config)# interface gigabitethernet0/1
R1(config-if)# service-policy output WRED-POLICYTrafficGen> [generates a mix of AF11 and
AF31 traffic sufficient to push
queue depth toward capacity]R1# show policy-map interface gigabitethernet0/1
Service-policy output: WRED-POLICY
Class-map: class-default
Exp-weight-constant: 9 (1/512)
Mean queue depth: 28
dscp Transmitted Random drop Tail drop Minimum Maximum
af11 842 packets 47 packets 0 packets 20 40
af31 1204 packets 0 packets 0 packets 35 40
-- At a mean queue depth of 28 (between
-- AF11's min of 20 and AF31's min of 35),
-- AF11 has already experienced random
-- drops while AF31 has experienced none
-- at all -- exactly the differentiated
-- behavior the distinct thresholds were
-- configured to produce-- With traffic volume pushed even higher,
-- approaching queue depth 35+:
R1# show policy-map interface gigabitethernet0/1
dscp Transmitted Random drop Tail drop Minimum Maximum
af11 1580 packets 312 packets 8 packets 20 40
af31 2100 packets 41 packets 0 packets 35 40
-- AF31 finally begins experiencing some
-- drops only once depth crosses its own
-- 35-packet minimum threshold -- but even
-- then, its drop count remains far lower
-- than AF11'sKey Takeaway
WRED's per-class minimum and maximum thresholds directly determine at what queue depth dropping begins and how aggressively it escalates for each traffic marking — configuring a lower minimum threshold for less important traffic (AF11 here) causes it to absorb congestion first and more heavily, protecting more important traffic (AF31) from drops until congestion becomes severe enough to cross its own, later threshold, achieving differentiated congestion response without requiring separate physical queues for each traffic class.