Class-Based Weighted Fair Queuing (Congestion Management and Queuing)

CBWFQ addresses some of the limitations of PQ, CQ, and WFQ. CBWFQ allows creation of user-defined classes, each of which is assigned to its own queue. Each queue receives a user-defined (minimum) bandwidth guarantee, but it can use more bandwidth if it is available. In contrast to PQ, no queue in CBWFQ is starved. Unlike PQ and CQ, you do not have to define classes of traffic to different queues using complex access lists. WFQ does not allow creation of user-defined classes, but CBWFQ does; moreover, defining the classes for CBWFQ is done with class maps, which are flexible and user friendly, unlike access lists. Similar to WFQ and CQ, CBWFQ does not address the low-delay requirements of real-time applications such as VoIP. The next section discusses LLQ, which through the use of a strict priority queue provides a minimum but policed bandwidth, plus a low-delay guarantee to real-time applications.

Figure 4-5 shows a CBWFQ with three user-defined classes. As each packet arrives, it is assigned to one of the queues based on the class to which the packet belongs. Each queue has a reserved bandwidth, which is a bandwidth guarantee.

Figure 4-5 CBWFQ

CBWFQ


CBWFQ can create up to 64 queues, one for each user-defined class. Each queue is a FIFO queue with a defined bandwidth guarantee and a maximum packet limit. If a queue reaches its maximum packet limit, it incurs tail drop. To avoid tail drop, you can apply WRED to a queue. Note that if you apply WRED to one (or more) of the queues in CBWFQ, you cannot apply WRED directly to the interface, too. In addition to the 64 queues mentioned, a queue called class-default is always present. Packets that do not match any of the defined classes are assigned to this queue. The 64 queues and the class-default queue are all FIFO queues, but you can configure the class-default queue (but not the others) to be a WFQ. In 7500 series routers (and maybe others, by the time you read this topic), you can configure all queues to be WFQ. Just as you can apply WRED to any of the queues, you can apply WRED to the class-default queue. The class-default queue, if you do not specify a reserved bandwidth for it, uses any remaining bandwidth of the interface.

Classification, Scheduling, and Bandwidth Guarantee

Classification of traffic for the purpose of CBWFQ is done using Cisco IOS modular command-line interface (MQC), specifically, using class maps. The options available for classification are based on the IOS version. Furthermore, relevance of certain match criteria depends on the interface, its encapsulation type, and any other options that might have been implemented on that interface. For example, you can match the Frame Relay DE (discard eligible) bit only on a Frame Relay interface. You should match MPLS EXP bits only if MPLS-IP packets are received; matching CoS bits only makes sense on 802.1Q trunk connections.

Scheduling and the bandwidth guarantee offered to each queue within a CBWFQ system is based on a weight that is assigned to it. The weight, in turn, is computed by the IOS based on the value you enter for bandwidth, bandwidth percent, or bandwidth remaining percent on the class that is assigned to the queue:

■ Bandwidth—Using the bandwidth command, you allocate (reserve) a certain amount of bandwidth (Kbps) to the queue of a class. This bandwidth amount is subtracted (taken) from the available/unreserved portion of the maximum reserved bandwidth of the interface. The maximum reserved bandwidth of an interface is by default equal to 75 percent of the total bandwidth of that interface, but it is modifiable. Maximum reserved bandwidth is set/modified using the max-reserved-bandwidth command in the interface configuration mode.

■ Bandwidth percent—Using the bandwidth percent command, you allocate/reserve an amount of bandwidth equal to a certain percentage of the interface bandwidth, to the queue of a class. Whatever this amount of bandwidth turns out to be, it is subtracted from the available/unreserved portion of the maximum reserved bandwidth of the interface. The Cisco IOS determines the bandwidth of the serial interfaces based on the configured value using the bandwidth statement.

