Cisco 10000 Series Router Quality of Service Configuration Guide - Managing Packet Queue Congestion [Cisco 10000 Series Routers]

Table Of Contents

Managing Packet Queue Congestion

Queue Scaling Limits

Queue Limit

Queue Limit Packet Buffers

Default Queue Limit and Packet Buffers

queue-limit Command

Syntax Description

queue-limit Command History

Default Behavior for the queue-limit Command

Usage Guidelines for the queue-limit Command

Queue IDs and Interface Queues

Reserved QIDs

Queuing Outbound Traffic

Queuing Outbound Traffic on ATM Interfaces

Queuing Outbound Traffic on Frame Relay Interfaces

Queuing Outbound Traffic on Virtual LAN Interfaces

Controlling Congestion Using Tail Drop

Feature History for Tail Drop

Tail Drop and Random Early Detection

Controlling Congestion Using Random Early Detection

Feature History for Random Early Detection

Random Early Detection and Queue Limit

Determining Packet Drop Probability

Recommended Settings for RED Drop Probability

Controlling Congestion Using Weighted Random Early Detection

Feature History for Weighted Random Early Detection

Benefits of Using Weighted Random Early Detection

How WRED Works

WRED Drop Mode

WRED Drop Profiles

WRED Aggregate Drop Profiles

Usage Guidelines for the random-detect Command

Minimum and Maximum Thresholds

WRED and Queue Limit

Average Queue Size and the Exponential Weight Constant

Interfaces Supporting Layer 3 Packet Drop Policies

Restrictions and Limitations for Controlling Layer 3 Congestion

Configuring Layer 3 Queue Limit and Drop Policies

Controlling Packet Dropping by Setting the Size of a Class Queue

Configuration Example for Controlling Packet Dropping by Setting a Queue Size

Dropping Packets Based on a Differentiated Services Code Point

Configuration Example for Configuring DSCP-Based WRED

Dropping Packets Based on IP Precedence

Configuration Example for Dropping Packets Based on IP Precedence

Dropping Packets Based on the Discard Class

Configuration Example for Dropping Packets Based on Discard Class

Dropping Packets Based on the ATM Cell Loss Priority

Configuration Example for Dropping Packets Based on the Cell Loss Priority

Verifying and Monitoring Layer 3 Packet Dropping

Verification Example for Queue Size and Packet Dropping

Verification Examples for DSCP-Based WRED

Verification Example for IP Precedence-Based WRED

Verification Example for Discard-Class-Based WRED

Verification Examples for ATM CLP-Based WRED

Controlling Packet Flow on Layer 2 Queues

Configuring the Depth of Layer 2 Queues

Related Documentation

Managing Packet Queue Congestion

A Layer 3 queuing strategy provides differentiated levels of service and assigns priority to delay-sensitive packets. Queuing limits the amount of traffic that can be sent to queues so that all of the packet buffers are not consumed. Commonly used mechanisms, such as random early detection (RED), monitor network traffic loads to control congestion by acting on the traffic if congestion is about to occur.

This chapter discusses congestion control mechanisms supported on the Cisco 10000 series router and includes the following topics:

•Queue Scaling Limits

•Queue Limit

•Queue IDs and Interface Queues

•Queuing Outbound Traffic

•Controlling Congestion Using Tail Drop

•Controlling Congestion Using Random Early Detection

•Controlling Congestion Using Weighted Random Early Detection

•Interfaces Supporting Layer 3 Packet Drop Policies

•Restrictions and Limitations for Controlling Layer 3 Congestion

•Configuring Layer 3 Queue Limit and Drop Policies

•Verifying and Monitoring Layer 3 Packet Dropping

•Controlling Packet Flow on Layer 2 Queues

•Related Documentation

Queue Scaling Limits

The router allocates at least two queues for every interface or subinterface for which separate queues are created. The first queue is the default queue for normal traffic and the second queue is the system queue. The system queue is used for a small amount of router-generated traffic that bypasses the normal drop mechanisms. For 32,000 VCs, the router would need to allocate a minimum of 64,000 queues. While Cisco IOS Release 12.3(7)XI1 adds support for up to 128,000 queues, a more effective use of these limited resources is to have the subinterfaces on a given main interface share the single system queue of the main interface.

In Cisco IOS Release 12.3(7)XI2, the subinterfaces on a given main interface share the single system queue of the main interface. This allows for 32,000 subinterfaces with a three-queue model that supports assured forwarding (AF) queues, expedited forwarding (EF) queues, and the default best effort (BE) queues. Because a system queue is not allocated for every subinterface, queues are freed up for a four-queue model.

Table 11-1 lists the scaling limits for class queues.

Table 11-1 Queue Scaling Limits

Queue Criteria

PRE3
Release 12.2(31)SB2 or later

PRE2
Release 12.3(7)XI or later

PRE2
Release 12.2(16)BX or later

PRE1

Total Number of Queues Per System¹

256,000

131,070

65,534

32,766

No. Queues Per Link

15

32²

32

16³

Total Number of Packet Buffers for Queue Depth⁴

Not Applicable⁵

4,194,304

4,194,304

1,048,576

¹Includes network-control and default queues.

²29 user-configurable queues, 1 class-default queue, 1 system queue, and 1 reserved queue

³14 user-configurable queues, 1 class-default queue, 1 system queue

⁴With 131,070 queues configured, the average queue limit across all of the configured queues is less than or equal to 32 packets per queue: 4,194,304 divided by 131,070 equals 32.

⁵The PRE3 implements queues in such a way that this limit no longer exists.

Queue Limit

Each queue has a limit on the number of packets that the router can place onto the queue. This limit, referred to as the depth, is a user-configurable limit. During periods of high traffic, a queue fills with packets waiting for transmission. When a queue reaches its queue limit and becomes full, by default the router drops packets until the queue is no longer full.

Table 11-2 describes the queuing limits for the various processor cards.

Table 11-2 Packets Per Queue

Processor

Cisco IOS Release

Packets Per Queue

PRE1

All releases

32 to 16,384

If you do not specify a value that is a power of 2, the router uses the nearest power of 2.

PRE2

Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX

32 to 16,384

The value does not need to be a power of 2.

PRE2

Cisco IOS Release 12.3(7)XI and later releases

Interfaces with speeds that are less than 500 MB

8 to 4,096 packets per queue

The value must be a power of 2.

Interfaces with speeds that are greater than 500 MB

128 to 64,000 packets per queue

The value must be a power of 2.

PRE3
PRE4

Cisco IOS Release 12.2(31)SB2 and later releases

16 to 32,767

When a packet queue temporarily experiences congestion, increasing the depth of the queue using the queue-limit command reduces the number of packets dropped. However, setting the queue limit to a high value might reduce the number of packet buffers available to other interfaces.

The queue limit applies to each buddy queue on links with:

•At least 500 Mbps (PRE1)

•1 Gbps (PRE2)

Note The PRE3 does not use buddy queues.

If you do not specify a queue limit, the router calculates the default buffer size for each class queue as follows:

•Class queues with weighted random early detection (WRED)—The router uses the default queue limit of two times the largest WRED maximum threshold value, rounded to the nearest power of 2.

Note For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX, the router does not round the value to the nearest power of 2.

•Class queues without WRED—The router has buffers for up to 50 milliseconds of 256-byte packets (PRE2) or 250-byte packets (PRE3) at line rate, but not less than 32 packets (PRE2) or 16 packets (PRE3).

•Priority queues without WRED—The router has buffers for up to 25 milliseconds of 80-byte packets at line rate, but not less than 32 packets (PRE2) or 16 packets (PRE3).

Queue Limit Packet Buffers

The router provides a total of 4,194,304 buffers for queuing packets and calculates the default buffer size for each class queue as described in the "Queue Limit" section. Whatever the default queue size the system calculates, if a class has a random early detection (RED) drop policy configured and one of the maximum thresholds is configured to be larger than the default buffer size, the router automatically increases the queue size to the nearest power of 2 of the largest maximum threshold.

You can use the show policy-map interface command to display the actual queue size. To make the queue size larger than the default size the router calculated, do the following:

•Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, and later releases—Configure the queue-limit command with RED.

For more information, see the "queue-limit Command" section, the "Random Early Detection and Queue Limit" section, and the "WRED and Queue Limit" section.

•Releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI—RED with queue-limit is not supported. As a workaround, configure RED with an unused IP precedence or DSCP level and define a maximum threshold that is larger than the default size the router calculated. By doing this, you force the router to increase the queue size to accommodate the larger threshold.

With 131,070 queues configured, the average queue limit across all of the configured queues is less than or equal to 32 packets per queue:

Total number of packet buffers / Total number of queues

4,194,304 / 131,070 = 32

If you change the queue size several times for 131,070 queues, the queue packet buffers can become fragmented or might still be in use. For more information, see the "Restrictions and Limitations for Controlling Layer 3 Congestion" section.

For more information, see the "Average Queue Size and the Exponential Weight Constant" section.

Default Queue Limit and Packet Buffers

When a queue is part of a high-speed interface, the default queue limit is very large. This allows the queue to store up many packets during congestion. If too many of these type of queues are congested on the system, it causes system packet buffer exhaustion and all queues in the system experience packet drop.

queue-limit Command

To specify or modify the maximum number of packets that a particular class queue can hold, 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

For PRE1, number-of-packets is a number from 32 to 16384; the number must be a power of 2. If the number you specify is not a power of 2, the router converts the number to the nearest power of 2 value.

For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX using the PRE2, number-of-packets is a number from 32 to 16384. The number does not need to be a power of 2.

For Cisco IOS Release 12.3(7)XI and later releases using the PRE2, if the interface speed is less than 500 MB, number-of-packets is a number from 8 to 4096; the number must be a power of 2. If the interface speed is greater than 500 MB, number-of-packets is a number from 128 to 64000 and must be a power of 2. If it is not, the router converts the number to the nearest power of 2 value.

For Cisco IOS Release 12.2(31)SB2 and later releases using the PRE3, number-of-packets is a number from 1 to 32,767. The number does not need to be a power of 2.

queue-limit Command History

Cisco IOS Release

Description

Release 12.0(17)SL

The queue-limit command was introduced on the PRE1.

Release 12.0(25)SX

This command was enhanced to allow you to simultaneously configure both the queue-limit and random-detect commands in the same class of a policy map.

