WFQ Queuing for the Class-Default
The
following example shows the configuration of WFQ queuing within
the default class. The number of dynamic queues is set to 1024,
and the discard threshold is set to 50. policy-map A
class
A
bandwidth 1000
class class-default
fair-queue
1024
queue-limit 50 Example: Using CBWFQ to Guarantee
Bandwidth
The example configuration in Figure shows how
CBWFQ guarantees bandwidth to each of the two classes.
Monitoring CBWFQ
As shown in Figure , the show
policy-map interface command displays all service policies
applied to the interface. As an example, a policy including
policing parameters, queuing mechanism, bandwidth and
statistics is applied on the FastEthernet 0/0 interface. The
class1 class map classifies any traffic matched by ACL 101 as
CBWFQ. Also, bandwidth of 3000 kbps is displayed. Traffic not
matching the configured classification (class1 and class2) will
be placed in the class-default class map. The sample output of
this command is shown in Figure .
Content 4.5
Configuring CBWFQ and LLQ 4.5.5 Low Latency
Queuing Although WFQ provides a fair share of bandwidth to
every flow and provides fair scheduling of its queues, it
cannot provide guaranteed bandwidth and low delay to selected
applications. For example, voice traffic may still compete with
other aggressive flows in the WFQ queuing system because the
WFQ system lacks priority scheduling for time-critical traffic
classes. For CBWFQ, the weight for a packet belonging to a
specific class is derived from the bandwidth that you assigned
to the class when you configured it. Therefore, the bandwidth
assigned to the packets of a class determines the order in
which packets are sent. All packets are serviced fairly based
on this internal weight; no class of packets may be granted
strict priority. This scheme poses problems for voice traffic,
which is largely intolerant of delay, especially variation in
delay. For voice traffic, variations in delay introduce
irregularities of transmission heard as jitter in the
conversation. LLQ reduces the jitter in voice conversations. To
enqueue real-time traffic to a strict-priority queue, you
configure the priority command for the class after you
specify the named class within a policy map. (Classes to which
the priority command is applied are considered priority
classes.) Within a policy map, you can give one or more classes
priority status. When multiple classes within a single policy
map are configured as priority classes, all traffic from these
classes is enqueued to the same, single, strict priority
queue. Figure summarizes these points.
Content 4.5
Configuring CBWFQ and LLQ 4.5.6 LLQ
Architecture and Benefits LLQ extends CBWFQ by adding
strict-priority queuing. Strict-priority queuing allows
delay-sensitive data such as voice to be removed from the queue
and sent first. Voice packets that enter the LLQ system are
sent to the priority queue of the LLQ system, where they have a
fixed bandwidth allocation and where they are served first.
Data packets enter the CBWFQ system directly where specifically
assigned weights determine how they are treated. Figure
illustrates the process. Without LLQ, CBWFQ provides weighted
queuing based on defined per-class bandwidth with no
strict-priority queue available for real-time traffic. CBWFQ
allows you to define traffic classes and then assign
characteristics to that class. For example, you can designate
the minimum bandwidth delivered to the class during
congestion. LLQ Benefits
Figure shows the benefits
of LLQ. One benefit of LLQ is having a consistent configuration
across all media types, irrespective of the media used. Also,
using LLQ as the entrance criteria for a class can be as
granular as you like because you define it by an ACL. You are
not limited, as with the IP RTP Priority feature, to a simple
UDP port range. VoIP traffic uses a well-known UDP port range,
16384-32767. While the actual ports used are dynamically
negotiated between end-devices or gateways, all Cisco VoIP
products use the same port range.
Content 4.5
Configuring CBWFQ and LLQ 4.5.7 Configuring and
Monitoring LLQ When you specify the priority command
for a class, you can use the bandwidth argument to specify the
maximum bandwidth in kilobits per second. You use this
parameter to specify the maximum amount of bandwidth allocated
for packets belonging to the class configured with the
priority command. The bandwidth parameter both
guarantees bandwidth to the priority class and restrains the
flow of packets from the priority class. Figure shows the
command syntax for these operations. priority
{bandwidth | percent percentage}
[burst] priority Parameters
Parameter Description bandwidth Guaranteed
allowed bandwidth, in kilobits per second, for the priority
traffic. The amount of guaranteed bandwidth varies according to
the interface and platform in use. Beyond the guaranteed
bandwidth, the priority traffic will be dropped in the event of
congestion to ensure that the nonpriority traffic is not
starved. percent Specifies that the amount of guaranteed
bandwidth will be a percentage of available bandwidth.
percentage Used in conjunction with the percent
keyword; specifies the percentage of the total available
bandwidth to be set aside for the priority class. The
percentage can be a number from 1 to 100. (By default, only 75
percent can be reserved.) burst (Optional) Specifies the burst
size, in bytes. The range of the burst size is 32 to 2,000,000
bytes. The burst size allows temporary bursting of traffic
above the maximum limit after a period of inactivity. The
default burst value is computed as 200 ms of traffic at the
configured bandwidth rate. When congestion occurs, traffic
destined for the priority queue is metered to ensure that the
bandwidth allocation configured for the class to which the
traffic belongs is not exceeded. Priority traffic metering has
the following qualities: - Priority traffic is metered
only under conditions of congestion. When the device is not
congested, the priority-class traffic is allowed to exceed its
allocated bandwidth. When the device is congested, the
priority-class traffic above the allocated bandwidth is
discarded.
- Metering is performed on a per-packet
basis, and tokens are replenished as packets are sent. If not
enough tokens are available to send the packet, the packet is
dropped.
- Metering restrains priority traffic to its
allocated bandwidth to ensure that nonpriority traffic, such as
routing packets and other data, is not starved.
With
metering, the classes are policed and rate-limited
individually. That is, although a single policy map might
contain four priority classes, all of which are enqueued in a
single priority queue, they are treated as separate flows with
separate bandwidth allocations and constraints. Keep the
following guidelines in mind when using the priority
command: - Layer 2 encapsulations are accounted for in
the amount of bandwidth specified with the priority
command. Therefore, ensure that a bandwidth allocation is
configured with room for the Layer 2 overhead.
- Use the
priority command for VoIP on serial links and ATM
PVCs.
Figure shows a configuration example where the
VoIP traffic class, classified based on the IP precedence of 5,
is queued in the LLQ priority queue. The priority class is
guaranteed but is also limited to 10 percent of interface
bandwidth. Monitoring LLQ
The show policy-map
interface command displays the packet statistics of all
classes that you configured for all service policies on the
specified interface. Figure shows a sample output. The “Key
Fields in the show policy-map interface Command Output”
table describes some of the key fields in the command output.
Key Fields in the show policy-map interface Command
Output
Field Description Class-map