Table Of Contents
Byte-Based Weighted Random Early Detection
Restrictions for Byte-Based WRED
Information About Byte-Based WRED
Changes in functionality of WRED
Changes in Queue Limit and WRED Thresholds
How to Configure Byte-Based WRED
Configuring the Queue Depth and WRED Thresholds
Changing the Queue Depth and WRED Threshold Unit Modes
Verifying the Configuration for Byte-Based WRED
Configuration Examples for Byte-Based WRED
Example: Configuring Byte-Based WRED
Feature Information for Byte-Based Weighted Random Early Detection
Byte-Based Weighted Random Early Detection
First Published: August 26, 2003Last Updated: June 16, 2010This module explains how to enable byte-based Weighted Random Early Detection (WRED), and set byte-based queue limits and WRED thresholds.
Finding Feature Information
For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Byte-Based Weighted Random Early Detection" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS XE software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Restrictions for Byte-Based WRED
•
Information About Byte-Based WRED
•
How to Configure Byte-Based WRED
•
Configuration Examples for Byte-Based WRED
•
Feature Information for Byte-Based Weighted Random Early Detection
Restrictions for Byte-Based WRED
•
WRED is only useful when the bulk of the traffic is TCP/IP traffic. With TCP, dropped packets indicate congestion, so the packet source will reduce its transmission rate. With other protocols, packet sources may not respond or may resend dropped packets at the same rate. Thus, dropping packets does not decrease congestion.
•
You cannot configure byte-based WRED on a class in which the queue-limit is configured in milliseconds or packets.
Information About Byte-Based WRED
Changes in functionality of WRED
This feature extends the functionality of WRED. In previous releases, you specified the WRED actions based on the number of packets. With the byte-based WRED, you can specify WRED actions based on the number of bytes.
Changes in Queue Limit and WRED Thresholds
In Cisco IOS XE Release 2.4, the Cisco ASR 1000 Series Aggregation Services Routers support the addition of bytes as a unit of configuration for both queue limits and WRED thresholds. Therefore, as of this release, packet-based and byte-based limits are configurable, with some restrictions.
How to Configure Byte-Based WRED
Configuring Byte-Based WRED
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
class-map class-map-name
4.
match ip precedence ip-precedence-value
5.
exit
6.
policy-map policy-name
7.
class class-name
8.
random-detect
9.
random-detect precedence precedence min-threshold bytes max-threshold bytes max-probability-denominator
DETAILED STEPS
Configuring the Queue Depth and WRED Thresholds
Prerequisites
Be sure that your configuration satisfies the following conditions when configuring the queue depth and WRED thresholds:
•
When configuring byte-based mode, the queue limit must be configured prior to the WRED threshold and before the service policy is applied.
•
When setting the queue depth and WRED thresholds in an enhanced QoS policies aggregation configuration, the limits are supported only for the default class at a subinterface policy map and for any classes at the main interface policy map.
Restrictions
Consider the following restrictions when you configure the queue depth and WRED thresholds:
•
Do not configure the queue limit unit before you configure a queueing feature for a traffic class.
•
If you do not configure a queue limit, then the default mode is packets.
•
When you configure WRED thresholds, the following restrictions apply:
–
The WRED threshold must use the same unit as the queue limit. For example, if the queue limit is in packets, then the WRED thresholds also must be in packets.
–
If you do not configure a queue limit in bytes, then the default mode is packets and you must also configure the WRED threshold in packets.
–
The queue limit size must be greater than the WRED threshold.
•
The unit modes for either the queue limit or WRED thresholds cannot be changed dynamically after a service policy is applied.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
policy-map policy-map-name
4.
class class-name
5.
qos-queueing-feature
6.
queue-limit queue-limit-size [bytes | packets]
7.
random-detect [dscp-based | prec-based]
8.
random-detect dscp dscp-value {min-threshold max-threshold | min-threshold bytes max-threshold bytes} [max-probability-denominator]
or
random-detect precedence precedence {min-threshold max-threshold | min-threshold bytes max-threshold bytes} [max-probability-denominator]DETAILED STEPS
Examples
The following examples show both correct and invalid configurations to demonstrate some of the restrictions.
Correct Configuration
The following example shows the correct usage of setting the queue limit in bytes mode after the bandwidth remaining ratio queueing feature has been configured for a traffic class:
class AF1bandwidth remaining ratio 90queue-limit 750000 bytesInvalid Configuration
The following example shows an invalid configuration for the queue limit in bytes mode before the bandwidth remaining ratio queueing feature has been configured for a traffic class:
class AF1queue-limit 750000 bytesbandwidth remaining ratio 90Correct Configuration
The following example shows the correct usage of setting the queue limit in bytes mode after the bandwidth remaining ratio queueing feature has been configured for a traffic class, followed by the setting of the thresholds for WRED in compatible byte mode:
class AF1bandwidth remaining ratio 90queue-limit 750000 bytesrandom-detect dscp-basedrandom-detect dscp 8 750000 bytes 750000 bytesInvalid Configuration
This example shows an invalid configuration of the WRED threshold in bytes without any queue limit configuration, which therefore defaults to a packet-based queue depth. Therefore, the WRED threshold must also be in packets:
class AF1bandwidth remaining ratio 90random-detect dscp-basedrandom-detect dscp 8 750000 bytes 750000 bytesChanging the Queue Depth and WRED Threshold Unit Modes
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type
4.
no service-policy number output policy-map-name
5.
exit
6.
policy-map policy-map-name
7.
class class-name
8.
queue-limit queue-limit-size [bytes | packets]
9.
no random-detect dscp dscp-value {min-threshold max-threshold | min-threshold bytes max-threshold bytes} [max-probability-denominator]
or
no random-detect precedence precedence {min-threshold max-threshold | min-threshold bytes max-threshold bytes} max-probability-denominator10.
random-detect dscp dscp-value {min-threshold max-threshold | min-threshold bytes max-threshold bytes} [max-probability-denominator]
or
random-detect precedence precedence {min-threshold max-threshold | min-threshold bytes max-threshold bytes} [max-probability-denominator]DETAILED STEPS
Examples
The following example shows how to change the queue depth and WRED thresholds to packet-based values once a service policy has been applied to an interface:
interface GigabitEthernet1/2/0no service-policy output main-interface-policyendpolicy-map main-interface-policyclass AF1queue-limit 5000 packetsno random-detect dscp 8 750000 bytes 750000 bytesrandom-detect dscp 8 4000 4000Verifying the Configuration for Byte-Based WRED
SUMMARY STEPS
1.
show policy-map interface
2.
show policy-map
DETAILED STEPS
Step 1
show policy-map
The show policy-map command shows the output for a service policy called pol1 that is configured for byte-based WRED.
Router# show policy-mapPolicy Map pol1Class class c1Bandwidth 10 (%)exponential weight 9class min-threshold(bytes) max-threshold(bytes) mark-probability-------------------------------------------------------------------0 - - 1/101 20000 30000 1/102 - - 1/103 - - 1/104 - - 1/105 - - 1/106 - - 1/107 - - 1/10rsvp - - 1/10Step 2
The show policy-map interface command shows output for an interface that is configured for byte-based WRED.
Router# show policy-map interface serial3/1Service-policy output: polClass-map: silver (match-all)366 packets, 87840 bytes30 second offered rate 15000 bps, drop rate 300 bpsMatch: ip precedence 1QueueingOutput Queue: Conversation 266Bandwidth 10 (%)(pkts matched/bytes matched) 363/87120depth/total drops/no-buffer drops) 147/38/0exponential weight: 9mean queue depth: 25920class Transmitted Random drop Tail drop Minimum Maximum Markpkts/bytes pkts/bytes pkts/bytes thresh thresh prob(bytes) (bytes)0 0/0 0/0 0/0 20000 40000 1/101 328/78720 38/9120 0/0 22000 40000 1/102 0/0 0/0 0/0 24000 40000 1/103 0/0 0/0 0/0 26000 40000 1/104 0/0 0/0 0/0 28000 40000 1/10
Configuration Examples for Byte-Based WRED
Example: Configuring Byte-Based WRED
The following example shows a service policy called wred-policy that sets up byte-based WRED for a class called prec2 and for the default class. The policy is then applied to Fast Ethernet interface 0/0/1.
policy wred-policyclass prec2bandwidth 1000random-detectrandom-detect precedence 2 100 bytes 200 bytes 10class class-defaultrandom-detectrandom-detect precedence 4 150 bytes 300 bytes 15random-detect precedence 6 200 bytes 400 bytes 5interface fastethernet0/0/1service-policy output wred-policyThe following example shows the byte-based WRED results for the service policy attached to Ethernet interface 0/0/1.
Router# show policy-map interfaceEthernet0/0/1Service-policy output: wred-policy (1177)Class-map: prec2 (match-all) (1178/10)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: ip precedence 2 (1179)Queueingqueue limit 62500 bytes(queue depth/total drops/no-buffer drops) 0/0/0(pkts queued/bytes queued) 0/0bandwidth 1000 (kbps)Exp-weight-constant: 9 (1/512)Mean queue depth: 0 bytesclass Transmitted Random drop Tail drop Minimum Maximum Markpkts/bytes pkts/bytes pkts/bytes thresh thresh probbytes bytes0 0/0 0/0 0/0 15625 31250 1/101 0/0 0/0 0/0 17578 31250 1/102 0/0 0/0 0/0 100 200 1/103 0/0 0/0 0/0 21484 31250 1/104 0/0 0/0 0/0 23437 31250 1/105 0/0 0/0 0/0 25390 31250 1/106 0/0 0/0 0/0 27343 31250 1/107 0/0 0/0 0/0 29296 31250 1/10Class-map: class-default (match-any) (1182/0)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: any (1183)0 packets, 0 bytes5 minute rate 0 bpsqueue limit 562500 bytes(queue depth/total drops/no-buffer drops) 0/0/0(pkts queued/bytes queued) 0/0Exp-weight-constant: 9 (1/512)Mean queue depth: 0 bytesclass Transmitted Random drop Tail drop Minimum Maximum Markpkts/bytes pkts/bytes pkts/bytes thresh thresh probbytes bytes0 0/0 0/0 0/0 140625 281250 1/101 0/0 0/0 0/0 158203 281250 1/102 0/0 0/0 0/0 175781 281250 1/103 0/0 0/0 0/0 193359 281250 1/104 0/0 0/0 0/0 150 300 1/155 0/0 0/0 0/0 228515 281250 1/106 0/0 0/0 0/0 200 400 1/57 0/0 0/0 0/0 263671 281250 1/10Additional References
Related Documents
Standards
Standard TitleNo new or modified standards are supported, and support for existing standards has not been modified.
—
MIBs
RFCs
RFC TitleNo new or modified RFCs are supported, and support for existing RFCs has not been modified.
—
Technical Assistance
Feature Information for Byte-Based Weighted Random Early Detection
Table 1 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS XE software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 lists only the Cisco IOS XE software release that introduced support for a given feature in a given Cisco IOS XE software release train. Unless noted otherwise, subsequent releases of that Cisco IOS XE software release train also support that feature.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2011 Cisco Systems, Inc. All rights reserved.