Release 12.2(16)BX

This command was introduced on the PRE2.

Release 12.3(7)XI

This command was enhanced on the PRE2 to allow you to simultaneously configure both the queue-limit and random-detect commands in the same class of a policy map.

Release 12.2(28)SB

This command was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

Release 12.2(31)SB2

This command was introduced on the PRE3.

Default Behavior for the queue-limit Command

The following describes the default behavior of the queue-limit command for class queues with and without weighted random early detection (WRED):

•Class queues with weighted random early detection (WRED)—The router uses the default queue limit of two times the largest WRED maximum threshold value, rounded to the nearest power of 2.

Note For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX using the PRE2, and for Cisco IOS Release 12.2(31)SB2 and later releases using the PRE3, the router does not round the value to the nearest power of 2.

•Priority queues and class queues without WRED—The router has buffers for up to 50 milliseconds of 256-byte packets at line rate, but not less than 32 packets.

Usage Guidelines for the queue-limit Command

Whenever you configure the bandwidth command for a class queue, the command sets a default queue limit for the class, which in most cases is sufficient to meet minimum bandwidth guarantees. However, if you configure all of the 131,070 queues for a system, lower the queue limit so that all of the queues have enough bandwidth. The queue-limit command overrides the default queue limit set by the bandwidth command. For more information, see the "Queue Limit Packet Buffers" section.

Cisco IOS Release 12.2(16)BX does not require that you specify a queue limit value that is a power of 2; therefore, the router does not round the value to the nearest power of 2.

Queue IDs and Interface Queues

The router allocates queue IDs (QIDs) to interface queues. The number of queues supported on an interface and the number of QIDs allocated depend on the speed of the interface and the processor card installed in the chassis. For each class that has a queue on an interface, the router allocates one or two QIDs as indicated in Table 11-3.

Table 11-3 QID Allocation for Classes with Queues on an Interface

Processor

Interface Bandwidth

QIDs Allocated

Queues Supported

PRE1

Less than 500 Mbps

1

32,766 total queues per system

500 Mbps or greater

2

PRE2

Less than 622 Mbps

1

130,816

622 Mbps or greater

2

254¹

PRE3

Not applicable²

1

256,000

¹QID 0 and QID 1 are not legal values. Therefore, instead of supporting 256 QIDs, the router supports 254.

²The PRE3 does not support buddy queues.

Note The PRE2 has buddy queues only for the OC-48 line card. All other interfaces have 1 queue. The PRE1 requires a buddy queue for the full-height Gigabit Ethernet line card.

Reserved QIDs

On the PRE2, if no more QIDs are left (all of them are used) and you attempt to modify the queue limit in a policy map that is attached to one or more interfaces, the operation fails and an out of resource message displays. To avoid this, you can do the following:

•Reserve one or more available QIDs

•Remove the policy map from the interface first, modify the queue limit, and then attach the new policy map to the interface

You might desire to reserve a pool of unused queues just in case a service policy is applied on a live production network and someone attempts to change the queue parameters. By using the show ha pxf cpu queue summary command, you can learn how many available queues are in the pool and plan accordingly.

Queuing Outbound Traffic

This section describes how the Cisco 10000 series router queues outbound traffic and includes the following:

•Queuing Outbound Traffic on ATM Interfaces

•Queuing Outbound Traffic on Frame Relay Interfaces

•Queuing Outbound Traffic on Virtual LAN Interfaces

Queuing Outbound Traffic on ATM Interfaces

On ATM interfaces, the Cisco 10000 series router creates one set of queues for all of the unspecified bit rate (UBR) PVCs and a separate set of queues for each variable bit rate (VBR) PVC. The following lists the queues the router creates:

•One default queue for all unshaped (no PCR specified) UBR PVCs

•One default queue for each VBR and shaped (PCR is specified) UBR PVCs

•One network control queue for each port

Using a policy map, you can optionally create additional class-based queues for UBR PVCs and each VBR PVC, and attach the policy map to the physical interface for UBR PVCs or to a VBR PVC.

Unshaped UBR PVCs that have their own service policy use the physical interface's default queue only. These PVCs cannot use any user-defined, class-based queue defined on the physical interface.

Queuing Outbound Traffic on Frame Relay Interfaces

The Cisco 10000 series router supports two queuing modes for Frame Relay interfaces: interface-based queuing and PVC-based queuing. In interface-based queuing, all PVCs share the same set of queues. In PVC-based queuing, each PVC has its own set of queues for its outbound traffic.

Interface-based queuing is the default queuing mode. In this mode, the system creates a default set of queues that all PVCs on the interface can use. Using a policy map, you can optionally create additional class-based queues, which are shared among all the PVCs.

You can configure PVC-based queuing by creating a hierarchical policy. In this way, you can enable class-based fair queuing for a PVC and shape the total PVC traffic to a desired rate. For more information, see Chapter 13, "Defining QoS for Multiple Policy Levels."

For information about enabling PVC-based fair queuing by using the Frame Relay QoS CLI, see Appendix A, "Configuring Frame Relay QoS Using Frame Relay Legacy Commands."

Queuing Outbound Traffic on Virtual LAN Interfaces

By default, the Cisco 10000 series router does not create a queue for a virtual LAN (VLAN) interface. All VLANs share the same set of queues on the physical Ethernet interface.

To create a separate queue for a VLAN interface, use a hierarchical policy. For more information, see Chapter 13, "Defining QoS for Multiple Policy Levels."

Controlling Congestion Using Tail Drop

The tail drop mechanism controls congestion using a specific drop policy to ensure that the maximum number of packets held in a queue is not exceeded.

During periods of high traffic, a queue fills with packets waiting for transmission. When a queue reaches its queue limit and becomes full, by default the router employs the tail drop mechanism to drop packets until the queue is no longer full.

Tail drop is the default mechanism used to control congestion for Layer 3 queues. While some mechanisms activate before a queue reaches its queue limit, tail drop activates when a queue becomes full. Tail drop treats all traffic equally and does not differentiate between classes of service. When a queue becomes full, tail drop continues to drop packets until the queue has room for more packets (the queue is no longer full).

Feature History for Tail Drop

Cisco IOS Release

Description

Required PRE

Release 12.0(17)SL

The tail drop feature was introduced on the router.

PRE1

Release 12.2(16)BX

This feature was introduced on the PRE2.

PRE2

Release 12.2(28)SB

This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

PRE2

Release 12.2(31)SB2

This feature was introduced on the PRE3.

PRE2
PRE3

Tail Drop and Random Early Detection

The Cisco 10000 series router allows you to combine tail drop with another congestion control mechanism called random early detection (RED). RED does not replace tail drop, but rather complements it by dropping packets before the queue reaches its queue limit or maximum threshold. Tail drop occurs after the queue is already full, when the mean queue depth for RED exceeds the maximum threshold value and when the queue limit is reached.

For more information about random early detection, see the "Controlling Congestion Using Random Early Detection" section and the "Controlling Congestion Using Weighted Random Early Detection" section.

Controlling Congestion Using Random Early Detection

Random early detection (RED) is an alternative mechanism for controlling congestion of Layer 3 queues. Unlike the tail drop mechanism, RED implements a proactive queuing strategy that controls congestion before a queue reaches its queue limit.

RED randomly discards packets. If the source host is using Transmission Control Protocol (TCP), the host detects that packets are dropped and decreases its transmission rate until all of the packets reach their destinations, indicating that the congestion is clear. The host can then resume its original transmission rate.

You can configure a drop policy for RED that is based on one of the following. Each queue on the router can have only one type of RED drop policy.

•IP precedence-based RED—Configures a drop policy for RED based on an IP precedence level. Valid values are from 0 to 7, where 0 typically represents low priority traffic that can be aggressively managed (dropped) and 7 represents high priority traffic. Traffic at a low precedence level typically has a higher drop probability. When RED drops packets, source hosts using TCP detect the drops and slow the transmission of packets.

•DSCP-based RED—Configures a drop policy for RED based on a differentiated services code point (DSCP) value. When configured, the router randomly drops packets with the specified DSCP value, according to the RED thresholds you configure. For the PRE1, DSCP-based RED supports one default drop profile per class, three assured forwarding (AF) drop profiles per class, and four non-AF drop profiles per policy map.

Feature History for Random Early Detection

Cisco IOS Release

Description

Required PRE

Release 12.0(17)SL

The random early detection feature was introduced on the router.

PRE1

Release 12.0(22)S

This feature was enhanced to allow you to configure RED based on a differentiated services code point (DSCP).

PRE1

Release 12.0(25)SX

This feature was enhanced to allow you to simultaneously configure the random-detect command and the queue-limit for the same class queue.

PRE1

Release 12.2(16)BX

This feature was introduced on the PRE2.

PRE2

Release 12.2(28)SB

This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

PRE2

Release 12.2(31)SB2

This feature was introduced on the PRE3.

PRE3

Random Early Detection and Queue Limit

Random early detection (RED) controls the average congestion level of a class queue and queue limit controls the instantaneous congestion level of a queue. By using the RED and queue limit mechanisms together, you can configure a drop policy for a class queue and simultaneously limit the maximum number of packets allowed to accumulate in the queue.

Note To simultaneously configure RED and queue limit for a class in a policy map, the router must be running Cisco IOS Release 12.0(25)SX or later releases. In releases prior to Cisco IOS Release 12.0(25)SX, you can configure either the random-detect command or the queue-limit command, but not both commands at the same time.

Determining Packet Drop Probability

RED uses three configurable parameters to determine the drop probability of packets: minimum threshold, maximum threshold, and mark probability denominator. The following describes how RED determines packet drop probability:

•RED begins dropping packets when the average queue size is equal to the value of the minimum threshold.

•RED continues dropping packets when the average queue size is between the minimum and maximum threshold values.

•As the average queue size approaches the maximum threshold, RED uses the mark probability denominator value to determine the slope (the increase in drop rate). For example, if the denominator is 512, RED drops one out of every 512 packets when the average queue limit reaches the maximum threshold.

•RED drops all packets when the average queue size is greater than the maximum threshold value.

Figure 11-1 illustrates how RED determines drop probability.

Figure 11-1 Determining Drop Probability Using RED

Recommended Settings for RED Drop Probability

To ensure an optimum drop policy for RED, use the following threshold settings:

