-
Cisco IOS XE Quality of Service Solutions Configuration Guide, Release 2
-
Quality of Service Overview
- Part 1: Classification
- Part 2: Congestion Management
- Part 3: Congestion Avoidance
- Part 4: Policing and Shaping
- Part 5: Link Efficiency Mechanisms
- Part 6: Quality of Service Solutions
- Part 7: Modular Quality of Service Command-Line Interface
-
Table Of Contents
Applying QoS Features Using the MQC
Restrictions for Applying QoS Features Using the MQC
Information About Applying QoS Features Using the MQC
Benefits of Applying QoS Features Using the MQC
How to Apply QoS Features Using the MQC
Creating a Traffic Class Using the MQC
The match-all and match-any Keywords of the class-map Command
Creating a Traffic Policy Using the MQC
Attaching a Traffic Policy to an Interface Using the MQC
The input and output Keywords of the service-policy Command
Verifying the Traffic Class and Traffic Policy Information
Configuration Examples for Applying QoS Features Using the MQC
Creating a Traffic Class: Example
Creating a Traffic Policy: Example
Attaching a Traffic Policy to an Interface: Example
Default Traffic Class Configuration: Example
class-map match-any and class-map match-all Commands: Example
Traffic Policy as a QoS Policy (Hierarchical Traffic Policies): Example
Feature Information for Applying QoS Features Using the MQC
Applying QoS Features Using the MQC
First Published: April 30, 2007Last Updated: March 2, 2009This module contains the concepts about applying QoS features using the Modular Quality of Service (QoS) Command-Line Interface (CLI) (MQC) and the tasks for configuring the MQC. The MQC allows you to define a traffic class, create a traffic policy (policy map), and attach the traffic policy to an interface. The traffic policy contains the QoS feature that will be applied to the traffic class.
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 Applying QoS Features Using the MQC" 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 Applying QoS Features Using the MQC
•
•
•
•
Restrictions for Applying QoS Features Using the MQC
Number of QoS Class Maps Supported (Cisco IOS XE Releases 2.1 and 2.2)
The MQC supports a maximum of 8 class maps in a single policy map.
Number of QoS Class Maps Supported (Cisco IOS XE Release 2.3)
The MQC supports a maximum of 256 class maps in a single policy map.
QoS Policy Maps and Sessions
When sessions are created and QoS policy maps are attached in both the ingress and egress directions, only 2000 sessions are supported. Sessions that exceed this limit can still be created, but the QoS policy maps will not be applied to the session.
Information About Applying QoS Features Using the MQC
Before applying QoS features using the MQC, you should be familiar with the following concepts:
•
The MQC Structure
The MQC structure allows you to define a traffic class, create a traffic policy, and attach the traffic policy to an interface.
The MQC structure consists of the following three high-level steps.
Step 1
Step 2
Step 3
Elements of a Traffic Class
A traffic class contains three major elements: a traffic class name, a series of match commands, and, if more than one match command is used in the traffic class, instructions on how to evaluate these match commands.
The match commands are used for classifying packets. Packets are checked to determine whether they meet the criteria specified in the match commands; if a packet meets the specified criteria, that packet is considered a member of the class. Packets that fail to meet the matching criteria are classified as members of the default traffic class.
Available match Commands
Table 1 lists some of the available match commands that can be used with the MQC. The available match commands vary by Cisco IOS XE release. For more information about the commands and command syntax, see the Cisco IOS Quality of Service Solutions Command Reference.
Multiple match Commands in One Traffic Class
If the traffic class contains more than one match command, you need to specify how to evaluate the match commands. You specify this by using either the match-any or match-all keywords of the class-map command. Note the following points about the match-any and match-all keywords:
•
•
•
Elements of a Traffic Policy
A traffic policy contains three elements: a traffic policy name, a traffic class (specified with the class command), and the command used to enable the QoS feature.
The traffic policy (policy map) applies the enabled QoS feature to the traffic class once you attach the policy map to the interface (by using the service-policy command).
Note
Commands Used to Enable QoS Features
The commands used to enable QoS features vary by Cisco IOS XE release. Table 2 lists some of the available commands and the QoS features that they enable. For complete command syntax, see the command reference for the release that you are using.
For more information about a specific QoS feature that you want to enable, see the appropriate module of the Cisco IOS Quality of Service Solutions Configuration Guide.
Benefits of Applying QoS Features Using the MQC
The MQC structure allows you to create the traffic policy (policy map) once and then apply it to as many traffic classes as needed. You can also attach the traffic policies to as many interfaces as needed.
How to Apply QoS Features Using the MQC
To apply QoS features using the MQC, perform the following tasks.
•
•
•
•
Creating a Traffic Class Using the MQC
To create a traffic class, use the class-map command to specify the traffic class name. Then use one or more match commands to specify the appropriate match criteria. Packets matching the criteria that you specify are placed in the traffic class.
To create the traffic class, complete the following steps.
Note
The match-all and match-any Keywords of the class-map Command
One of the commands used when you create a traffic class is the class-map command. The command syntax for the class-map command includes two keywords: match-all and match-any. The match-all and match-any keywords need to be specified only if more than one match criterion is configured in the traffic class. Note the following points about these keywords:
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
class-map [match-all | match-any] class-map-name
Example:Router(config)# class-map match-any class1
Creates a class to be used with a class map and enters class-map configuration mode. The class map is used for matching packets to the specified class.
•
Note
Step 4
match cos cos-number
Example:Router(config-cmap)# match cos 2
Matches a packet on the basis of a Layer 2 class of service (CoS) number.
•
Note
Step 5
Enter additional match commands, if applicable; otherwise, continue with Step 6.
—
Step 6
end
Example:Router(config-cmap)# end
(Optional) Exits class-map configuration mode and returns to privileged EXEC mode.
Creating a Traffic Policy Using the MQC
To create a traffic policy (or policy map) and enable one or more QoS features, perform the following steps.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
policy-map policy-map-name
Example:Router(config)# policy-map policy1
Creates or specifies the name of the traffic policy and enters policy-map configuration mode.
•
Step 4
class {class-name | class-default}
Example:Router(config-pmap)# class class1
Specifies the name of a traffic class and enters policy-map class configuration mode.
•
Note
Step 5
bandwidth {bandwidth-kbps | percent percent}
Example:Router(config-pmap-c)# bandwidth 3000
(Optional) Specifies a minimum bandwidth guarantee to a traffic class in periods of congestion. A minimum bandwidth guarantee can be specified in kbps or by a percentage of the overall available bandwidth.
Note
Step 6
Enter the commands for any additional QoS feature that you want to enable, if applicable; otherwise, continue with Step 7.
—
Step 7
end
Example:Router(config-pmap-c)# end
(Optional) Exits policy-map class configuration mode and returns to privileged EXEC mode.
Attaching a Traffic Policy to an Interface Using the MQC
The traffic policy (policy map) applies the enabled QoS feature to the traffic class once you attach the policy map to the interface (by using the service-policy command).
Depending on the platform and Cisco IOS XE release that you are using, a traffic policy can be attached to an ATM permanent virtual circuit (PVC) subinterface, to a Frame Relay data-link connection identifier (DLCI), or to another type of interface.
To attach a traffic policy to an interface, perform the following steps.
The input and output Keywords of the service-policy Command
As a general rule, the QoS features configured in the traffic policy can be applied to packets entering the interface or to packets leaving the interface. Therefore, when you use the service-policy command, you need to specify the direction of the traffic policy by using the input or output keyword.
For instance, the service-policy output policy1 command would apply the QoS features in the traffic policy to the interface in the output direction. All packets leaving the interface (output) are evaluated according to the criteria specified in the traffic policy named policy1.
Note
Restrictions
A traffic policy containing a queueing mechanism or feature cannot be attached to a physical interface or subinterface.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Verifying the Traffic Class and Traffic Policy Information
To display and verify the information about a traffic class or traffic policy, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuration Examples for Applying QoS Features Using the MQC
This section provides the following Modular QoS CLI configuration examples:
•
•
•
•
•
•
Creating a Traffic Class: Example
In the following example, two traffic classes are created and their match criteria are defined. For the first traffic class called class1, access control list (ACL) 101 is used as the match criterion. For the second traffic class called class2, ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the class.
Router(config)# class-map class1Router(config-cmap)# match access-group 101Router(config-cmap)# exitRouter(config)# class-map class2Router(config-cmap)# match access-group 102Router(config-cmap)# endCreating a Traffic Policy: Example
In the following example, a traffic policy called policy1 is defined. The traffic policy contains the QoS features to be applied to two classes—class1 and class2. The match criteria for these classes were previously defined (as described in the "Creating a Traffic Class: Example").
For class1, the policy includes a bandwidth allocation request and a maximum packet count limit for the queue reserved for the class. For class2, the policy specifies only a bandwidth allocation request.
Router(config)# policy-map policy1Router(config-pmap)# class class1Router(config-pmap-c)# bandwidth 3000Router(config-pmap-c)# queue-limit 30Router(config-pmap-c)# exitRouter(config-pmap)# class class2Router(config-pmap-c)# bandwidth 2000Router(config-pmap-c)# endAttaching a Traffic Policy to an Interface: Example
The following example shows how to attach an existing traffic policy to an interface. After you define a traffic policy with the policy-map command, you can attach it to one or more interfaces by using the service-policy command in interface configuration mode. Although you can assign the same traffic policy to multiple interfaces, each interface can have only one traffic policy attached in the input direction and only one traffic policy attached in the output direction.
Router(config)# interface fastethernet1/1/1Router(config-if)# service-policy output policy1Router(config-if)# exitRouter(config)# interface fastethernet1/0/0Router(config-if)# service-policy output policy1Router(config-if)# endmatch not Command: Example
The match not command is used to specify a specific QoS policy value that is not used as a match criterion. When using the match not command, all other values of that QoS policy become successful match criteria.
For instance, if the match not qos-group 4 command is issued in class-map configuration mode, the specified class will accept all QoS group values except 4 as successful match criteria.
In the following traffic class, all protocols except IP are considered successful match criteria:
Router(config)# class-map noipRouter(config-cmap)# match not protocol ipRouter(config-cmap)# endDefault Traffic Class Configuration: Example
Unclassified traffic (traffic that does not meet the match criteria specified in the traffic classes) is treated as belonging to the default traffic class.
If you do not configure a default class, packets are still treated as members of the default class. However, by default, the default class has no QoS features enabled. Therefore, packets belonging to a default class have no QoS functionality. These packets are placed into a first-in, first-out (FIFO) queue managed by tail drop. Tail drop is a means of avoiding congestion that treats all traffic equally and does not differentiate between classes of service. Queues fill during periods of congestion. When the output queue is full and tail drop is in effect, packets are dropped until the congestion is eliminated and the queue is no longer full.
The following example configures a traffic policy for the default class of the traffic policy called policy1. The default class (which is always called class-default) has these characteristics: 10 queues for traffic that does not meet the match criteria of other classes whose policy is defined by the traffic policy policy1, and a maximum of 20 packets per queue before tail drop is enacted to handle additional queued packets.
Router(config)# policy-map policy1Router(config-pmap)# class class-defaultRouter(config-pmap-c)# fair-queueRouter(config-pmap-c)# queue-limit 20class-map match-any and class-map match-all Commands: Example
This example illustrates the difference between the class-map match-any command and the class-map match-all command. The match-any and match-all keywords determine how packets are evaluated when multiple match criteria exist. Packets must either meet all of the match criteria (match-all) or meet one of the match criterion (match-any) to be considered a member of the traffic class.
The following example shows a traffic class configured with the class-map match-all command:
Router(config)# class-map match-all cisco1Router(config-cmap)# match protocol ipRouter(config-cmap)# match qos-group 4Router(config-cmap)# match access-group 101If a packet arrives on a router with the traffic class called cisco1 configured on the interface, the packet is evaluated to determine if it matches the IP protocol, QoS group 4, and access group 101. If all three of these match criteria are met, the packet is classified as a member of the traffic class cisco1.
The following example shows a traffic class that is configured with the class-map match-any command:
Router(config)# class-map match-any cisco2Router(config-cmap)# match protocol ipRouter(config-cmap)# match qos-group 4Router(config-cmap)# match access-group 101In the traffic class called cisco2, the match criteria are evaluated consecutively until a successful match criterion is located. The packet is first evaluated to the determine whether the IP protocol can be used as a match criterion. If the IP protocol can be used as a match criterion, the packet is matched to traffic class cisco2. If the IP protocol is not a successful match criterion, then QoS group 4 is evaluated as a match criterion. Each criterion is evaluated to see if the packet matches that criterion. Once a successful match occurs, the packet is classified as a member of traffic class cisco2. If the packet matches none of the specified criteria, the packet is classified as a member of the default traffic class (class default-class).
Note that the class-map match-all command requires that all of the match criteria be met in order for the packet to be considered a member of the specified traffic class (a logical AND operator). In the first example, protocol IP AND QoS group 4 AND access group 101 must be successful match criteria. However, only one match criterion must be met in order for the packet in the class-map match-any command to be classified as a member of the traffic class (a logical OR operator). In the second example, protocol IP OR QoS group 4 OR access group 101 must be successful match criterion.
Traffic Policy as a QoS Policy (Hierarchical Traffic Policies): Example
A traffic policy can be included in a QoS policy when the service-policy command is used in policy-map class configuration mode. A traffic policy that contains a traffic policy is called a hierarchical traffic policy.
A hierarchical traffic policy contains a child policy and a parent policy. The child policy is the previously defined traffic policy that is being associated with the new traffic policy through the use of the service-policy command. The new traffic policy using the preexisting traffic policy is the parent policy. In the example in this section, the traffic policy called child is the child policy and traffic policy called parent is the parent policy.
Hierarchical traffic policies can be attached to subinterfaces and ATM PVCs. When hierarchical traffic policies are used, a single traffic policy (with a child and a parent policy) can be used to shape and prioritize PVC traffic. In the following example, the child policy is responsible for prioritizing traffic and the parent policy is responsible for shaping traffic. In this configuration, the parent policy allows packets to be sent from the interface, and the child policy determines the order in which the packets are sent.
Router(config)# policy-map childRouter(config-pmap)# class voiceRouter(config-pmap-c)# priority 50Router(config)# policy-map parentRouter(config-pmap)# class class-defaultRouter(config-pmap-c)# shape average 10000000Router(config-pmap-c)# service-policy childThe value used with the shape command is provisioned from the committed information rate (CIR) value from the service provider.
Additional References
The following sections provide references related to the applying QoS features using the MQC.
Related Documents
QoS commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples
Packet classification
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
Feature Information for Applying QoS Features Using the MQC
Table 3 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 3 Feature Information for Applying QoS Features Using the MQC
Modular QoS CLI (MQC)
Cisco IOS XE Release 2.1
This module contains the concepts about applying QoS features using the Modular Quality of Service (QoS) Command-Line Interface (CLI) (MQC) and the tasks for configuring the MQC. The MQC allows you to define a traffic class, create a traffic policy (policy map), and attach the traffic policy to an interface. The traffic policy contains the QoS feature that will be applied to the traffic class.
This feature was introduced on Cisco ASR 1000 Series Routers.
This feature was enhanced to provide infrastructure support for additional features included with Cisco IOS XE Release 2.3.
Priority Queueing
Cisco IOS XE Release 2.1
This feature was introduced on Cisco ASR 1000 Series Routers.
The following section provides information about this feature:
•
Weighted Random Early Detection
Cisco IOS XE Release 2.1
This feature was introduced on Cisco ASR 1000 Series Routers.
The following section provides information about this feature:
•
Class-Based Weighted Fair Queueing (CBWFQ)
Cisco IOS XE Release 2.1
This feature was introduced on Cisco ASR 1000 Series Routers.
The following section provides information about this feature:
•
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco Ironport, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flip Video, Flip Video (Design), Flipshare (Design), Flip Ultra, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Store, and Flip Gift Card are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website 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. (0907R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2007-2009 Cisco Systems, Inc. All rights reserved.
