Class-based WFQ

CBWFQ extends the WFQ functionality so it can support user-defined classes. Here are a few key points I have found about CBWFQ.

• CBWFQ is configured using MQC
• A mechanism that enables the users to guarantee a minimum amount of bandwidth
• CBWFQ reserves multiple FIFO queues in the WFQ system
• The default queue limit is 64, after which packets will be tail dropped.
• WRED can be configured in combination with CBWFQ to prevent congestion
• CBWFQ guarantees bandwidth according to weights that are assigned to the different classes within the MQC.
• In CBWFQ, weights are defined based on bandwidth, bandwidth percent and bandwidth remaining percent keywords.
• When applying the policy-map to a given interface, weights assigned to the classes CANNOT be mixed.
• By default, only 75% of the bandwidth can be defined. This can be modified using “max-reserved bandwidth” command.

It is important to understand that CBWFQ guarantees the minimum amount of bandwidth to the specified traffic.

Why Use CBWFQ?

Here are some general factors you should consider in determining whether you need to configure CBWFQ:

• Bandwidth allocation. CBWFQ allows you to specify the exact amount of bandwidth to be allocated for a specific class of traffic. Taking into account available bandwidth on the interface, you can configure up to 64 classes and control distribution among them, which is not the case with flow-based WFQ. Flow-based WFQ applies weights to traffic to classify it into conversations and determine how much bandwidth each conversation is allowed relative to other conversations. For flow-based WFQ, these weights, and traffic classification, are dependent on and limited to the seven IP Precedence levels.
• Coarser granularity and scalability. CBWFQ allows you to define what constitutes a class based on criteria that exceed the confines of flow. CBWFQ allows you to use ACLs and protocols or input interface names to define how traffic will be classified, thereby providing coarser granularity. You need not maintain traffic classification on a flow basis. Moreover, you can configure up to 64 discrete classes in a service policy. 

EXAMPLE

Let’s guarantee a minimum of 2Mbps to all HTTP traffic using CBWFQ.

The easiest way to achieve this will be the use of NBAR. Let’s create a class-map and match all HTTP traffic.

class-map HTTP

match protocol http

Let’s create a policy-map CBWFQ and guarantee 2Mbps to it

Policy-map CBWFQ

class HTTP

bandwidth 2000

This example shows the use of bandwidth command but we can also use the bandwidth percent and bandwidth remaining percent to achieve CBWFQ. Doesn’t matter which option you use, they key is to use the same weight type within a policy-map.