|
|
This document describes the Modular Quality of Service Command-Line Interface (Modular QoS CLI) and contains the following sections:
The Modular QoS CLI allows users to specify a traffic class independently of QoS policies.
The Modular QoS CLI is used to configure QoS. The Modular QoS CLI contains the following three steps, which are detailed more thoroughly later in this document:
Step 2 Creating a service policy by associating the traffic class with one or more QoS policies (using the policy-map command)
Step 3 Attaching the service policy to the interface with the service-policy command
The class-map command is used to define a traffic class. A traffic class contains three major elements: a name, a series of match commands, and 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 don command while configuring the traffic class in the command-line interface, the traffic class would be named don.
Match commands are used to specify various criteria for classifying packets. Packets are checked to see 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 service policy. Packets that fail to meet any of the matching criteria are classified as members of the default class. The default class is detailed more thoroughly in the "Configuring a Default Class" section of this document.
The instruction on how to evaluate these match commands is specified with one of the following two options: class-map match-any or class-map match-all. The functionality of these options is detailed more thoroughly in the "Using the class-map match-any and class-map match-all Commands" section of this document.
The policy-map command is used to associate a traffic class, which was defined by the class-map command, with one or more QoS policies. The result of this association is called a service policy. A service policy contains three elements: a name, a traffic class (specified with the class command), and the QoS policies (which are detailed in the "Creating a Service Policy" section of this document). The purpose of the service policy is to associate a traffic class with one or more QoS policies. The name of a service policy is specified in the policy-map command-line interface (for example, issuing the policy-map gary command would create a service policy named gary).
The Modular QoS CLI does not necessarily require that users associate only one traffic class to one service policy. When packets match to more than one match criterion, multiple traffic classes can be associated with a single service 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 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 is provided in the "Using a Traffic Class as a Match Criterion (Nested Class Maps)" section of this document.
The service-policy command is used to attach the service policy, as specified with the policy-map command, to an interface. Because the elements of the service policy can be applied to packets entering and leaving the interface, users are required to specify whether the service policy characteristics should be applied to incoming or outgoing packets. For instance, the service-policy output gary command would attach all the characteristics of the service policy named gary to the specified interface. All packets leaving the specified interface are evaluated according to the criteria specified in the service policy named Gary. For information on using the service-policy command, see the "Attaching a Service Policy to an Interface" section of this document.
The Class-Based Quality of Service Management Information Base (Class-Based QoS MIB) provides read access to QoS configurations. This MIB also provides QoS statistics information based on the Modular QoS CLI, including information regarding class map and policy map parameters.
This Class-Based QoS MIB is actually two MIBs: CISCO-CLASS-BASED-QOS-MIB and CISCO-CLASS-BASED-QOS-CAPABILITY-MIB.
Use the Cisco Network Management Toolkit for MIBs tool on Cisco Connection Online (CCO) to locate MIBs.
This section describes the tasks for configuring QoS functionality with the Modular QoS CLI. For a complete description of the commands mentioned in this section, refer to the Quality of Service Solutions Command Reference. The commands are listed alphabetically within the guide. To locate documentation of a specific command, use the command reference, master index, or online search.
You must follow certain required, basic steps to configure the Modular QoS CLI. The following sections outline these tasks:
The class-map command is used to create a traffic class. To create a traffic class containing match criteria, use the class-map command to specify the traffic class name, and then use a match command in class map configuration mode.
The syntax of the class-map command is:
class-map [match-any | match-all] class-name
no class-map [match-any | match-all] class-name
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 the first possible match criterion from a list of match criteria must be met for a packet to match the specified traffic class. If neither match-all nor match-any 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.
For additional information on using the match-any and match-all options, see the "Using the class-map match-any and class-map match-all Commands" section of this document.
 |
