search
Ctrlk

CBWFQ

Class Based WFQ is configured using MQC. With CBWFQ, you use the same idea of Weighted Fair Queueingarrow-up-right, only this time, instead of using the IP_Priority to assign a weight for each flow, like in Flow-Based WFQarrow-up-right, you can classify traffic on different criteria and then assign a weight for each class. Class weight is derived from the bandwidth that is configured in the policy.

hashtag
Classification

See Classification using MQC.

hashtag
Defining a CBWFQ Policy

R(config)# policy-map CBWFQ-POLICY
! Up to 64 classes can be used in a CBWFQ Policy:
R(config-pmap)# class CLASS
R(config-pmap-c)# bandwidth {KBPS | [remaining] percent PERCENT} 
! In a single policy you can use only values in kbps or only values in percent, not both

The bandwidth can be expressed as an absolute value in kbps, or as a percentage of the interface bandwidth or of the available remaining bandwidth. By default, only 75% of the interface bandwidth can be assigned. The remaining 25% is used by the router for L2 overhead, routing traffic and best-effort traffic (class-default). This limit can be changed per interface, using:

R(config-if)# max-reserved-bandwidth PERCENT

The value used for bandwidth can be found using:

R# show interface INTERFACE | i BW
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

And can be changed with the interface command:

R(config-if)# bandwidth KBPS

Remember there is a “default-class” that matches all the previously unmatched traffic. The bandwidth for this traffic is taken from the remaining 25% of reserved bandwidth, or whatever is left after the max-reserved-bandwidth is set.

The “default-class” uses FIFO queuing. However, this can be changed to Fair Queuing with the command:

You can also configure the queue length for each class, using:

Once the queue-limit was reached, packets are dropped. You can use RED to prevent tail-drop.

hashtag
Low Latency Queuing (LLQ)

LLQ brings the feature of a strict priority queue to CBWFQ. The strict priority queue will always be serviced first. You can have more than one classes defined as priority classes, but they will all be assigned to the same priority queue. The other classes will be serviced in a normal CBWFQ fashion. In the event of congestion, policing is used, so that the priority queue will not use more than the bandwidth that was allocated. To define the priority queue, use:

In a class that was configured with the priority command, you can’t use the bandwidth or queue-limit commands. Furthermore, when using LLQ inside a policy, the other classes can only set bandwidth as relative remaining percent. The default setting for Burst size is used to handle voice-like non-bursty traffic, but this can be changed, by setting BURST size.

LLQ is not compatible with WRED, but can work together with IP RTP Priority, which takes precedence.

hashtag
Enabling CBWFQ on an interface

You enable CBWFQ on an interface by specifying a service-policy where at least one class uses the bandwidth or the priority command. Not every command is available in a policy that sets CBWFQ as the queueing mechanism. Also, these policies can only be applied in the outgoing direction. To configure CBWFQ, use:

You can only enable CBWFQ on interfaces with default Queuing. This means FIFO (high speed interfaces) or WFQ (serial interfaces with speeds lower than E1 – 2048kbps). To verify the configuration, use:

The interfaces configured for CBWFQ will also appear in the output of:

A more useful command is probably:

PreviousSPD – Selective Packet DiscardNextIP RTP Priority

Last updated