Switching (MPLS) experimental (EXP) bits has no
effect if MPLS is not enabled. Matching on
Inter-Switch Link (ISL) priority bits has no effect if ISL is
not used. It is important to note that CBWFQ is
configured using Cisco Modular QoS CLI (MQC). The
classifications that can be configured depend on the Cisco IOS
version and the type of interface that is configured.
Scheduling Mechanisms
The CBWFQ mechanism calculates
weights based on the available bandwidth. These weights are
then used by the CBWFQ scheduling mechanism to dispatch the
packets. You can configure bandwidth guarantees by using one of
the following commands: - The bandwidth command
allocates a fixed amount of bandwidth by specifying the amount
in kilobits per second. The reserved bandwidth is subtracted
from the available bandwidth of the interface where the
service policy is used. The allocated bandwidth must also be
within the configured reservable limit (75 percent of interface
bandwidth by default).
- The bandwidth percent
command can be used to allocate a percentage of the total
available bandwidth of an interface. The total interface
bandwidth is defined by using the bandwidth interface
command. It is recommended that the bandwidth command
reflect the real speed of the link. The allocated bandwidth is
subtracted from the available bandwidth of the interface where
the service policy is used.
- The bandwidth remaining
percent command is used to allocate the amount of
guaranteed bandwidth based on a relative percentage of
available bandwidth. When the bandwidth remaining
percent command is configured, hard bandwidth guarantees
may not be provided, and only relative per-class bandwidths are
assured. That is, class bandwidths are always proportionate to
the specified percentages of the interface bandwidth. When the
link bandwidth is fixed, class bandwidth guarantees are in
proportion to the configured percentages. If the link bandwidth
is unknown or variable, class bandwidth guarantees in kilobits
per second cannot be computed
A single service
policy cannot mix the bandwidth (fixed, in kilobits per
second) and bandwidth percent commands (except with
strict-priority queues). The weights needed for scheduling are
calculated by the CBWFQ process based on the configured
bandwidth or its percentage. Calculating Available
Bandwidth
The available bandwidth displayed by the
show interface command is calculated by subtracting all
fixed bandwidth reservations from the default 75 percent of the
configured bandwidth of an interface. The available bandwidth
is calculated with the following formula as shown in :
Bandwidthavail = Bandwidth * MaxReservable – SUM (all fixed
guarantees) Properly provisioning the network bandwidth is a
major component of successful network design. You can calculate
the required bandwidth by adding the bandwidth requirements for
each major application (for example, voice, video, and data).
The resulting sum represents the minimum bandwidth requirement
for any given link, and it should not exceed 75 percent of the
total available bandwidth for the link. The remaining 25
percent is used for other overhead, including Layer 2 overhead,
routing traffic, and best-effort traffic. 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 such as
Layer 2 keepalive messages, as well as the class default
traffic. If all of the bandwidth is not allocated, the
remaining bandwidth is proportionately allocated among the
classes based on the configured bandwidth of the classes.
CBWFQ Benefits and Drawbacks
CBWFQ allows you to
define traffic classes based on custom-defined match criteria
such as ACLs, input interfaces, and protocol type. Figure shows
the benefits and drawback of CBWFQ described as follows:
- Classification: CBWFQ allows custom-defined
classifications based on many parameters, such as ACLs, input
interfaces, byte count, and so on.
- Bandwidth
allocation: CBWFQ allows you to specify the exact minimum
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 the flow-based WFQ. Flow-based
WFQ applies weights to traffic to classify it into
conversations and determines 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 IP precedence levels.
- Finer granularity and scalability: CBWFQ allows you
to define what constitutes a class based on criteria that
exceed the confines of flow. You do not need to maintain
traffic classification on a per-flow basis. Moreover, you can
configure up to 64 discrete classes in a service policy.
The drawback is that voice traffic can still suffer from
unacceptable delays if you use CBWFQ as the only queuing
mechanism.
Content 4.5 Configuring CBWFQ and
LLQ 4.5.4 Configuring and Monitoring CBWFQ
The bandwidth command within the policy-map
class configuration command is used to specify or modify
the bandwidth allocated for a class belonging to a policy map.
Figures and show the command syntax to use. All classes
belonging to one policy map should use the same type of
bandwidth guarantee, in kilobits per second, percentage of
interface bandwidth, or percentage of available bandwidth.
Configuring bandwidth in percentages is most useful when the
underlying link bandwidth is unknown or the relative class
bandwidth distributions are known. bandwidth
{bandwidth | percent percent |
remaining percent percent} bandwidth
Parameters
Parameter Description
bandwidth Amount of bandwidth, in kilobits per second, to
be assigned to the class. percent percent Amount of
guaranteed bandwidth, based on an absolute percentage of
available bandwidth. The percentage can be a number from 1 to
100. (By default, only 75 percent can be reserved.) remaining
percent percent Amount of guaranteed bandwidth, based on
a relative percentage of available bandwidth. The percentage
can be a number from 1 to 100. These restrictions apply to the
bandwidth command: - If the percent
keyword is used, the sum of the class bandwidth percentages
cannot exceed 100 percent.
- The amount of bandwidth
configured should be large enough to accommodate Layer 2
overhead.
- A policy map can have all the class
bandwidths specified in kilobits per second or in percentages
but not a mix of both. However, the unit for the
priority command in the priority class can be different
from the bandwidth unit of the low-priority class.
The default queue limit of 64 packets can be changed using the
queue-limit command. It is recommended that you not
change the default value. The default class can be selected by
specifying the class-default name of the class. The
default class supports two types of queuing: a FIFO queue
(default) or a flow-based WFQ system. Both types can be
combined with WRED. A FIFO queue can also get a minimum
bandwidth guarantee. Example: Configuration of FIFO Queuing
for the Class-Default
This example shows the
configuration of FIFO queuing within the default class. The
default class is also guaranteed 1 Mbps of bandwidth, and the
maximum queue size is limited to 40 packets. policy-map A
class A
bandwidth 1000
class class-default
bandwidth 1000
queue-limit 40 Example: Configuration of