Controlling Congestion with WRED

Problem

You want to control congestion on an interface before it becomes a problem.

Solution

The syntax for configuring WRED changed with the introduction of class-based QoS. The old method defined WRED across an entire interface:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface HSSI0/0
Router(config-if)#random-detect
Router(config-if)#random-detect precedence 0 10 20 10
Router(config-if)#random-detect precedence 1 12 20 10
Router(config-if)#random-detect precedence 2 15 25 15
Router(config-if)#random-detect precedence 3 18 25 15
Router(config-if)#random-detect precedence 4 20 30 20
Router(config-if)#random-detect precedence 5 22 30 20
Router(config-if)#random-detect precedence 6 30 40 25
Router(config-if)#random-detect precedence 7 40 50 100
Router(config-if)#random-detect precedence RSVP 45 50 100
Router(config-if)#exit
Router(config)#end
Router#

The new configuration method uses the same syntax as CBWFQ:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#class-map Prec5
Router(config-cmap)#description Critical
Router(config-cmap)#match ip precedence 5
Router(config-cmap)#exit
Router(config)#policy-map cb_wred
Router(config-pmap)#class Prec5
Router(config-pmap-c)#random-detect dscp-based
Router(config-pmap-c)#exit
Router(config-pmap)#class class-default
Router(config-pmap-c)#fair-queue 512
Router(config-pmap-c)#queue-limit 96 
Router(config-pmap-c)#random-detect dscp-based
Router(config-pmap-c)#exit
Router(config-pmap)#exit
Router(config)#interface HSSI0/1
Router(config-if)#service-policy output cb_wred 
Router(config-if)#exit
Router(config)#end
Router#

 

Discussion

For the older method, you can set up the drop probabilities according to IP Precedence values by using the following command:

Router(config-if)#random-detect precedence 7 40 50 100

The first argument after the precedence keyword here is the IP Precedence value. The options are any integer between 0 and 7, or the keyword RSVP. After this are the minimum threshold, maximum threshold, and the so-called mark probability denominator.

The minimum threshold is the number of packets that must be in the queue before the router starts to discard. The probability at the minimum threshold is essentially zero, but it rises linearly as the number of packets in the queue rises. The maximum probability occurs at the maximum threshold. You specify the actual value of the probability at this maximum by using the mark probability denominator. In this case we have set the value to 100, which means that, at the maximum, we will discard one packet in 100. This means that halfway between the maximum and minimum thresholds, the router will drop one packet in 200.

Note that as we discuss in Appendix B, the router doesn't necessarily drop packets when the queue depth reaches the minimum threshold. Rather, it uses a moving average so that temporary bursts of data are not dropped. This configured minimum is the lower limit of this moving average, which is reached only when the congestion continues for a longer period of time.

If you do not change these values, the defaults take IP Precedence values into account. The default mark probability denominator is 10, so the router will discard one packet in 10. The default maximum threshold depends on the speed of the interface and the router's capacity for buffering packets, but it is the same for all Precedence values. So, by default, the only differences between WRED's treatment of different IP Precedence levels is in the minimum threshold. The default minimum threshold for packets with an IP Precedence of 0 is 50 percent of the maximum threshold. This value rises linearly with Precedence so that the minimum threshold for Precedence 7 and packets with RSVP reserved bandwidth allocations are almost the same as the maximum threshold.

In the new-style example, we have created only one class-based queue to show the principle. In practice, of course, you would probably want to create more than this. All of the traffic that doesn't have an IP Precedence value of 5 uses the default queue, where we have configured both WFQ and WRED.

This example uses DSCP-based random detection. WRED has a built-in ability to discriminate based on DSCP value, so that traffic streams with higher drop precedence values are more likely to drop packets. The default WRED settings when using DSCP-based random detection are shown in Table 11-1.

Table 11-1. Default WRED settins

DSCP value Minimum threshold queue depth Maximum threshold queue depth Drop probability at maximum
AFx1 32 40 1/10
AFx2 28 40 1/10
AFx3 24 40 1/10

As Table 11-1 shows, the default DSCP-based thresholds are the same for every class. So, for example, AF12, AF22, AF32, and AF42 all begin dropping packets in a sustained congestion situation when the queue depth reaches 28 packets. They reach their maximum drop probability when there are 40 packets in the queue. In all cases, the drop probability at the maximum threshold value is 1/10 (the mark probability), meaning that the router will randomly drop one packet in 10.

You can change these values in a policy map as follows:

Router(config-pmap)#class AF1x
Router(config-pmap-c)#bandwidth percent 20
Router(config-pmap-c)#random-detect dscp-based
Router(config-pmap-c)#random-detect dscp af13 10 20
Router(config-pmap-c)#random-detect dscp af12 20 50
Router(config-pmap-c)#random-detect dscp af11 50 100 50
Router(config-pmap-c)#exit

In each of the random-detect dscp commands, the first argument is the DSCP value, followed by the minimum threshold, the maximum threshold, and the denominator of the mark probability. In the case of the AF11 entry, the router will start dropping these packets when there are more than 50 packets in the queue, and increase the probability until the number reaches 100. At that point, the probability of dropping a packet of this type will be one in 50.

Note that these thresholds apply to all traffic in the queue, not just traffic with this particular DSCP value. So there may be 20 AF11 packets, 10 AF12, and 20 more marked with the AF13 DSCP value. Since this adds up to 50 packets, the router will start to drop the AF11 packets. However, because the maximum thresholds for AF12 and AF13 packets are 50 and 20, respectively, the router will already be dropping packets of these types at the full rate (1 packet in 10 by default) before it starts to drop any AF11 packets.

This example assumes that you want to use DSCP values to control the WRED thresholds. This is not necessary, however. You can also use an unweighted version of the command as follows:

Router(config)#class-map AF11
Router(config-cmap)#match ip dscp af11
Router(config-cmap)#exit
Router(config)#policy-map example
Router(config-pmap)#class AF11
Router(config-pmap-c)#bandwidth percent 10
Router(config-pmap-c)#random-detect 
Router(config-pmap-c)#exit

This is particularly useful when your class definitions already take DSCP values into account, as this class map does. Since there is no variation of DSCP values among the class of packets that have a DSCP value of AF11, it isn't necessary for WRED to look at the DSCP value again.

See Also

Recipe 11.7

Router Configuration and File Management

Router Management

User Access and Privilege Levels

TACACS+

IP Routing

RIP

EIGRP

OSPF

BGP

Frame Relay

Handling Queuing and Congestion

Tunnels and VPNs

Dial Backup

NTP and Time

DLSw

Router Interfaces and Media

Simple Network Management Protocol

Logging

Access-Lists

DHCP

NAT

First Hop Redundancy Protocols

IP Multicast

IP Mobility

IPv6

MPLS

Security

Appendix 1. External Software Packages

Appendix 2. IP Precedence, TOS, and DSCP Classifications

Index



Cisco IOS Cookbook
Cisco IOS Cookbook (Cookbooks (OReilly))
ISBN: 0596527225
EAN: 2147483647
Year: 2004
Pages: 505

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net