•Set the minimum threshold value high enough to utilize the transmission link to the maximum capability. If you set the minimum threshold too low, RED can drop packets unnecessarily and the transmission link is not fully used.

•Set the maximum threshold value and the minimum threshold value so that the difference between the two values is large enough to avoid global synchronization. If the difference is too small, RED drops many packets at one time, which results in global synchronization.

Controlling Congestion Using Weighted Random Early Detection

Weighted random early detection (WRED) is another mechanism for controlling congestion of Layer 3 queues. WRED combines the capabilities of the random early detection (RED) mechanism with IP precedence, differential services code point (DSCP), and discard-class to provide preferential handling of higher priority packets. When an interface starts to become congested, WRED discards lower priority traffic with a higher probability. WRED controls the average depth of Layer 3 queues.

Unlike tail drop, WRED attempts to anticipate and avoid congestion. WRED implements a proactive queuing strategy that manages congestion before a queue reaches its queue depth. By selectively dropping packets, WRED prevents packets from enqueuing to the Layer 3 queue.

You can configure a drop policy for WRED that is based on one of the following. Each queue on the router can have only one type of WRED drop policy.

•IP precedence-based WRED—Configures a drop policy for WRED based on an IP precedence level. Valid values are from 0 to 7, where 0 typically represents low priority traffic that can be aggressively managed (dropped) and 7 represents high priority traffic. Traffic at a low precedence level typically has a higher drop probability. When WRED drops packets, source hosts using TCP detect the drops and slow the transmission of packets.

Note When you configure IP precedence-based WRED on an output policy map and the outgoing packets are MPLS packets, instead of using the 3-bit IP precedence field in the underlying IP packets, the router drops the MPLS packets based on the three experimental (EXP) bits in the MPLS label.

•DSCP-based WRED—Configures a drop policy for WRED based on a DSCP value. When configured, the router randomly drops packets with the specified DSCP value, according to the WRED thresholds you configure.

•Discard-class-based WRED—Configures a drop policy for WRED based on a discard-class value. Valid values are from 0 to 7. The discard-class value sets the per-hop behavior (PHB) for dropping traffic. WRED based on discard-class is an egress function.

•ATM cell loss priority-based WRED—Configures a drop policy for WRED based on a cell loss priority (CLP) value. Valid values are 0 or 1. When configured, the router uses the value of the CLP bit to randomly drop packets leaving the Pseudowire and going out an ATM interface. The router also supports ATM CLP-based WRED on non-Layer2 VPN outbound ATM interfaces.

You can also configure WRED to ignore the IP precedence, DSCP, or discard-class when making drop decisions. As a result, the router implements non-weighted random early detection (RED) behavior when deciding which packets to drop.

Note The PRE2 uses sampled RED and the PRE3 uses per-packet RED.

Feature History for Weighted Random Early Detection

Cisco IOS Release

Description

Required PRE

Release 12.0(17)SL

The weighted random early detection feature was introduced on the router.

PRE1

Release 12.0(22)S

This feature was enhanced to allow you to configure WRED based on a differentiated services code point (DSCP).

PRE1

Release 12.0(25)SX

This feature was enhanced to allow you to simultaneously configure the random-detect command and the queue-limit for the same class queue.

PRE1

Release 12.2(16)BX

This feature was introduced on the PRE2 and uses sampled RED.

PRE2

Release 12.3(7)XI

This feature was enhanced on the PRE2 to:

•Enable the configuration of eight unique drop precedence levels for one queue instead of four levels

•Allow the simultaneous configuration of both the random-detect and queue-limit commands for a class queue

•Support discard-class-based WRED

•Maintain separate WRED drop statistics for each IP precedence, DSCP value, and discard-class

PRE2

Release 12.2(28)SB

This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2.

PRE2

Release 12.2(31)SB2

This feature was introduced on the PRE3 and uses per-packet RED. This feature is DiffServ-compliant on the PRE3.

PRE3

Release 12.2(33)SB

This feature was enhanced to support ATM cell loss priority-based WRED on the PRE2, PRE3 and PRE4.

PRE2, PRE3, PRE4

Benefits of Using Weighted Random Early Detection

Weighted random early detection (WRED) has the following benefits:

•WRED provides early detection of congestion for one or multiple traffic classes. It also protects against global synchronization. For these reasons, WRED is useful on any outbound interface where you expect congestion to occur.

•WRED provides separate thresholds and weights for different IP precedence levels, which allows you to provide different qualities of service for packet dropping for different traffic types. For example, during congestion WRED can drop standard traffic more frequently than premium traffic.

How WRED Works

When an output interface begins to show signs of congestion, but is not fully congested yet, WRED begins selectively dropping packets based on the IP precedence, DSCP, or discard-class level of the packet. WRED uses the minimum and maximum threshold values to determine the drop probability for packets. Typically, for drop policies with low values (closer to 0), WRED drops packets with low values (closer to 0) with a higher probability, based on the drop policy configuration.

For example, IP precedence-based WRED uses the IP precedence level of packets to selectively drop packets. WRED drops packets with a low precedence value (closer to 0) with a higher probability based on the WRED configuration. The higher the precedence value of a packet (the closer to 7), the greater the probability that WRED ignores the packet and allows the router to forward the packet to its destination.

WRED allows the transmission line to be used fully at all times, especially when most of the traffic is TCP/IP traffic. For TCP/IP traffic, the action of WRED dropping packets indicates congestion and causes a source host to reduce its transmission rate. After all of the packets reach their destinations (indicating reduced congestion), the source host increases the transmission rate again.

By dropping some packets early, WRED avoids dropping large numbers of packets at once and minimizes the chances of global synchronization. Global synchronization occurs when multiple TCP hosts reduce their transmission rates in response to packet dropping and then increase their transmission rates again when congestion reduces.

With protocols other than TCP/IP, packet sources might not respond to dropped packets by reducing their transmission rates. Instead, such hosts might resend the dropped packets at the same rate. As a result, when WRED drops packets, congestion is not decreased.

Statistically, WRED drops more packets from large users than from small users. Therefore, WRED is more likely to slow down the traffic sources that generate the most traffic and not the traffic sources that generate little traffic.

WRED Drop Mode

A WRED drop mode indicates the basis upon which the WRED drop policy is applied. The router supports DSCP, IP precedence, discard-class, and ATM cell loss priority (CLP) based WRED.

Table 11-4 lists the commands used to enable the WRED drop modes.

Note If you do not specify any arguments, WRED uses the default IP precedence in the WRED calculations.

Table 11-4 WRED Drop Mode Commands

Command

Description

random-detect dscp-based min-thresh-value max-thresh-value mark-probability-denominator-value

Drops packets based on a DSCP value. This option is available on the PRE2, PRE3, and PRE4.

random-detect prec-based min-thresh-value max-thresh-value mark-probability-denominator-value

Drops packets based on an IP precedence value. This option is available on the PRE2, PRE3, and PRE4.

random-detect discard-class-based min-thresh-value max-thresh-value mark-probability-denominator-value

Drops packets based on a discard-class value. This option is available on the PRE2, PRE3, and PRE4.

Note The min-thresh-value option is not available on the PRE3 for this command.

random-detect atm-clp-based min-thresh-value max-thresh-value mark-probability-denominator-value

Drops packets based on an ATM cell loss priority (CLP) value. This option is available on the PRE2, PRE3, and PRE4.

The minimum threshold indicates the minimum number of packets allowed in the queue. When the average queue length reaches the minimum threshold, WRED randomly drops some packets with the specified DSCP, IP precedence, or discard-class value. Valid minimum threshold values are from 1 to 16,384. This option is not available on the PRE3 for the random detect discard-class command.

The maximum threshold indicates the maximum number of packets allowed in the queue. When the average queue length exceeds the maximum threshold, WRED drops all packets with the specified DSCP, IP precedence, or discard-class value. Valid maximum threshold values are from the value of the min-threshold to 1.

The maximum probability denominator is the drop rate. It specifies the denominator for the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 512, 1 out of every 512 packets is dropped when the average queue is at the maximum threshold. Valid values are from 1 to 65,535. The default value is 10.

For information about the behavior of the random-detect command on the various PRE processor cards, see the "WRED Drop Profiles" section and the "WRED Aggregate Drop Profiles" section.

WRED Drop Profiles

A WRED drop profile specifies DSCP, IP precedence, discard-class, or ATM CLP values, which WRED uses to determine the drop probability of packets.

Table 11-5 lists the commands used to configure a packet drop policy. The behavior of these commands depends on the PRE installed in the router as the following describes:

•On the PRE2, the random-detect command specifies the default profile for the queue.

•On the PRE3 and PRE4, the supported random-detect commands specify the aggregate profile for the queue. To configure a default drop profile for a queue, the random-detect basis command is used (for example, random-detect dscp-based aggregate command). The random-detect discard-class-based and random-detect atm-clp-based commands do not have an aggregate form of the command on the PRE3 and PRE4.

Note If you do not specify any arguments, WRED uses the default IP precedence in the WRED calculations.
Table 11-5 WRED Drop Profile Commands
Command

Description
random-detect dscp dscp-value min-thresh-value max-thresh-value mark-probability-denominator-value
PRE3 and PRE4

random-detect dscp values sub-class-val1 [...[sub-class-val8]] minimum-thresh min-thresh-value maximum-thresh max-thresh-value mark-prob mark-prob-value
A number that indicates the drop eligibility of a packet based on the differentiated services code point. Value numbers are from 0 to 63.
random-detect ip precedence precedence-value min-thresh-value max-thresh-value mark-probability-denominator-value
PRE3 and PRE4

random-detect precedence values sub-class-val1 [...[sub-class-val8]] minimum-thresh min-thresh-value maximum-thresh max-thresh-value mark-prob mark-prob-value
A number that indicates the drop eligibility of a packet based on the IP precedence level. Valid values are from 0 to 7. Typically, 0 represents low priority traffic that can be aggressively managed (dropped) and 7 represents high priority traffic.
random-detect discard-class discard-class-value min-thresh-value max-thresh-value mark-probability-denominator-value
PRE3 and PRE4

random-detect discard-class discard-class-value min-thresh-value max-thresh-value mark-probability-denominator-value
A number that indicates the drop eligibility of a packet based on the discard-class. Valid values are from 0 to 7.
random-detect atm-clp clp-value min-thresh-value max-thresh-value mark-probability-denominator-value
PRE3 and PRE4

