Cisco 10000 Series Router Quality of Service Configuration Guide
Defining QoS for Multiple Policy Levels
Downloads: This chapterpdf (PDF - 586.0KB) The complete bookPDF (PDF - 21.32MB) | Feedback

Defining QoS for Multiple Policy Levels

Table Of Contents

Defining QoS for Multiple Policy Levels

Hierarchical Policies

Feature History for Hierarchical Policies

Benefits of Hierarchical Policies

Components Common to All Types of Hierarchical Policies

Child Policy

Parent Policy

service-policy Command

Types of Hierarchical Policies

Nested 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

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

Related Documentation


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:

Hierarchical Policies

Components Common to All Types of Hierarchical Policies

Types of Hierarchical 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

Configuration Examples

Verifying the Configuration of Hierarchical Policies

Related Documentation

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:

Specify multiple policy maps to shape multiple queues together

Apply specific policy map actions on the aggregate traffic

Apply class-specific policy map actions

Restrict the maximum bandwidth of a virtual circuit (VC) while allowing policing and marking of traffic classes within the VC


Note For more information about the types of hierarchical policies, see the "Nested Hierarchical Policies" section, "Three-Level Hierarchical Policies" section, and the "Hierarchical Input Policing Policies" section).


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:

Bottom-level child policy to a middle-level child policy

Middle-level child policy to a top-level parent policy

Top-level parent policy to an interface, subinterface, VC, or VLAN


Note For more information, see the "Child Policy" section, the "Parent Policy" section, and the "service-policy Command" section.


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

Cisco IOS Release
Description
Required PRE

Release 12.0(22)S

The hierarchical policies feature was introduced on the PRE1 and support two-level, nested hierarchical policies.

PRE1

Release 12.0(25)SX

This feature was enhanced on the PRE1 to support three-level hierarchical policies.

PRE1

Release 12.2(16)BX

This feature was introduced on the PRE2 and supported two-level, nested hierarchical policies.

PRE2

Release 12.3(7)XI

This feature was enhanced on the PRE2 to support three-level hierarchical policies.

PRE2

Release 12.2(28)SB

This feature was integrated into Cisco IOS Release 12.2(28)SB for the PRE2 and enhanced to support hierarchical input policing feature on the PRE2.

PRE2

Release 12.2(31)SB2

This feature was introduced on the PRE3

PRE3


Benefits of Hierarchical Policies

Depending on the type of hierarchical QoS policy you configure, you can:

Shape multiple queues to a single rate

Divide a single class of traffic into one or more subclasses

Specify the maximum transmission rate of a set of traffic classes that are queued separately, which is essential for virtual interfaces such as Frame Relay PVCs and IEEE 802.1Q virtual LANs (VLANs)

Configure fair queues on virtual circuits

Shape the aggregate traffic of queues on a physical interface (for example, provide a 10-megabits per second (Mbps) service on a 100-Mbps physical interface)

Restrict the maximum bandwidth of a VC while allowing policing and marking of classes within the VC

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

Parent Policy

service-policy Command

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:

Nested hierarchical policies—Apply a bottom-level child policy to a top-level parent policy only.

Three-level hierarchical policies—Apply a bottom-level child policy to a middle-level child policy; and apply the middle-level child policy to the top-level parent policy.

Hierarchical input policing policies—Apply a bottom-level child policy to a top-level parent policy.

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.

shape command—(Nested or three-Level Hierarchical Policies) Specifies a single shape rate for all of the traffic classes defined in the child policies. The router does not allocate unused (or excess) bandwidth for other traffic. You must configure the shape command when creating nested hierarchical policies and three-level hierarchical policies; do not configure the police command.

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.

service-policy command—Applies a child policy to the parent policy to create a single hierarchical QoS policy. Specify the name of the child policy map as the policy-map-name. Do not specify the input or output keyword.


Note For more information about hierarchical policies, see the "Types of Hierarchical Policies" section.


Table 13-1 summarizes the commands configured in the parent class-default class for the different types of hierarchical policies.

Table 13-1 Hierarchical Parent Class-Default Class Commands

Type of Policy
shape Command
police Command
service-policy Command

Nested Hierarchical

Yes

No

Yes

Three-Level Hierarchical

Yes

No

Yes

Hierarchical Input Policing

No

Yes

Yes


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:

Child policies to child policies

Child policies to parent policies

Parent policies to interfaces, subinterfaces, and virtual circuits

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

When attaching parent policies to interfaces, subinterfaces, or virtual circuits, enter the service-policy command and specify the output or input keyword as described below:

Nested hierarchical policies and three-level hierarchical policies—Specify the output keyword to tell the router to apply the policy to outbound traffic. For more information, see the "Nested Hierarchical Policies" section and the "Three-Level Hierarchical Policies" section.

Hierarchical input policing policies—Specify the input keyword to apply the policy to inbound traffic. For more information, see the "Hierarchical Input Policing Policies" section.


Note The router does not support nested and three-level hierarchical policies on inbound interfaces, and it does not support hierarchical input policing on outbound interfaces.


Types of Hierarchical Policies

The Cisco 10000 series router supports the following types of hierarchical policies:

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

Three-Level Hierarchical Policies

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.

Hierarchical Input Policing Policies

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:

Child policy (bottom-level)—Identifies one or more classes of traffic and defines QoS behavior for the individual traffic streams. If you specify a class bandwidth in a child policy as a percentage, the router uses the top-level parent shape rate as the bandwidth reference (100 percent) rather than the bandwidth of the network interface. For example, in a nested policy shaped at 2 Mbps with a bottom-level child policy configured for 50 percent bandwidth, the router allocates 1 Mbps of bandwidth to the child policy (50 percent of the parent shape rate).

Parent policy (top-level)—Shapes the output of the traffic classes into a single shape rate. The parent policy can contain only the class-default class with only the shape command specified.

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 The above restriction does not apply to Cisco IOS Release 12.0(25)SX and later releases.


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 This section lists restrictions for nested hierarchical policies. These restrictions might not apply to other types of hierarchical policies.


Nested hierarchical policies can have no more than two levels of hierarchy.

Only the top-level parent policy can have the class-default class defined.

The parent class-default class can have only the shape command configured; you cannot specify any other policy action. The class-default class can also have the service-policy command configured to attach a child policy to the parent policy. You must specify the shape command before you specify the service-policy command.

Queuing services must exist at a single hierarchy level, except for the shape command, which is defined in the parent policy's class-default class.

You cannot apply a child policy to a traffic class that contains the set or police command.

For the PRE1, the router does not support DotP marking and 802.1P for nested hierarchical policies, including matching and marking of the 802.1P header.

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:

Define QoS policies at three levels of hierarchy

Define a single shaping rate for multiple classes and subclasses of IP traffic

Apply specific actions on the aggregate traffic of multiple classes and execute class-specific actions

Selectively police a subclass of each guaranteed class and place a maximum transmission limit on the aggregate traffic

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:

Child policy (bottom-level)—Specifies marking and metering actions for one or more classes of traffic using the set and police commands. You cannot apply a child policy to a traffic class that contains the set or police command.

Child policy (middle-level)—Defines class-based queuing actions for one or more classes of traffic. You must configure all queuing actions (such as the bandwidth and priority commands) at a single hierarchical level. The exception to this rule is the shape command, which is also configured in the class-default class of a parent policy.

Parent policy (top-level)—Defines the transmission capacity of a physical or virtual link to shape the output of the traffic classes into a single shape rate. The shape rate you specify in the parent policy is reserved for the traffic classes you specify in the child policies. The router does not allocate unused (excess) bandwidth for other traffic.


Note The actual shape rate the router applies to the child traffic classes might differ from the rate you specify in the hierarchical policy. Use the show policy-map interface command to determine the actual shape rate applied.


Restrictions and Limitations for Three-Level Hierarchical Policies


Note This section lists restrictions for three-level hierarchical policies. These restrictions might not apply to other types of hierarchical policies.


A top-level parent policy can have only the class-default class. Do not configure any other traffic class.

The parent class-default class can have only the shape and service-policy commands configured. Specify the shape command first and then the service-policy command to apply a child policy to the parent policy.

A middle-level child policy cannot have the police and set commands configured. If you use these commands in a middle-level policy, you cannot apply a bottom-level child policy to it using the service-policy command.

