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

Категории