random-detect atm-clp clp-value min-thresh-value max-thresh-value mark-probability-denominator-value
A number that indicates the drop eligibility of a packet based on the ATM CLP. Valid values are 0 or 1.
On the PRE3, the number of WRED profiles supported per policy map depends on the number of interfaces with attached service policies:

•When less than 32,000 interfaces have service policies, the PRE3 supports 21 non-default WRED profiles and 16 default profiles per policy map. The 16 default profiles includes profiles for the class-default queue, net-control, and two priority queues. However, you cannot configure the default profiles for net-control and priority queues. Therefore, the PRE3 allows default profiles for 12 non-default (user) queues and one class-default queue per policy map.

•When 32,000 to 64,000 interfaces have service policies, the PRE3 supports any combination of non-default WRED and default profiles. The maximum total number of profiles (non-default and default) supported in a policy map is 21.

•When less than 32,000 interfaces have service policies, the PRE3 supports up to 21 non-default WRED profiles and up to 16 default profiles per policy map. The 16 default profiles include the class-default, net-control, and two priority queues. However, the default profiles for net-control and priority queues are not user-configurable; therefore the actual number of default profiles for user-configured queues is 12 with one class-default class per policy map.

Table 11-6 summarizes the WRED profiles supported by various PREs.

Table 11-6 WRED Profiles Support

Performance Routing Engine

Number of Non- Default WRED Profiles

Number of Default Profiles Per Policy Map

Number Interfaces with Service Policies

PRE1

4

No hard limit

Varies¹

PRE2

8

No hard limit

Varies²

PRE3

21 per policy map

16³ per policy map

Less than 32,000

21 total explicit and default profiles per policy map

32,000 to 64,000

¹Depends on a combination of factors, such as the number of queues on the router and packet heaps. Changes in the queue length and the number of classes per policy map also affect the number of interfaces on which policy maps can be applied.

²See footnote 1.

³Includes profiles for class-default, net-control, and two priority queues.

WRED Aggregate Drop Profiles

On the PRE3 and PRE4, WRED is extended to support an aggregate drop profile. A single random-detect command with multiple subclasses specified is used to configure the profile. The subclasses (for example, multiple DSCP values) share one specified minimum and maximum threshold and one specified mark-probability denominator.

Although the PRE3 and PRE4 allow you to specify only one DSCP or IP precedence value in the random-detect command (which is equivalent to the PRE2 form of the command), the advantage of aggregating DSCP or IP precedence values is that an aggregate drop profile only counts as one profile toward the maximum number of profiles allowed. As a result, you can configure drop profiles for more DSCPs or IP precedence levels using aggregation than you can when specifying only one value for each WRED profile.

The PRE3 and PRE4 random-detect commands have the following syntax:
random-detect aggregate [minimum-thresh min-thresh-value maximum-thresh max-thresh-value 
mark-prob mark-prob-value]
random-detect {precedence-based | dscp-based} aggregate [minimum-thresh min-thresh-value 
maximum-thresh max-thresh-value mark-prob mark-prob-value]
random-detect {precedence | dscp} values [sub-class-val1 [...sub-class-val8] 
[minimum-thresh min-thresh-value maximum-thresh max-thresh-value mark-prob 
mark-prob-value]]
Note If you enter the random detect command without the aggregate profile, the PRE3 and PRE4 accept the command, but the default action is to tail drop. For example:
random-detect {precedence-based | dscp-based}