A bottom-level child policy can have only the police and set commands configured for a class.

Each bottom-level class map must match only those packets that also match its parent class map. For example, the union of the set of packets of a bottom-level class and that of its parent class must be equal to the set of packets that match the parent class.


Note If a policy does not adhere to the above restriction, the router might incorrectly classify the traffic affected by the policy.


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 Parent
Router(config-cmap)# math ip precedence 1 2 3
!
Router(config)# class-map Child
Router(config-cmap)# match not ip precedence 1
 
   

Example 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 Parent
Router(config-cmap)# math ip precedence 1 2 3
!
Router(config)# class-map Child
Router(config-cmap)# match ip precedence 2 3

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

Using hierarchical input policing, you can:

Specify policing actions at two levels of hierarchy

Define a policing rate for the traffic that the router accepts on an inbound interface (with a service policy applied)

Define a policing rate for individual traffic streams

A hierarchical input policing policy specifies the following two levels of hierarchy:

Child policy (bottom-level)—Specifies policing actions for individual IP traffic streams by using a two-rate three-color policer (see the "Two-Rate Three-Color Marker for Traffic Policing" section).

Parent policy (top-level)—Defines a policing rate for all inbound traffic on the interface, subinterface, VC, or VLAN on which the service policy is applied.

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 Packets dropped during bottom-level child processing are not passed to the top-level parent policer.


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

Packet classification for the bottom-level child policy map occurs before the top-level policer acts on the traffic classes.

Traffic policing at the top-level parent does not guarantee fairness in sharing bandwidth among the child classes. If packets from two different traffic classes arrive at the same rate and then go through a traffic policer, the output rates of the two classes might be different because the hierarchical input policer acts as an aggregate policer. The parent policer might drop packets in one class in favor of the other class. This situation can happen when the top-level policer has enough tokens when the packets for one class arrive, but does not have enough tokens left for the other class. Based on the arrival pattern of the packets, this pattern could continue indefinitely.

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)

Physical

ATM constant bit rate (CBR) PVCs and point-to-point subinterfaces

ATM variable bit rate (VBR) PVCs and point-to-point subinterfaces

ATM shaped (peak cell rate is specified) unspecified bit rate (UBR) PVCs and point-to-point subinterfaces

Label-controlled ATM (LC-ATM) subinterfaces

Frame Relay PVCs, point-to-point subinterfaces, and map classes

Ethernet VLANs


Note The router only supports nested and three-level hierarchical policies on outbound interfaces.


Interfaces Supporting Hierarchical Policies (Inbound only)

Physical

ATM constant bit rate (CBR) PVCs and point-to-point subinterfaces

ATM variable bit rate (VBR) PVCs and point-to-point subinterfaces

Label-controlled (LC)-ATM subinterfaces

Frame Relay PVCs, point-to-point subinterfaces, and map classes

Ethernet VLANs


Note The router only supports hierarchical input policing policies on inbound interfaces.


Interfaces Not Supporting Hierarchical Policies

Multilink PPP and Multilink Frame Relay

ATM unshaped (no peak cell rate specified) UBR PVCs and point-to-point subinterfaces

IP tunnel

Virtual-access (See the "VAI QoS Inheritance" section.)

Guidelines for Configuring QoS for Multiple Queues

When configuring QoS for multiple queues, consider the following guidelines:

Define child policies before you define the parent policy. For example, for a nested policy, define the bottom-level policy and then the top-level parent policy. For a three-level policy, define the bottom-level policy, the middle-level policy, and then the top-level parent policy.

Do not specify the input or output keyword in the service-policy command when configuring a child policy within another child policy or within a parent policy.

Do not configure a child policy in a traffic class of a bottom-level policy. Configure child policies only in middle-level and top-level parent policies.

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

Creating Fair Queues at Three Levels of Hierarchy

Policing Inbound Traffic at Two Levels of Hierarchy

Policing Inbound Traffic at Two Levels of Hierarchy

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 Use the following commands to configure both the child and parent policies. Configure the bottom-level child policy first and then the top-level parent policy. For information about additional actions you can specify in child policies, see the "Types of QoS Actions" section.


 
Command
Purpose

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 child 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)# bandwidth {bandwidth-kbps | percent percentage | remaining percent percentage}

(Optional) Enables class-based fair queuing.

bandwidth-kbps specifies or modifies the minimum bandwidth allocated for a class belonging to a policy map. Valid values are from 8 to 2,488,320, which represents from 1 to 99 percent of the link bandwidth.

percent percentage specifies or modifies the minimum percentage of the link bandwidth allocated for a class belonging to a policy map. Valid values are from 1 to 99.

remaining percent percentage specifies or modifies the minimum percentage of unused link bandwidth allocated for a class belonging to a policy map. Valid values are from 1 to 99.

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 the top-level parent policy.

policy-map-name is the name of the parent policy map. The name can be a maximum of 40 alphanumeric characters.

Step 6 

Router(config-pmap)# class class-default

Configures or modifies the parent class-default class.

Note You can configure only the class-default class in a parent policy. Do not configure any other traffic class.

Step 7 

Router(config-pmap-c)# shape kbps-value

Shapes traffic to the indicated bit rate.

kbps-value is the bit-rate (in kilobits per second) used to shape the traffic.

Step 8 

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

Applies a bottom-level child policy to the top-level parent class-default class.

policy-map-name is the name of the previously configured child policy map.

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-Child
Router(config-pmap)# class Bronze
Router(config-pmap-c)# bandwidth percent 50
Router(config-pmap-c)# exit
Router(config-pmap)# policy-map Top-Parent
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape 1000
Router(config-pmap-c)# service-policy Bottom-Child

Creating 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

Configuring a Middle-Level Child Policy of a Three-Level Hierarchy

Configuring the Top-Level Parent Policy of a Three-Level Hierarchy

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 The bottom-level child policy of a three-level hierarchical policy typically contains only metering or marking actions. Therefore, configure only the police and set commands in the bottom-level policy.


 
Command
Purpose

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.

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.

Table 13-2 Traffic Marking Actions 

Action
Description

atm-clp

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

cos

Sets the IEEE 802.1P class of service bits in the user priority field.

discard-class

Marks a packet with the discard-class value that you specify, indicating the drop eligibility of a packet.

dscp

Marks a packet with the differentiated services code point (DSCP) you specify.

mpls experimental imposition

Sets the value of the MPLS experimental (EXP) field on all imposed label entries.

ip precedence

Marks a packet with the IP precedence level you specify.

qos-group

