Class-Based Weighted Fair Queueing

A Cisco Router Tutorial

By Chris Bryant, CCIE #12933

The first reaction to WFQ is usually something like this: "That sounds great, but shouldn't the network administrator be deciding which flows should be transmitted first, rather than the router?" Good question! There's an advanced form of WFQ, Class-Based Weighted Fair Queuing (CBWFQ) that allows manual configuration of queuing - and CBWFQ does involve access list configuration.

Since the name is the recipe, the first step in configuring CBWFQ is to create the classes themselves. If you've already passed your BCRAN exam, this will all look familiar to you. If not, no problem at all, we'll take a step-by-step approach to CBWFQ.

We'll first define two classes, one that will be applied to TCP traffic sourced from 172.10.10.0 /24, and another applied to FTP traffic from 172.20.20.0 /24. The first step is to write two separate ACLs, with one matching the first source and another matching the second. Don't write one ACL matching both.

R1(config)#access-list 100 permit tcp 172.10.10.0 0.0.0.255 any
R1(config)#access-list 110 permit tcp 172.20.20.0 0.0.0.255 any eq ftp

Now two class maps will be written, each calling one of the above ACLs.

R1(config)#class-map 17210100
R1(config-cmap)#match access-group 100

R1(config)#class-map 17220200
R1(config-cmap)#match access-group 110

By the way, we've got quite a few options for the match statement in a class map, and up to 64 classes can be created:

R1(config-cmap)#match ?
access-group Access group
any Any packets
class-map Class map
cos IEEE 802.1Q/ISL class of service/user priority values
destination-address Destination address
input-interface Select an input interface to match
ip IP specific values
mpls Multi Protocol Label Switching specific values
not Negate this match result
protocol Protocol
qos-group Qos-group
source-address Source address

At this point, we've created two class maps that aren't really doing anything except matching the access list. The actual values applied to the traffic are contained in our next step, the policy map.

R1(config)#policy-map CBWFQ
R1(config-pmap)#class 17210100
R1(config-pmap-c)#?
QoS policy-map class configuration commands:
bandwidth Bandwidth
exit Exit from QoS class action configuration mode
no Negate or set default values of a command
priority Strict Scheduling Priority for this Class
queue-limit Queue Max Threshold for Tail Drop
random-detect Enable Random Early Detection as drop policy
service-policy Configure QoS Service Policy
shape Traffic Shaping
<cr>
police Police

The values we'll set for both classes are the bandwidth and queue-limit values. For traffic matching class 17210100, we'll assign bandwidth of 400 and a queue limit of 50 packets; for traffic matching class 17220200, we'll assign bandwidth of 200 and a queue limit of 25 packets. The bandwidth assigned to a class is the value CBWFQ uses to assign weight.

The more bandwidth assigned to a class, the lower the weight.
The lower the weight, the higher the priority for transmission.

R1(config)#policy-map CBWFQ
R1(config-pmap)#class 17210100
R1(config-pmap-c)#bandwidth 400
R1(config-pmap-c)#queue-limit 50

R1(config-pmap-c)#class 17220200
R1(config-pmap-c)#bandwidth 200
R1(config-pmap-c)#queue-limit 25

If no queue limit is configured, the default of 64 is used.

Finally, we need to apply this policy map to the interface! As with ACLs, a Cisco router interface can have one policy map affecting incoming traffic and another affecting outgoing traffic. We'll apply this to traffic leaving Serial0.

R1(config)#int s0
R1(config-if)#service ?
history Keep history of QoS metrics
input Assign policy-map to the input of an interface
output Assign policy-map to the output of an interface

R1(config-if)#service output CBWFQ
Must remove fair-queue configuration first.

Here's a classic "gotcha" - to apply a policy map, you've got to disable WFQ first. The router will be kind enough to tell you that. The exam probably won't be that nice. :) Remove WFQ with the no fair-queue command, then we can apply the policy map.

R1(config-if)#no fair-queue
R1(config-if)#service output CBWFQ

To view the contents of a policy map, run show policy-map.

R1#show policy-map CBWFQ
Policy Map CBWFQ
Class 17210100
Bandwidth 400 (kbps) Max Threshold 50 (packets)
Class 17220200
Bandwidth 200 (kbps) Max Threshold 25 (packets)

CBWFQ configuration does have its limits. By default, you can't assign over 75% of an interface's bandwidth via CBWFQ, because 25% is reserved for network control and routing traffic. To illustrate, I've rewritten the previous policy map to double the requested bandwidth settings. When I try to apply this policy map to the serial interface, I get an interesting message:

