CBWFQ extends the standard WFQ functionality to provide support for user-defined traffic classes. For CBWFQ, you define traffic
classes based on match criteria including protocols, access control lists (ACLs), and input interfaces. Packets satisfying
the match criteria for a class constitute the traffic for that class.
Once a class has been defined according to its match criteria, you can assign it characteristics. To characterize a class,
you assign it bandwidth, weight, and maximum packet limit. The bandwidth assigned to a class is the guaranteed bandwidth delivered
to the class during congestion.
To characterize a class, you also specify the queue limit for that class, which is the maximum number of packets allowed to
accumulate in the queue for the class. Packets belonging to a class are subject to the bandwidth and queue limits that characterize
After a queue has reached its configured queue limit, enqueueing of additional packets to the class causes tail drop or packet
drop to take effect, depending on how class policy is configured.
Tail drop is used for CBWFQ classes unless you explicitly configure policy for a class to use WRED to drop packets as a means
of avoiding congestion. Note that if you use WRED packet drop instead of tail drop for one or more classes comprising a policy
map, you must ensure that WRED is not configured for the interface to which you attach that service policy.
If a default class is configured with the bandwidth policy-map class configuration command, all unclassified traffic is put into a single queue and given treatment according
to the configured bandwidth. If a default class is configured with the fair-queue command, all unclassified traffic is flow classified and given best-effort treatment. If no default class is configured,
then by default the traffic that does not match any of the configured classes is flow classified and given best-effort treatment.
Once a packet is classified, all of the standard mechanisms that can be used to differentiate service among the classes apply.
Flow classification is standard WFQ treatment. That is, packets with the same source IP address, destination IP address, source
TCP or UDP port, or destination TCP or UDP port are classified as belonging to the same flow. WFQ allocates an equal share
of bandwidth to each flow. Flow-based WFQ is also called fair queueing because all flows are equally weighted.
For CBWFQ, the weight specified for the class becomes the weight of each packet that meets the match criteria of the class.
Packets that arrive at the output interface are classified according to the match criteria filters you define, then each one
is assigned the appropriate weight. The weight for a packet belonging to a specific class is derived from the bandwidth you
assigned to the class when you configured it; in this sense the weight for a class is user-configurable.
After the weight for a packet is assigned, the packet is enqueued in the appropriate class queue. CBWFQ uses the weights assigned
to the queued packets to ensure that the class queue is serviced fairly.
Configuring a class policy--thus, configuring CBWFQ--entails these three processes:
This process determines how many types of packets are to be differentiated from one another.
This process entails configuration of policies to be applied to packets belonging to one of the classes previously defined
through a class map. For this process, you configure a policy map that specifies the policy for each traffic class.
This process requires that you associate an existing policy map, or service policy, with an interface to apply the particular
set of policies for the map to that interface.
CBWFQ Bandwidth Allocation
The sum of all bandwidth allocation on an interface cannot exceed 75 percent of the total available interface bandwidth. The
remaining 25 percent is used for other overhead, including Layer 2 overhead, routing traffic, and best-effort traffic. Bandwidth
for the CBWFQ class-default class, for instance, is taken from the remaining 25 percent. However, under aggressive circumstances
in which you want to configure more than 75 percent of the interface bandwidth to classes, you can override the 75 percent
maximum sum allocated to all classes or flows using the max-reserved-bandwidth command. If you want to override the default 75 percent, exercise caution and ensure that you allow enough remaining bandwidth
to support best-effort and control traffic, and Layer 2 overhead.
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.
CBWFQ and RSVP
RSVP can be used in conjunction with CBWFQ. When both RSVP and CBWFQ are configured for an interface, RSVP and CBWFQ act independently,
exhibiting the same behavior that they would if each were running alone. RSVP continues to work as it does when CBWFQ is not
present, even in regard to bandwidth availability assessment and allocation.
Configuring CBWFQ on a physical interface is only possible if the interface is in the default queueing mode. Serial interfaces
at E1 (2.048 Mbps) and below use WFQ by default--other interfaces use FIFO by default. Enabling CBWFQ on a physical interface
overrides the default interface queueing method.
If you configure a class in a policy map to use WRED for packet drop instead of tail drop, you must ensure that WRED is not
configured on the interface to which you intend to attach that service policy.