|
|
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.
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 use a traffic class as a classification policy, use the match class-map class map configuration command. To remove a specific traffic class as a match criterion, use the no form of this command.
Syntax Description
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
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.
By using the match class-map command, 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.
Examples
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 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.
Related Commands
To match a packet based on a Layer 2 Class of Service marking, use the match cos command in class map configuration mode. To remove a specific Layer 2 Class of Service/ISL marking, use the no form of this command:
match cos cos-value [cos-value cos-value cos-value]
no match cos cos-value [cos-value cos-value cos-value]
Syntax Description
Defaults
Command Modes
Command History
Examples
In the following example, the cos-values of 1, 2, and 3 are successful match criteria for the interface containing the classification policy cos:
In the following example, classes voice and video-n-data are created to classify traffic based on the CoS values. QoS treatment is then given to the appropriate packets (in this case, the QoS treatment is priority 64 and bandwidth 512) in the cos-based-treatment policy map.
The service policy configured in this section is attached to all packets leaving fastethernet interface 0/0.1. The service policy can be attached to any interface that supports service policies.
Related Commands
To use the destination MAC address as a match criterion in class map configuration mode, use the match destination-address mac class map configuration command. To remove a previously specified destination MAC address as a match criterion in class map configuration mode, use the no match destination-address mac command.
Syntax Description
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Examples
The following example specifies a class map called macaddress and specifies the destination mac address to be used as the match criteria for this class.
Related Commands
To configure a class map to use the specified input interface as match criterion, use the match input-interface class map configuration command. To remove the input interface match criterion from a class map, use the no form of this command.
Syntax Description
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
The match input-interface command specifies the name of an input interface to be used as the match criterion 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 input-interface command to configure its match criteria.
Examples
The following example specifies a class map called eth1 and configures the input interface named ethernet1to be used as the match criterion for this class:
Related Commands
| Command | Description |
Configures the match criteria for a class map based on the specified numbered ACL. |
|
Configures the match criteria for a class map based on the specified protocol. |
To identify a specific IP differentiated service code point (DSCP) value as a match criterion, use the match ip dscp command in class map configuration mode. To remove a specific IP DSCP value from a class map, use the no form of this command.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
Up to eight IP DSCP values can be matched in one match statement. For example, if you wanted the IP DCSP values of 0, 1, 2, 3, 4, 5, 6, 7 (note that only one of the IP DSCP values has to be a successful match criterion, not all of the specified IP DSCP values), enter the following command:
This command is used by the class map to identify a specific IP DSCP value marking on a packet. The ip-dscp-values are used as markings only. The IP DSCP values have no mathematical significance. For instance, the ip-dscp-value of 2 is not greater than 1. The value simply indicates that a packet marked with the ip-dscp-value of 2 is different than a packet marked with the ip-dscp-value of 1. The treatement of these marked packets is defined by the user through the setting of QoS policies in policy map class configuration mode.
Examples
The following example shows how to configure service policy priority50 and attach service policy priority50 to an interface. In this example, class map ipdscp15 will evaluate all packets entering interface fast ethernet 1/0/0 for an ip DSCP value of 15. If the incoming packet has been marked with the IP DSCP value of 15, the packet will be treated with a priority level of 55.
Related Commands
To identify IP precedence values as match criteria, use the match ip precedence command in class map configuration mode. To remove IP precedence values from a class map, use the no form of this command.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
Up to four precedence values can be matched in one match statement. For example, if you wanted the IP precedence values of 0, 1, 2, or 3 (note that only one of the IP precedence values has to be a successful match criterion, not all of the specified IP precedence values), enter the following command:
The ip-precedence-values are used as markings only. The IP precedence values have no mathematical significance. For instance, the ip-precedence-value of 2 is not greater than 1. The value simply indicates that a packet marked with the ip-precedence-value of 2 is different than a packet marked with the ip-precedence-value of 1. The treatement of these different packets is defined by the user through the setting of QoS policies in policy map class configuration mode.
Examples
The following example shows how to configure service policy priority50 and attach service policy priority50 to an interface. In this example, class map ipprec5 will evaluate all packets entering interface fast ethernet 1/0/0 for an IP precedence value of 5. If the incoming packet has been marked with the IP precedence value of 5, the packet will be treated with a priority level of 50.
Related Commands
To configure a class map to use the Real-Time Protocol (RTP) protocol port as the match criteria, use the match ip rtp class-map configuration command. To remove the RTP protocol port match criteria, use the no form of this command.
Syntax Description
Defaults
Command Modes
Command History
Usage Guidelines
This command is used to match IP RTP packets that fall within the specified port range. It matches packets destined to all even UDP port numbers in the range <starting port range> <starting port range + port range>.
Use of an RTP port range as the match criterion is particularly effective for applications that use RTP, such as voice or video.
Examples
The following example specifies a class map called eth1 and configures the RTP port number 2024 and range 1000 to be used as the match criterion for this class:
Related Commands
To configure a class map to use the specified value of the EXP field as a match criterion, use the match mpls experimental class map configuration command. To remove the EXP field match criterion from a class map, use the no form of this command.
Syntax Description
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Examples
The following example specifies a class map called eth1 and configures the MPLS values of 1 and 2 to be used as the match criterion for this class:
To specify the single match criterion value to use as an unsuccessful match criterion in class map configuration mode, use the match not class map configuration command. To remove a previously specified source value to not use as a match criterion, use the no match not command.
Syntax Description
(Required) Specifies the match criterion value that is an unsuccessful match criterion. All other values of the specified match criterion will be considered successful match criteria. |
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
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.
Examples
In the following traffic class, all protocols except IP are considered successful match criteria:
Related Commands
To configure the match criteria for a class map based on the specified protocol, use the match protocol class map configuration command. To remove protocol-based match criteria from a class map, use the no form of this command.
Syntax Description
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
The match protocol command specifies the name of a protocol to be 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 protocol command to configure the match criteria for it.
Examples
The following example specifies a class map called ipx and configures the ipx protocol as match criteria for it:
To identify a specific QoS group value as a match criterion, use the match qos-group command in class map configuration mode. To remove a specific QoS group value from a class map, use the no form of this command.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
This command is used by the class map to identify a specific QoS group value marking on a packet.
The qos-group-values are used as markings only. The QoS group values have no mathematical significance. For instance, the qos-group-value of 2 is not greater than 1. The value simply indicates that a packet marked with the qos-group-value of 2 is different than a packet marked with the qos-group-value of 1. The treatment of these packets is defined by the user through the setting of QoS policies in policy map class configuration mode.
The QoS group value is local to the router, meaning that the QoS group value that is marked on a packet does not leave the router when the packet leaves the router. If you need a marking that resides in the packet, use IP precedence setting, IP DSCP setting, or another method of packet marking.
Examples
The following example shows how to configure service policy priority50 and attach service policy priority50 to an interface. In this example, class map qosgroup5 will evaluate all packets entering interface fast ethernet 1/0/0 for a QoS group value of 5. If the incoming packet has been marked with the QoS group value of 5, the packet will be treated with a priority level of 50.
Related Commands
To use the source MAC address as a match criterion in class map configuration mode, use the match source-address mac class map configuration command. To remove a previously specified source MAC address as a match criterion in class map configuration mode, use the no match source-address mac command.
match source-address mac address
no match source-address mac address
Syntax Description
Defaults
Command Modes
Command History
| Release | Modification |
|---|---|
Usage Guidelines
This command can only be used on an input interface with a MAC address. These interfaces include FastEthernet and Ethernet interfaces.
This command cannot be used on output interfaces with no MAC address, such as serial and ATM interfaces.
Examples
class-map matchsrcmac
match source-address mac 0.0.0
Related Commands
To create or modify a policy map that can be attached to one or more interfaces to specify a service policy, use the policy-map global configuration command. To delete a policy map, use the no form of this command.
Syntax Description
Defaults
No default behavior or values.
Command Modes
Command History
Usage Guidelines
Use the policy-map command to specify the name of the policy map to be created, added to, or modified before you can configure policies for classes whose match criteria are defined in a class map. Entering the policy-map command enables policy map configuration mode in which you can configure or modify the class policies for that policy map.
You can configure class policies in a policy map only if the classes have match criteria defined for them. You use the class-map and match commands to configure the match criteria for a class. Because you can configure a maximum of 64 class maps, no policy map can contain more than 64 class policies.
A single policy map can be attached to multiple interfaces concurrently. When you attempt to attach a policy map to an interface, the attempt is denied if the interface's available bandwidth cannot accommodate the total bandwidth requested by class policies comprising the policy map. In this case, if the policy map is already attached to other interfaces, it is removed from them.
Whenever you modify class policy in an attached policy map, CBWFQ is notified and the new classes are installed as part of the policy map in the CBWFQ system.
Examples
The following example creates a policy map called policy9 and configures three class policies to belong to that map. Of these classes, two specify policy for classes with class maps that specify match criteria based on either a numbered access control list (ACL) or an interface name, and one specifies policy for the default class called class-default to which packets that do not satisfy configured match criteria are directed.
Related Commands
To attach a policy map to an input interface or an output interface to be used as the service policy for that interface, use the service-policy global command. To remove a service policy from an input or output interface, use the no form of this command.
Syntax Description
Defaults
Command Modes
Command History
Usage Guidelines
You can attach a single policy map to one or more interfaces to specify the service policy for those interfaces.
To successfully attach a policy map to an interface, the aggregate of the configured minimum bandwidths of the classes comprising the policy map must be less than or equal to 75 percent of the interface bandwidth.
Attaching a service policy and enabling CBWFQ on an interface renders ineffective any commands related to fancy queueing such as commands pertaining to fair queueing, custom queueing, priority queueing, and Weighted Random Early Detection (WRED). You can configure these features only after you remove the policy map from the interface.
You can modify a policy map attached to an interface, changing the bandwidth of any of the classes comprising the map. Bandwidth changes that you make to an attached policy map are effective only if the aggregate of the bandwidth amounts for all classes comprising the policy map, including the modified class bandwidth, is less than or equal to 75 percent of the interface bandwidth. If the new aggregate bandwidth amount exceeds 75 percent of the interface bandwidth, the policy map is not modified.
Examples
The following example attaches the service policy map called policy9 to the input interface Serial1:
The following example attaches the policy called policy9 to the output interface serial1 to specify the service policy for the interface and enable CBWFQ on it:
Related Commands
To display the configuration of all classes comprising the specified service policy map or all classes for all existing policy maps, use the show policy global configuration command.
Syntax Description
Defaults
All existing policy map configurations are displayed.
Command Modes
Command History
Usage Guidelines
The show policy command displays the configuration of a service policy map created using the policy-map command. You can use the show policy command to display all class configurations comprising any existing service policy map, whether or not that service policy map has been attached to an interface.
Examples
The following example displays the contents of the po1 service policy map:
The following example displays the contents of all policy maps on the router:
Related Commands Related Commands
To display the configuration for the specified class of the specified policy map, use the show policy class global configuration command.
Syntax Description
The name of a policy map that contains the class configuration to be displayed.
The name of the class whose configuration is to be displayed.
Defaults
No default behavior or values.
Command Modes
Command History
Usage Guidelines
You can use the show policy class command to display any one class configuration for any service policy map, whether or not the specified service policy map has been attached to an interface.
Examples
The following example displays configurations for the class called class7 that belongs to the policy map po1.
Related Commands Related Commands
To display the configuration of all classes configured for all service policies on the specified interface, use the show policy interface global configuration command.
Syntax Description
Defaults
Command Modes
Command History
Usage Guidelines
The show policy interface command displays the configuration for classes on the specified interface only if a service policy has been attached to the interface.
Examples
The following example displays configurations for classes on the output interface e1/1:
Related Commands Related Commands
Displays the configuration for all classes of the specified service policy map.
Displays the configuration for the specified class of the specified service policy map.
policy-map
Release
Modification
service-policy
Release
Modification
Command
Description
show policy
Release
Modification
Policy Map po1
Weighted Fair Queueing
Class class1
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class2
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class3
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class4
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class5
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class6
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class7
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class8
Bandwidth 937 (kbps) Max thresh 64 (packets)
Policy Map poH1
Weighted Fair Queueing
Class class1
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class2
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class3
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class4
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class5
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class6
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class7
Bandwidth 937 (kbps) Max thresh 64 (packets)
Class class8
Bandwidth 937 (kbps) Max thresh 64 (packets)
Policy Map policy2
Weighted Fair Queueing
Class class1
Bandwidth 300 (kbps) Max thresh 64 (packets)
Class class2
Bandwidth 300 (kbps) Max thresh 64 (packets)
Class class3
Bandwidth 300 (kbps) Max thresh 64 (packets)
Class class4
Bandwidth 300 (kbps) Max thresh 64 (packets)
Class class5
Bandwidth 300 (kbps) Max thresh 64 (packets)
Class class6
Bandwidth 300 (kbps) Max thresh 64 (packets)
show policy-map class
Release
Modification
show policy-map interface
Release
Modification
Command
Description
Posted: Fri Jan 17 04:45:35 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.