Configuring DSCPBased CBWRED

This topic describes the Cisco IOS commands that are required to configure DSCP-based CB-WRED.

Configuring DSCP-Based CB-WRED
	router(config-pmap-c)#
	random-detect dscp-based
	• Enables DSCP-based WRED.
	• Command can be used at the interface, per-VC (with random-detect-group), or the class level (service-policy).
	• Default service profile is used.
	• The WRED random-detect command and the WFQ queue-limit command are mutually exclusive for class policy.
— — — 1

Use the random-detect dscp-based command to enable DSCP-based WRED on an interface. By default, WRED is precedence-based and uses eight default WRED profiles, one for each value of IP precedence. Changing WRED weighting to values based on DSCP increases the number of WRED traffic profiles to 64.

You can configure WRED as part of the policy for a standard class or the default class. The WRED random-detect command and the WFQ queue-limit command are mutually exclusive for class policy. If you configure WRED, its packet-drop capability is used to manage the queue when packets exceeding the configured maximum count are enqueued. If you configure the WFQ queue-limit command for class policy, tail drop is used.

WRED cannot be configured on the same interface as CQ, PQ, or WFQ. However, both DWRED and DWFQ can be configured on the same interface. In addition, CB-WRED can be configured in conjunction with CBWFQ. Restricting nondistributed, non-class-based WRED only to FIFO queuing on an interface is not a major issue because WRED is usually applied in the network core, where advanced queuing mechanisms are not typically deployed. WRED is suited for the network core as it has a relatively low performance impact on routers. Further, DWRED or CB-WRED can be used to overcome this limitation by combining WRED with WFQ.

Changing the WRED Traffic Profile
	router(config-pmap-c)#
	random-detect dscp dscpvalue min-threshold max-threshold mark-prob-denominator
	• Changes WRED profile for specified DSCP value • Packet drop probability at maximum threshold is: 1 / mark-prob-denominator
— — —_J

When DSCP-based WRED is enabled, default values are selected for each traffic profile based on DSCP. You can modify these default values to match their specific administrative QoS policy goals. When modifying the default WRED profile for DSCP, these values are configurable:

■ Minimum threshold: When the average queue depth is above the minimum threshold, WRED starts dropping packets. The rate of packet drop increases linearly as the average queue size increases, until the average queue size reaches the maximum threshold. The default maximum threshold is equal to the default hold queue size (40) on an interface. The size of the hold queue is equivalent to the number of packets that can be held within a queue. The hold queue length ranges from 0 to 4096, and, therefore, the minimum/maximum threshold range is 1 to 4096. The default maximum threshold will reflect the defined hold queue size. Thus, if the hold queue is changed, the maximum threshold will change.

■ Maximum threshold: When the average queue size is above the maximum threshold, all packets are dropped. If the difference between the maximum threshold and the minimum threshold is too small, many packets might be dropped at once, resulting in global synchronization.

■ Mark probability denominator: This is the fraction of packets dropped when the average queue depth is at the maximum threshold. For example, if the denominator is 10, one out of every 10 packets is dropped when the average queue is at the maximum threshold. The maximum probability of drop at the maximum threshold can be expressed as 1 / mark-prob-denominator. The maximum drop probability is 10 percent if default settings are used that have a mark probability denominator value of 10. The value of the mark probability can range from 1 to 65536.

Note The default WRED parameters are based on the best available data. Cisco recommends that these parameters not be changed from their default values.

Example: CB-WRED Using DSCP with CBWFQ

In this example of CBWFQ with WRED, the service policy was implemented using classes of service based on IP precedence.

Continue reading here: Make sure the new configurations still conform to the design and implementation from the previous example

Was this article helpful?

0 0