Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

QOS :- The unknown facts of CBWFQ

The unknown facts of CBWFQ

CBWFQ allows user-defined traffic classes as compared to standard WFQ. WFQ applies weights to identified traffic to classify traffic into conversations and allocate bandwidth to each conversation. WFQ is enabled by default on all interfaces less than or equal to 2.048 Mbps.

For CBWFQ, traffic classes are defined matching protocols, ACLs and input interfaces. Packets satisfying the match criteria for a class constitutes the traffic for that class. A FIFO queue is reserved for each class, and traffic belonging to the class is directed to the queue for that class. A maximum of 64 classes/queues can be defined by a user in CBWFQ.

The characteristics of a particular class include bandwidth of the class, weight (derived from the "bandwidth" of the class), maximum packet limit and even queue limit.

If a default class is configured with bandwidth command, all unclassified traffic is put into a single FIFO queue and given treatment according to the configured bandwidth.

If a default class is configured with a fair-queue command, all unclassified traffic is flow classified and given best-effort treatment.

The mechanics behind "bandwidth" command:

    1) CBWFQ shares interface bandwidth inversely proportional to flow weights.
        If there are N number of flows and flow(i) has weight value Weight(i), then CBWFQ guarantees flow(i) the following share of bandwidth:
            Share(i) = ( Weight(1) + .... + Weight(i) + ... + Weight(N) )/ Weight(i)
    2) CBWQF assigns weights to dynamic conversations (non-user defined classes) using the formula-

            Weight(i) = 32384/ (IP_Prec(i) + 1)

    3) CBWFQ assigns weights to user-defined classes using the formula-

            Weight(i) = Constant * Interface_BW / Class_BW if the bandwidth of the class is configured explicitly
            Weight(i) = Constant * 100 / BW_percent is the bandwidth of the class is configured as bandwidth percent or bandwidth remaining percent commands.

The Constant depends on the number of flow queues in WFQ.

Number of flows
Constant Value
16 64
32 64
64 57
128 30
256 16
512 8
1024 4
2048 2
4096 1

The queues are allocated to different classes as below- if N is the number of dynamic flows of CBWFQ.

Flow / conversation number Weight Description
Below 2N Weight(i) = 32384/ (IP_Prec(i) + 1) Dynamic Queues (e.g. non-user defined classes
2N - 2N+7 Weight(i) = 1024 Link Queues (e.g. routing updates, Keepalives)
2N+8 Weight(i) = 0 LLQ or Priority Queue.
Above 2N+8 Weight(i) = Constant * Intf_BW/ Class_BW
  Weight(i) = Constant * 100 / BW_percent
User defined classes

I'd just like to point out a couple of facts for completion

1. The requlting sequence numbering is what actually defines the algorithm's decision of what to send and what not to send from the saturated queues. Without sequencing, the algorithm would work purely as a strict priority queuing mechanism.

2. Developers "trick" for LLQ's in the CBWFQ case also has a certain impact of priority queue behavior. Weight 0 means that resulting sequence number will always be zero, since zero times anything is zero. But when the queue crosses the set threshold (e.g. flow over 128Kbps when "priority 128" is set), the queue is actually not policed on software platforms, but some high Weight is set, probably using "32384/ (IP_Prec(i) + 1)". Therefore the queue is treated very unprefferentially, but it is not policed

3. This very well points to the queue starvation, when "bandwidth" parameter is not defined. Without "bandwidth" parameter, the weight is very high, and makes the packet departure very unlikely