Table Of Contents
Class-Based Weighted Fair Queueing and Weighted Random Early Detection
Resource Reservation Protocol Interaction with CBWFQ
Configuring a Service Policy in the Policy Map
Configuring a Service Policy with WRED in the Policy Map
Configuring a Service Policy Including IP Precedence Using WRED
Modifying the Bandwidth for an Existing Service Policy
Modifying the Queue Limit for an Existing Service Policy
Monitoring and Maintaining CBWFQ and WRED
Attaching a Service Policy to an Interface
random-detect exponential-weighting-constant
Class-Based Weighted Fair Queueing and Weighted Random Early Detection
The Class-Based Weighted Fair Queueing (CBWFQ) and Weighted Random Early Detection (WRED) features bring CBWFQ and WRED to both Versatile Interface Processor (VIP) and non-VIP platforms.
Note:
These features were previously called by the following names:
•
Class-Based Weighted Fair Queueing and Weighted Random Early Detection for the VIP Using the Modular QoS CLI
•
These features may be referred to by those names in some Cisco documentation.
Feature Specifications for the Class-Based Weighted Fair Queueing and Weighted Random Early Detection
12.1(5)T
This feature was introduced.
12.0(26)S
This feature was integrated into Cisco IOS Release 12.0(26)S for the Cisco 7200 and 7500 series routers.
The name of the feature changed from Distributed Class-Based Weighted Fair Queueing and Distributed Weighted Random Early Detection to Class-Based Weighted Fair Queueing and Weighted Random Early Detection.
The fair-queue (policy-map class) command was enhanced to enable fair queuing in every class (not just the default class) for VIP and non-VIP platforms.
The hierarchical queuing feature was added for the Cisco 7200 series routers, which allows you to enable queuing in child policies without enabling shaping in parent policies.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
Feature Overview
CBWFQ extends the standard WFQ functionality to provide support for user-defined traffic classes on both VIP and non-VIP platforms. These user-defined traffic classes are configured in the Modular Quality of Service Command-Line Interface (Modular QoS CLI). For information on configuring QoS with the Modular QoS CLI, see the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
The maximum number of packets allowed to accumulate in a traffic class queue is called the queue limit and is specified with the queue-limit command when you create a service policy with the policy-map command. Packets belonging to a traffic class are subject to the guaranteed bandwidth allocation and the queue limits that characterize the traffic class.
After a queue has reached its configured queue limit, enqueuing of additional packets to the traffic class causes tail drop or WRED drop to take effect, depending on how the service policy is configured. (Tail drop is a means of avoiding congestion that treats all traffic equally and does not differentiate between classes of service. Queues fill during periods of congestion. When the output queue is full and tail drop is in effect, packets are dropped until the congestion is eliminated and the queue is no longer full).
Tail drop is used for CBWFQ traffic classes unless you explicitly configure a service policy to use WRED to drop packets as a means of avoiding congestion. Note that if you use WRED packet drop instead of tail drop for one or more traffic classes making up a service policy, you must ensure that WRED is not configured for the interface to which you attach that service policy.
WRED drops packets selectively based on IP precedence. Packets with a higher IP precedence are less likely to be dropped than packets with a lower precedence. Thus, higher-priority traffic is delivered with a higher probability than lower priority traffic in the default scenario. However, packets with a lower IP precedence are less likely to be dropped than packets with a higher IP precedence in certain WRED configurations. You can also configure WRED to ignore IP precedence when making drop decisions, so that non-weighted RED behavior is achieved.
WRED is useful on any output interface where you expect to have congestion. However, WRED is usually used in the core routers of a network, rather than the edge. Edge routers assign IP precedences to packets as they enter the network. WRED uses these precedences to determine how it treats different types of traffic.
Resource Reservation Protocol Interaction with CBWFQ
When Resource Reservation Protocol (RSVP) and CBWFQ are configured, RSVP and CBWFQ act independently of one another. RSVP and CBWFQ allocate bandwidth among their traffic classes and flows according to unallocated bandwidth available at the underlying point of congestion.
WRED Functional Description
When a packet arrives, the following events occur:
•
•
•
•
Average Queue Size
The average queue size is based on the previous average and the current size of the queue. The formula is as follows, where n is the exponential weight factor, a user-configurable value:
average = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)
Note
For high values of n, the previous average queue size becomes more important. A large factor smooths out the peaks and lows in queue length. The average queue size is unlikely to change very quickly, avoiding drastic swings in size. The WRED process is slow to start dropping packets, but it may continue dropping packets for a time after the actual queue size has fallen below the minimum threshold. The slow-moving average accommodates temporary bursts in traffic.
If the value of n becomes too high, WRED does not react to congestion. Packets are transmitted or dropped as if WRED were not in effect.
For low values of n, the average queue size closely tracks the current queue size. The resulting average may fluctuate with changes in the traffic levels. In this case, the WRED process responds quickly to long queues. Once the queue falls below the minimum threshold, the process stops dropping packets.
If the value of n becomes too low, WRED overreacts to temporary traffic bursts and drops traffic unnecessarily.
Packet-Drop Probability
The probability that a packet will be dropped is based on the minimum threshold, maximum threshold, and mark probability denominator.
When the average queue size is above the minimum threshold, RED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold.
The mark probability denominator is the fraction of packets dropped when the average queue size is at the maximum threshold. For example, if the denominator is 512, one out of every 512 packets is dropped when the average queue is at the maximum threshold.
When the average queue size is above the maximum threshold, all packets are dropped.
Figure 1 summarizes the packet drop probability.
Figure 1 WRED Packet Drop Probability
The minimum threshold value should be set high enough to maximize the link utilization. If the minimum threshold is too low, packets may be dropped unnecessarily, and the transmission link will not be fully used.
The difference between the maximum threshold and the minimum threshold should be large enough to avoid global synchronization of TCP hosts (global synchronization of TCP hosts can occur as multiple TCP hosts reduce their transmission rates). If the difference between the maximum and minimum thresholds is too small, many packets may be dropped at once, resulting in global synchronization.
Benefits
Bandwidth Allocation
CBWFQ allows you to specify the amount of guaranteed bandwidth to be allocated for a traffic class. Taking into account available bandwidth on the interface, you can configure up to 64 traffic classes and control bandwidth allocation among them. If excess bandwidth is available, the excess bandwidth is divided amongst the traffic classes in proportion to their configured bandwidths.
Flow-based WFQ allocates bandwidth equally among all flows.
Coarser Granularity and Scalability
CBWFQ allows you to define what constitutes a traffic class based on criteria that exceed the confines of flow. CBWFQ allows you to use access control lists and protocols or input interface names to define how traffic is classified, thereby providing coarser granularity. You need not maintain traffic classification on a flow basis. Moreover, you can configure up to 64 discrete traffic classes in a service policy.
Consistent Traffic Flows
When WRED is not configured, output buffers fill during periods of congestion. When the buffers are full, tail drop occurs; all additional packets are dropped. Since the packets are dropped all at once, global synchronization of TCP hosts can occur as multiple TCP hosts reduce their transmission rates. The congestion clears, and the TCP hosts increase their transmission rates, resulting in waves of congestion followed by periods when the transmission link is not fully used.
WRED reduces the chances of tail drop by selectively dropping packets when the output interface begins to show signs of congestion. By dropping some packets early rather than waiting until the buffer is full, WRED avoids dropping large numbers of packets at once and minimizes the chances of global synchronization. Thus, RED allows the transmission line to be used fully at all times.
In addition, WRED statistically drops more packets from large users than small. Therefore, traffic sources that generate the most traffic are more likely to be slowed down than traffic sources that generate little traffic.
WRED provides separate thresholds and weights for different IP precedences, allowing you to provide different qualities of service for different traffic. Standard traffic may be dropped more frequently than premium traffic during periods of congestion.
Restrictions
Using the bandwidth Command on VIP Default Traffic Class
On a VIP, all traffic that does not match a user-defined traffic class is classified as part of the default traffic class. The implicit bandwidth allocated to the default traffic class is equal to the link bandwidth minus all of the user-defined bandwidth given to the user-defined traffic classes (with the bandwidth command). At least 1 percent of the link bandwidth is always reserved for the default traffic class.
Because the bandwidth of the default traffic class is implicit (the default traffic class receives all remaining bandwidth not given to the user-defined traffic classes), the bandwidth command cannot be used with the default traffic class when you configure a VIP.
Using the match protocol Command on a VIP
With a VIP, do not use the match protocol command to create a traffic class with a non-IP protocol as a match criterion. The VIP does not support matching of non-IP protocols.
WRED Restrictions
WRED has the following restrictions:
•
•
•
Prerequisites
Weighted Fair Queueing
Attaching a service policy to an interface disables WFQ on that interface if WFQ is configured for the interface. For this reason, you should ensure that WFQ is not enabled on such an interface.
For information on WFQ, see the "Configuring Weighted Fair Queueing" chapter of the Cisco IOS Release 12.2 Quality of Service Solutions Configuration Guide.
WRED
Attaching a service policy configured to use WRED to an interface disables WRED on that interface. If any of the traffic classes that you configure in a policy map use WRED for packet drop instead of tail drop, you must ensure that WRED is not configured on the interface to which you intend to attach that service policy.
Access Control Lists
You can specify a numbered access list as the match criterion for any traffic class that you create. For this reason, you should know how to configure access lists.
Cisco Express Forwarding
In order to use WRED, Cisco Express Forwarding switching must be enabled on the interface. Refer to the Cisco Express Forwarding feature documentation for configuration information.
Modular Quality of Service Command-Line Interface
You can configure CBWFQ and WRED using the Modular Quality of Service Command-Line Interface.
For information on configuring QoS features with the Modular QoS CLI, see the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
Configuration Tasks
CBWFQ is configured using user-defined traffic classes and service policies. Traffic classes and service policies are configured in the Modular QoS CLI. For information on configuring the Modular QoS CLI, see the Modular Quality of Service Command Line Interface document on CCO and the Documentation CD-ROM.
This section contains the following information:
•
•
•
•
•
Configuring a Service Policy in the Policy Map
CBWFQ is configured using the Modular QoS CLI. In the Modular QoS CLI, a traffic class must be created before you can configure a service policy. The following example assumes that a traffic class has already been created. For information on configuring the Modular QoS CLI, including information on configuring traffic classes, see the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
In the following example, a service policy (specified with the policy-map command) containing a bandwidth and queue-limit specification is created.
To configure Quality of Service features in a service policy, use the policy-map command in global configuration mode and specify the service policy name and then use the following service policy configuration commands to configure QoS policies for a specified traffic class. For each traffic class that you define, you can use one or more of the following service policy configuration commands to configure the service policy. For example, you might specify bandwidth for one traffic class and both bandwidth and queue limit for another traffic class.
After configuring the service policy with the policy-map command, you must still attach the service policy to an interface before it is successfully enabled. For information on attaching a service policy to an interface, see the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
Configuring a Service Policy with WRED in the Policy Map
To configure a service policy and create traffic classes (including a default traffic class) that make up the service policy, use the policy-map command in global configuration mode to specify the service policy name. Then use the following commands in policy map configuration mode to configure the service policy for a traffic class. The service policy's default traffic class is the traffic class to which traffic is directed if that traffic does not satisfy the match criteria of other traffic classes whose policy is defined in the service policy. To configure policy for more than one traffic class in the same policy map, repeat Step 2 through Step 4.
To attach a service policy to an interface and enable CBWFQ on the interface, you must create a policy map. You can configure traffic class policies for as many traffic classes as are defined on the router, up to the maximum of 64.
After configuring the service policy with the policy-map command, you must still attach the service policy to an interface before it is successfully enabled. For information on attaching a service policy to an interface, see the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
Configuring a Service Policy Including IP Precedence Using WRED
To configure a service policy using WRED to specify IP precedence, use the following commands beginning in global configuration mode:
After configuring the service policy with the policy-map command, you must still attach the service policy to an interface before it is successfully enabled. For information on attaching a service policy to an interface, see the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
Modifying the Bandwidth for an Existing Service Policy
To change the amount of bandwidth allocated for an existing traffic class, use the following commands.
After configuring the service policy with the policy-map command, you must still attach the service policy to an interface before it is successfully enabled. For information on attaching a service policy to an interface, see the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
Modifying the Queue Limit for an Existing Service Policy
To change the maximum number of packets that can accrue in a queue reserved for an existing traffic class, use the following commands beginning in global configuration mode:
After configuring the service policy with the policy-map command, you must still attach the service policy to an interface before it is successfully enabled. For information on attaching a service policy to an interface, see the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
Monitoring and Maintaining CBWFQ and WRED
Use the show policy-map [interface [interface-spec [input | output [class class-name]]]] command to display the configuration of a service policy and its associated traffic classes. Forms of this command are listed in the table below. See the Modular Quality of Service Command-Line Interface document for more information about the show policy-map command.
Configuration Examples
This section provides the following configuration examples:
•
•
Configuring a Traffic Class
In the following example, two traffic classes are created and their match criteria are defined. For the first traffic class, called class1, the numbered ACL 101 is used as the match criterion. For the second traffic class, called class2, the access control list ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the traffic class.
Router(config)# class-map class1Router(config-cmap)# match access-group 101Router(config-cmap)# exitRouter(config)# class-map class2Router(config-cmap)# match access-group 102Router(config-cmap)# exitAdditional information regarding traffic classes is contained in the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
Creating a Service Policy
In the following example, a service policy called policy1 is defined to associate Quality of Service (QoS) features with the two traffic classes—class1 and class2. The match criteria for these traffic classes were defined in the previous "Configuring a Traffic Class" section.
For class1, the QoS policies include bandwidth allocation request and maximum packet count limit for the queue reserved for the traffic class. For class2, the policy specifies only a bandwidth allocation request, so the default queue limit of 64 packets is assumed.
Router(config)# policy-map policy1Router(config-pmap)# class class1Router(config-pmap-c)# bandwidth 3000Router(config-pmap-c)# queue-limit 30Router(config-pmap)# exitRouter(config-pmap)# class class2Router(config-pmap-c)# bandwidth 2000Router(config-pmap)# exitAdditional information regarding service policy configurations is available in the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
Attaching a Service Policy to an Interface
The following example shows how to attach an existing service policy to an interface. After you define a service policy, you can attach it to one or more interfaces to specify a service policy for those interfaces. Although you can assign the same service policy to multiple interfaces, each interface can have only one service policy attached at the input and one policy map attached at the output at one time.
Router(config)# interface fe1/0/0Router(config-if)# service output policy1Router(config-if)# exitAdditional information regarding attaching service policy configurations to interfaces is available in the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.
Enabling Hierarchical Queuing
You can nest a traffic policy within another policy by using the service-policy command in policy-map class configuration mode. A traffic policy that contains a nested traffic policy is called a hierarchical traffic policy.
A hierarchical traffic policy contains the following components:
•
•
Cisco IOS Release 12.0(26)S introduces support for QOS queuing policies (both flat and hierarchical) on the Cisco 7200 series routers. Hierarchical queueing policies are supported on the Cisco 7200 series routers in the Cisco IOS 12.2 and 12.3 releases. However, those queueing policies require shaping in the parent policy. For an example of a queuing policy that has shaping in the parent policy and bandwidth in the child policy, see the feature module Class-Based Shaping.
In Cisco IOS Release 12.0(26)S, hierarchical queueing policies do not require shaping in the parent policy. You can specify queuing in the parent policy and in the child policy. The following example illustrates a traffic policy that specifies the bandwidth (policy-map class) command at both the child- and parent-level policies.
The policy named parent is attached to a link of bandwidth 100 kbps. The policy named parent includes two classes:
The class called customer1 has the following characteristics:
•
•
•
•
The class called customer2 has the following characteristics:
•
•
•
policy child_customer1class udp_customer1bandwidth 20class tcp_customer1bandwidth 40policy child_customer2class udp_customer2bandwidth 10class tcp_customer2bandwidth 20policy parentclass customer1bandwidth 70service-policy child_customer1class customer2bandwidth 30service-policy child_customer2Additional References
The following sections provide references related to Class-Based Weighted Fair Queueing and Weighted Random Early Detection.
Related Documents
Standards
MIBs
None
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
Technical Assistance
Command Reference
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.3 command references.
•
•
bandwidth (policy-map class)
To specify or modify the bandwidth allocated for a class belonging to a policy map, use the bandwidth command in policy-map class configuration mode. To remove the bandwidth specified for a class, use the no form of this command.
bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage}
no bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage}
Syntax Description
Defaults
No bandwidth is specified
Command Modes
Policy-map class configuration
Command History
Usage Guidelines
You should use the bandwidth command when you configure a policy map for a class defined by the class-map command. The bandwidth command specifies the bandwidth for traffic in that class. Class-based weighted fair queueing (CBWFQ) derives the weight for packets belonging to the class from the bandwidth allocated to the class. CBWFQ then uses the weight to ensure that the queue for the class is serviced fairly.
Specifying Bandwidth as a Percentage
Besides specifying the amount of bandwidth in kbps, you can specify bandwidth as a percentage of either the available bandwidth or the total bandwidth. During periods of congestion, the classes are serviced in proportion to their configured bandwidth percentages. Available bandwidth is equal to the interface bandwidth minus the sum of all bandwidths reserved by the Resource Reservation Protocol (RSVP) feature, the IP RTP Priority feature, and the Low Latency Queueing (LLQ) feature.
Note
Bandwidth Command Restrictions
The following restrictions apply to the bandwidth command:
•
•
•
For more information on bandwidth allocation, refer to the chapter "Congestion Management Overview" in the Cisco IOS Quality of Service Solutions Configuration Guide.
Note that when the policy map containing class policy configurations is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed. If a policy map cannot be attached to a particular interface because of insufficient interface bandwidth, then the policy is removed from all interfaces to which it was successfully attached.
Queue Limits
The bandwidth command can be used with the Modular Command-Line Interface (MQC) to specify the bandwidth for a particular class. When used with the MQC, the bandwidth command uses 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
Examples
CBWFQ Bandwidth Guarantee Example
The following example shows how bandwidth is guaranteed when only CBWFQ is configured:
! The following commands create a policy map with two classes:policy-map policy1class class1bandwidth percent 50exitclass class2bandwidth percent 25exitend!The following commands attach the policy to interface serial3/2:interface serial3/2service output policy1endThe following output from the show policy-map command shows the configuration for the policy map called policy1:
Router# show policy-map policy1Policy Map policy1Class class1Weighted Fair QueueingBandwidth 50 (%) Max Threshold 64 (packets)Class class2Weighted Fair QueueingBandwidth 25 (%) Max Threshold 64 (packets)The output from the show policy-map interface command shows that 50 percent of the interface bandwidth is guaranteed for the class called class1, and 25 percent is guaranteed for the class called class2. The output displays the amount of bandwidth as both a percentage and a number of kbps.
Router# show policy-map interface serial3/2Serial3/2Service-policy output:policy1Class-map:class1 (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:noneWeighted Fair QueueingOutput Queue:Conversation 265Bandwidth 50 (%)Bandwidth 772 (kbps) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:class2 (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:noneWeighted Fair QueueingOutput Queue:Conversation 266Bandwidth 25 (%)Bandwidth 386 (kbps) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:class-default (match-any)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:anyIn this example, interface serial3/2 has a total bandwidth of 1544 kbps. During periods of congestion, 50 percent (or 772 kbps) of the bandwidth is guaranteed to the class called class1, and 25 percent (or 386 kbps) of the link bandwidth is guaranteed to the class called class2.
CBWFQ and LLQ Bandwidth Allocation Example
The following output from the show policy-map command shows the configuration for a policy map called p1:
Router# show policy-map p1Policy Map p1Class voiceWeighted Fair QueueingStrict PriorityBandwidth 500 (kbps) Burst 12500 (Bytes)Class class1Weighted Fair QueueingBandwidth remaining 50 (%) Max Threshold 64 (packets)Class class2Weighted Fair QueueingBandwidth remaining 25 (%) Max Threshold 64 (packets)The following output from the show policy-map interface command on serial interface 3/2 shows that 500 kbps of bandwidth is guaranteed for the class called voice1. The classes called class1 and class2 receive 50 percent and 25 percent of the remaining bandwidth, respectively. Any unallocated bandwidth is divided proportionally among class1, class2, and any best-effort traffic classes.
Note
Router# show policy-map interface serial3/2Serial3/2Service-policy output:p1Class-map:voice (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:ip precedence 5Weighted Fair QueueingStrict PriorityOutput Queue:Conversation 264Bandwidth 500 (kbps) Burst 12500 (Bytes)(total drops/bytes drops) 0/0Class-map:class1 (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:noneWeighted Fair QueueingOutput Queue:Conversation 265Bandwidth remaining 50 (%) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:class2 (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:noneWeighted Fair QueueingOutput Queue:Conversation 266Bandwidth remaining 25 (%) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:class-default (match-any)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:anyRelated Commands
fair-queue (policy-map class)
To specify the number of queues to be reserved for use by a traffic class, use the fair-queue command in QoS policy-map class configuration mode. To delete the configured number of queues from the traffic class, use the no form of this command.
fair-queue [dynamic-queues]
no fair-queue [dynamic-queues]
Syntax Description
dynamic-queues
(Optional) A number specifying the number of dynamic conversation queues. The number can be in the range of 16 to 4096.
Defaults
No queues are reserved.
Command Modes
QoS policy-map class configuration
Command History
Usage Guidelines
On VIP and non-VIP platforms, the fair-queue command can be used for any traffic class, not just the default traffic class. The fair-queue command can be used in conjunction with either the queue-limit command or the random-detect exponential-weighting-constant command.
Examples
The following example configures the default traffic class for the policy map called policy9 to reserve ten queues for packets that do not satisfy match criteria specified for other traffic classes whose policy is configured in the same service policy. Because the queue-limit command is configured, tail drop is used for each queue when the maximum number of packets is enqueued and additional packets arrive.
policy-map policy9class class-defaultfair-queue 10queue-limit 20The following example configures a service policy called policy8 that is associated with a user-defined traffic class called class1. The fair-queue command reserves 20 queues to be used for the service policy. For congestion avoidance, Weighted Random Early Detection (WRED) packet drop is used, not tail drop.
policy-map policy8 class class1 fair-queue 20random-detect exponential-weighting-constant 14Related Commands
queue-limit
To specify or modify the maximum number of packets the queue can hold for a class policy configured in a policy map, use the queue-limit command in policy-map class configuration mode. To remove the queue packet limit from a class, use the no form of this command.
queue-limit number-of-packets
no queue-limit number-of-packets
Syntax Description
number-of-packets
A number in the range from 1 to 64 specifying the maximum number of packets that the queue for this class can accumulate.
Defaults
On the Versatile Interface Processor (VIP)-based platforms, the default value is chosen as a function of the bandwidth assigned to the traffic class. The default value is also based on available buffer memory. If sufficient buffer memory is available, the default queue-limit value is equal to the number of 250-byte packets that would lead to a latency of 500 milliseconds (ms) when the packets are delivered at the configured rate. For example, if two 250-byte packets are required to lead to a latency of 500 ms, the default number-of-packets value would be 2.
On all other platforms, the default is 64.
Command Modes
Policy-map class configuration
Command History
Usage Guidelines
Weighted fair queueing (WFQ) creates a queue for every class for which a class map is defined. Packets satisfying the match criteria 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 you defined for the class is reached, enqueueing of any further packets to the class queue causes tail drop or, if Weighted Random Early Detection (WRED) is configured for the class policy, packet drop to take effect.
Overriding Queue Limits Set by the Bandwidth Command
The bandwidth command can be used with the Modular Command-Line Interface (MQC) to specify the bandwidth for a particular class. When used with the MQC, the bandwidth command uses 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
Examples
The following example configures a policy map called policy11 to contain policy for a class called acl203. Policy for this class is set so that the queue reserved for it has a maximum packet limit of 40.
policy-map policy11class acl203bandwidth 2000queue-limit 40Related Commands
random-detect exponential-weighting-constant
To configure the Weighted Random Early Detection (WRED) exponential weight factor for the average queue size calculation for the queue, use the random-detect exponential-weighting-constant command in interface configuration mode. To configure the exponential weight factor for the average queue size calculation for the queue reserved for a class, use the random-detect exponential-weighting-constant command in policy-map class configuration mode. To return the value to the default, use the no form of this command.
random-detect exponential-weighting-constant exponent
no random-detect exponential-weighting-constant
Syntax Description
Defaults
The default exponential weight factor is 9.
Command Modes
Interface configuration when used on an interface
Policy-map class configuration when used to specify class policy in a policy map, or when used in the Modular Quality of Service Command-Line Interface (MQC)
Command History
Usage Guidelines
WRED is a congestion avoidance mechanism that slows traffic by randomly dropping packets when congestion exists. WRED is similar to DWRED but uses the Versatile Interface Processor (VIP) instead of the Route Switch Processor (RSP). WRED and DWRED are most useful with protocols like TCP that respond to dropped packets by decreasing the transmission rate.
Use this command to change the exponent used in the average queue size calculation for the WRED services. You can also use this command to configure the exponential weight factor for the average queue size calculation for the queue reserved for a class.
Note
Examples
The following example configures WRED on an interface with a weight factor of 10:
interface Hssi0/0/0description 45Mbps to R1ip address 10.200.14.250 255.255.255.252random-detectrandom-detect exponential-weighting-constant 10The following example configures the policy map called policy1 to contain policy specification for the class called class1. During times of congestion, WRED packet drop is used instead of tail drop. The weight factor used for the average queue size calculation for the queue for class1 is 12.
! The following commands create the class map called class1:class-map class1match input-interface FE0/1! The following commands define policy1 to contain policy specification for class1:policy-map policy1class class1bandwidth 1000random-detectrandom-detect exponential-weighting-constant 12The following example configures policy for a traffic class named int10 to configure the exponential weight factor as 12. This is the weight factor used for the average queue size calculation for the queue for traffic class int10. WRED packet drop is used for congestion avoidance for traffic class int10, not tail drop.
policy-map policy12class int10bandwidth 2000random-detect exponential-weighting-constant 12Related Commands
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0304R)
Guest