■ Bandwidth remaining percent—Using the bandwidth remaining percent command, you allocate a certain percentage of the remaining available bandwidth of the interface to the queue of a class. Whatever this amount of bandwidth turns out to be, you subtract it from the available/unreserved portion of the maximum reserved bandwidth of the interface.

NOTE When you configure the reserved bandwidth for each traffic class in a policy map, you cannot use the bandwidth command for one class and the bandwidth percent command on another class. In other words, for all classes within a policy map, you must use either the bandwidth command or the bandwidth percent command, but not a mix of the two commands.

From the total bandwidth of an interface, a certain percentage is available for reservation; this percentage is dictated by the value of a parameter called max-reserved-bandwidth on that interface. The default value of maximum reserved bandwidth is 75, meaning that 75 percent of the interface bandwidth can be reserved. However, as bandwidth reservation is made for different queues (and possibly flows or tunnels), the amount of bandwidth remaining for new reservations naturally diminishes. You can calculate the available bandwidth (available for reservation) based on this formula:

Available bandwidth = (interface bandwidth x maximum reserved bandwidth) – (sum of all existing reservations)

Note that the default value of 75 for maximum reserved bandwidth leaves 25 percent of interface bandwidth for network overhead, including Layer 2 overhead such as CDP. You can modify the default value for maximum reserved bandwidth, but you are cautioned to do so only if you are aware of the consequences.

Benefits and Drawbacks of CBWFQ

The main benefits of CBWFQ are as follows:

■ It allows creation of user-defined traffic classes. These classes can be defined conveniently using MQC class maps.

■ It allows allocation/reservation of bandwidth for each traffic class based on user policies and preferences.

■ Defining a few (up to 64) fixed classes based on the existing network applications and user policies, rather than relying on automatic and dynamic creation of flow-based queues (as WFQ does), provides for finer granularity and scalability.

The drawback of CBWFQ is that it does not offer a queue suitable for real-time applications such as voice or video over other IP applications. Real-time applications expect low-delay guarantee in addition to bandwidth guarantee, which CBWFQ does not offer.

Configuring and Monitoring CBWFQ

The first step in configuring CBWFQ is defining traffic classes, which is done using class maps. Example 4-3 shows two traffic classes: transaction-based and business-application. Any packet that matches access list 100 is classified as transaction-based, and any packet that matches access list 101 is classified as business-application.

Example 4-3 Class Maps Define Traffic Classes

Class Maps Define Traffic Classes

Example 4-4 shows a policy map called Enterprise-Policy. This policy creates a queue with a bandwidth guarantee of 128 Kbps and a maximum packet limit (queue limit) of 50 for the traffic classified as transaction-based. Enterprise-Policy creates a second queue with a bandwidth guarantee of 256 Kbps and a maximum packet limit (queue limit) of 90 for the traffic classified as business-application. The default value for the queue-limit command is 64. Any traffic that does not belong to transaction-based or business-application classes is assigned to the queue created for the class-default class. The fair-queue 16 command applied to the class-default class changes its queue discipline from FIFO to WFQ, and it sets the maximum number of dynamic queues for WFQ to 16. You can set the number of dynamic queues from 16 to 4096 (inclusive), but the number has to be a power of 2. Class-default has no bandwidth guarantees in this example.

Example 4-4 Policy Map


Policy Map

Example 4-5 shows the three alternative commands to reserve bandwidth for the queues of a CBWFQ. Remember that within a policy map, one or the other option can be used, but you cannot mix them within a single policy map.

Example 4-5 Three Alternative Ways to Reserve Bandwidth for CBWFQ Queues

Three Alternative Ways to Reserve Bandwidth for CBWFQ Queues

Example 4-6 shows sample output of the show policy-map interface interface command. This command displays information about the policy map applied to an interface using the service-policy command. You can see the classes, bandwidth reservations, queuing disciplines, and traffic statistics for each class, on the output.

Example 4-6 Sample Output of the show policy-map interface Command

Sample Output of the show policy-map interface Command

Next post:

Previous post: