-
Cisco 10000 Series Router Quality of Service Configuration Guide
-
Cisco 10000 Series Router Quality of Service Configuration Guide
-
About This Guide
-
Quality of Service Overview
-
Classifying Traffic
-
Configuring QoS Policy Actions and Rules
-
Attaching Service Policies
-
Distributing Bandwidth Between Queues
-
Policing Traffic
-
Marking Traffic
-
Prioritizing Services
-
Shaping Traffic
-
Overhead Accounting
-
Managing Packet Queue Congestion
-
Sharing Bandwidth Fairly During Congestion
-
Simultaneous Policy Maps
-
Defining QoS for Multiple Policy Levels
-
Oversubscribing Physical and Virtual Links
-
Fragmenting and Interleaving Real-Time and Nonreal-Time Packets
-
Configuring Dynamic Subscriber Services
-
Regulating Subscriber Traffic
-
Configuring Quality of Service for PVC Bundles
-
Configuring Quality of Service for MPLS Traffic
-
VLAN Tag-Based Quality of Service
-
Hierarchical Scheduling and Queuing
-
Configuring Frame Relay QoS Using Frame Relay Legacy Commands
-
QoS Policy Propagation Through the Border Gateway Protocol
-
Glossary
-
Table Of Contents
Defining QoS for Multiple Policy Levels
Feature History for Hierarchical Policies
Benefits of Hierarchical Policies
Components Common to All Types of Hierarchical Policies
Types of Hierarchical Policies
Restrictions and Limitations for Nested Hierarchical Policies
Three-Level Hierarchical Policies
Restrictions and Limitations for Three-Level Hierarchical Policies
Hierarchical Input Policing Policies
Restrictions and Limitations for Hierarchical Input Policing Policies
Hierarchical Policies and Oversubscription
Applying Child Policies Under Priority Classes
Interfaces Supporting Hierarchical Policies
Guidelines for Configuring QoS for Multiple Queues
Configuring QoS for Multiple Queues
Creating Fair Queues at Two Levels of Hierarchy
Creating Fair Queues at Three Levels of Hierarchy
Configuring a Bottom-Level Child Policy of a Three-Level Hierarchy
Configuring a Middle-Level Child Policy of a Three-Level Hierarchy
Configuring the Top-Level Parent Policy of a Three-Level Hierarchy
Policing Inbound Traffic at Two Levels of Hierarchy
Attaching Hierarchical Policies to Physical and Virtual Links
Configuration Examples for Nested Hierarchical Policies
Configuration Examples for Three-Level Hierarchical Policies
Configuration Example for Hierarchical Input Policing
Configuring Bandwidth-Remaining Ratios on ATM Subinterfaces: Example
Configuring Bandwidth-Remaining Ratios on Class Queues: Example
Verifying the Configuration of Hierarchical Policies
Verification Examples for Hierarchical Policies
Defining QoS for Multiple Policy Levels
In releases prior to Cisco IOS Release 12.0(22)S, you can specify QoS behavior at only one level. For example, to shape two outbound queues of an interface, you must configure each queue separately, defining only class-specific actions. You can define a minimum bandwidth for two traffic classes, but you cannot define a combined maximum bandwidth for the two classes. As a result, you cannot configure fair queues on virtual circuits where the total throughput of the fair queues must be within the virtual circuit's committed rate.
To implement fair queues on virtual circuits and virtual LANs (VLANs), the Cisco 10000 series router supports QoS with hierarchical queuing. Within the hierarchical QoS framework, you can enable the router to prioritize and manage packets at three policy levels (physical, logical, and class levels), thereby providing a high degree of granularity in traffic management. Congestion control mechanisms such as weighted random early detection (WRED) and tail drop regulate network traffic and control congestion.
This chapter describes the various types of hierarchical policies and includes the following topics:
•
Components Common to All Types of Hierarchical Policies
•
•
•
•
•
•
•
Hierarchical Policies
A hierarchical policy is a QoS model that enables you to specify QoS behavior at multiple levels of hierarchy. The router supports three types of hierarchical policies: nested, three-level, and input policing policies. Depending on the type of hierarchical policy you configure, you can use hierarchical policies to:
•
•
•
•
Note
All hierarchical policy types consist of a top-level parent policy and one or more child policies. The service-policy command is used to apply a policy to another policy, and a policy to an interface, subinterface, virtual circuit (VC), or virtual LAN (VLAN). For example, in a three-level hierarchical policy, you use the service-policy command to apply a:
•
•
•
Note
When you use hierarchical policies, the router allocates the physical pipe into smaller pipes. Instead of creating a single versatile time management scheduler (VTMS) link for the physical interface, each parent policy map has a VTMS link. The router uses this QoS link to service the associated traffic independently of other traffic.
For releases prior to Cisco IOS Release 12.0(25)SX, the router uses 128 discrete values between 64 kbps and 1 Gbps as multiqueue shape rates. Therefore, the sum of the nested policy shape rates you specify for an interface must be 64 kbps less than the total bandwidth of the interface. For example, on a DS1 Frame Relay interface with a total bandwidth of 1536 kbps, the combined shape rate of the hierarchical policy must be 1472 kbps or less:
1536 kbps - 64 kbps = 1472 kbps
If you specify a non-supported rate, the router uses the next lower supported rate instead.
For Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, and later releases, the router allows interface oversubscription. For more information, see Chapter 15, "Oversubscribing Physical and Virtual Links."
Feature History for Hierarchical Policies
Benefits of Hierarchical Policies
Depending on the type of hierarchical QoS policy you configure, you can:
•
•
•
•
•
•
Components Common to All Types of Hierarchical Policies
All types of hierarchical policies use the following components to provide multiple levels of QoS behavior:
Child Policy
A child policy is a policy map in a hierarchical QoS policy that defines QoS behavior for individual streams of traffic. A child policy defines one or more classes of traffic and the actions you want the router to take on the traffic, just as non-hierarchical policy maps do. However, in a hierarchical policy, a child policy map is applied to a parent policy map and can be applied to another child policy, depending on the type of hierarchical policy it is (see the "Types of Hierarchical Policies" section).
The following describes the ways in which you can apply child policies for the various types of hierarchical policies:
•
•
•
When applying child policies to other child policies or to a parent policy, use the service-policy command and specify the name of the child policy you are applying as the policy-map-name. Do not specify the input or output keyword.
If you specify the bandwidth percent command or the police percent command in a child policy, the percentage you indicate is the percentage of the total shape rate and not the percentage of the interface bandwidth. The router uses the bandwidth of the nearest parent policy (configured using the shape or police command) command to calculate the bandwidth percentage for the child policy. The router always looks to the nearest parent for the bandwidth reference point.
The router executes the child policy and then the parent policy. However, if the child policy contains policing with a specified drop policy, the router polices and drops the appropriate traffic at the child level, but does not execute the parent policy on the dropped packets.
The router executes the child policy and then the parent policy. As the packets pass through the router's forwarding engine, the router applies the QoS actions specified in the child policy. After child processing completes, the packets are fed back through the forwarding engine and the router applies the parent policy actions to the aggregate traffic. The router executes the parent policy only on the packets that are fed back. If the router dropped some packets during child processing (the child policy contained a drop policy), the router does not execute the parent policy on those dropped packets.
Parent Policy
A parent policy contains only the class-default class; it can contain no other classes. The parent policy defines the shape rate (nested and three-level hierarchical policies) or the policing rate (hierarchical input policing policies) for the aggregate traffic on an interface with a service policy applied.
The parent policy class-default class can contain only the following commands. Do not configure any other commands in the class-default class. Configure the service-policy command last.
•
or
police command—(Hierarchical Input Policing Policies) Configures traffic policing for the aggregate traffic of all of the classes defined in the child policies. You must configure the police command when creating hierarchical input policing policies; do not configure the shape command.
•
Note
Table 13-1 summarizes the commands configured in the parent class-default class for the different types of hierarchical policies.
The router reserves the bandwidth you specify in the parent policy shape or police command for the exclusive use of the PVC or VLANs to which the policy is applicable. The router does not share unused bandwidth with other PVCs or VLANs. However, the actual shape rate the router applies to the child traffic classes might differ from the rate you specify in the parent policy. For example, the router might map a specified shape rate of 10.5 Mbps to 11 Mbps. Use the show policy-map interface command to determine the actual shape rate applied.
service-policy Command
For hierarchical policies, the service-policy command is used to attach:
•
•
•
When attaching child policies to child or parent policies, do not specify the output or input keyword when you enter the service-policy command. For example, enter the following command:
Router(config-if)# service-policy policy-map-nameWhen attaching parent policies to interfaces, subinterfaces, or virtual circuits, enter the service-policy command and specify the output or input keyword as described below:
•
•
Note
Types of Hierarchical Policies
The Cisco 10000 series router supports the following types of hierarchical policies:
Defines up to two levels of hierarchy. A nested policy can define a minimum bandwidth for each type of traffic on a virtual circuit and a maximum bandwidth for the virtual circuit's total traffic. However, a nested policy cannot actively police a subclass of each guaranteed class while placing a maximum transmission limit on the aggregate traffic.
•
Defines up to three levels of hierarchy. A three-level policy can define a minimum bandwidth for each traffic type on a virtual circuit, define a maximum bandwidth for the virtual circuit's total traffic, police a subclass of each guaranteed class, and place a maximum transmission limit on the aggregate traffic.
•
Defines up to two levels of hierarchy for inbound traffic only. A hierarchical input policing policy can define two levels of policing, one in the parent policy and one in the child policy. The top-level parent policy is typically used to police an interface, subinterface, ATM VC, Frame Relay DLCI, or 802.1Q VLAN, and is applied to all traffic.
Nested Hierarchical Policies
A nested hierarchical policy is a queuing model that defines a minimum bandwidth for multiple classes and specifies a combined maximum bandwidth for the classes. Using a nested hierarchical policy, you can shape two or more queues together into one logical QoS policy. In this way, you can associate multiple logical links with a physical interface and enable the router to service any group of queues independently of other queues. The router provides distinct dequeuing rates to the subsets of the queues on a physical link.
Figure 13-1 shows a sample queuing configuration on a T1 network interface that is running Frame Relay. The network interface has two PVCs (PVC1 and PVC2), each with a multiqueue shape rate of 768 kbps. Each PVC has two fair queues whose aggregate output is shaped at 768 kbps.
Figure 13-1 Nested Hierarchical Policy on Frame Relay
Nested policy maps specify QoS policies at the following two levels of hierarchy:
•
•
For releases prior to Cisco IOS Release 12.0(25)SX, the sum of the nested policy shape rates you specify can be no more than 64 kbps less than the physical interface bandwidth. For example, the sum of the nested policy shape rates for a DS1 Frame Relay interface must be no more than 1472 kbps, calculated as follows:
1536 kbps - 64 kbps = 1472 kbps
If you specify a non-supported rate, the router uses the next lower supported rate instead.
Note
For releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, the router does not limit the number of nested policies you can configure on a physical network interface as long as the sum of the nested policy shape rates is 64 kbps less than the total bandwidth of the interface. In Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, and later releases, the router allows oversubscription. For more information, see Chapter 15, "Oversubscribing Physical and Virtual Links."
The router reserves the shape rate you specify in the parent policy for the child traffic classes. The router does not allocate unused (or excess) bandwidth to other traffic. For example, consider a nested policy with a shape rate of 64 kbps. If the nested policy traffic rate is 32 kbps, the router does not allocate the remaining 32 kbps to the other traffic on the network interface.
In some cases, the nested policy shape rate that the system uses might be lower than the shape rate you specify. Use the show policy-map interface command to verify the actual shape rate.
For Frame Relay PVCs, instead of using a nested policy map to specify the multiqueue shape rate, you can use the frame-relay traffic-shape command to specify a fair queue policy map.
Restrictions and Limitations for Nested Hierarchical Policies
Note
•
•
•
•
•
•
Three-Level Hierarchical Policies
A three-level hierarchical policy extends the functionality of a nested hierarchical policy from two to three levels of hierarchy. Using three-level hierarchical policies, you can:
•
•
•
•
For example, you can use a three-level hierarchical policy to define a minimum bandwidth and a combined maximum bandwidth for two classes. Similarly, you can also define a minimum bandwidth for each type of traffic on a virtual circuit and a maximum bandwidth for the virtual circuit's total traffic.
A three-level policy specifies the following three levels of hierarchy:
•
•
•
Note
Restrictions and Limitations for Three-Level Hierarchical Policies
Note
•
•
•
•
•
Note
Example 13-1 shows a configuration that violates the requirement that the bottom-level class map match only those packets that also match its parent class map. In the example, the class map named Child matches any packet that is not IP precedence 1 (for example, IP precedence 5). The class map named Parent matches only IP precedence 1, 2, and 3. As a result, no packets from the Child and Parent classes intersect.
Example 13-1 Improperly Defining Bottom-Level Child and Top-Level Parent Class Maps
Router(config)# class-map ParentRouter(config-cmap)# math ip precedence 1 2 3!Router(config)# class-map ChildRouter(config-cmap)# match not ip precedence 1Example 13-2 modifies the configuration in Example 13-1 to ensure the union of Child and Parent packets, which in Example 13-2 is IP precedence 2 and 3.
Example 13-2 Properly Defining Bottom-Level Child and Top-Level Parent Class Maps
Router(config)# class-map ParentRouter(config-cmap)# math ip precedence 1 2 3!Router(config)# class-map ChildRouter(config-cmap)# match ip precedence 2 3Hierarchical Input Policing Policies
A hierarchical input policing policy extends the functionality of traffic policing to two levels of hierarchy for inbound interfaces. The hierarchical input policer limits the rate of the traffic that the router accepts on the interface with the service policy applied. In this way, the service provider network is protected on the aggregate traffic level to ensure that the service provider can honor service level agreements. A two-rate three-color policer limits the rate of individual traffic streams (see the "Two-Rate Three-Color Marker for Traffic Policing" section on page 6-8).
Using hierarchical input policing, you can:
•
•
•
A hierarchical input policing policy specifies the following two levels of hierarchy:
•
•
During hierarchical input policing, the bottom-level policer acts on all of the traffic arriving at the interface, subinterface, VC, or VLAN on which the hierarchical policer is applied. As the traffic passes through the forwarding engine of the router for the first time, the bottom-level policer limits the rate of the individual streams of IP traffic before passing the traffic back through the forwarding engine again. During this feedback operation, the top-level traffic policer limits the rate of all of the traffic passed to it. The top-level policer acts only on the packets sent by the bottom-level policer. If the outbound interface has policing configured, a second feedback occurs during which the outbound policer limits the rate of the traffic.
Note
Figure 13-2 shows how packets flow between policy maps in a hierarchical input policing policy. In the figure, 500 packets arrive at the interface with the policy_map_level1 policy attached. Because of the way in which the policer is configured in policy_map_level1, the policer drops 100 packets and passes 400 packets. The traffic policer in the policy_map_level2 policy then evaluates the 400 packets it receives, drops 200, and transmits the remaining 200 packets.
Figure 13-2 Packet Flow Between Hierarchical Input Policing Policies
Restrictions and Limitations for Hierarchical Input Policing Policies
•
•
Hierarchical Policies and Oversubscription
For releases prior to Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI, the router does not allow oversubscription of interfaces. If you oversubscribe hierarchical policies, instead of reducing the shape rate of all policies, the router preserves as many policies as possible and reduces the policy shape rates of a minimum number of policies to bring the sum of the hierarchical policy shape rates to less than the physical interface bandwidth.
For Cisco IOS Release 12.0(25)SX and Release 12.3(7)XI and later releases, the router allows you to oversubscribe interfaces. Oversubscription is always enabled.
For more information about oversubscription, see Chapter 15, "Oversubscribing Physical and Virtual Links."
Applying Child Policies Under Priority Classes
The Cisco 10000 series router allows you to apply a child policy with non-queuing features under a priority class in Cisco IOS Release 12.2(31)SB2 and later releases. In a three-level hierarchical policy, the priority class to which you attach the child policy must be in the middle-level policy. In a two-level hierarchical policy (nested policy), the priority class to which you attach the child policy is in the parent policy.
For more information, see the Child Service Policy Allowed Under Priority Class feature module for Cisco IOS Release 12.2(31)SB2.
Interfaces Supporting Hierarchical Policies
The following describes interface support for hierarchical policies using the service-policy command:
Interfaces Supporting Hierarchical Policies (Outbound Only)
•
•
•
•
•
•
•
Note
Interfaces Supporting Hierarchical Policies (Inbound only)
•
•
•
•
•
•
Note
Interfaces Not Supporting Hierarchical Policies
•
•
•
•
Guidelines for Configuring QoS for Multiple Queues
When configuring QoS for multiple queues, consider the following guidelines:
•
•
•
Configuring QoS for Multiple Queues
To configure QoS for multiple queues using a hierarchical policy, perform the following configuration tasks:
•
•
•
•
Creating Fair Queues at Two Levels of Hierarchy
To create fair queues at two levels of hierarchy, enter the following commands beginning in global configuration mode:
Note
Example 13-3 shows how to create a nested hierarchical policy that creates two fair queues: one queue for the Bronze traffic and one queue for all other traffic. The top-level policy named Top-Parent shapes the total output rate of both queues to 1 Mbps. The bottom-level policy named Bottom-Child shapes Bronze traffic to 50 percent of the total output rate, or 500 kbps. The router allocates the remaining 500 kbps to all other traffic.
Example 13-3 Creating Fair Queues at Two Levels of Hierarchy
Router(config)# policy-map Bottom-ChildRouter(config-pmap)# class BronzeRouter(config-pmap-c)# bandwidth percent 50Router(config-pmap-c)# exitRouter(config-pmap)# policy-map Top-ParentRouter(config-pmap)# class class-defaultRouter(config-pmap-c)# shape 1000Router(config-pmap-c)# service-policy Bottom-ChildCreating Fair Queues at Three Levels of Hierarchy
To create fair queues at three levels of hierarchy, perform the following required configuration tasks:
•
•
•
Configuring a Bottom-Level Child Policy of a Three-Level Hierarchy
To configure the bottom-level child policy, enter the following commands beginning in global configuration mode:
Note
Step 1
Router(config)# policy-map policy-map-name
Creates or modifies the bottom-level child policy.
policy-map-name is the name of the policy map. The name can be a maximum of 40 alphanumeric characters.
Step 2
Router(config-pmap)# class class-map-name
Assigns the traffic class you specify to the policy map. Enters policy-map class configuration mode.
class-map-name is the name of a previously configured class map and is the traffic class for which you want to define QoS actions.
Step 3
Router(config-pmap-c)# police [cir] bps [burst-normal] [burst-excess] conform-action {action} exceed-action {action} [violate-action {action}]
(Optional) Configures kilobits per second-based traffic policing.
For more information, see Chapter 6, "Policing Traffic."
Step 4
Router(config-pmap-c)# police [cir] percent percent bc normal-burst-in-msec [pir pir] be excess-burst-in-msec conform-action {action} exceed-action {action} [violate-action {action}]
(Optional) Configures percent-based traffic policing.
For more information, see Chapter 6, "Policing Traffic."
For information about traffic policing actions, see Table 6-1 on page 6-3.
Step 5
Router(config-pmap-c)# set action
(Optional) Configures traffic marking.
For a description of the traffic marking actions you can configure, see Table 13-2.
Table 13-2 describes the traffic marking actions you can configure using the set command.
Example 13-4 shows how to configure the bottom-level child policy of a three-level hierarchy. Remember, the bottom-level policy typically defines marking and metering actions. In this example, the policy map named Gold-Meter defines the policing rate and actions for Business class traffic; the policy map named Default-Meter defines the default policing rate and actions.
Example 13-4 Configuring a Bottom-Level Child Policy of a Three-Level Hierarchy
Router(config)# policy-map Gold-MeterRouter(config-pmap)# class BusinessRouter(config-pmap-c)# police 15000 10000 6000 conform-action transmit exceed-action set-prec-transmit 1Router(config-pmap-c)# exitRouter(config-pmap)# policy-map Default-MeterRouter(config-pmap)# class BusinessRouter(config-pmap-c)# police percent 10 1500 0 conform-action transmit exceed-action set-prec-transmit 4Router(config-pmap-c)# exitRouter(config-pmap)#Configuring a Middle-Level Child Policy of a Three-Level Hierarchy
To configure a middle-level child policy, enter the following commands beginning in global configuration mode:
Note
Step 1
Router(config-pmap)# policy-map policy-map-name
Creates or modifies a middle-level child policy map.
policy-map-name is the name of the policy map. The name can be a maximum of 40 alphanumeric characters.
Step 2
Router(config-pmap)# class class-map-name
Assigns the traffic class you specify to the policy map. Enters policy-map class configuration mode.
class-map-name is the name of a previously configured class map and is the traffic class for which you want to define QoS actions.
Step 3
Router(config-pmap-c)# priority
(Optional) Assigns strict priority to the traffic class.
Note
Step 4
Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percentage | remaining percent percentage}
(Optional) Specifies the bandwidth allocated for a traffic class.
Note
Step 5
Router(config-pmap-c)# random-detect dscp-based
(Optional) Enables DSCP-based WRED.
Step 6
Router(config-pmap-c)# random-detect dscp dscpvalue min-threshold max-threshold [mark-probability-denominator]
(Optional) Specifies a packet drop policy based on the DSCP value you specify.
For more information, see Chapter 11, "Managing Packet Queue Congestion."
Step 7
Router(config-pmap-c)# service-policy policy-map-name
Applies the bottom-level child policy map to the traffic class. Do not specify an input or output keyword.
policy-map-name is the name of a previously configured bottom-level child policy map.
Example 13-5 shows how to configure a middle-level child policy using the bottom-level child policy configured in Example 13-4. In this middle-level policy, the policy map named Southwest defines three traffic classes: Premium, Gold, and class-default. The configuration of these classes provides the following QoS behavior:
Premium Traffic
•
•
Gold Traffic
•
–
–
•
Default Traffic
•
–
–
•
Example 13-5 Configuring a Middle-Level Child Policy of a Three-Level Hierarchy
Router(config-pmap)# policy-map SouthwestRouter(config-pmap)# class PremiumRouter(config-pmap-c)# priorityRouter(config-pmap-c)# police percent 50Router(config-pmap-c)# class GoldRouter(config-pmap-c)# random-detect prec-basedRouter(config-pmap-c)# random-detect precedence 2 3Router(config-pmap-c)# service-policy Gold-MeterRouter(config-pmap-c)# class class-defaultRouter(config-pmap-c)# random-detect prec-basedRouter(config-pmap-c)# random-detect precedence 1Router(config-pmap-c)# service-policy Default-MeterRouter(config-pmap-c)# exitRouter(config-pmap)#Configuring the Top-Level Parent Policy of a Three-Level Hierarchy
To configure a top-level parent policy, enter the following commands beginning in global configuration mode:
Note
Example 13-6 shows how to configure a top-level parent policy using the middle-level child policy configured in Example 13-5. In this top-level policy, the shape command indicates a total transmission capacity of 64,000 kbps for the combined queues. The service-policy command applies the middle-level policy named Southwest to the parent class-default class.
Example 13-6 Configuring a Top-Level Parent Policy of a Three-Level Hierarchy
Router(config-pmap)# policy-map Region1Router(config-pmap)# class class-defaultRouter(config-pmap-c)# shape 64000Router(config-pmap-c)# service-policy SouthwestRouter(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)#Policing Inbound Traffic at Two Levels of Hierarchy
To police the traffic the router accepts on an inbound interface with a service policy applied, enter the following commands beginning in global configuration mode:
Note
Step 1
Router(config-pmap)# policy-map policy-map-name
Creates or modifies a bottom-level child policy map.
policy-map-name is the name of the policy map. The name can be a maximum of 40 alphanumeric characters.
Step 2
Router(config-pmap)# class class-map-name
Assigns the traffic class you specify to the policy map. Enters policy-map class configuration mode.
class-map-name is the name of a previously configured class map and is the traffic class for which you want to define QoS actions.
Step 3
Router(config-pmap-c)# police {cir cir} [bc conform-burst] [pir pir] [be peak-burst] [conform-action action [exceed-action action [violate-action action]]]
Configures traffic policing using two rates, the committed information rate (CIR) and the peak information rate (PIR).
cir is the committed information rate (CIR) and indicates an average rate at which the policer meters traffic.
cir specifies the CIR value in bits per second. Valid values are from 8000 to 2,488,320,000.
(Optional) bc conform-burst is conform burst (bc) size used by the first token bucket for policing. The conform-burst specifies the bc value in bytes. Valid values are from 1 to 51200,000.
pir pir is the peak information rate (PIR) at which the second token bucket is updated. The pir specifies the PIR value in bits per second. Valid values are from 8000 to 2,488,320,000.
(Optional) be peak-burst is the peak burst (be) size used by the second token bucket for policing. The peak-burst specifies the peak burst (be) size in bytes. The size varies according to the interface in use. Valid values are from 0 to 1,024,000,000.
conform-action {action} is the action to take on packets that conform to the CIR and PIR. The default action is transmit.
exceed-action {action} is the action to take on packets that conform to the PIR but not the CIR. The default action is drop.
(Optional) violate-action {action} is the action to take on packets that exceed the PIR. The default action is the same as the exceed-action.
{action} is the action to take on packets. See Table 6-1 on page 6-3 for a description of each action.
Step 4
Router(config-pmap-c)# exit
Exits policy-map class configuration mode.
Step 5
Router(config-pmap)# policy-map policy-map-name
Creates or modifies a top-level parent policy map.
policy-map-name is the name of the policy map. The name can be a maximum of 40 alphanumeric characters.
Step 6
Router(config-pmap)# class class-default
Configures or modifies the default traffic class.
Step 7
Router(config-pmap-c)# police {cir cir} [bc conform-burst] [pir pir] [be peak-burst] [conform-action action [exceed-action action [violate-action action]]]
Configures traffic policing using two rates, the committed information rate (CIR) and the peak information rate (PIR).
For more information, see Chapter 6, "Policing Traffic."
{action} is the action to take on packets. See Table 6-1 on page 6-3 for a description of each action.
Step 8
Router(config-pmap-c)# service-policy policy-map-name
Applies the bottom-level child policy map to the parent class-default class. Do not specify an input or output keyword.
policy-map-name is the name of a previously configured bottom-level child policy map.
Example 13-7 shows how to configure a hierarchical input policing policy to police the traffic that enters the router on a specific interface. In the example, the two class maps named class-default and Gold define the criteria the router uses to classify traffic. The bottom-level child policy map named Business defines the policing actions for traffic classified as Gold; the top-level parent policy map named All_Traffic defines the policing actions for default traffic. The Business policy map is applied to the All_Traffic policy, creating a two-level hierarchical input policing policy.
Example 13-7 Policing Inbound Traffic at Two Levels of Hierarchy
Router(config)# class-map class-defaultRouter(config-cmap)# match anyRouter(config-cmap)# class-map GoldRouter(config-cmap)# match ip precedence 3Router(config-cmap)# exitRouter(config)# policy-map BusinessRouter(config-pmap)# class GoldRouter(config-pmap-c)# police 20000 200 pir 40000 300 conform-action set-qos-transmit 80 exceed-action set-qos-transmit 35 violate-action dropRouter(config-pmap-c)# exitRouter(config-pmap)# policy-map All_TrafficRouter(config-pmap)# class class-defaultRouter(config-pmap-c)# police 6400 200 pir 12800 400 conform-action transmit exceed-action transmit violate-action dropRouter(config-pmap-c)# service-policy BusinessAttaching Hierarchical Policies to Physical and Virtual Links
To attach hierarchical policies to interfaces, subinterfaces, virtual circuits, and virtual LANs, enter the following command:
Configuration Examples
This section provides the following configuration examples:
•
•
•
•
•
Configuration Examples for Nested Hierarchical Policies
Example 13-8 shows how to configure a nested hierarchical policy. This example configuration includes the following:
•
•
•
Example 13-8 Configuring a Two-Level Hierarchical Policy
Router(config)# policy-map Child-Policy [Defines bottom-level child policy.]Router(config-pmap)# class NewUsersRouter(config-pmap-c)# police percent 20 400 800 conform-action transmit exceed-action dropRouter(config-pmap-c)# class Bronze-UsersRouter(config-pmap-c)# bandwidth 256Router(config-pmap-c)# random-detect dscp-basedRouter(config-pmap-c)# random-detect dscp 8 24 40Router(config-pmap-c)# queue-limit 128Router(config-pmap-c)# exitRouter(config-pmap)# policy-map Parent-Policy [Defines top-level parent policy.]Router(config-pmap)# class class-defaultRouter(config-pmap-c)# shape 512Router(config-pmap-c)# service-policy Child-Policy [Applies child to top-level parent.]Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# interface atm 1/0/0Router(config-if)# service-policy output Parent-Policy [Applies parent to the interface.]Example 13-9 shows how to configure another nested hierarchical policy. In the example, the bottom-level child policy named Bottom consists of two traffic classes named Group1 and Group2. The traffic matching Group1 has a minimum bandwidth guarantee of 5000 kbps; Group2 has a minimum bandwidth guarantee of 2000 kbps and also has a DSCP-based weighted random early detection (WRED) packet drop policy defined. The bottom-level child policy is applied to the class-default class in the top-level Parent policy map. The router shapes the aggregate of all of the Group1 and Group2 traffic to 8000 kbps as specified by the shape command in the Parent class-default class. The hierarchical policy is attached to outbound ATM interface 1/0/0 using the service-policy command.
Example 13-9 Configuring a Nested Hierarchical Policy at Two Levels of Hierarchy
Router(config)# policy-map Bottom [Defines bottom-level child policy.]Router(config-pmap)# class Group1Router(config-pmap-c)# bandwidth 5000Router(config-pmap)# class Group2Router(config-pmap)# bandwidth 2000Router(config-pmap-c)# random-detect dscp-basedRouter(config-pmap-c)# random-detect dscp 40 10 20 10Router(config-pmap-c)# exitRouter(config-pmap)# policy-map Parent [Defines top-level parent policy.]Router(config-pmap)# class class-defaultRouter(config-pmap-c)# shape 8000Router(config-pmap-c)# service-policy Bottom [Applies bottom-level child policy.]Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# interface atm 1/0/0Router(config-if)# service-policy output Parent [Applies top-level parent policy.]Configuration Examples for Three-Level Hierarchical Policies
Example 13-10 shows how to configure a three-level hierarchical policy. This example configuration includes the following:
•
•
•
•
Example 13-10 Configuring a Three-Level Hierarchical Policy
Router(config)# policy-map DefaultMeter [Defines bottom-level child policy.]Router(config-pmap)# class Group1Router(config-pmap-c)# police percent 30Router(config-pmap-c)# set cos 2Router(config-pmap-c)# exitRouter(config-pmap)# policy-map BusinessMeter [Defines bottom-level child.]Router(config-pmap-c)# class Group2Router(config-pmap-c)# police percent 10Router(config-pmap-c)# exitRouter(config-pmap)# policy-map Middle-Level [Defines middle-level child policy.]Router(config-pmap-c)# class BusinessRouter(config-pmap-c)# random-detect dscp-basedRouter(config-pmap-c)# random-detect dscp 40 10 20 10Router(config-pmap-c)# service-policy BusinessMeter [Applies bottom-level child policy.]Router(config-pmap-c)# class Non-BusinessRouter(config-pmap-c)# random-detect dscp-basedRouter(config-pmap-c)# random-detect dscp 20 10 20 10Router(config-pmap-c)# service-policy DefaultMeter [Applies bottom-level child policy.]Router(config-pmap-c)# exitRouter(config-pmap)# policy-map Top-Level [Defines top-level parent policy.]Router(config-pmap)# class class-defaultRouter(config-pmap-c)# shape 8000Router(config-pmap-c)# service-policy Middle-Level [Applies middle-level child to parent.]Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# interface atm 1/0/0Router(config-if)# atm pxf queuingRouter(config-if)# interface atm 1/0/0.1 point-to-pointRouter(config-subif)# pvc 1/32Router(config-subif-atm-vc)# ubr 10000Router(config-subif-atm-vc)# service-policy output Top-Level [Attaches parent to PVC.]Example 13-11 shows how to configure another three-level hierarchical policy. This example configuration includes the following:
•
•
–
–
–
•
•
Example 13-11 Configuring a QoS Policy at Three Levels of Hierarchy
Router(config)# policy-map Business-Meter [Defines bottom-level child policy.]Router(config-pmap)# class non-SAARouter(config-pmap-c)# police percent 40 1500 0 conform-action transmit exceed-action set-dscp-transmit 40Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# policy-map Default-Meter [Defines another bottom-level child policy.]Router(config-pmap)# class non-SAARouter(config-pmap-c)# police percent 10 1500 0 conform-action transmit exceed-action set-dscp transmit 20Router(config-pmap-c)# exitRouter(config-pmap)# policy-map Southwest [Defines middle-level child policy.]Router(config-pmap)# class PremiumRouter(config-pmap-c)# priorityRouter(config-pmap-c)# police 8000 6000 2000 conform-action transmit exceed-action dropRouter(config-pmap-c)# exitRouter(config-pmap)# class BusinessRouter(config-pmap-c)# random-detect dscp-basedRouter(config-pmap-c)# random-detect dscp 40 10 20 10Router(config-pmap-c)# random-detect dscp 44 100 200 10Router(config-pmap-c)# service-policy Business-Meter [Applies bottom-level child policy.]Router(config-pmap-c)# exitRouter(config-pmap)# class Non-EssentialRouter(config-pmap-c)# random-detect dscp-basedRouter(config-pmap-c)# random-detect dscp 20 10 20 10Router(config-pmap-c)# random-detect dscp 24 100 200 10Router(config-pmap-c)# service-policy Default-Meter [Applies bottom-level child policy.]Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# policy-map Region1 [Defines top-level parent policy.]Router(config-pmap)# class class-defaultRouter(config-pmap-c)# shape 20000Router(config-pmap-c)# service-policy Southwest [Applies middle-level child policy.]Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# interface serial 5/0/0.1 point-to-pointRouter(config-subif)# ip address 10.1.0.2 255.255.255.252Router(config-subif)# service-policy output Region1 [Applies top-level parent.]Configuration Example for Hierarchical Input Policing
Example 13-12 shows how to configure a hierarchical input policing policy to limit the rate of traffic that the router accepts on an inbound interface. This example configuration includes the following
•
•
•
•
Example 13-12 Configuring Hierarchical Input Policing
Router(config)# class-map match-any class-default [Defines classification criterion.]Router(config-cmap)# class-map Click [Defines classification criterion.]Router(config-cmap)# match ip precedence 2Router(config-cmap)# exitRouter(config)# policy-map Policy2 [Defines bottom-level child policy.]Router(config-pmap)# class ClickRouter(config-pmap-c)# police 200000 2000 pir 400000 3000 conform-action set-dscp-transmit 59 exceed-action set-dscp-transmit 60 violate-action drop [Configures two-rate policer.]Router(config-pmap-c)# exitRouter(config-pmap)# policy-map Parentbps1 [Defines top-level parent policy.]Router(config-pmap)# class class-defaultRouter(config-pmap-c)# police 128000 2000 pir 256000 4000 conform-action transmit exceed-action transmit violate-action drop [Configures two-rate three-color policer.]Router(config-pmap-c)# service-policy Policy2 [Applies bottom-level child to parent.]Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# interface atm 1/0/0.10 point-to-pointRouter(config-subif)# pvc 101/102Router(config-subif-atm-vc)# ubr 1000Router(config-subif-atm-vc)# service-policy input Parentbps1 [Attaches parent to PVC.]Configuring Bandwidth-Remaining Ratios on ATM Subinterfaces: Example
The following example shows how to differentiate one ATM PVC from another during congestion by using bandwidth-remaining ratios. In the example, during periods of congestion in which the traffic on all PVCs on the interface exceeds the interface speed, the router uses the configured bandwidth-remaining ratio of 10 to determine the amount of excess (unused by priority traffic) bandwidth to allocate to non-priority traffic on PVC 0/200, relative to the other ATM PVCs configured on the interface.
policy-map Childclass precedence_0bandwidth 100class precedence_1bandwidth 10000!policy-map Parentclass class-defaultbandwidth remaining ratio 10service-policy Child!interface ATM2/0/3.200 point-to-pointip address 10.20.1.1 255.255.255.0pvc 0/200protocol ip 10.20.1.2vbr-nrt 50000encapsulation aal5snapservice-policy output Parent
Note
For information on bandwidth-remaining ratios, see "Distribution of Remaining Bandwidth Using Ratio" section on page 5-14 or the Distribution of Remaining Bandwidth Using Ratio, Release 12.2(31)SB2 feature module.
Configuring Bandwidth-Remaining Ratios on Class Queues: Example
In the following sample configuration, the vlan10_policy is applied on the subinterface Gigabit Ethernet 1/0/0.10 and the vlan20_policy is applied on the subinterface Gigabit Ethernet 1/0/0.20. During congestion on the interface, subinterface GE 1/0/0.20 has 10 times more available bandwidth than subinterface GE1/0/0.10 because the bandwidth-remaining ratio for subinterface GE 1/0/0.20 is 10 times more than the bandwidth-remaining ratio for subinterface 1/0/0.10: 100 on subinterface 1/0/0.20 and 10 on subinterface 1/0/0.10.
When congestion occurs within a subinterface level, the class queues receive bandwidth according to the class-level bandwidth-remaining ratios. In the example, the bandwidth for classes precedence_0, precedence_1, and precedence_2 is allocated based on the bandwidth-remaining ratios of the classes: 20, 40, and 60, respectively.
policy-map child-policyclass precedence_0shape average 500000bandwidth remaining ratio 20 <---- Class-level ratioclass precedence_1shape average 500000bandwidth remaining ratio 40 <---- Class-level ratioclass precedence_2shape average 500000bandwidth remaining ratio 60 <---- Class-level ratio!policy-map vlan10_policyclass class-defaultshape average 1000000bandwidth remaining ratio 10 <---- Subinterface-level ratioservice-policy child-policy!policy-map vlan20_policyclass class-defaultshape average 1000000bandwidth remaining ratio 100 <---- Subinterface-level ratioservice-policy child_policy!!interface GigabitEthernet 1/0/0.10encapsulation dot1q 10service-policy output vlan10_policy!interface GigabitEthernet 1/0/0.20encapsulation dot1q 20service-policy output vlan20_policyFor information on bandwidth-remaining ratios, see "Distribution of Remaining Bandwidth Using Ratio" section on page 5-14 or the Distribution of Remaining Bandwidth Using Ratio, Release 12.2(31)SB2 feature module.
Verifying the Configuration of Hierarchical Policies
To verify hierarchical policies, enter any of the following commands in privileged EXEC mode:
Verification Examples for Hierarchical Policies
Example 13-13 shows sample output from the show class-map, show policy-map, show policy-map interface, and show running-config interface commands for the hierarchical input policing policy configured in Example 13-12.
Example 13-13 Verifying a Hierarchical Input Policing Policy
Router# show class-mapClass Map match-any class-default (id 0)Match anyClass Map match-any click (id 3)Match ip precedence 2Router# show policy-mapPolicy Map policy2Class clickpolice 200000 2000 pir 400000 3000 conform-action set-dscp-transmit 59 exceed-actionset-dscp-transmit 60 violate-action dropPolicy Map parentbps1Class class-defaultpolice 128000 2000 pir 256000 4000 conform-action transmit exceed-action transmitviolate-action dropservice-policy policy2Router# show policy-map interface atm 5/0/0.1ATM5/0/0.1Service-policy input: Parentbps1Class-map: class-default (match-any)16080 packets, 2251200 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: any0 packets, 0 bytes5 minute rate 0 bpsOutput queue: 0/64; 0/0 packets/bytes output, 0/0 dropsPolice:128000 bps, 2000 limit, 256000 pir, 4000 extended limitconformed 6870 packets, 961800 bytes; action: transmitexceeded 6871 packets, 961940 bytes; action: transmitviolated 2339 packets, 327460 bytes; action: dropService-policy : policy2Class-map: click (match-any)16080 packets, 2251200 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: ip precedence 216080 packets, 2251200 bytes5 minute rate 0 bpsPolice:200000 bps, 2000 limit, 400000 pir, 3000 extended limitconformed 10727 packets, 1501780 bytes; action: set-dscp-transmit 59exceeded 5353 packets, 749420 bytes; action: set-dscp-transmit 60violated 0 packets, 0 bytes; action: dropClass-map: class-default (match-any)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: any0 packets, 0 bytes5 minute rate 0 bpsOutput queue: 0/64; 0/0 packets/bytes output, 0/0 dropsRouter# show running-config interface atm 5/0/0.1Building configuration...Current configuration : 173 bytes!interface ATM5/0/0.1 point-to-pointip address 1.1.1.2 255.255.255.0pvc 0/100vbr-nrt 3000 2000 10encapsulation aal5snap!service-policy input Parentbps1endRouter#Related Documentation
This section provides hyperlinks to additional Cisco documentation for the features discussed in this chapter. To display the documentation, click the document title or a section of the document highlighted in blue. When appropriate, paths to applicable sections are listed below the documentation title.
Class maps
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2
Part 8: Modular Quality of Service Command-Line Interface > Configuring the Modular Quality of Service Command-Line Interface > Modular QoS CLI Configuration Task List > Creating a Traffic Class
Cisco IOS Quality of Service Solutions Command Reference, Release 12.2
access-list rate-limit - fair-queue (WFQ) > class-map command
Oversubscription
Cisco 10000 Series Router Quality of Service Configuration Guide
Policing
Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting tech note
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2
Configuring Traffic Policing
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2
Quality of Service Overview > Policing and Shaping
Policy maps
Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2
Part 8: Modular Quality of Service Command-Line Interface > Configuring the Modular Quality of Service Command-Line Interface > Modular QoS CLI Configuration Task List > Creating a Traffic Policy
Cisco IOS Quality of Service Solutions Command Reference, Release 12.2
policy map - qos preclassify > policy map command
Three level scheduler
Three-Level Scheduler Using MQC Hierarchical Queuing Framework, Release 12.2(31)SB2 feature module
Two-rate three-color policer
Two-Rate Policer, Release 12.2(4)T3 feature module
RFC 2698—"A Two Rate Three Color Marker", J. Heinanen, T. Finland, G. Guerin, September 1999