The PRE3 and PRE4 also supports drop profiles based on discard class and cell loss priority (CLP), but do not use the aggregate form of the command. Instead, the PRE3 and PRE4 support the PRE2 form of the commands:
random-detect {discard-class-based | atm-clp-based}
random-detect {discard-class discard-class-value | clp clp-value} [min-thresh-value] 
[max-thresh-value] [mark-probability-denominator-value]
For example, to configure a WRED DSCP profile, the following command creates drop profiles for DSCP value 1, DSCP value 2, and so on. Each profile has the same specified drop threshold and mark-probability denominator. The router aggregates these drop profiles, that is statistics are counted for the group of all of the DSCP values together.
random-detect dscp values [dscp-val1 [...dscp-val8] [minimum-thresh min-thresh-value 
maximum-thresh max-thresh-value mark-prob mark-prob-value]
To have the statistics counted for each DSCP separately, enter the random-detect command once for each DSCP value, using the same threshold values and mark-probability denominator.

Statistics displayed for the subclasses are aggregated and shown in one line. If some subclasses do not have a user-defined WRED profile, the router collects the statistics as an aggregate for the unconfigured subclasses and displays the statistics in one line. The router maintains separate statistics for each random-detect command with a group of subclasses.

On the PRE3 and PRE4, the random-detect command is used to configure a default drop profile for a queue and has the following syntax:
random-detect {precedence-based | dscp-based} aggregate [minimum-thresh min-thresh-value 
maximum-thresh max-thresh-value mark-prob mark-prob-value]
If you enter the random-detect command without the aggregate profile (the equivalent of the PRE2 command), the PRE3 and PRE4 accept the command, but the default action is to tail drop.
random-detect {precedence-based | dscp-based} 
The PRE3 and PRE4 support drop profiles based on discard class and ATM CLP, but do not use the aggregate form of the command. Instead, the PRE3 and PRE4 support the PRE2 form of the commands:
random-detect discard-class-based
random-detect discard-class discard-class-value min-thresh-value max-thresh-value 
mark-probability-denominator-value
random-detect atm-clp-based
random-detect clp clp-value min-thresh-value max-thresh-value 
mark-probability-denominator-value
Usage Guidelines for the random-detect Command

General

If you do not specify any arguments, WRED uses the default IP precedence value to calculate the drop probability.

When specifying class policy within a policy map, you can use the random-detect command with the bandwidth command.

To modify the queue length, always use the queue-limit command instead of the max-threshold parameter of the random-detect command. Modifying the max-threshold parameter does not necessarily change the queue limit. When you increase the max-threshold parameter, WRED adjusts the queue length to be no less than the max-threshold value. However, when you reduce the max-threshold parameter, WRED does not change the queue length.

exponential-weight-constant

The router calculates the average queue size based on the previous average and the current size of the queue, using the following formula:

Average = (old-average * (1 - 2 - n)) + (current-queue-size * 2 - n)

where n is the exponential weight constant

For MPLS packets, when you use precedence-based WRED, the router calculates the average queue size using the MPLS experimental (EXP) bits.

random-detect dscp

You must first enable the drop mode by using the random-detect dscp-based command. You can then set the drop probability profile by using the random-detect dscp command.

With the dscp-based keyword, WRED uses the DSCP value (that is, the first six bits of the IP type of service (ToS) byte) to calculate the drop probability.

random-detect ip precedence

You must first enable the drop mode by using the random-detect prec-based command. You can then set the drop probability profile by using the random-detect ip precedence command.

With the prec-based keyword, WRED uses the IP precedence value to calculate the drop probability.

For all precedence levels, the mark-probability-denominator default value is 10, and the max-threshold is based on the output buffering capacity and the transmission speed for the interface.

If you want weighted random early detection (WRED) to ignore the precedence level when determining which packets to drop, enter this command with the same parameters for each precedence level. Remember to use reasonable values for the minimum and maximum thresholds.

random-detect discard-class

You must first enable the drop mode by using the random-detect discard-class-based command. You can then set the drop probability profile by using the random-detect discard-class command.

With the discard-class-based keyword, WRED uses the discard-class value to calculate the drop probability.

Minimum and Maximum Thresholds

The random-detect command allows you to specify the minimum and maximum threshold settings for a class queue:

•Minimum threshold—The minimum number of packets allowed in the queue. When the average queue length reaches the minimum threshold, weighted random early detection (WRED) randomly drops some packets with the specified DSCP, IP precedence, discard-class, or atm-clp value. Valid minimum threshold values are from 1 to 16,384.

•Maximum threshold—The maximum number of packets allowed in the queue. When the average queue length exceeds the maximum threshold, WRED drops all packets with the specified DSCP, IP precedence, discard-class, or atm-clp value. Valid maximum threshold values are from the value of the minimum threshold to 16,384.

Table 11-7 lists the default drop thresholds for weighted random early detection (WRED) based on DSCP, IP precedence, and discard-class. For example, if a user-defined drop profile is not available, for discard-class 3, the router calculates the minimum and maximum thresholds as follows:

Minimum threshold = 11/32 * queue size

Maximum threshold = 1/2 * queue size

The drop probability indicates that the router drops one packet for every 10 packets.

Note Table 11-7 applies to the PRE2. On the PRE3, when you specify a WRED default drop profile for a queue, the same profile applies to all DSCP or precedence values. If you do not configure the default profile, the behavior is to tail drop.

Table 11-7 Weighted Random Early Detection Default Drop Thresholds

DSCP, Precedence, and Discard-Class Values

Minimum Threshold

(times the queue size)

Maximum Threshold

(times the queue size)

Drop Probability

All DSCPs

1/4

1/2

1/10

0

1/4

1/2

1/10

1

9/32

1/2

1/10

2

5/16

1/2

1/10

3

11/32

1/2

1/10

4

3/8

1/2

1/10

5

13/32

1/2

1/10

6

7/16

1/2

1/10

7

15/32

1/2

1/10

For more information about how WRED uses the minimum and maximum thresholds, and the drop probability parameters, see the "Determining Packet Drop Probability" section.

WRED and Queue Limit

To help you manage packet delay due to congestion, you can configure weighted random early detection (WRED) on a class queue and customize the size of the queue using the queue-limit command. This allows you to establish a drop policy for a traffic class and simultaneously limit the maximum number of packets allowed to accumulate in the class queue.

WRED controls the average length of a queue and queue-limit controls the maximum number of packets that can be waiting for transmission at any time. Together, these mechanisms limit packet delay.

Note To simultaneously configure WRED and queue limit for a class in a policy map, the router must be running Cisco IOS Release 12.3(7)XI or later releases. In releases prior to Cisco IOS Release 12.3(7)XI, you can configure either the random-detect command or the queue-limit command, but not both commands at the same time.

If you do not specify a queue limit, the router uses the default queue limit of two times the largest maximum threshold, rounded to the nearest power of 2.

Note To modify the queue length, always use the queue-limit command instead of the max-threshold parameter of the random-detect command. Modifying the max-threshold parameter does not necessarily change the queue limit. When you increase the max-threshold parameter, WRED adjusts the queue length to be no less than the max-threshold value. However, when you reduce the max-threshold parameter, WRED does not change the queue length.

Average Queue Size and the Exponential Weight Constant

The router calculates the average queue size based on the previous average and the current size of the queue, using the following formula:

Average = (old-average * (1 - 2 - n)) + (current-queue-size * 2 - n)

where n is the exponential weight constant

You can configure the exponential weight constant; however, we recommend that you use the default value of 9. Valid values are from 1 to 16.

•A high exponential weight constant smooths out the peaks and lows in queue length. The average queue size is unlikely to change very quickly, avoiding drastic swings in size. WRED might be slow to start dropping packets and can 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 exponential weight constant is too high, WRED does not react to congestion and packets are transmitted or dropped as if WRED were not in effect.

•If the exponential weight constant is too low, the average queue size might fluctuate with changes in the traffic levels. As a result, WRED responds quickly to long queues, overreacts to temporary traffic bursts, and drops traffic unnecessarily. After the queue falls below the minimum threshold, WRED stops dropping packets.

Interfaces Supporting Layer 3 Packet Drop Policies

The following describes interface support for tail drop, random early detection (RED), and weighted random early detection (WRED) drop policies using the queue-limit and random-detect commands:

Interfaces Supporting the queue-limit and random-detect Commands (Outbound Only)

•Physical

•Multilink PPP and Multilink Frame Relay

•ATM shaped (peak cell rate is specified) unspecified bit rate (UBR) PVCs and point-to-point subinterfaces *

•ATM constant bit rate (CBR) PVCs and point-to-point subinterfaces *

•ATM variable bit rate (VBR) PVCs and point-to-point subinterfaces *

•Label-controlled ATM (LC-ATM) subinterfaces **

•Frame Relay PVCs, point-to-point subinterfaces, and map classes **

•Ethernet VLANs **

* The PRE3 does not support the queue-limit and random-detect commands on ATM subinterfaces because the PRE3 only supports MQC policy maps on ATM PVCs.

** Requires a specific type of hierarchical policy. For more information, see the Chapter 13, "Defining QoS for Multiple Policy Levels."

Note The router supports the queue-limit and random-detect commands on outbound interfaces only.

Interfaces Not Supporting the queue-limit and random-detect Commands

•ATM unshaped (no peak cell rate specified) UBR PVCs and point-to-point subinterfaces

•IP tunnel

•Virtual-access (See the "VAI QoS Inheritance" section on page 4-24.)

Note The router does not support the queue-limit and random-detect commands on inbound interfaces.

Restrictions and Limitations for Controlling Layer 3 Congestion

Queue Limit

•You cannot apply queue limits to ATM unshaped unspecified bit rate (UBR) PVCs. Unshaped UBR PVCs do not have a peak cell rate (PCR) specified.

•For classes other than class-default, when you configure a queue limit, you must also configure one of the following commands for the class:

–bandwidth

–bandwidth remaining (PRE2), bandwidth remaining ratio (PRE3), or bandwidth remaining percent (PRE3)

–priority

–shape

•For releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, you cannot combine the queue-limit command with the random-detect command.

•The router restricts the aggregate sum of queue limits to 1,048,576 (PRE1) or 4,194,304 (PRE2) packets.

•If you attempt to change the queue size when packets are in the queue, the router does not change the queue size. However, changing the queue size several times can cause the buffers to become fragmented or the buffers can still be in use. When you attempt to change the queue size again (with or without traffic running), a traceback message or an "out of resources" message might appear, or both messages might appear. The workaround for this is to execute the same queue-limit command again. Use the show pxf cpu queue summary command to determine if traffic is being properly distributed. (See CSCed81996.)

Note In Cisco IOS Release 12.2(33)SB and later releases, the show pxf cpu queue interface summary command displays the physical interface and the number of logical links. It no longer displays the number of priority queues, class queues and so on.

The following are examples of the messages that appear:

Without traffic running:
-Traceback= 604D58EC 604C00C0 604C0288 604C43C4 604C43E4 604C254C 604C260C 
604C478C 60D4B868 603AC304 6013B410 603C6270 604569C0 604569A4 
!
With traffic running:
Router# config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# policy-map qos_pq_cbwfq_0
Router(config-pmap)# class dscp_10 
Router(config-pmap-c)# queue-limit 32
Queue limit failed on ATM2/0/0.2484 VC 2484 (out of resources)
Queue limit failed on ATM2/0/0.2485 VC 2485 (out of resources)
Queue limit failed on ATM2/0/0.2486 VC 2486 (out of resources)
Queue limit failed on ATM2/0/0.2487 VC 2487 (out of resources)
Queue limit failed on ATM2/0/0.2488 VC 2488 (out of resources)
Queue limit failed on ATM2/0/0.2489 VC 2489 (out of resources)
!
!
Queue limit failed on ATM3/0/0.1547 VC 1547 (out of resources)
Queue limit failed on ATM3/0/0.1548 VC 1548 (out of resources)
!
!
-Traceback= 604D58EC 604C00C0 604C0288 604C43C4 604C43E4 604C254C 604C260C 
604C478C 60D4B868 603AC304 6013B410 603C6270 604569C0 604569A4 
-Traceback= 6049CA48 6049CCA4 60489224 60493688 604BFA4C 604C3EEC 604C3EE4 
604C2554 604C260C 604C478C 60D4B868 603AC304 6013B410 603C6270 604569C0 604569A4
Random Early Detection and Weighted Random Early Detection

•For classes other than class-default, you must use random early detection (RED) with the bandwidth, bandwidth remaining, or shape command.

•You cannot use DSCP-based WRED with Multiprotocol Label Switching (MPLS) encapsulated packets. The router supports this feature for use with IP packets only.

•You must configure the bandwidth command before you configure the random-detect dscp-based, random-detect prec-based, or random-detect discard-class-based command to enable WRED.

•For DSCP-based WRED, you can configure:

–One default drop profile for each class

–Three assured forwarding (AF) drop profiles for each class

–Four non-AF drop profiles for each policy map (PRE1) or four non-AF drop profiles for each class (PRE2)

•On the PRE3, when you configure multiple WRED profiles for a specific traffic class in a policy map, each WRED profile within the same class must be based on the same drop type: DSCP-based, precedence-based, or discard-class-based. You cannot mix drop types within a class in a policy map. For example, the following example configuration shows how to configure WRED for the Bronze class. Notice that each of the WRED profiles is based on a DSCP.
class-map Bronze
match ip dscp 1 2 3
policy-map Business
class Bronze
random-detect dscp 1 100 200 1
random-detect dscp default 200 400 1
•On the PRE2, DSCP-based WRED enables you to configure eight unique drop precedence levels for one queue. Each of the 64 (0 to 63) DSCP values correspond to one of the eight drop levels. The default setting applies to any DSCP-based WRED without a specified minimum and maximum threshold value.

•On the PRE1, DSCP-based WRED enables you to configure four unique drop precedence levels for one queue. Each of the 64 DSCP values correspond to one of the four drop levels. When you configure the four unique drop precedence levels, all of the queues configured on an interface share the different levels.

•For PRE1, you cannot use DSCP-based and IP precedence-based WRED together in the same policy map.

Configuring Layer 3 Queue Limit and Drop Policies

To configure the queue limit of a class queue and a drop policy, perform any of the following configuration tasks:

•Controlling Packet Dropping by Setting the Size of a Class Queue

•Dropping Packets Based on a Differentiated Services Code Point

•Dropping Packets Based on IP Precedence

•Dropping Packets Based on the Discard Class

•Dropping Packets Based on the ATM Cell Loss Priority

Controlling Packet Dropping by Setting the Size of a Class Queue

To control when the router drops packets (for example, using tail drop), configure the maximum number of packets a class queue can hold by entering the following commands beginning in global configuration mode:

Command

Purpose

Step 1

Router(config)# policy-map policy-map-name

Specifies the name of the policy map and enters policy-map configuration mode.

policy-map-name is the name of the policy map.

Step 2

Router(config-pmap)# class class-map-name

Assigns the traffic class you specify to the policy map. Enters policy-map class configuration mode.

class-map-name is the name of a previously configured class map and is the traffic class for which you want to define QoS actions.

Step 3

Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}

Specifies the amount of bandwidth (in kbps or as a percentage of available bandwidth) to be assigned to the class. The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead.

Step 4

Router# queue-limit number-of-packets

Specifies or modifies the maximum number of packets that the queue can hold for this class.

For PRE1, number-of-packets is a number from 32 to 16,384; the number must be a power of 2. If the number you specify is not a power of 2, the router converts the number to the nearest power of 2 value.

For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX with PRE2, number-of-packets is a number from 32 to 16,384. The number does not need to be a power of 2.

For Cisco IOS Release 12.3(7)XI and later releases with PRE2, if the interface speed is less than 500 MB, number-of-packets is a number from 8 to 4096; the number must be a power of 2. If the interface speed is greater than 500 MB, number-of-packets is a number from 128 to 64,000; the number must be a power of 2.

For PRE3, number-of-packets is a number from 1 to 32,767. The number does not need to be a power of 2.

If you do not specify number-of-packets, by default the router uses the values described in the "Queue-Limit Default Behavior" section.

Queue-Limit Default Behavior

The following describes the default behavior of the queue-limit command for class queues with and without weighted random early detection (WRED):

•Class queues with weighted random early detection (WRED)—The router uses the default queue limit of two times the largest WRED maximum threshold value, rounded to the nearest power of 2.

Note For Cisco IOS Release 12.2(15)BX and Release 12.2(16)BX, the router does not round the value to the nearest power of 2.

•Priority queues and class queues without WRED—The router has buffers for up to 50 milliseconds of 256-byte packets at line rate, but not less than 32 packets.

Configuration Example for Controlling Packet Dropping by Setting a Queue Size

