Refer to the exhibit. Based on the configuration shown, which queuing mechanism has been
configured on interface serial.1/0?

A.
PQ

B.
CQ

C.
WFQ

D.
LLQ

E.
CBWFQ

Explanation:
Class-based weighted fair queueing (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. A queue is reserved for each class,
and traffic belonging to a class is directed to the queue 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 the class.
After a queue has reached its configured queue limit, enqueuing 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
Weighted Random Early Detection (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 Transmission Control Protocol (TCP) or User Datagram Protocol
(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, which extends the standard WFQ fair queueing, 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:

• Defining traffic classes to specify the classification policy (class maps).
This process determines how many types of packets are to be differentiated from one another.
• Associating policies—that is, class characteristics—with each traffic class (policy maps).
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.
• Attaching policies to interfaces (service policies).
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

http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/cbwfq.html