(queue). The side effect is that flows with small
packets (usually interactive flows) get much better service
because they do not need a lot of bandwidth. They need
low-delay handling, however, which they get because small
packets have a low finish time.
Content 4.4
Configuring WFQ 4.4.5 Benefits and Drawbacks of
WFQ The WFQ mechanism provides simple configuration (no
manual classification is necessary) and guarantees throughput
to all flows. It drops packets of the most aggressive flows.
Because WFQ is a standard queuing mechanism, most platforms and
most Cisco IOS versions support WFQ. As good as WFQ is, it does
have its drawbacks: - Multiple flows can end up in a
single queue.
- WFQ does not allow a network engineer
to manually configure classification. Classification and
scheduling are determined by the WFQ algorithm.
- WFQ
is supported only on links with a bandwidth less than or equal
to 2 Mb.
- WFQ cannot provide fixed guarantees to
traffic flows.
Figure summarizes these points.
Content 4.4 Configuring WFQ 4.4.6
Configuring WFQ Cisco routers automatically enable WFQ
on all interfaces that have a default bandwidth of less than
2.048 Mbps. The fair-queue command enables WFQ on
interfaces where it is not enabled by default or was previously
disabled. Figure shows the command syntax. fair-queue
[congestive-discard-threshold [dynamic-queues
[reservable-queues]]] fair-queue Parameters
Parameter Description
congestive-discard-threshold (Optional) Number of messages
allowed in the WFQ system. The default is 64 messages, and a
new threshold must be a power of 2 in the range from 16 to
4096. When a conversation reaches this threshold, new message
packets are discarded. dynamic-queues (Optional) Number
of dynamic queues used for best-effort conversations. Values
are 16, 32, 64, 128, 256, 512, 1024, 2048, and 4096.
reservable-queues (Optional) Number of reservable queues
used for reserved conversations in the range 0 to 1000. The
default is 0. Reservable queues are used for interfaces
configured for features such as RSVP. WFQ Maximum Limit
Configuration
The WFQ system will generally never
reach the hold-queue limit because the CDT limit starts
dropping the packets of aggressive flows in the software queue.
Under special circumstances, it might be possible to fill the
WFQ system. For example, a denial-of-service attack that floods
the interface with a large number of packets (each different)
could fill all queues at the same rate. Figure shows the
command syntax for the hold-queue max-limit
out command.
Content 4.4 Configuring
WFQ 4.4.7 Monitoring WFQ The show
interface command, as shown in Figure can be used to
determine the queuing strategy. The output also displays
summary statistics. The sample output in this figure shows that
there are currently no packets in the WFQ system. The system
allows up to 1000 packets (hold-queue limit) with a CDT of 64.
WFQ is using 256 queues. The maximum number of concurrent flows
(conversations, or active queues) is four. The show
queue command as shown in Figure is used to display the
contents of packets inside a queue for a particular interface,
including flow (conversation) statistics: - Queue depth
is the number of packets in the queue.
- Weight is 4096
/ (IP precedence + 1), or 32,384 / (IP precedence + 1),
depending on the Cisco IOS version.
- In the command
output, discards are used to represent the number of drops that
are due to the CDT limit.
- In the command output, tail
drops are used to represent the number of drops that are due to
the hold-queue limit.
Content 4.5
Configuring CBWFQ and LLQ 4.5.1 Combining
Queuing Methods Neither the basic queuing methods nor the
more advanced weighted fair queuing (WFQ) methods completely
solve the quality of service (QoS) problems resulting from
converged network traffic. The following problems remain:
- If only a priority queue is used for a voice-enabled
network, voice gets the needed priority. However, data traffic
would suffer.
- If only custom queuing (CQ) is used for
a voice-enabled network, data traffic is assured of some
bandwidth. However, voice traffic would suffer delays.
- If WFQ is used, voice still experiences delay even when
treated “fairly” by WFQ.
- In PQ and CQ, all of the
classification, marking, and queuing mechanisms are complicated
to use and time-consuming when applied on an
interface-by-interface basis.
Newer queuing
mechanisms combine the best aspects of existing queuing
methods. Low latency queuing (LLQ) is a combination of
class-based weighted fair queuing (CBWFQ), which assigns
weights according to bandwidth, and a priority system based on
class that gives voice the priority it requires while ensuring
that data is serviced efficiently. This solves the potential
starvation problem of the priority queue by including a
policing function based on the configured bandwidth of the
priority system. Figure illustrates the concept.
Content
4.5 Configuring CBWFQ and LLQ 4.5.2
Class-Based Weighted Fair Queuing Figure summarizes the
characteristics CBWFQ. CBWFQ extends the standard WFQ
functionality to provide support for user-defined traffic
classes. With CBWFQ, the user defines the traffic classes based
on match criteria, including protocols, 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
that class queue. After a class has been defined and its match
criteria have been formulated, you can assign characteristics
to the class. To characterize a class, you assign a bandwidth
and a maximum packet limit to it. The bandwidth assigned to a
class is the minimum 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 class queue. The queuing
guarantees the minimum bandwidth, but also gives a class
unlimited access to more bandwidth if more is available. After
a queue has reached its configured queue limit, enqueuing of
additional packets to the class causes tail drop or random
packet drop, depending on how the class policy is configured.
You can configure up to 64 discrete classes in a service
policy.
Content 4.5 Configuring CBWFQ and
LLQ 4.5.3 CBWFQ Architecture, Classification
and Scheduling CBWFQ supports multiple class maps to
classify traffic into its corresponding FIFO queues as shown in
Figure . CBWFQ classes use tail drop unless you explicitly
configure a 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 the WRED packet drop instead
of tail drop for one or more classes in a policy map, you must
ensure that WRED is not configured for the interface to which
you attach that service policy. 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 queuing method. Be cautious when configuring
CBWFQ on ATM interfaces. Enabling CBWFQ on an ATM permanent
virtual circuit (PVC) does not override the default queuing
method. Unspecified bit rate (UBR) connections do not support
CBWFQ. Classification
You can use any classification
option for CBWFQ, depending on availability in the Cisco IOS
version, support on the selected interface, and encapsulation.
Figure lists relevant considerations. The following examples
illustrate some of the limitations regarding classification
options: - Matching on Frame Relay discard-eligible bits
can be used only on interfaces with Frame Relay
encapsulation.
- Matching on Multiprotocol Label