![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Modular QoS CLI Three-Level Hierarchical Policer
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Contents
Modular QoS CLI Three-Level Hierarchical PolicerLast Updated: May 17, 2012
The Modular QoS CLI (MQC) Three-Level Hierarchical Policer extends the traffic policing functionality by allowing you to configure traffic policing at three levels of policy map hierarchies; a primary level, a secondary level, and a tertiary level. Traffic policing may be configured at any or all of these levels, depending on the needs of your network. Configuring traffic policing in a three-level hierarchical structure provides a high degree of granularity for traffic policing.
Finding Feature InformationYour software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Restrictions for the Modular QoS CLI Three-Level Hierarchical PolicerIf traffic policing is configured at both the top level and secondary levels, note the following caveats:
However, the packet classification for the policy map at the secondary level occurs before the primary level policer has acted on the classes. When this situation occurs, the class counters for the policy map at the secondary level may not be equal to the number of packets acted upon by the second level policer. The following output of the show policy-map interfacecommand helps to illustrate this point. In this sample output two policy maps (called "primary_level," and "secondary_level," respectively) have been configured. The primary_level policy map contains a class map called "c1," and the secondary_level policy map contains a class map called "c3".
> > > show policy interface serial5/0.1
> > > Serial5/0.1
> > >
> > > Service-policy output: primary_level
> > >
> > > Class-map: c1 (match-all)
> > > 24038 packets, 3004750 bytes
> > > 30 second offered rate 0 bps, drop rate 0 bps
> > > Match: any
> > > police:
> > > cir 300000 bps, bc 9375 bytes
> > > conformed 18105 packets, 2263125 bytes; actions:
> > > transmit
> > > exceeded 5933 packets, 741625 bytes; actions: (*)
> > > drop
> > > conformed 0 bps, exceed 0 bps
> > >
> > > Service-policy : secondary_level
> > >
> > > Class-map: c3 (match-all)
> > > 24038 packets, 3004750 bytes
> > > 30 second offered rate 0 bps, drop rate 0 bps
> > > Match: any
> > > police: (<= Indicates traffic policing has been configured)
> > > cir 200000 bps, bc 3000 bytes
> > > pir 250000 bps, be 3000 bytes
> > > conformed 12047 packets, 1505875 bytes; actions: (**)
> > > set-frde-transmit
> > > exceeded 3004 packets, 375500 bytes; actions: (**)
> > > set-frde-transmit
> > > violated 3054 packets, 381750 bytes; actions: (**)
> > > set-frde-transmit
> > > conformed 0 bps, exceed 0 bps, violate 0 bps
> > >
> > > Class-map: class-default (match-any)
> > > 0 packets, 0 bytes
> > > 30 second offered rate 0 bps, drop rate 0 bps
> > > Match: any
> > > 0 packets, 0 bytes
> > > 30 second rate 0 bps
Note the following about this example:
In other words, it is possible that the primary-level policer could drop packets in one class in favor of the other class. This situation would happen because the primary-level policer had enough tokens when the packets for one class arrived, but there were not enough tokens left for the other class. This pattern could continue indefinitely, based on the arrival pattern of the packets. Information About the Modular QoS CLI Three-Level Hierarchical Policer
Modular Quality of Service Command-Line InterfaceThe MQC is a command-line interface (CLI) structure that allows you to create traffic policies and attach these policies to interfaces. In the MQC, the class-map command is used to define a traffic class (which is then associated with a traffic policy). The purpose of a traffic class is to classify traffic. The Modular quality of service (QoS) CLI structure consists of the following three processes:
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; that is, if you enter the class-map ciscocommand 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. Packet Flow in the Modular QoS CLI Three-Level Hierarchical PolicerThe figure below illustrates the flow of packets among policy maps configured for traffic policing at each level in the hierarchy. In the figure above, three policy maps are configured: policy_map_level1 (the primary-level policy map), policy_map_level2 (the secondary-level policy map), and policy_map_level3 (the tertiary-level policy map). Traffic policing is configured in each policy map, and each policy map is attached to a service policy and to an interface. In this simplified illustration, 500 packets arrive at the interface at which the policy map called "policy_map_level1" is attached. Because of the way traffic policing is configured in this policy map, 100 packets are dropped and 400 packets are transmitted. The traffic policer at the secondary-level policy map (policy_map_level2) then evaluates the packets and treats them as determined by the way traffic policing is configured at this level. Of the 400 packets received, 200 are dropped and 200 are transmitted. The traffic policer at the tertiary-level policy map (policy_map_level3), in turn, evaluates the 200 packets it has now received and applies the appropriate treatment as determined by the way the traffic policing is configured at this level. Other Traffic Policing-Related FeaturesThe Cisco IOS traffic policing software features allow you to control the maximum rate of traffic sent or received on an interface. Traffic policing is often configured on interfaces at the edge of a network to limit traffic into or out of the network. Traffic that falls within the rate parameters is sent, whereas traffic that exceeds or violates the parameters is dropped or sent with a different priority. The Cisco IOS software currently includes the following traffic policing features:
Previously, these features could be configured at two levels of a policy map hierarchy; the top level and one secondary level. With the Modular QoS CLI (MQC) Three-Level Hierarchical Policer, these traffic policing-related features can configured in three levels of a policy map hierarchy. The tasks for configuring each of these traffic policing-related features is essentially the same. That is, you use the MQC to create a policy map. Then you use the police command to configure traffic policing for a specific class within that policy map. The policy map is then attached to an interface. Traffic policing can be configured to specify multiple marking actions for the traffic being policed, or to use a percentage of available bandwidth when policing traffic. How to Configure the Modular QoS CLI Three-Level Hierarchical PolicerConfiguring Traffic PolicingTraffic policing can be configured at any level of the policy map hierarchy, that is, at the primary level, secondary level, or the tertiary level. DETAILED STEPS
Attaching the Policy Map to an InterfaceAfter the policy map has been created and traffic policing has been configured, the policy map must be attached to an interface. Policy maps can be attached to either the input or output direction of the interface. Depending on the needs of your network, you may need to attach the policy map to a subinterface, an ATM permanent virtual circuit (PVC), a Frame Relay data-link connection identifier (DLCI), or other type of interface. DETAILED STEPS
What to Do NextIf you want to configure traffic policing at another level in the policy map hierarchy, repeat the steps in the Configuring Traffic Policing section and the Attaching the Policy Map to an Interface section. Verifying the ConfigurationThis task allows you to verify that you created the configuration you intended and that the feature is functioning correctly.
DETAILED STEPS Troubleshooting TipsThe commands in the Verifying the Configuration section allow you to verify that you achieved the intended configuration and that the feature is functioning correctly. If after using the show commands listed above, the configuration is not correct or the feature is not functioning as expected, do the following: If the configuration is not the one you intended, complete the following procedures:
If the packets are not being matched correctly (for example, the packet counters are not incrementing correctly), complete the following procedures:
Configuration Examples for the Modular QoS CLI Three-Level Hierarchical PolicerExample Configuring the Modular QoS CLI Three-Level Hierarchical PolicerIn the following example, the Modular QoS CLI (MQC) Three-Level Hierarchical Policer has been configured for three classes within three separate policy maps. The three classes, called "c1," "c2," and "c3," respectively, have been configured using the match criteria specified as follows: class-map c1 match any class-map c2 match ip precedence 1 2 3 class-map c3 match ip precedence 2 Next, the classes are configured in three separate policy maps, called "p_all" (the primary-level policy map), "pmatch_123" (the secondary-level policy map), and "pmatch_2" (the tertiary-level policy map), as shown below. policy p_all class c1 police 100000 service-policy pmatch_123 policy pmatch_123 class c2 police 20000 service-policy pmatch_2 policy pmatch_2 class c3 police 8000 The primary goal of this configuration is to limit all traffic to 100 kbps. Within this, the secondary goal is make sure that packets with precedence values of 1, 2, or 3 do not exceed 20 kbps and that packets with precedence value of 2 never exceed 8 kbps. To verify that the classes have been configured correctly and to confirm the results of the traffic policing configuration in the policy maps, the show policy-map command and the show policy-map interfacecommand can be used, as shown in the following sections. The following sample output of the show policy-mapcommand verifies the configuration of the classes in the policy maps:
Router# show policy map
Policy Map p_all
Class c1
police cir 100000 bc 3000
conform-action transmit
exceed-action drop
service-policy pmatch_123
Policy Map pmatch_123
Class c2
police cir 20000 bc 1500
conform-action transmit
exceed-action drop
service-policy pmatch_2
Policy Map pmatch_2
Class c3
police cir 8000 bc 1500
conform-action transmit
exceed-action drop
The following sample output of the show policy-map interface command confirms the results of this configuration on the attached interface:
Router# show policy-map interface Ethernet3/1
Ethernet3/1
Service-policy output:p_all
Class-map:c1 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:any
police:
cir 100000 bps, bc 3000 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps,
Service-policy :pmatch_123
Class-map:c2 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:ip precedence 1 2 3
police:
cir 20000 bps, bc 1500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps,
Service-policy :pmatch_2
Class-map:c3 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:ip precedence 2
police:
cir 8000 bps, bc 1500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps,
Class-map:class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:any
Class-map:class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:any
Class-map:class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match:any
Additional ReferencesThe following sections provide additional references related to the Modular QoS CLI (MQC) Three-Level Hierarchical Policer: Related Documents
MIBsTechnical Assistance
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2012 Cisco Systems, Inc. All rights reserved.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||