Example 11-1 shows how to create a policy map named Policy1 that contains two classes named Class1 and Class2. The Class1 configuration requests a specific bandwidth allocation and specifies the maximum number of packets that can be queued for the class. Because Class1 limits the number of packets that can be held in the queue to 32, the router uses tail drop to drop packets when that limit is reached. Class2 specifies only the bandwidth allocation request. The Policy1 QoS service policy is applied to the point-to-point PVC 1/32 for outbound packets.

Example 11-1 Configuring a Queue Limit to Control Tail Drop
Router(config)# policy-map Policy1
Router(config-pmap)# class Class1
Router(config-pmap-c)# bandwidth 3000
Router(config-pmap-c)# queue-limit 32
Router(config-pmap-c)# exit
Router(config-pmap)# class Class2
Router(config-pmap-c)# bandwidth 2000
Router(config-pmap-c)# exit
Router(config)# interface atm 1/0/0
Router(config-if)# atm pxf queuing
Router(config-if)# interface atm 1/0/0.1 point-to-point
Router(config-subif)# pvc 1/32
Router(config-subif-atm-vc)# ubr 10000
Router(config-subif-atm-vc)# service-policy output Policy1 
Dropping Packets Based on a Differentiated Services Code Point

To configure WRED to drop packets based on a specific differentiated services code point (DSCP) value, enter the following commands beginning in global configuration mode:
Command

Purpose

Step 1

Router(config-if)# class-map class-map-name

Creates a class map to be used for matching packets to a specified class. Enters class map configuration mode.

class-map-name identifies the class map.

Step 2

Router(config-cmap)# match match-criterion

Configures the match criterion for a class map.

match-criterion is a match statement that indicates how the router is to classify packets. See the "Defining Match Criteria Using the match Commands" section on page 2-5.

Step 3

Router(config-cmap)# exit

Exits class map configuration mode.

Step 4

Router(config)# policy-map policy-map-name

Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy. Enters policy map configuration mode.

policy-map-name is the name of the policy map.

Step 5

Router(config-pmap)# class class-map-name

Specifies the name of the traffic class for which you want to define QoS actions. Enters policy map class configuration mode.

class-map-name identifies the traffic class. It is the name of the class-map you configured in Step 1.
Step 6
PRE2
Router(config-pmap-c)# random-detect dscp-based
PRE3
Router(config-pmap-c)# random-detect dscp-based aggregate [minimum-thresh min-thresh maximum-thresh max-thresh mark-prob mark-prob]
Indicates that WRED is to use the DSCP value when calculating the drop probability for a packet.

(Optional) min-thresh is the minimum number of packets allowed in the queue. Valid minimum threshold values are from 1 to 16,384.

(Optional) max-thresh is the maximum number of packets allowed in the queue. Valid maximum threshold values are from the value of the minimum threshold to 16,384.

(Optional) mark-prob is the drop rate. Valid values are from 1 to 65,535. The default value is 10.
Step 7
PRE2
Router(config-pmap-c)# random-detect dscp dscp-value min-thresh-value max-thresh-value mark-probability-denominator-value
PRE3
Router(config-pmap-c)# random-detect dscp values sub-class-val1 [...[sub-class-val8]] minimum-thresh min-thresh maximum-thresh max-thresh mark-prob mark-prob
Configures WRED to drop packets based on the DSCP value you specify.

dscp-value or sub-class-val is a number or keyword that indicates the differentiated services code point. Value numbers are from 0 to 63, or it can be one of the following keywords: ef, af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs1, cs2, cs3, cs4, cs5, or cs7.

min-threshold is the minimum number of packets allowed in the queue. Valid minimum threshold values are from 1 to 16,384.

max-thresh is the maximum number of packets allowed in the queue. Valid maximum threshold values are from the value of the minimum-threshold to 16,384.

mark-probability-denominator-value (PRE2) or mark-prob (PRE3) is the drop rate. Valid values are from 1 to 65,535. The default value is 10.
Step 8

Router(config-pmap-c)# exit

Exits policy map class configuration mode.

Step 9

Router(config-pmap)# exit

Exits policy map configuration mode.

Step 10

Router(config)# interface type slot/module/port.subinterface-number

Configures an interface type and enters interface configuration mode.

Step 11

Router(config-if)# service-policy output policy-map-name

Attaches a policy map to an output interface or VC to be used as the service policy for that interface or VC.

policy-map-name is the name of the policy map you configured in Step 4.
Configuration Example for Configuring DSCP-Based WRED

Example 11-2 shows how to create a class map named Gold and associate it with the policy map named Business. The configuration enables WRED to drop Gold packets based on DSCP 8 with a minimum threshold of 24 and a maximum threshold of 40. The Business policy map is attached to the outbound ATM interface 1/0/0.

Example 11-2 Configuring DSCP-Based WRED
Router(config-if)# class-map Gold 
Router(config-cmap)# match access-group 101 
Router(config-cmap)# exit
Router(config)# policy-map Business 
Router(config-pmap)# class Gold
Router(config-pmap-c)# bandwidth 48 
Router(config-pmap-c)# random-detect dscp-based 
Router(config-pmap-c)# random-detect dscp 8 24 40 
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface atm 1/0/0
Router(config-if)# service-policy output Business
Dropping Packets Based on IP Precedence

To drop packets based on IP precedence, enter the following commands beginning in global configuration mode:
Command

Purpose

Step 1

Router(config)# policy-map policy-map-name

Specifies the name of the policy map to be created or modified. Enters policy-map configuration mode.

policy-map-name is the name of the policy map.

Step 2

Router(config-pmap)# class class-map-name

Assigns the traffic class you specify to the policy map. Enters policy-map class configuration mode.

class-map-name is the name of a previously configured class map and is the traffic class for which you want to define QoS actions.
Step 3
PRE2
Router(config-pmap-c)# random-detect precedence-based
PRE3
Router(config-pmap-c)# random-detect precedence-based aggregate [minimum-thresh min-thresh maximum-thresh max-thresh mark-prob mark-prob]
Indicates that weighted random early detection (WRED) is to use the IP precedence of a packet when calculating the packet drop probability.

(Optional) min-thresh is the minimum number of packets allowed in the queue. Valid minimum threshold values are from 1 to 16,384.

(Optional) max-thresh is the maximum number of packets allowed in the queue. Valid maximum threshold values are from the value of the minimum threshold to 16,384.

(Optional) mark-prob is the drop rate. Valid values are from 1 to 65,535. The default value is 10.
Step 4
Router(config-pmap-c)# random-detect precedence prec-value min-thresh-value max-thresh-value mark-probability-denominator-value
PRE3
Router(config-pmap-c)# random-detect precedence values sub-class-val1 [...[sub-class-val8]] minimum-thresh min-thresh maximum-thresh max-thresh mark-prob mark-prob
Configures WRED to drop packets based on the IP precedence value you specify.

prec-value (PRE2) or values sub-class-val (PRE3) is a number that identifies the IP precedence level. Valid values are from 0 to 7.

min-thresh is the minimum number of packets allowed in the queue. Valid minimum threshold values are from 1 to 16,384.

max-thresh is the maximum number of packets allowed in the queue. Valid maximum threshold values are from the value of the minimum threshold to 16,384.

mark-probability-denominator-value (PRE2) or mark-prob (PRE3) is the drop rate. Valid values are from 1 to 65,535. The default value is 10.
Configuration Example for Dropping Packets Based on IP Precedence

Example 11-3 shows how to enable IP precedence-based weighted random early detection (WRED). In this example, the configuration of the class map named Class1 indicates to classify traffic based on IP precedence 3, 4, and 5. Traffic that matches IP precedence 3, 4, or 5 is assigned to the class named Class1 in the policy map named Policy1. WRED-based packet dropping is configured for Class1 and is based on IP precedence 3 with a minimum threshold of 500, maximum threshold of 1500, and a mark-probability-denominator of 200. The QoS policy is applied to PVC 1/32 on the point-to-point ATM subinterface 1/0/0.1.

Example 11-3 Configuring IP Precedence-Based WRED
Router(config)# class-map Class1
Router(config-cmap)# match ip precedence 3 4 5
Router(config-cmap)# exit
Router(config)# policy-map Policy1
Router(config-pmap)# class Class1
Router(config-pmap-c)# bandwidth 1000
Router(config-pmap-c)# random-detect prec-based
Router(config-pmap-c)# random-detect precedence 3 500 1500 200
Router(config-pmap-c)# exit 
Router(config-pmap)# exit
Router(config)# interface atm 1/0/0
Router(config-if)# atm pxf queuing
Router(config-if)# interface atm 1/0/0.1 point-to-point
Router(config-subif)# pvc 1/32 
Router(config-subif-atm-vc)# ubr 10000
Router(config-subif-atm-vc)# service-policy output policy1
Dropping Packets Based on the Discard Class

To drop packets based on the discard class, enter the following commands beginning in global configuration mode:

Note Dropping packets based on the discard class requires Cisco IOS Release 12.3(7)XI or later releases (PRE2), or Cisco IOS Release 12.2(31)SB2 or later releases (PRE3).

Command

Purpose

Step 1

Router(config)# policy-map policy-map-name

Specifies the name of the policy map to be created or modified. Enters policy-map configuration mode.

policy-map-name is the name of the policy map.

Step 2

Router(config-pmap)# class class-map-name

Assigns the traffic class you specify to the policy map. Enters policy-map class configuration mode.

class-map-name is the name of a previously configured class map and is the traffic class for which you want to define QoS actions.

Step 3

PRE2, PRE3
Router(config-pmap-c)# random-detect discard-class-based

Indicates that weighted random early detection (WRED) is to use the discard class of a packet when calculating the packet drop probability.

Step 4

PRE2, PRE3
Router(config-pmap-c)# random-detect discard-class discard-class-value min-thresh-value max-thresh-value mark-probability-denominator-value

Configures WRED to drop packets based on the discard value you specify.

discard-class-value is a number that indicates the drop eligibility of a packet. Valid values are from 0 to 7.

min-thresh-value is the minimum number of packets allowed in the queue. Valid minimum threshold values are from 1 to 16,384.

max-thresh-value is the maximum number of packets allowed in the queue. Valid maximum threshold values are from the value of the minimum threshold to 16,384.

mark-probability-denominator-value is the drop rate. Valid values are from 1 to 65,535. The default value is 10.

Configuration Example for Dropping Packets Based on Discard Class

