QOS
Content
Applying QoS Features Using the MQC First Published: April 30, 2007 Last Updated: December 3, 2008 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. Finding Feature Information in This Module Your Cisco IOS software release may not support all of the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the “Feature Information for Applying QoS Features Using the MQC” section on page 20. Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS 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, page 2 • Information About Applying QoS Features Using the MQC, page 2 • How to Apply QoS Features Using the MQC, page 7 • Configuration Examples for Applying QoS Features Using the MQC, page 13 • Additional References, page 18 • Feature Information for Applying QoS Features Using the MQC, page 20 Applying QoS Features Using the MQC Restrictions for Applying QoS Features Using the MQC 2 Restrictions for Applying QoS Features Using the MQC IPX Packets The MQC does not support Internetwork Packet Exchange (IPX) packets. Number of QoS Class Maps Supported The number of QoS class maps supported in a single policy map varies by release, as follows: • For Cisco IOS XE Release 2.1, and Cisco IOS XE Release 2.2, the MQC supports a maximum of 8 class maps in a single policy map. • For Cisco IOS Release 12.4T, Cisco IOS Release 12.2 SR, and Cisco IOS XE Release 2.3, the MQC supports a maximum of 256 class maps in a single policy map.
Number of QoS Policy Maps Supported The number of QoS class maps supported on a router varies by release, as follows: • For Cisco IOS XE Release 2.1, and Cisco IOS XE Release 2.2, the MQC supports no more than 1000 policy maps in the incoming (ingress) direction, outgoing (egress) direction, or a combination of both on a router. • For Cisco IOS Release 12.4T, Cisco IOS Release 12.2 SR, and Cisco IOS XE Release 2.3, the MQC supports no more than 4000 policy maps in the incoming (ingress) direction, outgoing (egress) direction, or a combination of both on a router. 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 exceeding 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, page 3 • Elements of a Traffic Class, page 3 • Elements of a Traffic Policy, page 5 • Nested Traffic Classes, page 7 • Benefits of Applying QoS Features Using the MQC, page 7 Applying QoS Features Using the MQC Information About Applying QoS Features Using the MQC 3 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 Define a traffic class by using the class-map command. A traffic class is used to classify traffic. Step 2 Create a traffic policy by using the policy-map command. (The terms traffic policy and policy map are often synonymous.) A traffic policy (policy map) contains a traffic class and one or more QoS features that will be applied to the traffic class. The QoS features in the traffic policy determine how to treat the classified traffic. Step 3 Attach the traffic policy (policy map) to the interface by using the servicepolicy command. 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 release and platform. For more information about the commands and command syntax, see the command reference for the Cisco IOS release and platform that you are using. Table 1 match Commands That Can Be Used with the MQC Command Purpose match access-group Configures the match criteria for a class map on the basis of the specified access control list (ACL). match any Configures the match criteria for a class map to be successful match criteria for all packets. match class-map Specifies the name of a traffic class to be used as a matching criterion (for nesting traffic classes [nested class maps] within one another). match cos Matches a packet based on a Layer 2 class of service (CoS) marking. match destination-address mac Uses the destination MAC address as a match criterion. match discard-class Matches packets of a certain discard class. Applying QoS Features Using the MQC Information About Applying QoS Features Using the MQC 4 match [ip] dscp Identifies a specific IP differentiated service code point (DSCP) value as a match criterion. Up to eight DSCP values can be included in one match statement. match field Configures the match criteria for a class map on the basis of the fields defined in the protocol header description files (PHDFs). match fr-dlci Specifies the Frame Relay data-link connection identifier (DLCI) number as a match criterion in a class map. match input-interface Configures a class map to use the specified input interface as a match criterion. match ip rtp Configures a class map to use the Real-Time Transport Protocol (RTP) port as the match criterion. match mpls experimental Configures a class map to use the specified value of the Multiprotocol Label Switching (MPLS) experimental (EXP) field as a match criterion.
match mpls experimental topmost Matches the MPLS EXP value in the topmost label. match not Specifies the single match criterion value to use as an unsuccessful match criterion. Note 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. match packet length Specifies the Layer 3 packet length in the IP header as a match criterion in a class map. match port-type Matches traffic on the basis of the port type for a class map. match [ip] precedence Identifies IP precedence values as match criteria. match protocol Configures the match criteria for a class map on the basis of the specified protocol. Note There is a separate match protocol (NBAR) command used to configure Network-Based Application Recognition (NBAR) to match traffic by a protocol type known to NBAR. match protocol citrix Configures NBAR to match Citrix traffic. match protocol fasttrack Configures NBAR to match FastTrack peer-to-peer traffic. match protocol gnutella Configures NBAR to match Gnutella peer-to-peer traffic. match protocol http Configures NBAR to match Hypertext Transfer Protocol (HTTP) traffic by URL, host, Multipurpose Internet Mail Extension (MIME) type, or fields in HTTP packet headers. Table 1 match Commands That Can Be Used with the MQC (continued) Command Purpose Applying QoS Features Using the MQC Information About Applying QoS Features Using the MQC 5 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 matchall keywords: • If you specify the match-any keyword, the traffic being evaluated by the traffic class must match one of the specified criteria. • If you specify the match-all keyword, the traffic being evaluated by the traffic class must match all of the specified criteria.
• If you do not specify either keyword, the traffic being evaluated by the traffic class must match all of the specified criteria (that is, the behavior of the match-all keyword is used). 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 A packet can match only one traffic class within a traffic policy. If a packet matches more than one traffic class in the traffic policy, the first traffic class defined in the policy will be used. Commands Used to Enable QoS Features The commands used to enable QoS features vary by Cisco IOS release and platform. 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 Cisco IOS release and platform 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. match protocol rtp Configures NBAR to match Real-Time Transport Protocol (RTP) traffic. match qos-group Identifies a specific QoS group value as a match criterion. match source-address mac Uses the source MAC address as a match criterion. match start Configures the match criteria for a class map on the basis of the datagram header (Layer 2) or the network header (Layer 3). match tag Specifies tag type as a match criterion. Table 1 match Commands That Can Be Used with the MQC (continued) Command Purpose Table 2 Commands Used to Enable QoS Features Command Purpose bandwidth Enables Class-Based Weighted Fair Queuing (CBWFQ). fair-queue Specifies the number of queues to be reserved for a traffic class. Applying QoS Features Using the MQC Information About Applying QoS Features Using the MQC 6 drop Discards the packets in the specified traffic class. identity policy Creates an identity policy. police Configures traffic policing. police (control-plane) Configures traffic policing for traffic that is destined for the control plane. police (EtherSwitch) Defines a policer for classified traffic. police (percent) Configures traffic policing on the basis of a percentage of bandwidth available on an interface. police (two rates) Configures traffic policing using two rates, the committed information rate (CIR) and the peak information rate (PIR). police rate pdp Configures Packet Data Protocol (PDP) traffic policing using the police rate.
Note This command is intended for use on the Gateway General Packet Radio Service (GPRS) Support Node (GGSN). priority Gives priority to a class of traffic belonging to a policy map. queue-limit Specifies or modifies the maximum number of packets the queue can hold for a class configured in a policy map. random-detect Enables Weighted Random Early Detection (WRED) or distributed WRED (DWRED). random-detect discard-class Configures the WRED parameters for a discardclass value for a class in a policy map. random-detect discard-class-based Configures WRED on the basis of the discard class value of a packet. random-detect ecn Enables explicit congestion notification (ECN). random-detect exponential-weighting-constant Configures the exponential weight factor for the average queue size calculation for the queue reserved for a class. random-detect precedence Configure the WRED parameters for a particular IP Precedence for a class policy in a policy map. service-policy Specifies the name of a traffic policy used as a matching criterion (for nesting traffic policies [hierarchical traffic policies] within one another). set atm-clp Sets the cell loss priority (CLP) bit when a policy map is configured. set cos Sets the Layer 2 class of service (CoS) value of an outgoing packet. set discard-class Marks a packet with a discard-class value. set [ip] dscp Marks a packet by setting the differentiated services code point (DSCP) value in the type of service (ToS) byte. set fr-de Changes the discard eligible (DE) bit setting in the address field of a Frame Relay frame to 1 for all traffic leaving an interface. Table 2 Commands Used to Enable QoS Features (continued) Command Purpose Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 7 Nested Traffic Classes The MQC does not necessarily require that you associate only one traffic class to one traffic policy. When packets meet more than one match criterion, multiple traffic classes can be associated with a single traffic policy. Similarly, the MQC 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 matchall characteristics within a single traffic class is with the match class-map command. For an example of a nested traffic class configuration, see the “Traffic Class as a Match Criterion (Nested Traffic Classes): Example” section on page 16. 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 (required) • Creating a Traffic Policy (required) • Attaching a Traffic Policy to an Interface (required) • Verifying the Traffic Class and Traffic Policy Information (optional) set mpls experimental Designates the value to which the MPLS bits are set if the packets match the specified policy map. set precedence Sets the precedence value in the packet header. set qos-group Sets a QoS group identifier (ID) that can be used later to classify packets. shape Shapes traffic to the indicated bit rate according to the algorithm specified. shape adaptive Configures a Frame Relay interface or a point-to-point subinterface to estimate the available bandwidth by backward explicit congestion notification (BECN) integration while traffic shaping is enabled. shape fecn-adapt Configures a Frame Relay interface to reflect received forward explicit congestion notification (FECN) bits as backward explicit congestion notification (BECN) bits in Q.922 test response messages. Table 2 Commands Used to Enable QoS Features (continued) Command Purpose Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 8 Creating a Traffic Class 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 cos command is shown in Step 4. The match cos command is simply an example of one of the match commands that you can use. For information about the other available match commands, see Table 1 on page 3.
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 matchany. 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: • The match-all keyword is used when all of the match criteria in the traffic class must be met in order for a packet to be placed in the specified traffic class. • The match-any keyword is used when only one of the match criterion in the traffic class must be met in order for a packet to be placed in the specified traffic class. • If neither the match-all keyword nor match-any keyword is specified, the traffic class will behave in a manner consistent with match-all keyword. SUMMARY STEPS 1. enable 2. configure terminal 3. class-map [match-all | match-any] class-map-name 4. match cos cos-number 5. Enter additional match commands, if applicable; otherwise, continue with Step 6. 6. end DETAILED STEPS Command or Action Purpose Step 1 enable Example: Router> enable Enables privileged EXEC mode. • Enter your password if prompted. Step 2 configure terminal Example: Router# configure terminal Enters global configuration mode. Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 9 Creating a Traffic Policy To create a traffic policy (or policy map) and enable one or more QoS features, perform the following steps. Note The bandwidth command is shown in Step 5. The bandwidth command is simply an example of one of the commands that you can use in a policy map to enable a QoS feature (in this case, CBWFQ). For information about other available commands, see Table 2 on page 5. SUMMARY STEPS 1. enable
2. configure terminal 3. policy-map policy-map-name 4. class {class-name | class-default} 5. bandwidth {bandwidth-kbps | percent percent} 6. Enter the commands for any additional QoS feature that you want to enable, if applicable; otherwise, continue with Step 7. 7. end 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. • Enter the class name. Note The match-all keyword specifies that all match criteria must be met. The match-any keyword specifies that one of the match criterion must be met. Use these keywords only if you will be specifying more than one match command. 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. • Enter the CoS number. Note The match cos command is simply an example of one of the match commands you can use. For information about the other match commands that are available, see Table 1 on page 3. 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. Command or Action Purpose Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 10 DETAILED STEPS Command or Action Purpose Step 1 enable Example: Router> enable Enables privileged EXEC mode. • Enter your password if prompted.
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. • Enter the policy map name. 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. • Enter the class name created in the “Creating a Traffic Class” section on page 8). Note This step associates the traffic class with the traffic policy. 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 The bandwidth command enables CBWFQ. The bandwidth command is simply an example of one of the commands that you can use in a policy map to enable a QoS feature. For information about the other commands available, see Table 2 on page 5. 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. Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 11 Attaching a Traffic Policy to an Interface 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 release that you are using, a traffic policy can be attached to
an ATM permanent virtual circuit (PVC) subinterface, a Frame Relay data-link connection identifier (DLCI), or 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 The QoS feature 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 by using the input or output keyword. For instance, the service-policy output class1 command would apply the feature in the traffic policy to the interface. All packets leaving the interface are evaluated according to the criteria specified in the traffic policy named class1. Restrictions Multiple traffic policies on tunnel interfaces and physical interfaces are not supported if the interfaces are associated with each other. For instance, if a traffic policy is attached to a tunnel interface while another traffic policy is attached to a physical interface—with which the tunnel interface is associated—only the traffic policy on the tunnel interface works properly. SUMMARY STEPS 1. enable 2. configure terminal 3. interface interface-type interface-number 4. service-policy {input | output} policy-map-name 5. end DETAILED STEPS Command or Action Purpose Step 1 enable Example: Router> enable Enables privileged EXEC mode. • Enter your password if prompted. Step 2 configure terminal Example: Router# configure terminal Enters global configuration mode. Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 12 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. enable 2. show class-map 3. show policy-map policy-map-name class class-name
4. show policy-map 5. show policy-map interface interface-type interface-number 6. exit DETAILED STEPS Step 3 interface interface-type interface-number Example: Router(config)# interface serial0 Configures an interface type and enters interface configuration mode. • Enter the interface type and interface number. Step 4 service-policy {input | output} policy-map-name Example: Router(config-if)# service-policy input policy1 Attaches a policy map to an interface. • Enter either the input or output keyword and the policy map name. Step 5 end Example: Router (config-if)# end (Optional) Exits interface configuration mode and returns to privileged EXEC mode. Command or Action Purpose Command or Action Purpose Step 1 enable Example: Router> enable Enables privileged EXEC mode. • Enter your password if prompted. Step 2 show class-map Example: Router# show class-map (Optional) Displays all class maps and their matching criteria. Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 13 Configuration Examples for Applying QoS Features Using the MQC This section provides the following Modular QoS CLI configuration examples: • Creating a Traffic Class: Example • Creating a Traffic Policy: Example • Attaching a Traffic Policy to an Interface: Example • match not Command: Example • Default Traffic Class Configuration: Example • class-map match-any and class-map match-all Commands: Example • Traffic Class as a Match Criterion (Nested Traffic Classes): Example • Traffic Policy as a QoS Policy (Hierarchical Traffic Policies): Example Step 3 show policy-map policy-map-name class
class-name Example: Router# show policy-map policy1 class class1 (Optional) Displays the configuration for the specified class of the specified policy map. • Enter the policy map name and the class name. Step 4 show policy-map Example: Router# show policy-map (Optional) Displays the configuration of all classes for all existing policy maps. Step 5 show policy-map interface interface-type interface-number Example: Router# show policy-map interface serial0 (Optional) Displays the statistics and the configurations of the input and output policies that are attached to an interface. • Enter the interface type and number. Step 6 exit Example: Router# exit (Optional) Exits privileged EXEC mode. Command or Action Purpose Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 14 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 class1 Router(config-cmap)# match access-group 101 Router(config-cmap)# exit Router(config)# class-map class2 Router(config-cmap)# match access-group 102 Router(config-cmap)# exit Creating 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 policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30 Router(config-pmap-c)# exit Router(config-pmap)# class class2 Router(config-pmap-c)# bandwidth 2000 Router(config-pmap-c)# exit Attaching 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 ethernet1/1 Router(config-if)# service-policy output policy1 Router(config-if)# exit Router(config)# interface fastethernet1/0/0 Router(config-if)# service-policy output policy1 Router(config-if)# exit Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 15 match 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 noip Router(config-cmap)# match not protocol ip Router(config-cmap)# exit Default 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 policy1 Router(config-pmap)# class class-default Router(config-pmap-c)# fair-queue 10 Router(config-pmap-c)# queue-limit 20 class-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 matchall command: Router(config)# class-map match-all cisco1 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# match access-group 101 If 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. Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 16 The following example shows a traffic class configured with the class-map matchany command: Router(config)# class-map match-any cisco2
Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# match access-group 101 In 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 classmap 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 Class as a Match Criterion (Nested Traffic Classes): Example There are two reasons to use the match class-map command. One reason is maintenance; if a large traffic class currently exists, using the traffic class match criterion is simply easier than retyping the same traffic class configuration. The more common 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 criterion 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 criterion type. Here is a possible scenario: 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 the 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, you 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 you can simply add the new destination address match criterion without reconfiguring the entire traffic class. Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 17 Router(config)# class-map match-any class2 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 3 Router(config-cmap)# match access-group 2 Router(config-cmap)# exit Router(config)# class-map match-all class1 Router(config-cmap)# match class-map class2 Router(config-cmap)# match destination-address mac 00.00.00.00.00.00 Router(config-cmap)# exit Nested 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 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 00.00.00.00.00.00, 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 class3 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# exit Router(config)# class-map match-any class4 Router(config-cmap)# match class-map class3 Router(config-cmap)# match destination-address mac 00.00.00.00.00.00 Router(config-cmap)# match access-group 2 Router(config-cmap)# exit Router(config)# policy-map policy1 Router(config-pmap)# class class4 Router(config-pmap-c)# police 8100 1500 2504 conform-action transmit exceed-action set-qos-transmit 4 Router(config-pmap-c)# end Traffic 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 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. Applying QoS Features Using the MQC Additional References 18 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.12 (and
higher) 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 child Router(config-pmap)# class voice Router(config-pmap-c)# priority 50 Router(config)# policy-map parent Router(config-pmap)# class class-default Router(config-pmap-c)# shape average 10000000 Router(config-pmap-c)# service-policy child With 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.12 (or higher). The value used with the shape command is provisioned from the committed information rate (CIR) value from the service provider. For more information about FRF.12 (or higher) PVCs, see the “FRF .20 Support” module. Additional References The following sections provide references related to the applying QoS features using the MQC. Related Documents Related Topic Document Title QoS commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples Cisco IOS Quality of Service Solutions Command Reference Packet classification “Classifying Network Traffic” module FRF PVCs “FRF .20 Support” module Applying QoS Features Using the MQC Additional References 19 Technical Assistance Description Link The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website
requires a Cisco.com user ID and password. http://www.cisco.com/techsupport
Number of QoS Policy Maps Supported The number of QoS class maps supported on a router varies by release, as follows: • For Cisco IOS XE Release 2.1, and Cisco IOS XE Release 2.2, the MQC supports no more than 1000 policy maps in the incoming (ingress) direction, outgoing (egress) direction, or a combination of both on a router. • For Cisco IOS Release 12.4T, Cisco IOS Release 12.2 SR, and Cisco IOS XE Release 2.3, the MQC supports no more than 4000 policy maps in the incoming (ingress) direction, outgoing (egress) direction, or a combination of both on a router. 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 exceeding 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, page 3 • Elements of a Traffic Class, page 3 • Elements of a Traffic Policy, page 5 • Nested Traffic Classes, page 7 • Benefits of Applying QoS Features Using the MQC, page 7 Applying QoS Features Using the MQC Information About Applying QoS Features Using the MQC 3 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 Define a traffic class by using the class-map command. A traffic class is used to classify traffic. Step 2 Create a traffic policy by using the policy-map command. (The terms traffic policy and policy map are often synonymous.) A traffic policy (policy map) contains a traffic class and one or more QoS features that will be applied to the traffic class. The QoS features in the traffic policy determine how to treat the classified traffic. Step 3 Attach the traffic policy (policy map) to the interface by using the servicepolicy command. 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 release and platform. For more information about the commands and command syntax, see the command reference for the Cisco IOS release and platform that you are using. Table 1 match Commands That Can Be Used with the MQC Command Purpose match access-group Configures the match criteria for a class map on the basis of the specified access control list (ACL). match any Configures the match criteria for a class map to be successful match criteria for all packets. match class-map Specifies the name of a traffic class to be used as a matching criterion (for nesting traffic classes [nested class maps] within one another). match cos Matches a packet based on a Layer 2 class of service (CoS) marking. match destination-address mac Uses the destination MAC address as a match criterion. match discard-class Matches packets of a certain discard class. Applying QoS Features Using the MQC Information About Applying QoS Features Using the MQC 4 match [ip] dscp Identifies a specific IP differentiated service code point (DSCP) value as a match criterion. Up to eight DSCP values can be included in one match statement. match field Configures the match criteria for a class map on the basis of the fields defined in the protocol header description files (PHDFs). match fr-dlci Specifies the Frame Relay data-link connection identifier (DLCI) number as a match criterion in a class map. match input-interface Configures a class map to use the specified input interface as a match criterion. match ip rtp Configures a class map to use the Real-Time Transport Protocol (RTP) port as the match criterion. match mpls experimental Configures a class map to use the specified value of the Multiprotocol Label Switching (MPLS) experimental (EXP) field as a match criterion.
match mpls experimental topmost Matches the MPLS EXP value in the topmost label. match not Specifies the single match criterion value to use as an unsuccessful match criterion. Note 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. match packet length Specifies the Layer 3 packet length in the IP header as a match criterion in a class map. match port-type Matches traffic on the basis of the port type for a class map. match [ip] precedence Identifies IP precedence values as match criteria. match protocol Configures the match criteria for a class map on the basis of the specified protocol. Note There is a separate match protocol (NBAR) command used to configure Network-Based Application Recognition (NBAR) to match traffic by a protocol type known to NBAR. match protocol citrix Configures NBAR to match Citrix traffic. match protocol fasttrack Configures NBAR to match FastTrack peer-to-peer traffic. match protocol gnutella Configures NBAR to match Gnutella peer-to-peer traffic. match protocol http Configures NBAR to match Hypertext Transfer Protocol (HTTP) traffic by URL, host, Multipurpose Internet Mail Extension (MIME) type, or fields in HTTP packet headers. Table 1 match Commands That Can Be Used with the MQC (continued) Command Purpose Applying QoS Features Using the MQC Information About Applying QoS Features Using the MQC 5 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 matchall keywords: • If you specify the match-any keyword, the traffic being evaluated by the traffic class must match one of the specified criteria. • If you specify the match-all keyword, the traffic being evaluated by the traffic class must match all of the specified criteria.
• If you do not specify either keyword, the traffic being evaluated by the traffic class must match all of the specified criteria (that is, the behavior of the match-all keyword is used). 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 A packet can match only one traffic class within a traffic policy. If a packet matches more than one traffic class in the traffic policy, the first traffic class defined in the policy will be used. Commands Used to Enable QoS Features The commands used to enable QoS features vary by Cisco IOS release and platform. 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 Cisco IOS release and platform 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. match protocol rtp Configures NBAR to match Real-Time Transport Protocol (RTP) traffic. match qos-group Identifies a specific QoS group value as a match criterion. match source-address mac Uses the source MAC address as a match criterion. match start Configures the match criteria for a class map on the basis of the datagram header (Layer 2) or the network header (Layer 3). match tag Specifies tag type as a match criterion. Table 1 match Commands That Can Be Used with the MQC (continued) Command Purpose Table 2 Commands Used to Enable QoS Features Command Purpose bandwidth Enables Class-Based Weighted Fair Queuing (CBWFQ). fair-queue Specifies the number of queues to be reserved for a traffic class. Applying QoS Features Using the MQC Information About Applying QoS Features Using the MQC 6 drop Discards the packets in the specified traffic class. identity policy Creates an identity policy. police Configures traffic policing. police (control-plane) Configures traffic policing for traffic that is destined for the control plane. police (EtherSwitch) Defines a policer for classified traffic. police (percent) Configures traffic policing on the basis of a percentage of bandwidth available on an interface. police (two rates) Configures traffic policing using two rates, the committed information rate (CIR) and the peak information rate (PIR). police rate pdp Configures Packet Data Protocol (PDP) traffic policing using the police rate.
Note This command is intended for use on the Gateway General Packet Radio Service (GPRS) Support Node (GGSN). priority Gives priority to a class of traffic belonging to a policy map. queue-limit Specifies or modifies the maximum number of packets the queue can hold for a class configured in a policy map. random-detect Enables Weighted Random Early Detection (WRED) or distributed WRED (DWRED). random-detect discard-class Configures the WRED parameters for a discardclass value for a class in a policy map. random-detect discard-class-based Configures WRED on the basis of the discard class value of a packet. random-detect ecn Enables explicit congestion notification (ECN). random-detect exponential-weighting-constant Configures the exponential weight factor for the average queue size calculation for the queue reserved for a class. random-detect precedence Configure the WRED parameters for a particular IP Precedence for a class policy in a policy map. service-policy Specifies the name of a traffic policy used as a matching criterion (for nesting traffic policies [hierarchical traffic policies] within one another). set atm-clp Sets the cell loss priority (CLP) bit when a policy map is configured. set cos Sets the Layer 2 class of service (CoS) value of an outgoing packet. set discard-class Marks a packet with a discard-class value. set [ip] dscp Marks a packet by setting the differentiated services code point (DSCP) value in the type of service (ToS) byte. set fr-de Changes the discard eligible (DE) bit setting in the address field of a Frame Relay frame to 1 for all traffic leaving an interface. Table 2 Commands Used to Enable QoS Features (continued) Command Purpose Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 7 Nested Traffic Classes The MQC does not necessarily require that you associate only one traffic class to one traffic policy. When packets meet more than one match criterion, multiple traffic classes can be associated with a single traffic policy. Similarly, the MQC 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 matchall characteristics within a single traffic class is with the match class-map command. For an example of a nested traffic class configuration, see the “Traffic Class as a Match Criterion (Nested Traffic Classes): Example” section on page 16. 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 (required) • Creating a Traffic Policy (required) • Attaching a Traffic Policy to an Interface (required) • Verifying the Traffic Class and Traffic Policy Information (optional) set mpls experimental Designates the value to which the MPLS bits are set if the packets match the specified policy map. set precedence Sets the precedence value in the packet header. set qos-group Sets a QoS group identifier (ID) that can be used later to classify packets. shape Shapes traffic to the indicated bit rate according to the algorithm specified. shape adaptive Configures a Frame Relay interface or a point-to-point subinterface to estimate the available bandwidth by backward explicit congestion notification (BECN) integration while traffic shaping is enabled. shape fecn-adapt Configures a Frame Relay interface to reflect received forward explicit congestion notification (FECN) bits as backward explicit congestion notification (BECN) bits in Q.922 test response messages. Table 2 Commands Used to Enable QoS Features (continued) Command Purpose Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 8 Creating a Traffic Class 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 cos command is shown in Step 4. The match cos command is simply an example of one of the match commands that you can use. For information about the other available match commands, see Table 1 on page 3.
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 matchany. 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: • The match-all keyword is used when all of the match criteria in the traffic class must be met in order for a packet to be placed in the specified traffic class. • The match-any keyword is used when only one of the match criterion in the traffic class must be met in order for a packet to be placed in the specified traffic class. • If neither the match-all keyword nor match-any keyword is specified, the traffic class will behave in a manner consistent with match-all keyword. SUMMARY STEPS 1. enable 2. configure terminal 3. class-map [match-all | match-any] class-map-name 4. match cos cos-number 5. Enter additional match commands, if applicable; otherwise, continue with Step 6. 6. end DETAILED STEPS Command or Action Purpose Step 1 enable Example: Router> enable Enables privileged EXEC mode. • Enter your password if prompted. Step 2 configure terminal Example: Router# configure terminal Enters global configuration mode. Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 9 Creating a Traffic Policy To create a traffic policy (or policy map) and enable one or more QoS features, perform the following steps. Note The bandwidth command is shown in Step 5. The bandwidth command is simply an example of one of the commands that you can use in a policy map to enable a QoS feature (in this case, CBWFQ). For information about other available commands, see Table 2 on page 5. SUMMARY STEPS 1. enable
2. configure terminal 3. policy-map policy-map-name 4. class {class-name | class-default} 5. bandwidth {bandwidth-kbps | percent percent} 6. Enter the commands for any additional QoS feature that you want to enable, if applicable; otherwise, continue with Step 7. 7. end 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. • Enter the class name. Note The match-all keyword specifies that all match criteria must be met. The match-any keyword specifies that one of the match criterion must be met. Use these keywords only if you will be specifying more than one match command. 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. • Enter the CoS number. Note The match cos command is simply an example of one of the match commands you can use. For information about the other match commands that are available, see Table 1 on page 3. 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. Command or Action Purpose Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 10 DETAILED STEPS Command or Action Purpose Step 1 enable Example: Router> enable Enables privileged EXEC mode. • Enter your password if prompted.
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. • Enter the policy map name. 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. • Enter the class name created in the “Creating a Traffic Class” section on page 8). Note This step associates the traffic class with the traffic policy. 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 The bandwidth command enables CBWFQ. The bandwidth command is simply an example of one of the commands that you can use in a policy map to enable a QoS feature. For information about the other commands available, see Table 2 on page 5. 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. Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 11 Attaching a Traffic Policy to an Interface 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 release that you are using, a traffic policy can be attached to
an ATM permanent virtual circuit (PVC) subinterface, a Frame Relay data-link connection identifier (DLCI), or 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 The QoS feature 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 by using the input or output keyword. For instance, the service-policy output class1 command would apply the feature in the traffic policy to the interface. All packets leaving the interface are evaluated according to the criteria specified in the traffic policy named class1. Restrictions Multiple traffic policies on tunnel interfaces and physical interfaces are not supported if the interfaces are associated with each other. For instance, if a traffic policy is attached to a tunnel interface while another traffic policy is attached to a physical interface—with which the tunnel interface is associated—only the traffic policy on the tunnel interface works properly. SUMMARY STEPS 1. enable 2. configure terminal 3. interface interface-type interface-number 4. service-policy {input | output} policy-map-name 5. end DETAILED STEPS Command or Action Purpose Step 1 enable Example: Router> enable Enables privileged EXEC mode. • Enter your password if prompted. Step 2 configure terminal Example: Router# configure terminal Enters global configuration mode. Applying QoS Features Using the MQC How to Apply QoS Features Using the MQC 12 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. enable 2. show class-map 3. show policy-map policy-map-name class class-name
4. show policy-map 5. show policy-map interface interface-type interface-number 6. exit DETAILED STEPS Step 3 interface interface-type interface-number Example: Router(config)# interface serial0 Configures an interface type and enters interface configuration mode. • Enter the interface type and interface number. Step 4 service-policy {input | output} policy-map-name Example: Router(config-if)# service-policy input policy1 Attaches a policy map to an interface. • Enter either the input or output keyword and the policy map name. Step 5 end Example: Router (config-if)# end (Optional) Exits interface configuration mode and returns to privileged EXEC mode. Command or Action Purpose Command or Action Purpose Step 1 enable Example: Router> enable Enables privileged EXEC mode. • Enter your password if prompted. Step 2 show class-map Example: Router# show class-map (Optional) Displays all class maps and their matching criteria. Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 13 Configuration Examples for Applying QoS Features Using the MQC This section provides the following Modular QoS CLI configuration examples: • Creating a Traffic Class: Example • Creating a Traffic Policy: Example • Attaching a Traffic Policy to an Interface: Example • match not Command: Example • Default Traffic Class Configuration: Example • class-map match-any and class-map match-all Commands: Example • Traffic Class as a Match Criterion (Nested Traffic Classes): Example • Traffic Policy as a QoS Policy (Hierarchical Traffic Policies): Example Step 3 show policy-map policy-map-name class
class-name Example: Router# show policy-map policy1 class class1 (Optional) Displays the configuration for the specified class of the specified policy map. • Enter the policy map name and the class name. Step 4 show policy-map Example: Router# show policy-map (Optional) Displays the configuration of all classes for all existing policy maps. Step 5 show policy-map interface interface-type interface-number Example: Router# show policy-map interface serial0 (Optional) Displays the statistics and the configurations of the input and output policies that are attached to an interface. • Enter the interface type and number. Step 6 exit Example: Router# exit (Optional) Exits privileged EXEC mode. Command or Action Purpose Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 14 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 class1 Router(config-cmap)# match access-group 101 Router(config-cmap)# exit Router(config)# class-map class2 Router(config-cmap)# match access-group 102 Router(config-cmap)# exit Creating 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 policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth 3000 Router(config-pmap-c)# queue-limit 30 Router(config-pmap-c)# exit Router(config-pmap)# class class2 Router(config-pmap-c)# bandwidth 2000 Router(config-pmap-c)# exit Attaching 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 ethernet1/1 Router(config-if)# service-policy output policy1 Router(config-if)# exit Router(config)# interface fastethernet1/0/0 Router(config-if)# service-policy output policy1 Router(config-if)# exit Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 15 match 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 noip Router(config-cmap)# match not protocol ip Router(config-cmap)# exit Default 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 policy1 Router(config-pmap)# class class-default Router(config-pmap-c)# fair-queue 10 Router(config-pmap-c)# queue-limit 20 class-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 matchall command: Router(config)# class-map match-all cisco1 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# match access-group 101 If 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. Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 16 The following example shows a traffic class configured with the class-map matchany command: Router(config)# class-map match-any cisco2
Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# match access-group 101 In 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 classmap 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 Class as a Match Criterion (Nested Traffic Classes): Example There are two reasons to use the match class-map command. One reason is maintenance; if a large traffic class currently exists, using the traffic class match criterion is simply easier than retyping the same traffic class configuration. The more common 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 criterion 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 criterion type. Here is a possible scenario: 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 the 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, you 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 you can simply add the new destination address match criterion without reconfiguring the entire traffic class. Applying QoS Features Using the MQC Configuration Examples for Applying QoS Features Using the MQC 17 Router(config)# class-map match-any class2 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 3 Router(config-cmap)# match access-group 2 Router(config-cmap)# exit Router(config)# class-map match-all class1 Router(config-cmap)# match class-map class2 Router(config-cmap)# match destination-address mac 00.00.00.00.00.00 Router(config-cmap)# exit Nested 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 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 00.00.00.00.00.00, 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 class3 Router(config-cmap)# match protocol ip Router(config-cmap)# match qos-group 4 Router(config-cmap)# exit Router(config)# class-map match-any class4 Router(config-cmap)# match class-map class3 Router(config-cmap)# match destination-address mac 00.00.00.00.00.00 Router(config-cmap)# match access-group 2 Router(config-cmap)# exit Router(config)# policy-map policy1 Router(config-pmap)# class class4 Router(config-pmap-c)# police 8100 1500 2504 conform-action transmit exceed-action set-qos-transmit 4 Router(config-pmap-c)# end Traffic 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 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. Applying QoS Features Using the MQC Additional References 18 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.12 (and
higher) 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 child Router(config-pmap)# class voice Router(config-pmap-c)# priority 50 Router(config)# policy-map parent Router(config-pmap)# class class-default Router(config-pmap-c)# shape average 10000000 Router(config-pmap-c)# service-policy child With 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.12 (or higher). The value used with the shape command is provisioned from the committed information rate (CIR) value from the service provider. For more information about FRF.12 (or higher) PVCs, see the “FRF .20 Support” module. Additional References The following sections provide references related to the applying QoS features using the MQC. Related Documents Related Topic Document Title QoS commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples Cisco IOS Quality of Service Solutions Command Reference Packet classification “Classifying Network Traffic” module FRF PVCs “FRF .20 Support” module Applying QoS Features Using the MQC Additional References 19 Technical Assistance Description Link The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website
requires a Cisco.com user ID and password. http://www.cisco.com/techsupport