R1#show policy-map
Policy Map CBWFQ
Class 17210100
Bandwidth 800 (kbps) Max Threshold 50 (packets)
Class 17220200
Bandwidth 400 (kbps) Max Threshold 25 (packets)

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interfac serial0
R1(config-if)#service output CBWFQ
Serial0 class 17220200 requested bandwidth 400 (kbps) Available only 358 (kbps)

Why is 358 Kbps all that's available? Start with the bandwidth of a serial interface, 1544 kbps. Only 75% of that bandwidth can be assigned through CBWFQ, and 1544 x .75 = 1158. We can assign only 1158 kbps of a T1 interface's bandwidth in the policy map. We have already assigned 800 kbps to class 17210100, leaving only 358 kbps for other classes.

Keep this 75% rule in mind - it's a very common error with CBWFQ configurations. Don't jump to the conclusion that bandwidth 64 is the proper command to use when you've got a 64 kbps link and you want to enable voice traffic to use all of it. Always go with a minimum of 75% of available bandwidth, and don't forget all the other services that will need bandwidth as well!

If you really need to change this reserved percentage - and you should have a very good reason before doing so - use the max-reserved-bandwidth command on the interface. The following configuration changes the reservable bandwidth to 85%.

R1(config-if)#max-reserved-bandwidth ?
<1-100> Max. reservable bandwidth as % of interface bandwidth
<cr>

R1(config-if)#max-reserved-bandwidth 85

The "reservable bandwidth" referenced in this command isn't just the bandwidth assigned in CBWFQ. It also includes bandwidth allocated for the following:

Low Latency Queuing (LLQ)
IP Real Time Protocol (RTP) Priority
Frame Relay IP RTP Priority
Frame Relay PVC Interface Priority Queuing
Resource Reservation Protocol (RSVP)
CBWFQ And Packet Drop

Earlier in this section, we used the queue-limit command to dictate how many packets a queue could hold before packets would have to be dropped. Below is part of that configuration, and for this particular class the queue is limited to holding 50 packets.

R1(config)#policy-map CBWFQ
R1(config-pmap)#class 17210100
R1(config-pmap-c)#bandwidth 400
R1(config-pmap-c)#queue-limit 50

If the queue is full, what happens? No matter how efficient your queuing strategy, sooner or later, the router is going to drop some packets. The default method of packet drop with CBWFQ is tail drop, and it's just what it sounds like - packets being dropped from the tail end of the queue.

Tail drop may be the default, but there are two major issues with it. First, this isn't a very discriminating way to drop traffic. What if this were voice traffic that needed to go to the head of the line? Tail drop offers no mechanism to look at a packet and decide that a packet already in the queue should be dropped to make room for it.

The other issue with tail drop is TCP global synchronization. This is a result of TCP's behavior when packets are lost.

Packets dropped due to tail drop result in the TCP senders reducing their transmission rate. As the transmission slows, the congestion is reduced. All TCP senders will gradually increase their transmission speed as a result of the reduced congestion - which results in congestion occurring all over again.

The result of TCP global synchronization? When the TCP sender simultaneously slow their transmission, that results in underutilization of the bandwidth. When the TCP senders all increase their transmission rate at the same time, the bandwidth is oversubscribed, packets are dropped and must be retransmitted, and the entire process begins all over again. Basically, the senders are either sending too little or too much traffic at any given time.

To avoid the TCP Global Synchronization problems, Random Early Detection (RED) or Weighted Random Early Detection (WRED) can be used in place of Tail Drop. RED will proactively drop packets before the queue gets full, but the decision of which packets will be dropped is still random. WRED uses either a packet's IP Precedence or Differentiated Services Code Point (DSCP) to decide which packets should be dropped.

WRED gives the best service it can to packets in a priority queue. If the priority queue becomes full, WRED will drop packets from other queues before dropping any from the priority queue.

The random-detect command is used to enable WRED. You know it can't be just that simple, right? You must keep in mind that when WRED is configured as part of a class in a policy map, WRED must not be running on the same interface that the policy is going to be applied to.

R1(config)#policy-map CBWFQ_WRED
R1(config-pmap)#class 17210100
R1(config-pmap-c)#bandwidth 400
R1(config-pmap-c)#random-detect
R1(config-pmap-c)#random-detect ?
dscp parameters for each dscp value
dscp-based Enable dscp-based WRED as drop policy
exponential-weighting-constant weight for mean queue depth calculation
prec-based Enable precedence-based WRED as drop policy
precedence parameters for each precedence value
<cr>

Both RED and WRED are useful only when the traffic in question is TCP-based.

To your success,

Chris Bryant

CCIE #12933

chris@thebryantadvantage.com