Example 11-4 shows how to enable discard-class-based weighted random early detection (WRED). In this example, the configuration of the class map named Silver indicates to classify traffic based on discard class 3 and 5. Traffic that matches discard class 3 or 5 is assigned to the class named Silver in the policy map named Premium. The Silver configuration includes WRED packet dropping based on discard class 5 with a minimum threshold of 500, maximum threshold of 1500, and a mark-probability-denominator of 200. The QoS policy is applied to PVC 1/81 on point-to-point ATM subinterface 2/0/0.2 in the outbound direction.

Example 11-4 Configuring Discard-Class-Based WRED
Router(config)# class-map Silver
Router(config-cmap)# match discard-class 3 5 
Router(config-cmap)# exit
Router(config)# policy-map Premium
Router(config-pmap)# class Silver
Router(config-pmap-c)# bandwidth percent 30
Router(config-pmap-c)# random-detect discard-class-based
Router(config-pmap-c)# random-detect discard-class 5 500 1500 200
Router(config-pmap-c)# exit 
Router(config-pmap)# exit
Router(config)# interface atm 2/0/0
Router(config-if)# atm pxf queuing
Router(config-if)# interface atm 2/0/0.2 point-to-point
Router(config-subif)# pvc 1/81
Router(config-subif-atm-vc)# ubr 10000
Router(config-subif-atm-vc)# service-policy output Premium
Dropping Packets Based on the ATM Cell Loss Priority

To drop packets based on the ATM cell loss priority (CLP), enter the following commands beginning in global configuration mode:

Note Dropping packets based on the CLP requires Cisco IOS Release 12.2(33)SB, or a later release.

Command

Purpose

Step 1

Router(config)# policy-map policy-map-name

Specifies the name of the policy map to be created or modified. Enters policy-map configuration mode.

policy-map-name is the name of the policy map.

Step 2

Router(config-pmap)# class class-map-name

Assigns the traffic class you specify to the policy map. Enters policy-map class configuration mode.

class-map-name is the name of a previously configured class map and is the traffic class for which you want to define QoS actions.

Step 3

Router(config-pmap-c)# random-detect atm-clp-based

Indicates that weighted random early detection (WRED) is to use the CLP value of a packet when calculating the packet drop probability.

Step 4

Router(config-pmap-c)# random-detect clp [clp-value] [min-thresh-value] [max-thresh-value] [mark-probability-denominator-value]

Configures WRED to drop packets based on the CLP value you specify.

clp-value is a number that indicates the cell loss priority of a packet. Valid values are 0 or 1.

(Optional) min-thresh-value is the minimum number of packets allowed in the queue. Valid minimum threshold values are from 1 to 16,384.

(Optional) max-thresh-value is the maximum number of packets allowed in the queue. Valid maximum threshold values are from the value of the minimum threshold to 16,384.

(Optional) mark-probability-denominator-value is the drop rate. Valid values are from 1 to 65,535. The default value is 10.

Configuration Example for Dropping Packets Based on the Cell Loss Priority

Example 11-5 shows how to configure ATM CLP-based WRED. In the example, traffic that matches CLP 1 is classified as belonging to class1. In the policy map named policymap1, the class1 configuration enables the ATM CLP-based WRED feature and configures WRED to randomly drop traffic with the CLP bit set to 1 when traffic exceeds the minimum threshold of 12 and the maximum threshold of 25. WRED uses a mark-probability-denominator of 10.

Example 11-5 Configuring CLP-Based WRED
Router(config)# class-map class1
Router(config-cmap)# match clp 1
Router(config-cmap)# exit
Router(config)# policy-map policymap1
Router(config-pmap)# class class1
Router(config-pmap-c)# random-detect atm-clp-based
Router(config-pmap-c)# random-detect clp 1 12 25 10
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Verifying and Monitoring Layer 3 Packet Dropping

For releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, the router maintains only the total random and tail drop statistics for all IP precedence levels.

In Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, and later releases, the router maintains separate WRED drop statistics for each IP precedence, DSCP, and discard-class value.

The router collects the following statistical information:

•Current average queue length

•Per-precedence random and maximum threshold packets and bytes dropped

To verify and monitor packet dropping, use any of the following commands in privileged EXEC mode:

Command

Purpose

Router# show interface type slot/module/port.subinterface

Displays configuration information about the interface you specify, including the current queue limit.

Router# show policy-map policy-map-name

Displays configuration information about the policy map you specify.

In Cisco IOS Release 12.3(7)XI and later releases, this command shows WRED drop counts for each IP precedence, DSCP value, and discard class.

In all releases prior to Cisco IOS Release 12.3(7)XI, this command shows drop counts for each class.

Router# show policy-map interface

Displays the configuration of classes configured for service policies on all interfaces.

Router# show pxf cpu queue interface

Displays the queuing statistics of an interface or VC.

For diagnostic purposes, use any of the following commands in privileged EXEC mode:

Command

Purpose

Router# show pxf cpu queue interface

Displays the output queue statistics for a particular interface. If you do not specify an interface, the route processor queue statistics display.

Use this command to determine if traffic is being properly distributed.

Note Each interface has two queues: low and high priorities. When you enter this command, the output that displays includes the following fields:

wq_len indicates the current depth of the output queue for the interface.

wq_limit_drop indicates the number of packets dropped because the output queue was full.

packet xmit indicates the number of packets that have been output.

byte xmit indicates the number of bytes that have been output.

Router# show pxf cpu queue interface summary

Displays queue scaling information such as:

•Number of queues and recycled queues

•Number of available queue IDs (QIDs)

•Number of packet buffers, recycled packet buffers, and free packet buffers

Note In Cisco IOS Release 12.2(33)SB, this command was modified to display only the physical interface and the number of logical links, and was implemented on the PRE3 and PRE4. The command output no longer displays the number of priority queues, class queues, and so on.

Router# show pxf cpu schedule

Displays the rates at which each interface gets packets from the forwarding engine.

Note The show pxf commands are entered as show hardware pxf on the PRE1.

Verification Example for Queue Size and Packet Dropping

Example 11-6 shows sample output for the show policy-map interface command. In this example, the policy map named Traffic-5-PR is attached to serial interface 1/0/0 and includes three traffic classes. The Voice-5-PR class has a configured queue limit of 32 packets with 0 packets dropped. The Gold-5-PR class also indicates that no packets dropped. The Silver-5-PR class has a configured queue limit of 64 packets with 0 packets dropped.

Example 11-6 Displaying Queue Sizes and Packet Drop Counts
Router# show policy-map interface serial 1/0/0
 Serial1/0/0 
  Service-policy output: Traffic-Parent (1051)
    Class-map: class-default (match-any) (1068/0)
      2064335 packets, 120273127 bytes
      5 minute offered rate 1000 bps, drop rate 0 bps
      Match: any  (1069)
        126970 packets, 3982597 bytes
        5 minute rate 0 bps
      Shape : 6000 kbps
      Service-policy : Traffic-5-PR (1052)
        Class-map: Voice-5-PR (match-all) (1053/1)
          82310 packets, 4938600 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip precedence 5  (1054)
          Output queue: 0/32; 82310/4938600 packets/bytes output, 0 drops
          Absolute priority
          Queue-limit: 32 packets
          Police:
            304000 bps, 1536 limit, 0 extended limit
            conformed 82312 packets, 4938720 bytes; action: transmit
            exceeded 0 packets, 0 bytes; action: drop
            violated 0 packets, 0 bytes; action: drop
        Class-map: Gold-5-PR (match-any) (1058/2)
          1125476 packets, 67528560 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip precedence 3  4  (1059)
            1125476 packets, 67528560 bytes
            5 minute rate 0 bps
          Output queue: 0/128; 1125503/67530180 packets/bytes output, 0 drops
          Bandwidth : 188 kbps (Weight 3)
        Class-map: Silver-5-PR (match-any) (1061/3)
          697908 packets, 41874480 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: ip precedence 0  1  2  (1062)
            697908 packets, 41874480 bytes
            5 minute rate 0 bps
          Output queue: 0/64; 697919/41875140 packets/bytes output, 0 drops
          Bandwidth : 71 kbps (Weight 1)
          Random-detect (precedence-based):
            Exponential weight: 9 (1/512)
            Current average queue length: 0 packets
            -------------------------------------------------
                      Min   Max Prob    Rand-Drops Tail-Drops
            -------------------------------------------------
                  0    16    32 1/10             0          0
                  1    18    32 1/10             0          0
                  2    20    32 1/10             0          0
                  3    22    32 1/10             0          0
                  4    24    32 1/10             0          0
                  5    26    32 1/10             0          0
                  6    28    32 1/10             0          0
                  7    30    32 1/10             0          0
          Queue-limit: 64 packets
        Class-map: class-default (match-any) (1066/0)
          158641 packets, 5931487 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any  (1067)
            158641 packets, 5931487 bytes
            5 minute rate 0 bps
          Output queue: 0/128; 31672/1695625 packets/bytes output, 0 drops
Verification Examples for DSCP-Based WRED

Example 11-7 shows sample output for the show policy-map interface command. In this example, DSCP-based weighted random early detection is configured on the nyusers class queue. The output shows the exponential weight of 9 used to calculate the average queue size. In this case, WRED has not dropped any packets based on DSCP 8 and DSCP 0 (default).

