Usage Guidelines
Weighted Fair Queueing
Weighted fair 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.
Changes in 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.
Thresholds were 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.
Beginning in 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 the queue-limit command to explicitly configure the values, these values are used as the definition of the queue limit.
To ensure optimum functionality, use the queue-limit command to configure the proper min/max threshold for each WRED class based on the queue-limit configuration.
Changes in 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 platform.
Overriding Queue Limits Set by the bandwidth Command
Use the bandwidth command with the modular quality of service (QoS) CLI) (MQC) to specify the bandwidth for a particular class. When used with MQC, the bandwidth command has a default queue limit for the class. This queue limit can be modified using the queue-limit command, thereby overriding the default set by the bandwidth command.
Note |
Using the queue-limit 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 main interface.
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 interface.
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 per subinterface.
The maximum 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.