queueing (WFQ) creates a queue for every class for which a class map is
defined. Packets that satisfy the match criterion for a class accumulate in the
queue reserved for the class until they are sent, which occurs when the queue
is serviced by the fair queueing process. When the maximum packet threshold
that you defined for the class is reached, enqueueing of any further packets to
the class queue causes tail drop or, if WRED is configured for the class
policy, packet drop to take effect.
Cisco IOS Release 15.0(1)S1
Prior to Cisco
IOS Release 15.0(1)S1, if no queue limit was configured, the queue limit for
the current class was based on the parent values for available buffers and
current class allocated bandwidth. In the implicit WRED min/max scenario,
thresholds were calculated from the available buffers.
calculated from the available aggregate queue limit for each class. The WRED
min/max threshold values would not be adjusted if there was a user-defined
queue-limit configuration. The min/max threshold would still be derived from
the “visible_bw” value seen by this traffic class. The WRED functionality could
fail because of this inconsistent qlimit and min/max threshold calculation.
Cisco IOS Release 15.0(1)S1, the queue limit is always calculated from the
parent queue limit and allocated bandwidth in the current class. When you use
command to explicitly configure the values, these values are used as the
definition of the queue limit.
To ensure optimum
functionality, use the
command to configure the proper min/max threshold for each WRED class based on
the queue-limit configuration.
Cisco IOS Release 15.2(2)T
Prior to Cisco IOS
Release 15.2(2)T, if the optional unit of measure was not specified, the unit
of measure used was packets. Beginning in Cisco IOS Release 15.2(2)T, if the
optional unit of measure is not specified, the unit used depends on the
Queue Limits Set by the bandwidth Command
command with the modular quality of service (QoS) CLI) (MQC) to specify the
bandwidth for a particular class. When used with MQC, the
command has a default queue limit for the class. This queue limit can be
modified using the
command, thereby overriding the default set by the
command to modify the default queue limit is especially important for
higher-speed interfaces, in order to meet the minimum bandwidth guarantees
required by the interface.
Prior to the
deployment of the Hierarchical Queueing Framework (HQF), the default maximum
queue limit on a subinterface was 512 if no hold queue was configured on the
As part of HQF,
this restriction was removed beginning in Cisco IOS Release 15.0(1)M5. Now the
maximum queue limit can be set as high as the hold-queue size on the main
If no hold queue
is configured on the main interface, the aggregate queue limit can go up to
1000. If the hold-queue is explicitly configured on the main interface, then
the aggregate queue limit can go up to the hold-queue value. There is no limit
configurable hold-queue value of 4096 was increased to 240,000 for users who
want to configure higher aggregate queue-limit values. However, configuring
high queue-limit and hold-queue values is not recommended.
Values configured using
command override those configured using the