Example 11-7 Displaying DSCP-Based WRED Statistics
Router# show policy-map interface GigabitEthernet 3/0/0
GigabitEthernet3/0/0 
  Service-policy output: manhattan
    Class-map: nyusers (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 101
      Output queue: 0/128; 0/0 packets/bytes output, 0 drops
      Bandwidth : 47 kbps (Weight 0)
      Random-detect (DSCP-based):
        Exponential weight: 9 (1/512)
        Current average queue length: 0 packets
        ------------------------------------------------------
        Diff-Serv   Min   Max    Mark    Rand-Drops Tail-Drops
        codepoint  thres  thres  probability
        ------------------------------------------------------
              8    24    40      1/50        0          0
        Default    64   128      1/10        0          0
    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 
      Output queue: 0/4096; 0/0 packets/bytes output, 0 drops
Example 11-8 shows sample output for the show class-map command. The show class-map command output indicates that the router classifies traffic based on the default DSCP 0 and DSCP 1, 2, 3, and 5. Traffic must match all of these DSCP values before the router can assign the traffic to the per_dscp_class traffic class.

Example 11-8 Displaying Sample Output from the show class-map Command
Router# show class-map per_dscp_class 
 Class Map match-all per_dscp_class (id 11)
   Match ip  dscp default  1  2  3  5 
Example 11-9 shows sample output for the show policy-map command. The show policy-map command output indicates that the drop policy for the class named per_dscp_class is based on DSCP 1, 2, 3, and 5.

Example 11-9 Displaying Sample Output from the show policy-map Command
Router# show policy-map per_dscp_policy
  Policy Map per_dscp_policy
    Class per_dscp_class
      priority
      random-detect dscp-based
      random-detect dscp 1 10 20 50
      random-detect dscp 2 10 40 20
      random-detect dscp 3 100 400 20
      random-detect dscp 5 22 60 30
Verification Example for IP Precedence-Based WRED

Example 11-10 shows sample output for the show policy-map interface command when IP precedence-based WRED is configured on the new-users class queue. For each precedence level, the output indicates the minimum and maximum thresholds, the mark probability value, the number of packets dropped using RED, and the number of packets dropped using tail drop.

Example 11-10 Displaying IP Precedence-Based WRED Statistics
Router# show policy-map interface FastEthernet 3/0/0
 FastEthernet3/0/0 
  Service-policy output: voice
    Class-map: new-users (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 101
      Output queue: 0/128; 0/0 packets/bytes output, 0 drops
      Bandwidth: 47 kbps (Weight 0)
	Random-detect (precedence-based):
	Exponential weight: 9 (1/512)
	Current average queue length: 0 packets
	-----------------------------------------------------------------------
	TOS 	Min	Max	Mark 	Rand-Drops	Tail-Drops
	precedence	thres	thres	probability
	-----------------------------------------------------------------------
	0	2048	4096	1/10	10	5
	1	2304	4096	1/10	3	1
	2	2560	4096	1/10	0	0
	3	2816	4096	1/10	0	0
	4	3072	4096	1/10	5	1
	5	3328	4096	1/10	0	0
	6	3584	4096	1/10	2	0
	7	3840	4096	1/10	0	0
Verification Example for Discard-Class-Based WRED

Example 11-11 shows sample output for the show policy-map interface command when discard-class-based WRED is configured on the vlan1 class queue. For each discard-class level, the output indicates the minimum and maximum thresholds, the mark probability value, the number of packets dropped using RED, and the number of packets dropped using tail drop.

Example 11-11 Displaying Discard-Class-Based WRED Statistics
Router# show policy-map interface GigabitEthernet 1/0/0
GigabitEthernet1/0/0 
  Service-policy output: bronze
    Class-map: vlan1 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 101
      Output queue: 0/128; 0/0 packets/bytes output, 0 drops
      Bandwidth: 47 kbps (Weight 0)
	Random-detect (discard-class-based):
	Exponential weight: 9 (1/512)
	Current average queue length: 0 packets
	---------------------------------------------------------------
	Discard	Min	Max	Mark	Rand-Drops	Tail-Drops
	class	thres	thres	probability
	---------------------------------------------------------------
	0	10	100	1/40	2	100
	1	100	200	1/40	15	0
	2	2560	4096	1/10	0	0
	3	2816	4096	1/10	0	0
	4	3072	4096	1/10	0	0
	5	3328	4096	1/10	0	0
	6	3584	4096	1/10	0	0
	7	3840	4096	1/10	0	0
Verification Examples for ATM CLP-Based WRED

Example 11-7 shows sample output for the show policy-map interface command when ATM CLP-based WRED is configured on a Cisco 10000 series router with a PRE3. The output shows the threshold values configured for CLP 1.

Example 11-12 Displaying ATM CLP-Based WRED Statistics (PRE3)
Router# show policy-map policymap1 
Service-policy output: policymap1
Class-map: class1 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: none
Queueing
Queue limit 50 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 20% (00000 kbps)
Exp-weight-constant: 9 (1/512)
Mean queue depth: 0 bytes
clp	Transmitted	Random drop	Tail drop	Minimum	Maximum	Mark
	pkts/bytes	pkts/bytes	pkts/bytes	thresh	thresh	prob
0	0/0	0/0	0/0	0	0	1/0
1	0/0	0/0	0/0	12	25	1/10
Example 11-7 shows sample output for the show policy-map command when ATM CLP-based WRED is configured on a Cisco 10000 series router with a PRE2. The output shows the threshold values configured for CLP 1.

Example 11-13 Displaying ATM CLP-Based WRED Statistics (PRE2)
Router# show policy-map policymap1
Service-policy output: policymap1
Class-map: class1 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: none
Output queue: 0/16384; 0/0 packets/bytes output, 0/0 drops
Bandwidth : 200000 kbps (Weight 20)
Random-detect (clp-based) :
Exponential weight: 9 (1/512)
Current average queue length: 0 packets
-------------------------------------------------------------------------
ATM	Min	Max	Mark	Rand-Drop	Tail-Drop
CLP	thres	thres	probability	Pkts	Bytes	Pkts	Bytes
----------------------------------------------------------------
0	4097	8192	1/10	0	0	0	0
1	12	25	1/10	0	0	0	0
Controlling Packet Flow on Layer 2 Queues

The ATM VC queue depth feature controls the depth of Layer 2 ATM cell queues and is used primarily for flow control. You specify the VC queue depth when you create the ATM VC on the line card.

To be fully effective, you must set the segmentation and reassembly (SAR) line card queue depth for each VC interface queue above the weight for VC weighting by using the queue-depth command. This command enables you to set the high watermark and low watermark, which define the depth of the VC interface queue. The optimum threshold values for these watermarks are a function of a number of variables, such as the following:

•Number of queues on a VC

•Priority queue latency requirements

•Bandwidth of the VC

•Accuracy of VC bandwidth utilization

•Per-queue bandwidth accuracy

Because so many variables influence watermark threshold values, you might need to experiment with different values to determine the optimum high and low watermark values for your configuration. In general, the following guidelines apply:

•Set the low watermark equal to the VC weight. If the low watermark is less than the VC weight, a full weight worth of cells might not be enqueued in the SAR mechanism when the scheduler round-robin gets to the VC. As a result, the VC might not get its fair share.

•Set the high watermark equal to the low watermark plus 2.

For more information about the high and low watermarks, see the "High Watermark and Low Watermark Default Values" section on page 15-25 in Chapter 15, "Oversubscribing Physical and Virtual Links."

Table 11-8 lists the default minimum and maximum threshold values for ATM variable bit rate (VBR) and unspecified bit rate (UBR) virtual circuits.

Table 11-8 ATM Default Threshold Values

Type of ATM
Virtual Circuit

Virtual Circuit Rate
(in bps)

Minimum
Threshold

Maximum
Threshold

Variable Bit Rate (VBR)

0 to 18999

48

56

19000 to 40999

64

72

41000 to 99999

128

144

100000 to 622000

224

240

Unspecified Bit Rate (UBR)

Not Applicable

224

240

When changing the minimum and maximum threshold values, consider the following guidelines:

•To enhance virtual circuit utilization accuracy, increase the minimum threshold and possibly the maximum threshold.

•To enhance per-queue accuracy, increase the spread between the thresholds. For example, if the minimum threshold is 66 and the maximum threshold is 70, increase the maximum threshold to 72 to increase the spread.

•To reduce latency, decrease the maximum threshold.

•To increase the number of queues, increase the maximum threshold.

For more information, see the "Configuring VC Weighting" section on page 15-28 in Chapter 15, "Oversubscribing Physical and Virtual Links."

Configuring the Depth of Layer 2 Queues

For information about configuring Layer 2 queue depths, see the "Configuring VC Queue Depth" section on page 15-38.

Related Documentation

This section provides hyperlinks to additional Cisco documentation for the features discussed in this chapter. To display the documentation, click the document title or a section of the document highlighted in blue. When appropriate, paths to applicable sections are listed below the documentation title.

Feature

Related Documentation

Class-Based Weighted Random Early Detection (CBWRED)

Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.3

Part 2: Congestion Management > Configuring Weighted Fair Queuing > Class-Based Weighted Fair Queuing Configuration Task List > Configuring Class Policy in the Policy Map > Configuring Class Policy Using WRED Packet Drop

Part 3: Congestion Avoidance > Congestion Avoidance Overview > About Random Early Detection

Part 3: Congestion Avoidance > Configuring Weighted Random Early Detection

DiffServ-Compliant WRED

DiffServ Compliant Weighted Random Early Detection, Release 12.1(5)T feature module

DSCP-Based Weighted Random Early Detection (WRED)

DiffServ Compliant Weighted Random Early Detection, Release 12.1(5)T feature module

Implementing Quality of Service Policies with DSCP tech notes

DSCP-Compliant WRED

Low-Latency Priority Queuing

ATM Traffic Management, Troubleshooting Output Drops with Priority Queuing tech note

Low Latency Queuing, Release 12.0S feature module

IP to ATM Class of Service, Low Latency Queuing

Low Latency Queuing, Release 12.0T feature module

Per-VC Queuing for VBR-nrt

Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2

Part 7: Quality of Service Solutions > IP to ATM Class of Service Overview > IP to ATM CoS Features

Per-VC WRED for VBR-nrt

Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2

Part 7: Quality of Service Solutions > IP to ATM CoS Overview > IP to ATM CoS Features

Part 7: Quality of Service Solutions > Configuring IP to ATM CoS > IP to ATM CoS on a Single ATM VC Configuration Task List

Part 7: Quality of Service Solutions > Configuring IP to ATM CoS > Per-VC WFQ and CBWFQ Configuration Task List

Priority Queuing (PQ)/CBWFQ on ATM PVCs

Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2

Part 2: Congestion Management > Congestion Management Overview > Priority Queuing

Part 2: Congestion Management > Configuring Priority Queuing

Part 2: Congestion Management > Congestion Management Overview > Weighted Fair Queuing > Class-Based Weighted Fair Queuing

Part 2: Congestion Management > Configuring Weighted Fair Queuing > Class-Based Weighted Fair Queuing Configuration Task List

Random Early Detection with Queue-Limit

Release Notes for the Cisco 10000 Series Internet Router for Cisco IOS Release 12.0(25)SX

New Features in Cisco IOS Release 12.0(25)SX > Random Early Detection with Queue-Limit