Marks a packet with the QoS group identifier you specify.


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-Meter
Router(config-pmap)# class Business
Router(config-pmap-c)# police 15000 10000 6000 conform-action transmit exceed-action 
set-prec-transmit 1
Router(config-pmap-c)# exit
Router(config-pmap)# policy-map Default-Meter
Router(config-pmap)# class Business
Router(config-pmap-c)# police percent 10 1500 0 conform-action transmit exceed-action 
set-prec-transmit 4
Router(config-pmap-c)# exit
Router(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 For information about additional actions you can specify in child policies, see the "Types of QoS Actions" section.


 
Command
Purpose

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 For Cisco IOS Release 12.0(25)S and Release 12.3(7)XI, and later releases, the priority command has no arguments. To specify a bandwidth rate, use the police command (see Chapter 6 "Policing Traffic").

Step 4 

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

(Optional) Specifies the bandwidth allocated for a traffic class.

Note Do not enter the bandwidth command if you configure the priority command.

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

Gives priority service to Premium traffic

Limits Premium packets to 50 percent of the total transmission capacity

Gold Traffic

Uses the Gold-Meter policy to police all Gold traffic (see Example 13-4)

Guarantees Gold packets a minimum of 15,000 kbps of transmission capacity

Marks any traffic that exceeds 15,000 kbps with IP precedence 1 and then transmits the packet

During congestion, discards Gold packets with IP precedence level 2 or 3 before discarding other packets

Default Traffic

Uses the Default-Meter policy to police default traffic (see Example 13-4)

Guarantees default traffic a minimum of 10 percent of the total transmission capacity

Marks any traffic that exceeds 10 percent with IP precedence 4 and then transmits the packet

During congestion, discards default packets with IP precedence level 1 before discarding other packets

Example 13-5 Configuring a Middle-Level Child Policy of a Three-Level Hierarchy

Router(config-pmap)# policy-map Southwest
Router(config-pmap)# class Premium
Router(config-pmap-c)# priority
Router(config-pmap-c)# police percent 50
Router(config-pmap-c)# class Gold
Router(config-pmap-c)# random-detect prec-based
Router(config-pmap-c)# random-detect precedence 2 3 
Router(config-pmap-c)# service-policy Gold-Meter
Router(config-pmap-c)# class class-default
Router(config-pmap-c)# random-detect prec-based
Router(config-pmap-c)# random-detect precedence 1 
Router(config-pmap-c)# service-policy Default-Meter
Router(config-pmap-c)# exit
Router(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 In a top-level parent policy, define only the class-default class and specify the shape command and then the service-policy command in the class configuration. Do not specify any other commands.


 
Command
Purpose

Step 1 

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 2 

Router(config-pmap)# class class-default

Configures or modifies the class-default class.

Step 3 

Router(config-pmap-c)# shape kbps-value

Shapes traffic to the indicated bit rate.

kbps-value is the bit-rate (in kilobits per second) used to shape the traffic.

Step 4 

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

Applies the middle-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 middle-level child policy map.

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 Region1
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape 64000
Router(config-pmap-c)# service-policy Southwest
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(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 Use the following commands to configure both the child and parent policies. Configure the bottom-level child policy first and then the top-level parent policy. For information about additional actions you can specify, see the "Types of QoS Actions" section.


 
Command
Purpose

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 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 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-default
Router(config-cmap)# match any
Router(config-cmap)# class-map Gold
Router(config-cmap)# match ip precedence 3
Router(config-cmap)# exit
Router(config)# policy-map Business
Router(config-pmap)# class Gold
Router(config-pmap-c)# police 20000 200 pir 40000 300 conform-action set-qos-transmit 80 
exceed-action set-qos-transmit 35 violate-action drop
Router(config-pmap-c)# exit
Router(config-pmap)# policy-map All_Traffic
Router(config-pmap)# class class-default
Router(config-pmap-c)# police 6400 200 pir 12800 400 conform-action transmit exceed-action 
transmit violate-action drop
Router(config-pmap-c)# service-policy Business

Attaching Hierarchical Policies to Physical and Virtual Links

To attach hierarchical policies to interfaces, subinterfaces, virtual circuits, and virtual LANs, enter the following command:

Command
Purpose

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

Attaches the policy map you specify.

input indicates to apply the QoS policy to inbound packets. You must specify the input keyword for hierarchical input policing policies.

output indicates to apply the QoS policy to outbound packets. You must specify the output keyword for nested policies and three-level hierarchical policies.

policy-map-name is the name of a previously configured top-level parent policy map.


Configuration Examples

This section provides the following configuration examples:

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

Configuration Examples for Nested Hierarchical Policies

Example 13-8 shows how to configure a nested hierarchical policy. This example configuration includes the following:

A bottom-level Child-Policy that defines two traffic classes: NewUsers and Bronze-Users.

A top-level Parent-Policy that defines the class-default class, which is shaped to a rate of 512 kbps. The Child-Policy is applied to the class-default class.

The Parent-Policy is attached to ATM interface 1/0/0 in the outbound direction.

Example 13-8 Configuring a Two-Level Hierarchical Policy

Router(config)# policy-map Child-Policy [Defines bottom-level child policy.]
Router(config-pmap)# class NewUsers
Router(config-pmap-c)# police percent 20 400 800 conform-action transmit exceed-action 
drop
Router(config-pmap-c)# class Bronze-Users
Router(config-pmap-c)# bandwidth 256
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp 8 24 40
Router(config-pmap-c)# queue-limit 128
Router(config-pmap-c)# exit
Router(config-pmap)# policy-map Parent-Policy [Defines top-level parent policy.]
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape 512
Router(config-pmap-c)# service-policy Child-Policy [Applies child to top-level parent.]
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface atm 1/0/0
Router(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 Group1
Router(config-pmap-c)# bandwidth 5000 
Router(config-pmap)# class Group2
Router(config-pmap)# bandwidth 2000
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp 40 10 20 10
Router(config-pmap-c)# exit
Router(config-pmap)# policy-map Parent [Defines top-level parent policy.]
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape 8000
Router(config-pmap-c)# service-policy Bottom [Applies bottom-level child policy.]
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface atm 1/0/0
Router(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:

A bottom-level child policy contains two policy maps named DefaultMeter and BusinessMeter. These policy maps define marking and policing for the associated traffic classes.

A Middle-Level policy defines queuing services for the classes. In the Middle-Level policy map, the bottom-level BusinessMeter policy is applied to the Business class and the bottom-level DefaultMeter policy is applied to the Non-Business class.

The Middle-Level policy is applied to the class-default class in the parent policy map named Top-Level, which shapes the traffic to 8000 kbps.

The hierarchical policy is attached to PVC 1/32 on the point-to-point ATM subinterface 1/0/0.1 in the outbound direction.

Example 13-10 Configuring a Three-Level Hierarchical Policy

Router(config)# policy-map DefaultMeter [Defines bottom-level child policy.]
Router(config-pmap)# class Group1
Router(config-pmap-c)# police percent 30
Router(config-pmap-c)# set cos 2
Router(config-pmap-c)# exit
Router(config-pmap)# policy-map BusinessMeter [Defines bottom-level child.]
Router(config-pmap-c)# class Group2
Router(config-pmap-c)# police percent 10
Router(config-pmap-c)# exit
Router(config-pmap)# policy-map Middle-Level [Defines middle-level child policy.]
Router(config-pmap-c)# class Business
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp 40 10 20 10
Router(config-pmap-c)# service-policy BusinessMeter [Applies bottom-level child policy.]
Router(config-pmap-c)# class Non-Business
Router(config-pmap-c)# random-detect dscp-based 
Router(config-pmap-c)# random-detect dscp 20 10 20 10 
Router(config-pmap-c)# service-policy DefaultMeter [Applies bottom-level child policy.]
Router(config-pmap-c)# exit
Router(config-pmap)# policy-map Top-Level [Defines top-level parent policy.]
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape 8000
Router(config-pmap-c)# service-policy Middle-Level [Applies middle-level child to parent.]
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface atm 1/0/0
Router(config-if)# atm pxf queuing
Router(config-if)# interface atm 1/0/0.1 point-to-point
Router(config-subif)# pvc 1/32
Router(config-subif-atm-vc)# ubr 10000
Router(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:

Bottom-level child policies named Business-Meter and Default-Meter that define a policing rate.

A middle-level child policy named Middle-Level that does the following:

Gives priority service to Premium traffic and limits Premium traffic to 8000 bps.

Defines a Business class with a DSCP-based packet drop policy. The bottom-level child policy named Business-Meter is applied to the Business traffic. The Business-Meter policy indicates to police traffic at 40 percent of available bandwidth, mark traffic that exceeds 40 percent with DSCP 40, and during congestion, discard Business class traffic marked with DSCP 40 (the traffic that exceeds the policing rate) before it discards Business traffic at or below the policing rate.

Defines a Non-Essential class with a DSCP-based traffic drop policy. Notice that the bottom-level child policy named Default-Meter is applied to the Non-Essential traffic. The Default-Meter indicates to police traffic at 10 percent of the available bandwidth, mark exceeding traffic with DSCP 20, and during congestion, discard Non-Essential traffic marked with DSCP 20 (the traffic that exceeds the policing rate) before it discards Non-Essential traffic at or below the policing rate.

A top-level parent policy named Region1 that contains the class-default class, shapes the total bandwidth rate to 20 kbps. Notice that the Southwest policy is applied to the class-default class, which enables the router to shape the aggregate of all of the traffic to the shape rate defined in the Region1 class-default class, in this case 20 kbps.

The three-level hierarchical policy attaches to the point-to-point serial subinterface 5/0/0.1 in the outbound direction.

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-SAA
Router(config-pmap-c)# police percent 40 1500 0 conform-action transmit exceed-action 
set-dscp-transmit 40
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# policy-map Default-Meter [Defines another bottom-level child policy.]
Router(config-pmap)# class non-SAA
Router(config-pmap-c)# police percent 10 1500 0 conform-action transmit exceed-action 
set-dscp transmit 20
Router(config-pmap-c)# exit
Router(config-pmap)# policy-map Southwest [Defines middle-level child policy.]
Router(config-pmap)# class Premium
Router(config-pmap-c)# priority
Router(config-pmap-c)# police 8000 6000 2000 conform-action transmit exceed-action drop
Router(config-pmap-c)# exit
Router(config-pmap)# class Business
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp 40 10 20 10
Router(config-pmap-c)# random-detect dscp 44 100 200 10
Router(config-pmap-c)# service-policy Business-Meter [Applies bottom-level child policy.]
Router(config-pmap-c)# exit
Router(config-pmap)# class Non-Essential
Router(config-pmap-c)# random-detect dscp-based
Router(config-pmap-c)# random-detect dscp 20 10 20 10
Router(config-pmap-c)# random-detect dscp 24 100 200 10
Router(config-pmap-c)# service-policy Default-Meter [Applies bottom-level child policy.]
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# policy-map Region1 [Defines top-level parent policy.]
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape 20000
Router(config-pmap-c)# service-policy Southwest [Applies middle-level child policy.]
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface serial 5/0/0.1 point-to-point
Router(config-subif)# ip address 10.1.0.2 255.255.255.252
Router(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

Class maps named class-default and Click that define the classification criteria the router uses to classify packets.

A bottom-level child policy map named Policy2 that defines a two-rate three-color policer for the Click traffic class.

A top-level parent policy named Parentbps1 that contains the class-default class, which defines a two-rate three-color policer for default traffic. The bottom-level child policy named Policy2 is applied to the Parentbps1 class-default class.

The top-level parent policy is attached to PVC 101/102 on the ATM point-to-point subinterface 1/0/0.10.

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 2
Router(config-cmap)# exit
Router(config)# policy-map Policy2 [Defines bottom-level child policy.]
Router(config-pmap)# class Click
Router(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)# exit
Router(config-pmap)# policy-map Parentbps1 [Defines top-level parent policy.]
Router(config-pmap)# class class-default
Router(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)# exit
Router(config-pmap)# exit
Router(config)# interface atm 1/0/0.10 point-to-point
Router(config-subif)# pvc 101/102
Router(config-subif-atm-vc)# ubr 1000
Router(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 Child
class precedence_0
bandwidth 100
class precedence_1
bandwidth 10000
!
policy-map Parent
class class-default
bandwidth remaining ratio 10
service-policy Child
!
interface ATM2/0/3.200 point-to-point
ip address 10.20.1.1 255.255.255.0
pvc 0/200
protocol ip 10.20.1.2
vbr-nrt 50000
encapsulation aal5snap
service-policy output Parent

Note If PVC 98/204 is configured on the same interface as PVC 0/200 and with a bandwidth-remaining ratio of 1, during times of congestion PVC 0/200 would have 10 times more bandwidth available to it for non-priority traffic than PVC 98/204 would have.


For information on bandwidth-remaining ratios, see "Distribution of Remaining Bandwidth Using Ratio" section 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-policy
class precedence_0
shape average 500000
bandwidth remaining ratio 20 <---- Class-level ratio
class precedence_1
shape average 500000
bandwidth remaining ratio 40 <---- Class-level ratio
class precedence_2
shape average 500000
bandwidth remaining ratio 60 <---- Class-level ratio
!
policy-map vlan10_policy
class class-default
shape average 1000000
bandwidth remaining ratio 10 <---- Subinterface-level ratio
service-policy child-policy
!
policy-map vlan20_policy
class class-default
shape average 1000000
bandwidth remaining ratio 100 <---- Subinterface-level ratio
service-policy child_policy
!
!
interface GigabitEthernet 1/0/0.10
encapsulation dot1q 10
service-policy output vlan10_policy
!
interface GigabitEthernet 1/0/0.20
encapsulation dot1q 20
service-policy output vlan20_policy
 
   

For information on bandwidth-remaining ratios, see "Distribution of Remaining Bandwidth Using Ratio" section 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:

Command
Purpose

Router# show class-map

Displays the configuration of all class maps configured on the router.

Router# show policy-map

Displays the configuration of all policy maps configured on the router.

Router# show policy-map interface

Displays the configuration of all classes configured for all policy maps attached to all interfaces.

Router# show policy-map interface interface [input | output]

Displays the configuration of all classes configured for all inbound or outbound policy maps attached to the specified interface.

interface is the name of the interface or subinterface for the policy configuration you want to display.

input indicates to display the statistics for the attached inbound policy.

output indicates to display the statistics for the attached outbound policy.

Note If you do not specify input or output, the router displays information about all classes that are configured for all inbound and outbound policies attached to the interface you specify.

Router# show policy-map policy-map-name

Displays the configuration of all classes contained in the policy map you specify.

policy-map-name is the name of the policy map for the configuration information you want to display.

If you do not specify a policy-map-name, the command displays the configuration of all policy maps configured on the router.

Router# show policy-map policy-map-name class class-name

Displays the configuration of the class you specify. The policy map you specify includes this class.

policy-map-name is the name of the policy map that contains the class configuration you want to display.

class-name is the name of the class for the configuration you want to display. If you do not specify class-name, the router displays class configuration for all classes in the policy map.

Router# show running-config interface interface

Displays the configuration of the interface you specify that is currently configured in the running-config file, including any service policies attached to the interface.


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-map 
	Class Map match-any class-default (id 0) 
	Match any 
 
   
	Class Map match-any click (id 3) 
	Match ip precedence 2 
 
   
Router# show policy-map 
Policy Map policy2 
	Class click 
	police 200000 2000 pir 400000 3000 conform-action set-dscp-transmit 59 exceed-action 
set-dscp-transmit 60 violate-action drop
 
   
	Policy Map parentbps1 
	Class class-default 
	police 128000 2000 pir 256000 4000 conform-action transmit exceed-action transmit 
violate-action drop 
	service-policy policy2
 
   
Router# show policy-map interface atm 5/0/0.1
 
   
	ATM5/0/0.1
 
   
	Service-policy input: Parentbps1
 
   
	Class-map: class-default (match-any)
	16080 packets, 2251200 bytes 
	5 minute offered rate 0 bps, drop rate 0 bps 
	Match: any 
	0 packets, 0 bytes 
	5 minute rate 0 bps 
	Output queue: 0/64; 0/0 packets/bytes output, 0/0 drops 
	Police: 
	128000 bps, 2000 limit, 256000 pir, 4000 extended limit 
	conformed 6870 packets, 961800 bytes; action: transmit 
	exceeded 6871 packets, 961940 bytes; action: transmit 
	violated 2339 packets, 327460 bytes; action: drop
 
   
	Service-policy : policy2
 
   
	Class-map: click (match-any) 
	16080 packets, 2251200 bytes 
	5 minute offered rate 0 bps, drop rate 0 bps 
	Match: ip precedence 2 
	16080 packets, 2251200 bytes 
	5 minute rate 0 bps 
	Police: 
	200000 bps, 2000 limit, 400000 pir, 3000 extended limit 
	conformed 10727 packets, 1501780 bytes; action: set-dscp-transmit 59 
	exceeded 5353 packets, 749420 bytes; action: set-dscp-transmit 60 
	violated 0 packets, 0 bytes; action: drop
 
   
	Class-map: class-default (match-any) 
	0 packets, 0 bytes 
	5 minute offered rate 0 bps, drop rate 0 bps 
	Match: any 
	0 packets, 0 bytes 
	5 minute rate 0 bps 
	Output queue: 0/64; 0/0 packets/bytes output, 0/0 drops 
 
   
Router# show running-config interface atm 5/0/0.1 
Building configuration...
Current configuration : 173 bytes 
! 
interface ATM5/0/0.1 point-to-point 
	ip address 1.1.1.2 255.255.255.0 
	pvc 0/100 
	vbr-nrt 3000 2000 10 
	encapsulation aal5snap 
! 
service-policy input Parentbps1 
end
 
   
Router#

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.

Feature
Related Documentation

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

Oversubscribing Physical and Virtual Links

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