Using Class-Based Weighted Fair Queuing

Problem

You want to use Class-Based Weighted Fair Queuing on an interface.

Solution

There are three steps to configuring Class-Based Weighted Fair Queuing (CBWFQ) on a router. First, you have to create one or more class maps that describe the traffic types. Then you create a policy map that tells the router what to do with these traffic types. Finally, you need to attach this policy map to one or more of the router's interfaces:

Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#class-map highprec Router(config-cmap)#description Highest priority Prec=5 Router(config-cmap)#match ip precedence 5 Router(config-cmap)#exit Router(config)#class-map medhiprec Router(config-cmap)#description Medium-high priority Prec=4 Router(config-cmap)#match ip precedence 4 Router(config-cmap)#exit Router(config)#class-map medloprec Router(config-cmap)#description Medium-low priority Prec=2,3 Router(config-cmap)#match ip precedence 2 3 Router(config-cmap)#exit Router(config)#policy-map cbwfqpolicy Router(config-pmap)#class highprec Router(config-pmap-c)#bandwidth percent 25 Router(config-pmap-c)#exit Router(config-pmap)#class medhiprec Router(config-pmap-c)#bandwidth percent 25 Router(config-pmap-c)#exit Router(config-pmap)#class medloprec Router(config-pmap-c)#bandwidth percent 25 Router(config-pmap-c)#exit Router(config-pmap)#class class-default Router(config-pmap-c)#fair-queue 512 Router(config-pmap-c)#queue-limit 96 Router(config-pmap-c)#exit Router(config-pmap)#exit Router(config)#interface serial0/1 Router(config-if)#service-policy output cbwfqpolicy Router(config-if)#exit Router(config)#end Router#

This feature is available in IOS levels 12.0(5)T and higher.

Discussion

CBWFQ need not be significantly different from regular WFQ. In the example we have defined all traffic with an IP Precedence value of critical (5) to have a special queue. We have also created a single queue for traffic with Precedence 4, and another one for traffic with Precedence values of 2 and 3. All other traffic, including traffic with Precedence 0 and 1, as well as all nonIP traffic uses regular WFQ. To make this fact slightly more clear, we have modified the default WFQ parameters with the following commands:

Router(config)#policy-map cbwfqpolicy Router(config-pmap)#class class-default Router(config-pmap-c)#fair-queue 512 Router(config-pmap-c)#queue-limit 96

This simply modifies the default WFQ behavior for all traffic that doesn't match one of the other defined classes. It sets the number of WFQ queues to 512, and sets the queue depth to a maximum of 96 packets. You could achieve the same effect by using the fair-queue interface command from Recipe 11.6:

Router(config-if)#fair-queue 96 512 0

But that example doesn't give you the ability to also have separate queues for special classes of traffic, as shown in this recipe. We note in passing that the final argument for this fair-queue interface command specifies the number of queues to set aside for RSVP. We are trying to duplicate the effect of the cbwfqpolicy policy map, which doesn't include any RSVP queues, so we have set the last argument to zero here. Please refer to Recipe 11.6 for more information on this command.

You can create up to 64 Class-based queues for use with CBWFQ. You can control the share of the bandwidth to each queue using the bandwidth keyword either by using an absolute value in kilobits per second, or a percentage of the total available bandwidth. The following example shows the syntax for using a percentage:

Router(config-pmap)#class highprec Router(config-pmap-c)#bandwidth percent 25 Router(config-pmap-c)#exit

The bandwidth percent command is available in IOS levels 12.1(1) and higher. For earlier releases, you can only specify an absolute bandwidth:

Router(config-pmap-c)#bandwidth 5000

The argument for this version of the command is a value in kilobits per second between 8 and 2,000,000, which should be sufficient for most interface types. Note that the upper limit here is 2 Mbps, which is roughly the E1 speed mentioned earlier as the effective upper limit to using WFQ. Because CBWFQ generally uses fewer queues and doesn't need to sort based on flow, you can use it for higher speed interfaces as well. However, you should let your average CPU utilization be your guide here. If you do too many tests when classifying packets, you might find that the router can't keep up with high packet rates.

In both versions, you have to keep two important factors in mind. First, although this is essentially a Layer 3 feature, when configuring the bandwidth you have to include any Layer 2 framing overhead. If a given queue supports a streaming multimedia application with a known bit rate, it is often a good idea to slightly overestimate the requirements to include this Layer 2 overhead. If the application doesn't use the excess, CBWFQ allocates it to other queues.

The second important factor is that the total allocated bandwidth must not exceed a configurable maximum value. By default, this maximum is 75 percent. You can change it, for example, to 80 percent by using the following interface level command:

Router(config-if)#max-reserved-bandwidth 80

You would apply this command to the interface that runs CBWFQ and needs a little extra reserved capacity. It is usually best to leave this at its default value, however. The router uses the remainder for unclassified traffic and network control packets. In this case, we have configured WFQ for the unclassified traffic. It is vital, however, to reserve enough bandwidth for critical network functions such as Layer 2 keepalive frames and routing protocols.

Creating the policy map alone doesn't actually change the way the router behaves. To do that, you have to attach this policy to an interface as follows:

Router(config)#interface serial0/1 Router(config-if)#service-policy output cbwfqpolicy

One of the classes defined in this example is a high-priority class that we called highpriority. This class map simply looks for traffic that is tagged with an IP precedence value of 5. The policy map then tells the interface to give up to 25 percent of its bandwidth to this high priority traffic. If there is not enough high-priority traffic to use this, the router will allocate the excess to the remaining traffic.

We will expand on this concept in Recipe 11.16.

See Also

Recipe 11.2; Recipe 11.6; Recipe 11.16