Note This document lists some of the command options in class map configuration mode. These
command options 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. For the most current command options for your Cisco IOS software, see the New Feature Documentation index for your particular Cisco IOS software release on CCO. |
To configure a service policy, use the policy-map command to specify the service 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 service policy when the class command is used. The class command has to 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 service policy are defined.
The QoS policies that can be applied in the service policy in policy map class configuration mode are detailed below.
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
If a default class is configured, all traffic that fails to meet the matching criteria belongs to the default class.
|
Note This document lists some of the command options for the policy map configuration mode.
These command options 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. For the most current command options for your Cisco IOS software, see the New Feature Documentation index for your particular Cisco IOS software release on CCO. |
Use the service-policy interface configuration command to attach a service 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 service policy from an interface. The service-policy command syntax is:
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 service policy can be attached to an ATM permanent virtual circuit (PVC) subinterface, Frame Relay data-link connection identifier (DLCI), or other type of interface. |
Use the show class-map class-name command to display the information relating to a traffic class. Use the show policy-map command to display the configuration of a service policy and its associated traffic classes. Forms of these commands are listed in the table below.
This section provides the following configuration examples:
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.
In the following example, a service 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 "Defining a Traffic Class" section).
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.
The following example shows how to attach an existing service policy (which was created in the preceding "Creating a Service Policy" section) to an interface. After you define a service policy with the policy-map command, you can attach it to one or more interfaces to specify the service policy for those interfaces by using the service-policy command in interface configuration mode. Although you can assign the same service policy to multiple interfaces, each interface can have only one service policy attached at the input and only one service policy attached at the output.
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:
Unclassified traffic (traffic that does not meet the match criteria specified in the traffic classes) is treated as belonging to the default 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 (first-in, first-out) 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 service policy for the default class of the service 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 service policy policy1, and a maximum of 20 packets per queue before tail drop is enacted to handle additional enqueued packets.
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:
If a packet arrives on a router with traffic class john configured on the interface, the packet is evaluated to see 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 john.
The following example shows a traffic class configured with the class-map match-any command:
In traffic class george, the match criteria are evaluated consecutively until a successful match criterion is located. The packet is first evaluated to the see 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 george. If the packet matches none of the specified criteria, the packet is classified as a member of the default 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. 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.
Traffic classes can be nested within one another, saving users the overhead of re-creating a new traffic class when most of the information exists in a previously configured traffic class. In the following example, traffic class brando has the same characteristics as traffic class marlon, with the exception that traffic class brando has added a destination address as a match criterion. Rather than configuring traffic class brando line by line, a user can enter the match class-map marlon command. This command allows all of the characteristics in traffic class marlon to be included in traffic class brando, and the user can simply add the new destination address match criterion without reconfiguring the entire traffic class.
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 end 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 montana: IP protocol and QoS group 4, destination MAC address 1.1.1, or access group 2.
In this example, only traffic class montana is used with service policy niners.
A service policy can be nested within a QoS policy when the service-policy command is used in policy map class configuration mode. A service policy that contains a nested service policy is called a hierarchical service policy.
A hierarchical service policy contains a child and a parent policy. The child policy is the previously defined service policy that is being associated with the new service policy through the use of the service-policy command. The new service policy using the preexisting service policy is the parent policy. In the example in this section, service policy child is the child policy and service policy parent is the parent policy.
Hierarchical service policies can be attached to subinterfaces, Frame Relay PVCs, and ATM PVCs. A hierarchical service policy is particularly beneficial when configuring Versatile Interface Processor-Based Distributed FRF.11 and FRF.12 PVCs. By using hierarchical service policies, a single service 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 while 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.
With the exception that the values associated with the priority and shape commands can be modified, the above example is the required configuration for PVCs using FRF.11 or FRF.12. The value used with the shape command is provisioned from the cir value from the service provider. For additional information on FRF.11 and FRF.12 PVCs, see the Versatile Interface Processor-Based Distributed FRF.11 and FRF.12 document on CCO.
For additional information on hierarchical service policies, see the "Creating a Service Policy for FRF.11 and FRF.12" section and the ,service-policy command reference section of Versatile Interface Processor-Based Distributed FRF.11 and FRF.12 document on CCO.
This section documents commands associated with the Modular QoS CLI. All other commands used with this feature are documented in the Cisco IOS Release 12.1 command reference publications.
|
Note This section does not document commands for the QoS policies that can be used in policy map class configuration mode. For the command references for these QoS policies, see the individual feature modules associated with these features on CCO or the Documentation CD-ROM. |
This section contains the following command references:
To specify the name of the class whose policy you want to create or change or to specify the default class called class-default before you configure its policy, use the class policy map configuration command. To remove a class from the policy map, use the no form of this command.
Syntax Description
The name of the class for which you want to configure or modify policy. |
|
Specifies the default class so that you can configure or modify its policy. |
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
Enter the policy-map command to identify the policy map and enter policy map configuration mode before you use the class command. After you specify a policy map, you can configure policy for new classes or modify policy for any existing classes in that policy map.
The class name that you specify in the policy map ties the characteristics for that class—that is, its policy—to the class map and its match criteria configured using the class-map command.
When you configure policy for a class and specify its bandwidth and attach the policy map to an interface, class-based weighted fair queuing (CBWFQ) checks to determine if the bandwidth requirement of the class can be satisfied. If so, CBWFQ allocates a queue for the bandwidth requirement.
When a class is removed, available bandwidth for the interface is incremented by the amount previously allocated to the class.
The maximum number of classes you can configure for a router—and, therefore, within a policy map—is 64.
Examples
The following example configures policy for a class named acl136 included in the policy map called policy1. Class acl136 has these characteristics: a minimum of 2000 kilobits per second (kbps) of bandwidth are expected to be delivered to this class in the event of congestion, and the queue reserved for this class can enqueue 40 packets before tail drop is enacted. Note that when the policy map containing this class is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed, taking into account all class policies and RSVP, if configured.
The following example configures policy for a class named int101 included in the policy map called policy8. Class int101 has these characteristics: a minimum of 3000 kbps of bandwidth are expected to be delivered to this class in the event of congestion, and a weight factor of 10 is used to calculate the average queue size. For congestion avoidance, WRED packet drop is used, not tail drop. Note that when the policy map containing this class is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed.
The following example configures policy for the class-default default class included in the policy map called policy1. The class-default default class has these characteristics: 10 hashed queues for traffic that does not meet the match criteria of other classes whose policy is defined by the policy map policy1, and a maximum of 20 packets per queue before tail drop is enacted to handle additional enqueued packets.
The following example configures policy for the class-default default class included in the policy map called policy8. The class-default default class has these characteristics: 20 hashed queues for traffic that does not meet the match criteria of other classes whose policy is defined by the policy map policy8 and a weight factor of 14 is used to calculate the average queue size. For congestion avoidance, WRED packet drop is used, not tail drop.
Related Commands Related Commands
To create a class map to be used for matching packets to the class whose name you specify, use the class-map global configuration command. To remove an existing class map from the router, use the no form of this command.
Syntax Description
Name of the class for the class map. The class name is used for both the class map and to configure policy for the class in the policy map. |
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
Use this command to specify the name of the class for which you want to create or modify class map match criteria. Use of the class-map command enables class map configuration mode in which you can enter one of the match commands to configure the match criteria for this class. Packets arriving at the output interface are checked against the match criteria configured for a class map to determine if the packet belongs to that class.
Examples
The following example specifies access101 as the name of a class, and it defines a class map for this class. The match access-group command is entered following the class-map command to configure the numbered access control list (ACL) 101, whose contents are to be used as match criteria for the class.
Related Commands
To configure the match criteria for a class map based on the specified access-control list (ACL) number, use the match access-group class map configuration command. To remove ACL match criteria from a class map, use the no form of this command.
Syntax Description
A numbered ACL whose contents are used as the match criteria against which packets are checked to determine if they belong to this class. |
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
Traffic classes are defined based on match criteria including numbered ACLs, protocols, and input interfaces. Packets satisfying the match criteria for a class constitute the traffic for that class. The match access-group command specifies a numbered ACL whose contents are used as the match criteria against which packets are checked to determine if they belong to the class specified by the class map. Use the class-map command to specify the name of the class whose match criteria you want to establish. After you identify the class, you can use the match access-group command to configure the match criteria.
Examples
The following example specifies a class map called acl144 and configures the ACL numbered 144 to be used as the match criteria for this class.
Related Commands
| Command | Description |
Configures the match criteria for a class map based on the specified input interface. |
|
Configures the match criteria for a class map based on the specified protocol. |
To configure the match criteria for a class map to be successful match criteria for all packets, use the match any class map configuration command. To remove all criteria as successful match criteria, use the no form of this command.
Syntax Description
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Examples
In the following configuration, all packets leaving interface e1/1 will be policed based on the parameters specified in policy map class configuration mode.