Cisco IOS® Software Release 12.0(26)S supports the Modular Quality-of-Service (QoS) Command-Line-Interface (MQC). It will be added to Release 12.2 (Rls7)S. Releases 12.2 and 12.2T have historically supported MQC differently for distributed hardware (for example, Cisco® 7500 Series Routers and FlexWAN) than for nondistributed hardware (for example, Cisco 7200 Series Routers and other lower-end hardware). Cisco IOS Software will provide a consistent and common MQC behavior on both distributed and nondistributed hardware. Certain MQC behaviors that appear in Cisco 7200 Series Router and other lower-end hardware feature sets will be eliminated or replaced with the behavior from the Cisco 7500 Series Router implementation.
The resulting common behavior has been applied to Releases 12.0(26)S and later, future 12.2(Rls7)S and T train releases. This document describes the new behavioral changes and CLI modifications to the QoS features on the nondistributed hardware (Cisco 7200 Series Router and other lower-end hardware) that result from this effort.
Document Purpose
The purpose of this document is to help service providers that might be affected by the behavioral changes to migrate from Release 12.2T to Release 12.2S. Enterprise customers will be affected when these changes are ported to future T train release. Customers migrating to releases 12.0 (26)S and later will not be affected, because the QoS functionality support was introduced in this release.
This document is not intended to discuss all of the new MQC feature capabilities that have been introduced on the Cisco 7200 Series Router and other lower-end hardware. For a complete list of new feature capabilities, please refer to the appropriate Cisco IOS Software release documentation on Cisco.com.
Benefits of Common Behavior
• Feature parity for Releases 12.2S and 12.0(26)S with future T train releases
• Instant CLI and semantics consistency of QoS features across all hardware that supports Cisco IOS Software
• Common functionality for both distributed and nondistributed implementations, providing consistency of QoS feature behavior across all software-forwarding hardware
• Behavioral consistency across hardware, resulting in accelerated delivery of feature enhancements and new QoS features in different Cisco IOS Software releases
• All hierarchical scheduling capabilities (for example, flow-based fair queuing within a class, hierarchical shaping, and queuing) of the Cisco 7500 Series Router will also be available on the Cisco 7200 Series Router and other lower-end hardware
Effect of QoS Features/CLI Changes on Customers
• Certain QoS feature behaviors will be affected on the Cisco 7200 Series Router and other lower-end hardware.
• To help ensure easy customer migration, certain default values and default feature behaviors will remain unchanged on the Cisco 7200 Series Router and lower-end hardware. Some default parameters might be different across hardware because of various hardware dependencies.
• Certain output commands will be obsolete and no longer supported on the Cisco 7200 Series Router and lower-end hardware. The CLI output for the show policy-map interface command will have some minor changes.
• Certain new QoS feature capabilities will be introduced on both the Cisco 7200 and 7500 Series Routers.
The rest of this document describes the behavioral and CLI changes in more detail, provides any workarounds necessary to achieve the old behavior, and discusses possible side effects to the new behavior.
QoS Feature Behavioral Changes
Fair Queuing
Old Behavior
The fair queuing feature uses a weighted fair queuing (WFQ) function with weights based on IP precedence value and the volume of the flow to make bandwidth guarantees to different flows within a class.
New Behavior
The fair queuing feature is flow based and uses an unweighted queuing function (that is all flows are given equal share of the available bandwidth irrespective of their IP precedence values).
Possible Side Effects of New Behavior
Cisco Systems® recommends that users have separate user-defined classes for traffic that needs to meet certain application requirements/criteria (for example, throughput, latency, and so on). Performance problems under the new behavior might occur if the QoS deployment relies primarily on WFQ in the class default, rather than allocating separate resources for traffic that needs additional help.
Workaround
As of July 2005, there is no compelling technical reason to mandate WFQ in the default class, because MQC has been successfully deployed on the Cisco 7500 Series Router.
Allocation of Bandwidth to Class Default
Old Behavior
The default class can use up to 25 percent of total available bandwidth; however, the entire 25 percent is not guaranteed. Rather, it is proportionately shared between different flows in the default class and excess traffic from other bandwidth classes. Thus, the amount of bandwidth that the default class will receive depends on a number of factors, including the total number of flows currently in the router, the bandwidth guarantees (or weights) made to the other user-defined classes, and the number of hash queues in the router. To make minimum bandwidth guarantees to the default class, the bandwidth command needs to be explicitly configured under the class in the policy.
New Behavior
The class default has a default minimum guarantee that equals the difference between the total available bandwidth (for example, link rate, shaped rate) and the amount of bandwidth guaranteed to the other classes. For example, if 90 percent of bandwidth is allocated to other classes, then the class default is guaranteed the remaining 10 percent. If there is no traffic in the class default, then the other classes share that 10 percent proportionally. Alternatively, the user can explicitly configure the amount of bandwidth that should be available to default class using the bandwidth <x> command. This will lower the guarantee that is given to the class default and allow 10 minus "x" to always be available for the other classes.
Workaround
As of July 2005, there is no workaround available.
Class-Based Shaping Support on ATM Permanent Virtual Circuits
Old Behavior
Class-based traffic shaping is not supported in ATM interfaces, because traffic shaping is native to the ATM framework. To achieve different levels of QoS, users must configure the permanent virtual circuits (PVCs) as either real-time variable bit rate (VBR-rt), non-real-time variable bit rate (VBR-nrt), constant bit rate (CBR), available bit rate (ABR), or unspecified bit rate (UBR).
New Behavior
Class-based traffic shaping is supported on all ATM interfaces. This will allow an extra level of specificity by allowing users to shape one or more classes under the ATM traffic contract.
Hierarchical Queuing Support
Old Behavior
Support exists for hierarchical queuing/policies only if shaping is configured at the parent policy.
New Behavior
Hierarchical queuing also supports the bandwidth command configured at the parent policy. The following sample configuration illustrates the new hierarchical queuing with the bandwidth command configured at the parent level:
policy child-foo
class child1-c1
bandwidth 40
class child2-c1
bandwidth 60
policy foo
class c1
bandwidth 100
service-policy child-foo
Changes in Default Values and Behavior
Default Queuing Strategy for Class Default Changes from WFQ to First In, First Out
Old Behavior
The queuing strategy is weighted fair between the different flows in the class default. If any bandwidth guarantee to default class is made using the bandwidth statement, queuing within the default class is no longer WFQ between the different flows, but simply first in, first out (FIFO). Class-based shaping also has implicit fair-queuing behavior within the class.
New Behavior
The class-default traffic goes into a FIFO queue, and by default there is no fair queuing involved. Class-based shaping will have implicit FIFO instead of fair-queuing behavior.
Workaround
The user can explicitly configure fair queuing in this class to create a layer of flow queues within the FIFO queue in the class default.
Dual FIFO Behavior for Frame Relay Traffic Shaping
Old Behavior
When FRF.12 fragmentation is configured on a Frame Relay PVC, the interface queue becomes a dual FIFO queue. Low Latency Queuing (LLQ) traffic from all the virtual circuits goes to the high-priority FIFO queue, while traffic from the remaining bandwidth classes goes to the low-priority FIFO queue. The low-priority queue is serviced only when the high-priority queue is empty. This is done to meet latency guarantees for LLQ traffic under the previous scheduler implementation.
New Behavior
There will be no interface-level dual FIFO queuing support for Frame Relay traffic shaping (FRTS). The show interface command will also not display dual FIFO as a queuing strategy. The functionality is removed because it is no longer needed to meet performance expectations under the new behavior.
Weighted Random Early Detection Minimum/Maximum Threshold Changes
Old Behavior
The default min/max threshold values for precedence/Differentiated Services Code Point (DSCP)-based Weighted Random Early Detection (WRED) are based on a fixed value table for the Cisco 7200 Series Router and lower-end hardware. Users can change the default threshold settings by using the random-detect dscp <dscp> <min threshold> <max threshold> command.
New Behavior
The old behavior will be maintained for DSCP and IP precedence-based WRED on the Cisco 7200 Series Router and lower-end hardware.
The new byte-based and time-based WRED features introduced in Cisco IOS Software Release 12.2S will have their default min/max threshold values derived from the available system buffer size.
Obsolete and New Commands
Support for Fair-Queue Queue-Limit Command
Old Behavior
None.
New Behavior
Users can use the fair-queue queue-limit < > command to set per flow queue limit for each dynamic flow queue within a class.
Shape Max-Buffers
Old Behavior
This command specifies the maximum number of buffers allowed in each shaping queue.
New Behavior
Not supported.
Workaround
The queue-limit command should be used to specify the depth of the shaping queue. This command is allowed on any class that has bandwidth or shape enabled.
Max-Reserved-Bandwidth
Old Behavior
The default maximum reserved bandwidth is 75 percent, so the maximum bandwidth that can be guaranteed to any user-defined class is also 75 percent. If 75 percent of the bandwidth is allocated only for the LLQ, then no minimum bandwidth can be guaranteed to the other classes, and they will share the remaining 25 percent bandwidth with the class default traffic.
If more bandwidth needs to be allocated, use the max-reserved-bandwidth command to modify the bandwidth amount that can be reserved for user-defined classes.
New Behavior
The max-reserved-bandwidth command no longer affects the amount of bandwidth available to a service-policy. 1% must be reserved for the class-default with the rest being available to the users classes. Please also refer to the previous section "Allocation of Bandwidth to Class Default."
CLI Output Changes
"Show Queuing" and "Show Queue" Commands
The above two commands will no longer be supported. Instead, users can use the show policy-map interface and show policy-map commands to gather QoS-related information and statistics.
"Show Policy-Map Interface" and "Show Policy-Map" Output
The new show policy-map interface output has additional fields that display the DSCP value, WRED statistics in bytes, new column for number of transmitted packets by WRED, and a counter displaying packets output/bytes output in each class. The packets queued/bytes queued counter will no longer be supported.
Table 1 compares the old and new output formats for both commands.
Table 1. Comparison of Old and New Command Output Formats
Comments
New Output Format
Old Output Format
Show policy-map parent
Policy Map parent
Class class-default
Average Rate Traffic Shaping
cir 300000 (bps) bc 1200 (bits) be 1200 (bits)
service-policy child
Show policy-map child
Policy Map child
Class prec2
priority 40 (%)
Class prec4
bandwidth 40 (%)
packet-based wred, exponential weight 9
class min-threshold max-threshold mark-probability
Show policy-map parent
Policy Map parent
Class class-default
Traffic Shaping
Average Rate Traffic Shaping
CIR 300000 (bps) Max. Buffers Limit 1000 (Packets) Bc 1200 Be 1200
service-policy child
Show policy-map child
Policy Map child
Class prec2
Bandwidth 40 (%) Max Threshold 64 (packets)
Class prec4
Bandwidth 40 (%)
exponential weight 9
class min-threshold max-threshold mark-probability
0 - - 1/10
1 - - 1/10
2 - - 1/10
3 - - 1/10
4 - - 1/10
5 - - 1/10
6 - - 1/10
7 - - 1/10
Class class-default
fair-queue
packet-based wred, exponential weight 9
class min-threshold max-threshold mark-probability
0 - - 1/10
1 - - 1/10
2 - - 1/10
3 - - 1/10
4 - - 1/10
5 - - 1/10
6 - - 1/10
7 - - 1/10
rsvp - - 1/10
Class class-default
Flow based Fair Queueing
exponential weight 9
dscp min-threshold max-threshold mark-probability
0 - - 1/10
1 - - 1/10
2 - - 1/10
3 - - 1/10
4 - - 1/10
5 - - 1/10
6 - - 1/10
7 - - 1/10
af11 - - 1/10
af12 - - 1/10
af13 - - 1/10
af21 - - 1/10
af22 - - 1/10
af23 - - 1/10
af31 - - 1/10
af32 - - 1/10
af33 - - 1/10
af41 - - 1/10
af42 - - 1/10
af43 - - 1/10
cs1 25 50 1/10
cs2 - - 1/10
cs3 - - 1/10
cs4 - - 1/10
cs5 - - 1/10
cs6 - - 1/10
cs7 - - 1/10
ef - - 1/10
rsvp - - 1/10
default - - 1/10
show policy-map int fas0/0
FastEthernet0/0
Service-policy output: parent (1045)
Class-map: class-default (match-any) (1058/0)
414491 packets, 24869460 bytes
30 second offered rate 3571000 bps, drop rate 3495000 bps
