Guest

Cisco IOS Software Releases 12.0 S

Modular Quality of Service Command Line Interface

  • Viewing Options

  • PDF (301.3 KB)
  • Feedback
Modular Quality of Service Command-Line Interface

Table Of Contents

Modular Quality of Service Command-Line Interface

Contents

Information About Modular QoS CLI

How to Configure Modular QoS CLI

Creating a Traffic Class

Creating a Traffic Policy

Attaching a Traffic Policy to an Interface

Verifying the Configuration

Configuration Examples for Modular QoS CLI

Traffic Classes Defined Example

Traffic Policy Created Example

Traffic Policy Attached 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 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

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Command Reference


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

Release
Modification

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

How to Configure Modular QoS CLI

Configuration Examples for Modular QoS CLI

Additional References

Command Reference

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 Define a traffic class with the class-map command.

Step 2 Create a traffic policy by associating the traffic class with one or more QoS features (using the policy-map command).

Step 3 Attach the traffic policy to the interface with the service-policy command.


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 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.


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 (Required)

Creating a Traffic Policy (Required)

Attaching a Traffic Policy to an Interface (Required)

Verifying the Configuration (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-name

The 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

Command
Purpose

Router(config)# class-map class-map-name

Specifies the user-defined name of the traffic class. Names can be a maximum of 40 alphanumeric characters. If match-all or match-any are not specified, traffic must match all the match criterion to be classified as part of the traffic class.

Router(config)# class-map match-all class-map-name

Specifies that all match criterion must be met for traffic entering the traffic class to be classified as part of the traffic class.

Router(config)# class-map match-any class-map-name

Specifies that one of the match criterion must be met for traffic entering the traffic class to be classified as part of the traffic class.

Router(config-cmap)# match access-group access-group

Specifies the numbered access list against whose contents packets are checked to determine if they belong to the class.

Router(config-cmap)# match any

Specifies that all packets will be matched.

Router config-cmap)# match class-map class-name

Specifies the name of a traffic class to be used as a matching criterion (for nesting traffic class [nested class maps] within one another).

Router(config-cmap)# match cos cos-number

Specifies the CoS value against whose contents packets are checked to determine if they belong to the class.

Router(config-cmap)# match discard-class class-number

Specifies a discard class used as a match criterion against which packets are checked to determine if they belong to the class.

Router(config-cmap)# match destination-address mac address


Specifies the name of the destination MAC address used as a match criterion against which packets are checked to determine if they belong to the class.

Router(config-cmap)# match fr-dlci dlci-number

Specifies the Frame Relay data-link connection identifier (DLCI) number as a match criterion in a class map.

Router(config-cmap)# match input-interface interface-name

Specifies the name of the input interface used as a match criterion against which packets are checked to determine if they belong to the class.

Router (config-cmap)# match ip dscp number

Specifies up to eight differentiated services code point (DSCP) values used as match criteria. The value of each service code point is between 0 and 63.

Router (config-cmap)# match ip precedence number

Specifies up to eight IP precedence values used as match criteria.

Router (config-cmap)# match ip rtp starting-port-number port-range

Specifies the Real-Time Protocol (RTP) port as the match criterion.

Router (config-cmap)# match mpls experimental mpls-values

Specifies the Multiprotocol Label Switching (MPLS) values to use as match criterion against which packets are checked to determine if they belong to the class.

Router (config-cmap)# match not match-criteria

Specifies a match criterion value that prevents packets from being classified as members of a specified traffic class. All other values of that particular match criterion belong to the class.

Router (config-cmap)# match precedence precedence-value

Specifies IP precedence values as match criterion.

Router (config-cmap)# match protocol protocol

Specifies the name of the protocol used as a match criterion against which packets are checked to determine if they belong to the class.

Router (config-cmap)# match protocol citrix [app application-name-string]

Specifies network-based application recognition (NBAR) as match criterion for Citrix traffic.

Router (config-cmap)# match protocol http [url url-string | host hostname-string | mime MIME-type]

Specifies NBAR as mattch criterion for HTTP traffic by URL, HOST, or Multipurpose Internet Mail Extension (MIME)-type.

Router (config-cmap)# match qos-group qos-group-value


Specifies the number of the QoS group index used as a match criterion against which packets are checked to determine if they belong to the class.

Router (config-cmap)# match source-address mac address-destination


Specifies the name of the source MAC address used as a match criterion against which packets are checked to determine if they belong to the class.


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-name

The syntax of the class command is:

class class-name
no class class-name

All 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 These command options are not limited to this release and can vary among platforms and Cisco IOS releases. Because software is updated frequently, this list of commands might not represent the most updated software command options.


Table 2 Commands Available in Policy-Map Configuration Mode

Command
Purpose

Router (config)# policy-map policy-name

Specifies the name of the traffic policy to configure. Names can be a maximum of 40 alphanumeric characters.

Router (config-pmap)# class class-name

Specifies the name of a predefined traffic class, which was configured with the class-map command, used to classify traffic to the traffic policy.

Router (config-pmap)# class class-default

Specifies the default class to be created as part of the traffic policy.

Router (config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}

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.

Router (config-pmap-c)# default command

Sets a command to its default value.

Router (config-pmap-c)# fair-queue number-of-queues

Specifies the number of queues to be reserved for a traffic class.

Router (config-pmap-c)# police bps burst-normal burst-max conform-action action exceed-action action violate-action action

Specifies a maximum bandwidth usage by a traffic class through the use of a token bucket algorithm.

Router (config-pmap-c)# priority {kbps | percent percent} [bytes]

