 Feedback
|
Table Of Contents
Modular Quality of Service Command-Line Interface
Information About Modular QoS CLI
How to Configure Modular QoS CLI
Attaching a Traffic Policy to an Interface
Configuration Examples for Modular QoS CLI
Traffic Classes Defined Example
Traffic Policy Created Example
Traffic Policy Attached to an Interface Example
Default Traffic Class Configuration Example
class-map match-any and class-map match-all Commands Example
Traffic Class as a Match Criterion (Nested Class Maps) Example
Nested Traffic Class for Maintenance Example
Nested Traffic Class to Combine match-any and match-all Characteristics in One Traffic Class Example
Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example
Modular Quality of Service Command-Line Interface
This feature module provides a high-level overview of the Modular Quality of Service (QoS) Command-Line Interface (CLI), a feature that allows users to specify a traffic class independently of QoS policies.
Feature History for Modular QoS CLI
12.0(5)XE
This feature was introduced.
12.0(26)S
This feature was integrated into Cisco IOS release 12.0(26)S for the Cisco 7200 and 7500 series routers.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Information About Modular QoS CLI
•
•
Information About Modular QoS CLI
The Modular QoS CLI is a CLI structure that allows users to create traffic polices and attach these polices to interfaces. A traffic policy contains a traffic class and one or more QoS features. A traffic class is used to classify traffic, while the QoS features in the traffic policy determine how to treat the classified traffic.
Modular QoS CLI configuration includes contains the following three steps, which are detailed more thoroughly in the section How to Configure Modular QoS CLI.
Step 1
Step 2
Step 3
The class-map command is used to define a traffic class. The purpose of a traffic class is to classify traffic.
A traffic class contains three major elements: a name, a series of match commands, and, if more than one match command exists in the traffic class, an instruction on how to evaluate these match commands. The traffic class is named in the class-map command line; for example, if you enter the class-map cisco command while configuring the traffic class in the CLI, the traffic class would be named cisco.
The match commands are used to specify various criteria for classifying packets. Packets are checked to determine whether they match the criteria specified in the match commands; if a packet matches the specified criteria, that packet is considered a member of the class and is forwarded according to the QoS specifications set in the traffic policy. Packets that fail to meet any of the matching criteria are classified as members of the default traffic class. The default traffic class is detailed more thoroughly in the section How to Configure Modular QoS CLI.
The instruction on how to evaluate these match commands needs to be specified if more than one match criterion exists in the traffic class. The evaluation instruction is specified with one of the following two options: class-map match-any or class-map match-all. If match-any is specified as the evaluation instruction, the traffic being evaluated by the traffic class must match one of the specified criteria. If match-all is specified as the evaluation instruction, the traffic being evaluated by the traffic class must match all of the specified criteria. The functionality of these options is detailed more thoroughly in the section How to Configure Modular QoS CLI.
The policy-map command is used to create a traffic policy. The purpose of a traffic policy is to configure the QoS features that should be associated with the traffic that has been classified in a user-specified traffic class or classes. A traffic policy contains three elements: a name, a traffic class (specified with the class command), and the QoS policies (which are detailed in the section How to Configure Modular QoS CLI. The name of a traffic policy is specified in the policy-map CLI (for example, issuing the policy-map class1 command would create a traffic policy named class1). The traffic class that is used to classify traffic to the specified traffic policy is defined in policy map configuration mode, which is the automatic mode after naming the traffic policy. After choosing the traffic class that is used to classify traffic to the traffic policy, the user can enter the QoS features to apply to the classified traffic. This is done in policy-map class configuration mode. The QoS feature options are detailed more thoroughly in the section How to Configure Modular QoS CLI.
The Modular QoS CLI does not necessarily require that users associate only one traffic class to one traffic policy. When packets match to more than one match criterion, multiple traffic classes can be associated with a single traffic policy.
Similarly, the Modular QoS CLI allows multiple traffic classes (nested traffic classes, which are also called nested class maps) to be configured as a single traffic class. This nesting can be achieved with the use of the match class-map command. The only method of combining match-any and match-all characteristics within a single traffic class is with the match class-map command. An example of a nested traffic class configuration using both match-all and match-any is provided in the section How to Configure Modular QoS CLI.
Note
The service-policy command is used to attach the traffic policy, as specified with the policy-map command, to an interface. Because the elements of the traffic policy can be applied to packets entering and leaving the interface, users are required to specify whether the traffic policy characteristics should be applied to incoming or outgoing packets. For instance, the service-policy output class1 command would attach all the characteristics of the traffic policy named class1 to the specified interface. All packets leaving the specified interface are evaluated according to the criteria specified in the traffic policy named class1. For information on using the service-policy command, see the section How to Configure Modular QoS CLI.
How to Configure Modular QoS CLI
To configure and enable class-based QoS features, perform the tasks described in the following sections. The tasks in the first three sections are required; the task in the remaining section is optional.
•
•
•
•
Creating a Traffic Class
The class-map global configuration command is used to create a traffic class. The syntax of the class-map command is as follows:
class-map [match-any | match-all] class-name
no class-map [match-any | match-all] class-nameThe match all and match any options need to be specified only if more than one match criterion is configured in the traffic class. The class-map match-all command is used when all of the match criteria in the traffic class must be met in order for a packet to match the specified traffic class. The class-map match-any command is used when only one of the match criterion in the traffic class must be met in order for a packet to match the specified traffic class. If neither the match-all nor match-any keyword is specified, the traffic class will behave in a manner consistent with class-map match-all command.
The match not command, rather than identifying the specific match parameter to use as a match criterion, is used to specify a match criterion that prevents a packet from being classified as a member of the class. For instance, if the match not qos-group 6 command is issued while you configure the traffic class, QoS group 6 becomes the only QoS group value that is not considered a successful match criterion. All other QoS group values would be successful match criteria.
To create a traffic class containing match criteria, use the class-map global configuration command to specify the traffic class name, and then use the following match commands in class-map configuration mode, as needed. See Table 1 for the class-map and match commands you can use.
Table 1 class-map and match Commands
Creating a Traffic Policy
To configure a traffic policy, use the policy-map global configuration command to specify the traffic policy name, and the use the following configuration commands to associate a traffic class, which was configured with the class-map command, with one or more QoS features. The traffic class is associated with the traffic policy when the class command is used. The class command must be issued after entering policy-map configuration mode. After entering the class command, you are automatically in policy-map class configuration mode, which is where the QoS policies for the traffic policy are defined.
The QoS policies that can be applied in the traffic policy in policy-map class configuration mode are detailed in the following example:
The syntax of the policy-map command is:
policy-map policy-name
no policy-map policy-nameThe syntax of the class command is:
class class-name
no class class-nameAll traffic that fails to meet the matching criteria belongs to the default traffic class. The default traffic class is user-configurable, but the default traffic class cannot be deleted.
To configure a traffic policy, use the policy-map global configuration command to specify the traffic policy name, and then use the following configuration commands to associate a traffic class, which was configured with the class-map command, with one or more QoS policies. The traffic class is associated with the traffic policy when the class command is used. The class command must be issued immediately after entering policy-map configuration mode. After entering the class command, you are automatically in policy-map class configuration mode, which is where the QoS policies for the traffic policy are defined.
To create a traffic policy, use the following commands beginning in global configuration mode, as needed. Table 2 lists some of the command options for the policy-map configuration mode.
Note
Table 2 Commands Available in Policy-Map Configuration Mode
Attaching a Traffic Policy to an Interface
Use the service-policy interface configuration command to attach a traffic policy to an interface and to specify the direction in which the policy should be applied (either on packets coming into the interface or packets leaving the interface).
Use the no form of the command to detach a traffic policy from an interface. The service-policy command syntax is as follows:
service-policy {input | output} policy-map-name
no service-policy {input | output} policy-map-name
Note
To attach a traffic policy to an interface, use the following commands in interface configuration mode, as needed.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Note
Verifying the Configuration
To display the information relating to a traffic class or traffic policy, use one of the following commands.
SUMMARY STEPS
1.
2.
or
show policy-map [policy-map-name]
or
show policy-map [interface [interface-name [input | output] [class class-name]]]
3.
DETAILED STEPS
Configuration Examples for Modular QoS CLI
This section provides the Modular QoS CLI configuration examples:
•
•
•
•
•
•
•
Traffic Classes Defined 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 class1 Router(config-cmap)# match access-group 101 Router(config-cmap)# exitRouter(config)# class-map class2 Router(config-cmap)# match access-group 102 Router(config-cmap)# exitTraffic Policy Created Example
In the following example, a traffic policy called policy1 is defined to contain policy specifications for the two classes—class1 and class2. The match criteria for these classes were defined in the traffic classes (see the section "Creating a Traffic Class" ).
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 class1 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30 Router(config-pmap)# exitRouter(config-pmap)# class class2 Router(config-pmap-c)# bandwidth 2000 Router(config-pmap)# exitTraffic Policy Attached to an Interface Example
The following example shows how to attach an existing traffic policy (which was created in the preceding "Traffic Policy Created Example" section) to an interface. After you define a traffic policy with the policy-map command, you can attach it to one or more interfaces to specify the traffic policy for those 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 at the input and only one traffic policy attached at the output.
Router(config)# interface e1/1 Router(config-if)# service-policy output policy1 Router(config-if)# exitRouter(config)# interface fa1/0/0 Router(config-if)# service-policy output policy1 Router(config-if)# exitmatch 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 ip Router(config-cmap)# exitDefault 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 the user does not configure a default class, packets are still treated as members of the default class. However, by default, the default class has no enabled features. Therefore, packets belonging to a default class with no configured features have no QoS functionality. These packets are then placed into a FIFO queue and forwarded at a rate determined by the available underlying link bandwidth. This FIFO queue is 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 policy1 Router(config-pmap)# class class-default Router(config-pmap-c)# fair-queue 10 Router(config-pmap-c)# queue-limit 20class-map match-any and class-map match-all Commands Example
This section illustrates the difference between the class-map match-any command and the class-map match-all command. The match-any and match-all options determine how packets are evaluated when multiple match criteria exist. Packets must either meet all of the match criteria (match-all) or one of the match criteria (match-any) in order 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 ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# match access-group 101If a packet arrives on a router with 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 matches traffic class cisco1.
The following example shows a traffic class configured with the class-map match-any command:
Router(config)# class-map match-any cisco2 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4Router(config-cmap)# match access-group 101In 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 IP protocol can be used as a match criterion. If IP protocol can be used as a match criterion, the packet is matched to traffic class george. If IP protocol is not a successful match criterion, then QoS group 4 is evaluated as a match criterion. Each matching 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 traffic class.
Note that the class-map match-all command requires that all of the match criteria must be met in order for the packet to be considered a member of the specified traffic class (a logical AND operator). In the example, protocol IP AND QoS group 4 AND access group 101 have to be successful match criteria. However, only one match criterion must be met 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 example, protocol IP OR QoS group 4 OR access group 101 have to be successful match criteria.
Traffic Class as a Match Criterion (Nested Class Maps) Example
There are two reasons to use the match class-map command. One reason is maintenance; if a long traffic class currently exists, using the Traffic Class match criterion is simply easier than retyping the same traffic class configuration.
The more prominent reason for the match class-map command is to allow users to use match-any and match-all statements in the same traffic class. If you want to combine match-all and match-any characteristics in a traffic policy, create a traffic class using one match criteria evaluation instruction (either match any or match all) and then use this traffic class as a match criterion in a traffic class that uses a different match criteria type.
A concept example: Suppose A, B, C, and D were all separate match criterion, and you wanted traffic matching A, B, or C and D (A or B or [C and D]) to be classified as belonging to the traffic class. Without the nested traffic class, traffic would either have to match all 4 of the match criterion (A and B and C and D) or match any of the match criterion (A or B or C or D) to be considered part of the traffic class. You would not be able to combine "and" (match-all) and "or" (match-any) statements within the traffic class, and you would therefore be unable to configure the desired configuration.
The solution: Create one traffic class using match-all for C and D (which we will call criterion E), and then create a new match-any traffic class using A, B, and E. The new traffic class would have the correct evaluation sequence (A or B or E, which would also be A or B or [C and D]). The desired traffic class configuration has been achieved.
The only method of mixing match-all and match-any statements in a traffic class is through the use of the traffic class match criterion.
Nested Traffic Class for Maintenance Example
In the following example, the traffic class called class1 has the same characteristics as traffic class called class2, with the exception that traffic class class1 has added a destination address as a match criterion. Rather than configuring traffic class class1 line by line, a user can enter the match class-map class2 command. This command allows all of the characteristics in the traffic class called class2 to be included in the traffic class called class1, and the user can simply add the new destination address match criterion without reconfiguring the entire traffic class.
Router(config)# class-map match-any class2Router(config-cmap)# match protocol ipRouter(config-cmap)# match qos-group 3Router(config-cmap)# match access-group 2Router(config-cmap)# exitRouter(config)# class-map match-all class1Router(config-cmap)# match class-map class2Router(config-cmap)# match destination-address mac 1.1.1Router(config-cmap)# exitNested Traffic Class to Combine match-any and match-all Characteristics in One Traffic Class Example
The only method of including both match-any and match-all characteristics in a single traffic class is to use the match class-map command. To combine match-any and match-all characteristics into a single class, a traffic class created with the match-any instruction must use a class configured with the match-all instruction as a match criterion (through the match class-map command), or vice versa.
The following example shows how to combine the characteristics of two traffic classes, one with match-any and one with match-all characteristics, into one traffic class with the match class-map command. The result of traffic class montana requires a packet to match one of the following three match criteria to be considered a member of traffic class class4: IP protocol and QoS group 4, destination MAC address 1.1.1, or access group 2.
In this example, only the traffic class called class4 is used with the traffic policy called policy1.
Router(config)# class-map match-all class3Router(config-cmap)# match protocol ipRouter(config-cmap)# match qos-group 4Router(config-cmap)# exitRouter(config)# class-map match-any class4Router(config-cmap)# match class-map class3Router(config-cmap)# match destination-address mac 1.1.1Router(config-cmap)# match access-group 2Router(config-cmap)# exitRouter(config)# policy-map policy1Router(config-pmap)# class class4Router(config-pmap-c)# police 8100 1500 2504 conform-action transmit exceed-action set-qos-transmit 4Router(config-pmap-c)# exitTraffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example
A traffic policy can be nested within a QoS policy when the service-policy command is used in policy-map class configuration mode. A traffic policy that contains a nested traffic policy is called a hierarchical traffic policy.
A hierarchical traffic policy contains a child 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 the traffic policy called parent is the parent policy.
Hierarchical traffic policies can be attached to subinterfaces, Frame Relay PVCs, and ATM PVCs. A hierarchical traffic policy is particularly beneficial when configuring VIP-based distributed FRF.11 and FRF.12 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 childWith the exception that the values associated with the priority and shape commands can be modified, the example is the required configuration for PVCs using FRF.11 or FRF.12. The value used with the shape command is provisioned from the committed information rate (CIR) value from the service provider. For additional information on FRF.11 and FRF.12 PVCs, refer to the Cisco IOS Voice Configuration Library.
Additional References
For additional information related to Modular QoS CLI, refer to the following references:
Related Documents
QOS CLI commands
Cisco IOS Quality of Service Solutions Command Reference, Release 12.2
Class-Based Marking
Class-Based Marking
Class-Based Shaping
Class-Based Shaping
Standards
MIBs
RFCs
Technical Assistance
Command Reference
This section does not contain any new and modified commands. Commands used with this feature are documented in the Cisco IOS Release 12.3 command reference publications.
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site 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. (0304R)