Specifies the guaranteed allowed bandwidth, in kbps or percentage, for priority (time-sensitive) traffic. The optional bytes argument controls the size of the burst allowed to pass through the system without being considered in excess of the configured kbps rate.

Router (config-pmap-c)# queue-limit packets

Specifies the maximum number of packets queued for a traffic class (in the absence of the random-detect command).

Router (config-pmap-c)# random-detect

Enables a Weighted Random Early Detection (WRED) drop policy for a traffic class that has a bandwidth guarantee.

Router (config-pmap-c)# set atm-clp

Sets the ATM cell loss priority (CLP) bit to 1.

Router (config-pmap-c)# set cos cos-value

Specifies a Class of Service (CoS) value or values to associate with the packet. The number is in the range from 0 to 7.

Router (config-pmap-c)# set discard-class value

Marks a packet with a discard-class value.

Router (config-pmap-c)# 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.

Router(config-pmap-c)# set ip dscp ip-dscp-value

Specifies the IP DSCP of packets within a traffic class. The IP DSCP value can be any value between 0 and 63.

Router(config-pmap-c)# set ip precedence ip-precedence-value

Specifies the IP precedence of packets within a traffic class. The IP precedence value can be any value between 0 and 7.

Router (config-pmap-c)# set mpls experimental value

Designates the value to which the MPLS bits are set if the packets match the specified policy map.

Router (config-pmap-c)# set qos-group qos-group-value

Specifies a QoS group value to associate with the packet. The QoS group value can be any value from 0 to 99.

Router (config-pmap-c)# service-policy policy-map-name

Specifies the name of a traffic policy to be used as a matching criterion (for nesting traffic policies [hierarchical traffic policies] within one another).

Router (config-pmap-c)# shape {average | peak} mean-rate [burst-size [excess-burst-size]]

Shapes traffic to the indicated bit rate according to the algorithm specified.


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 Depending on the platform and Cisco IOS release, a traffic policy can be attached to an ATM permanent virtual circuit (PVC) subinterface, Frame Relay data-link connection identifier (DLCI), or other type of interface.


To attach a traffic policy to an interface, use the following commands in interface configuration mode, as needed.

SUMMARY STEPS

1. enable

2. configure {terminal | memory | network}

3. interface type number

4. service-policy {input | output} policy-map-name

5. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables higher privilege levels, such as privileged EXEC mode.

Enter your password if prompted.

Step 2 

configure {terminal | memory | network}

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

interface type number

Example:

Router(config-if)# interface s4/0

Configures an interface (or subinterface) type and enters interface configuration mode.

Enter the interface type number.

Step 4 

service-policy {input | output} policy-map-name

Example:

Router(config-if)# service-policy input policy1


Specifies the name of the policy map to be attached to the input or output direction of the interface.

Note Policy maps can be configured on ingress or egress routers. They can also be attached in the input or output direction of an interface. The direction (input or output) and the router (ingress or egress) to which the policy map should be attached varies according your network configuration. When using the service-policy command to attach the policy map to an interface, be sure to choose the router and the interface direction that are appropriate for your network configuration.

Enter the policy map name.

Step 5 

exit

Example:

Router(config-if)# exit

(Optional) Exits interface configuration mode.


Note 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.


Verifying the Configuration

To display the information relating to a traffic class or traffic policy, use one of the following commands.

SUMMARY STEPS

1. enable

2. show class-map [class-map-name]

or

show policy-map [policy-map-name]

or

show policy-map [interface [interface-name [input | output] [class class-name]]]

3. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables higher privilege levels, such as privileged EXEC mode.

Enter your password if prompted.

Step 2 

show class-map [class-map-name]


or

show policy-map [policy-map-name]

or

show policy-map interface [interface-name [vc [vpi/] vci] [dlci dlci] [input | output]]]]

Example:

Router# show class-map class1

or

Example:

Router# show policy-map policy2

Example:

Router# show policy-map interface s4/0

Displays all information about a class map, including the match criterion.

or

Displays the configuration of all classes for a specified service policy map or all classes for all existing policy maps.

or

Displays the packet statistics of all classes that are configured for all service policies either on the specified interface or subinterface or on a specific permanent virtual circuit (PVC) on the interface.

Step 3 

exit

Example:

Router# exit

(Optional) Exits EXEC mode.

Configuration Examples for Modular QoS CLI

This section provides the Modular QoS CLI configuration examples:

Traffic Classes Defined Example

Traffic Policy Created Example

Traffic Policy Attached 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 Class Maps) Example

Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example

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)# exit 

Router(config)# class-map class2 
Router(config-cmap)# match access-group 102 
Router(config-cmap)# exit

Traffic 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 policy1
Router(config-pmap)# class class1 
Router(config-pmap-c)# bandwidth 3000  
Router(config-pmap-c)# queue-limit 30 
Router(config-pmap)# exit
 
Router(config-pmap)# class class2 
Router(config-pmap-c)# bandwidth 2000 
Router(config-pmap)# exit

Traffic 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)# exit 

Router(config)# interface fa1/0/0 
Router(config-if)# service-policy output policy1  
Router(config-if)# exit

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 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 20

class-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 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 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 4
Router(config-cmap)# match access-group 101

In 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 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 1.1.1
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 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 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 1.1.1
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)# exit

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 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 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.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

Related Topic
Document Title

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

Standards
Title

None


MIBs

MIBs
MIBs Link

The Class-Based Quality of Service Management Information Base 

CISCO-CLASS-BASED-QOS-MIB

CISCO-CLASS-BASED-QOS-CAPABILITY-MIB

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs


RFCs

RFCs
Title

None


Technical Assistance

Description
Link

Technical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/public/support/tac/home.shtml


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.