Traffic policing | Congestion Management | Modular QoS Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

Details traffic policing mechanisms that enforce configured traffic rates, including 1R2C and 2R3C policers, hierarchical ingress policing, burst values, guidelines, and configuration procedures.

Traffic policing is a QoS congestion management feature that

limits the maximum rate of traffic entering or leaving an interface by enforcing compliance with a configured bandwidth profile
uses a token bucket algorithm to determine whether each packet conforms to or exceeds a configured rate profile and applies the corresponding transmit or drop action, and
applies immediate actions—such as transmitting, marking, or dropping packets—without buffering excess traffic.

Key concepts of traffic policing

Token bucket: is a rate-control mechanism that accumulates tokens at a configured rate and uses them to determine whether packets conform to or exceed a traffic policer’s allowed bandwidth profile.
Conform, exceed, and violate actions: are policing outcomes that classify each packet based on whether it fits within the allowed rate: conforming packets are transmitted, exceeding packets may be marked or dropped, and violating packets are typically dropped according to the configured policing mode.
Committed Information Rate (CIR): is the sustained bandwidth level that a policer guarantees for a traffic flow, defining the average rate at which tokens are added to the token bucket.
Peak Information Rate (PIR): is the upper bandwidth limit configured for two-rate policers, defining the maximum rate at which traffic is allowed to be sent when both the committed and peak token buckets contain sufficient tokens.
Committed Burst (Bc): or Committed Burst Size (CBS) is the maximum amount of data that can be sent at once while still conforming to the CIR, representing the number of bytes or time interval that the committed token bucket can hold at full capacity.

This value represents the capacity of the primary token bucket. The larger the value, the more tolerant the policer is of momentary traffic bursts above the average rate.
Excess Burst (Be): or Excess Burst Size (EBS) is the additional amount of data that may be permitted beyond the committed burst when excess tokens are available, allowing short-term transmission above the CIR before packets are treated as exceeding or violating the rate.

Excess Burst (Be) is an optional parameter used in traffic policing, specifically within a two-bucket, three-color policing mode, to allow for a secondary, higher level of burst tolerance beyond the Committed Burst (Bc)

Types of traffic policing modes

This section outlines the traffic-policing modes supported on your router.

Single-Rate policer
- Single-rate two-color (1R2C) policer: is a rate-control mode that uses a single token bucket and classifies each packet as either conform or exceed based on the CIR, applying corresponding actions such as transmit or drop.
Two-rate policer
- Two-rate three-color (2R3C) policer: is a metering mode that uses two token buckets—one for the CIR and one for the peak information rate (PIR)—to classify packets into conform, exceed, or violate actions, enforcing both a sustained rate limit and a peak rate limit.

Single-rate two-color policers

The single-rate two-color (1R2C) policer is a traffic-policing feature that

uses a single token bucket to meter packets against a configured committed information rate (CIR)
classifies each packet as either conforming or exceeding the allowed rate based solely on the available committed burst tokens, and
applies fixed policing actions—transmit for conforming packets and drop for exceeding packets—without buffering excess traffic.

Guidelines for configuring single-rate two-color policers

Default policer actions

The policer always transmits packets that conform to the CIR.
The policer always drops packets that exceed the CIR.
The default actions cannot be modified, regardless of class configuration or policy-map settings.

How the single-rate two-color policer works

Summary

The key components involved in the single-rate two-color policer are:

Traffic policer: A metering function on the interface that evaluates each packet against a configured committed information rate (CIR) and burst parameters, then applies a conform or exceed action based on that evaluation.
Token bucket (Tc): A logical bucket that accumulates tokens at the CIR up to a configured committed burst value (Bc). The number of tokens represents how much traffic can be sent at any given moment.
Committed information rate (CIR): The configured average rate (in bits per second) at which the policer replenishes tokens and against which packet sizes are evaluated.

The single-rate two-color policer meters traffic by updating a single token bucket at the committed information rate and comparing the size of each packet against the available tokens. Based on this comparison, the policer classifies each packet as conforming or exceeding the CIR and applies the corresponding default action. This process limits the maximum traffic rate on the interface without buffering excess packets.

Workflow

These stages describe how the single-rate two-color policer works.

The router receives packets on an interface with a single-rate two-color policer configured.

The traffic policer on the interface inspects each incoming packet and prepares to meter it against the configured committed information rate (CIR) and burst parameters.
The policer updates the token bucket based on the committed information rate.

At every refresh interval, the policer adds tokens to the token bucket (Tc) at a rate equal to the CIR, up to the committed burst value (Bc). Tokens represent the amount of traffic that can be sent at the committed rate.
The policer compares the packet size to the available tokens.

For each packet of size B, the policer checks whether the current token count in the bucket is sufficient to accommodate the packet. If the bucket holds enough tokens, the packet can conform to the CIR; otherwise, the packet exceeds the CIR.
The policer classifies conforming packets and applies the conform action.

If the packet size B is less than or equal to the number of tokens in the bucket, the packet conforms. The policer decrements the token bucket by B and applies the conform action, which transmits the packet.
The policer classifies exceeding packets and applies the exceed action.

If the packet size B is greater than the number of available tokens in the bucket, the packet exceeds the CIR. The policer applies the exceed action, which drops the packet for the single-rate two-color policer. Excess packets are not buffered for later transmission.
The policer continues metering traffic to enforce the configured rate.

Result

As traffic continues to arrive, the policer repeats the cycle of replenishing tokens, classifying packets as conform or exceed, and applying the corresponding actions. This ongoing process enforces the configured committed information rate on the interface without buffering excess packets.

Configure single-rate two-color policers

Before you begin

Prepare or identify a class map that matches the traffic you want to police.

Follow these steps to configure traffic policing (1R2C) on an ingress interface.

Procedure

Create or modify a policy-map to apply the single-rate two-color policer to a traffic class.

This step creates a policy-map that applies a 1R2C policer to a class of traffic. The policer limits the rate for that class on the ingress interface.
Example:
```
Router# configure
Router(config)# policy-map test-police-1R2C
Router(config-pmap)# class dscp1
Router(config-pmap-c)# police rate 10 gbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# exit
          
```
The policy-map now includes a single-rate two-color policer that enforces a 10-Gbps committed rate for the dscp1 class.

Attach the policing policy-map to the ingress interface.

Attaching the policy-map enables traffic policing on the selected interface in the ingress direction.

Example:

Router(config)# interface HundredGigE 0/0/0/18
Router(config-if)# service-policy input test-police-1R2C
Router(config-if)# commit

The single-rate two-color policer is now active on the specified input interface.

Running Configuration:

class-map match-any dscp1
 match dscp ipv4 1
 end-class-map
!
!
policy-map test-police-1R2C
 class dscp1
  police rate 10 gbps
  !
 !
 class class-default
  !
 !
 end-policy-map
!
!
interface HundredGigE0/0/0/8
service-policy input test-police-1R2C
!

Verify the traffic policing configuration and policer statistics.

Example:

Router# show qos interface HundredGigE 0/0/0/8 input
NOTE:- Configured values are displayed within parentheses
Interface HundredGigE0/0/0/8 ifh 0xf0001e8  -- input policy
NPU Id:                        0
Total number of classes:       2
Interface Bandwidth:           100000000 kbps
Policy Name:                   test-police-1R2C
Accounting Type:               Layer1 (Include Layer 1 encapsulation and above)
------------------------------------------------------------------------------
Level1 Class                             =   dscp1
Policer committed rate                   =   10000000 kbps (10 gbits/sec)
Policer conform burst                    =   1024000 bytes (default)
Policer conform action                   =   Just TX
Policer exceed action                    =   DROP PKT

Level1 Class                             =   class-default
Policer not configured for this class

The output confirms that the input interface is using the test-police-1R2C policy and that the dscp1 class is policed at the configured rate with the expected conform and exceed actions.

Two-rate three-color policers

The two-rate three-color (2R3C) policer is a traffic-policing feature that

uses two token buckets, a committed bucket and a peak bucket, to meter traffic at both the committed information rate (CIR) and the peak information rate (PIR)
classifies each packet into one of three conformance levels—conform, exceed, or violate—based on the configured rates and burst parameters, and
applies predefined per-color actions in which conform and exceed traffic are transmitted and violate traffic is dropped.

Guidelines for configuring two-rate three-color policers

Default policer actions

The policer always transmits packets that conform to the committed or peak information rates.
The policer always drops packets that violate the configured rate thresholds.
You cannot modify these default actions, regardless of class configuration or policy-map settings.

How the two-rate three-color policer works

Summary

The key components involved in two-rate three-color policing are:

Committed information rate (CIR): The configured average rate (in bits per second) at which the policer replenishes tokens and against which packet sizes are evaluated.
Peak information rate (PIR): The higher metering rate that allows short-term bursts above the CIR, up to a configured peak limit.
Committed token bucket (Tc): A token bucket associated with the CIR that determines whether packets conform to the committed rate.
Peak token bucket (Tp): A token bucket associated with the PIR that determines whether packets exceed the committed rate but still remain within the peak rate.

The two-rate three-color policer uses the committed and peak token buckets together to meter packets against CIR and PIR and to assign a color-based action that enforces the configured traffic policy at the ingress interface.

Workflow

These stages describe how the two-rate three-color policer works.

The policer initializes the committed and peak token buckets.

The committed bucket is sized by the committed burst (Bc), and the peak bucket is sized by the peak burst (Be). Both buckets start accumulating tokens as soon as the policer is active.

Based on the configured committed information rate (CIR), peak information rate (PIR), and burst parameters, the router initializes the committed and peak token buckets used to meter incoming traffic.
The policer refreshes tokens based on the CIR and PIR.

When a packet arrives at the interface, then
- the committed bucket is refilled at the CIR rate, up to Bc, and
- the peak bucket is refilled at the PIR rate, up to Be.
This dual-rate update occurs each time traffic arrives, ensuring both long-term and peak-rate metering.

The policer evaluates the packet size against both token buckets.

The policer compares the packet’s size (B) with the committed and then the peak bucket.

Table 1. Packet evaluation against token buckets
When…	Then…
the packet size B is less than or equal to the committed token bucket (Tc)	the policer determines that the committed bucket has enough tokens and classifies the packet as conform.
the packet size B is greater than Tc but less than or equal to the peak token bucket (Tp)	the policer determines that the committed bucket overflows, but the peak bucket can accommodate the packet, and classifies it as exceed.
the packet size B is greater than Tp	the policer determines that neither bucket has enough tokens and classifies the packet as violate.

The policer assigns a color to the packet based on CIR and PIR.

Table 2. Packet color assignment
When…	Then…
the packet size B is less than or equal to the committed token bucket (Tc)	the policer assigns the packet the conform (green) color.
the packet size B is greater than Tc but less than or equal to the peak token bucket (Tp)	the policer assigns the packet the exceed (yellow) color because it does not fit in the committed bucket but still fits within the peak bucket.
the packet size B is greater than Tp	the policer assigns the packet the violate (red) color because it does not fit in either token bucket and exceeds the PIR.

The policer applies the default transmit or drop actions for each color.

Table 3. Color-based policer actions
When…	Then…
a packet is classified as conform (green)	the packet is transmitted, and the policer decrements both the committed and peak token buckets by the packet size B.
a packet is classified as exceed (yellow)	the packet is transmitted, the committed bucket is decremented by B, and the peak bucket is decremented by the overflow amount.
a packet is classified as violate (red)	the packet is dropped, and the peak token bucket is not decremented.

Result

As traffic continues to arrive, the policer repeatedly refreshes tokens in both the committed and peak buckets, evaluates packet sizes against the available tokens, assigns each packet a conform, exceed, or violate color, and applies the corresponding predefined actions. This continuous metering process enforces both the committed and peak information rates on the interface and ensures that exceeding and violating traffic is handled according to the policer’s color-based rules.

Configure two-rate three-color policers

Before you begin

Prepare or identify a class map that matches the traffic you want to police.

Follow these steps to configure two-rate three-color traffic policing (2R3C) on an ingress interface.

Procedure

Create or modify a policy-map to apply the two-rate three-color policer to a traffic class.

This step creates a policy-map that applies a 2R3C policer to a class of traffic. The policer meters traffic using a committed information rate (CIR) and a peak information rate (PIR).
Example:
```
Router# configure
Router(config)# policy-map test-police-2R3C
Router(config-pmap)# class dscp1
Router(config-pmap-c)# police rate 10 gbps peak-rate 20 gbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# exit
```
The policy-map now includes a two-rate three-color policer with a 10 Gbps committed rate and a 20 Gbps peak rate for the dscp1 class.

Attach the policing policy-map to the ingress interface.

Attaching the policy-map enables two-rate three-color traffic policing on the selected interface in the ingress direction.

Example:

Router(config)# interface HundredGigE 0/0/0/8
Router(config-if)# service-policy input test-police-2R3C
Router(config-if)# commit

The two-rate three-color policer is now active on the specified input interface.

Running Configuration:

class-map match-any dscp1
match dscp ipv4 1
end-class-map
!
!
policy-map test-police-2R3C
class dscp1
police rate 10 gbps peak-rate 20 gbps
!
!
class class-default
!
!
end-policy-map
!
!
interface HundredGigE0/0/0/8
service-policy input test-police-2R3C
!

Verify the two-rate three-color traffic policing configuration and policer statistics.

Verify the policer configuration applied on the ingress interface.

Example:

Router# show qos interface HundredGigE 0/0/0/8 input
NOTE:- Configured values are displayed within parentheses
|Interface HundredGigE0/0/0/8 ifh 0xf0001e8  -- input policy
|NPU Id:||0
|Total number of classes:       2
|Interface Bandwidth:           100000000 kbps
|Policy Name:|       test-police-2R3C
|Accounting Type:|   Layer1 (Include Layer 1 encapsulation and above)
|------------------------------------------------------------------------------
|Level1 Class||     =   dscp1
|Policer committed rate|       =   10000000 kbps (10 gbits/sec)
|Policer peak rate||=   20000000 kbps (20 gbits/sec)
|Policer conform burst|        =   1024000 bytes (default)
|Policer exceed burst|         =   2048000 bytes (default)
|Policer conform action|       =   Just TX
|Policer exceed action|        =   DROP PKT
|Policer violate action|       =   DROP PKT
|
|Level1 Class||     =   class-default
|Policer not configured for this class

Review detailed policer statistics on the ingress interface.

Example:

Router# policy-map interface HundredGigE 0/0/0/8 input
|HundredGigE0/0/0/8 input: test-police-2R3C
|
|Class dscp1
|Classification statistics          (packets/bytes)     (rate - kbps)
|Matched| :           289228439/289228439000         27734775
|Transmitted         :|56422213/56422213000          5410359
|Total Dropped       :           232806226/232806226000         22324416
|Policing statistics|    (packets/bytes)     (rate - kbps)
|Policed(conform)    :|56422213/56422213000          5410359
|Policed(exceed)     :|56422215/56422215000          5410358
|Policed(violate)    :           176384011/176384011000         16914058
|Policed and dropped :           232806226/232806226000
|Class class-default
|Classification statistics          (packets/bytes)     (rate - kbps)
|Matched| :|61136620/61136620000          0
|Transmitted         :|61136620/61136620000          0
|Total Dropped       :|       0/0|        0
|Policy Bag Stats time: 1570155764000  [Local Time: 10/04/19 02:22:44.000]

The output confirms that the input interface is using the test-police-2R3C policy and that the dscp1 class is metered at the configured committed and peak rates with the expected conform, exceed, and violate actions.

Two-level hierarchical ingress policing

Two-level hierarchical ingress policing is an ingress QoS traffic-policing feature that

uses a parent policer to enforce an aggregate ingress rate for a customer, service, or traffic aggregate,
preserves child policers for per-class or per-application committed and peak rate treatment, and
prioritizes traffic that child policers classify as conforming over child exceed or violate traffic when the policy is designed for child-conform-aware behavior.

From Cisco IOS XR Release 26.3.1 , you can configure the parent policer under the parent class-default class. The parent policy contains only the default parent class, and the child policy is attached under that class.

Use this model when you need both aggregate ingress enforcement and child class-level policing in the same policy hierarchy. For example, a service provider can enforce a contracted customer aggregate while individual application classes keep their own policers.

Table 4. Feature History Table
Feature Name	Release Information	Feature Description
Two-level hierarchical ingress policing	Release 26.3.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8400 [ASIC: K100]); Modular Systems (8800 [LC ASIC: P100, K100]). You can enforce an aggregate bandwidth limit for a customer, service, or traffic aggregate while preserving per-class traffic policies. This helps keep aggregate ingress traffic within contracted bandwidth limits while maintaining application-level and class-level traffic handling.

The parent policer and child policers provide different levels of control in the same ingress policy hierarchy.

Table 5. Parent and child policer roles
Aspect	Parent Policer	Child Policers
Policy level	Configured under parent class-default in the parent policy map.	Configured under classes in the child policy map that is attached to the parent class.
Primary role	Enforces the aggregate ingress rate for the policy hierarchy.	Enforce class-level or application-level committed and peak rates.
Traffic treatment	Evaluates traffic after child policing and determines the final aggregate policing behavior.	Classify packets as conform, exceed, or violate before parent policing.
Verification output	Appears as Level1 Class = class-default in show qos interface interface input output.	Appear as Level2 Class entries in show qos interface interface input output.

Two-level hierarchical ingress policing uses the same policer concepts as the existing single-rate, two-rate, and configurable-burst policer content. The difference is the hierarchy: the parent policer controls the aggregate ingress rate, and the child policers control the traffic classes under that aggregate.

Applications under a customer aggregate

A service provider applies an ingress policy to keep a customer aggregate within its contracted bandwidth. Under that aggregate, child policers continue to enforce class-level treatment for application traffic, such as voice, business-critical data, storage, telemetry, checkpointing, or AI inference traffic.

When the parent CIR is greater than or equal to the sum of the child CIRs and the parent actions support the intended excess-traffic handling, the parent policer can prioritize child-conforming traffic over child-exceed or child-violate traffic. This design helps keep traffic within the aggregate ingress contract without flattening all application classes into one policer.

What two-level hierarchical ingress policing is not

Two-level hierarchical ingress policing is not automatically child-conform-aware for every parent and child policer configuration. A parent committed information rate (CIR) lower than the sum of child CIRs, or a parent action configuration that drops traffic the design expects to transmit, does not provide the intended child-conform-aware behavior.

Household budget analogy

Think of hierarchical policing as managing a household budget. You can set spending controls for individual categories, such as groceries, travel, and entertainment, while also enforcing an overall monthly spending limit. Similarly, child policers control individual traffic classes, while the parent policer controls their aggregate traffic rate.

Benefits and scope of two-level hierarchical ingress policing

Use this reference to identify the benefits and supported scope for two-level hierarchical ingress policing.

Two-level hierarchical ingress policing provides these benefits:

Aggregate ingress enforcement: You can enforce an aggregate ingress rate for a customer, service, or traffic aggregate.
Class-level traffic control: You can preserve child policers for individual traffic classes or applications under the aggregate policer.
Child-conform-aware design: You can design policies so that the parent policer gives preference to traffic that child policers classify as conforming over child exceed or violate traffic.
Existing MQC workflow: You use the existing policy-map , service-policy , and police rate command model.
Flexible hierarchical policy design: You can combine aggregate ingress rate enforcement with class-specific traffic controls in a single hierarchical policy structure.

This capability can be useful in service provider and data center networks that carry multiple application or workload traffic classes under a common aggregate bandwidth limit.

The following table lists key reference details for two-level hierarchical ingress policing.

Table 6. Reference details for two-level hierarchical ingress policing
Reference Item	Supported Value or Behavior	Applies To	Notes
Direction	Ingress (input)	Ingress QoS policy maps	The feature enforces traffic contracts at ingress by using parent and child policers.
Parent policy scope	Parent class-default	Parent policy map	The parent policy contains only the default parent class. Attach the child policy under this class and configure the parent policer under the same class.
Child policy scope	Child classes with 1R2C or 2R3C policers	Child policy map	Child policers continue to classify traffic as conform, exceed, or violate before parent policing.
Interface scope	Physical main interfaces and subinterfaces, bundle main interfaces and subinterfaces	Layer 2 and Layer 3 interface scenarios	This scope reflects the supported interface coverage for Cisco IOS XR Release 26.3.1.
Parent policer variants	1R3C parent, 2R3C parent, and 1R2C parent with user-configured burst	Parent policer under parent class-default	A single-rate parent policer is 1R3C by default. You can configure a 1R2C parent policer by using police rate with a user-defined burst value. You can configure a 2R3C parent policer by using police rate with the peak-rate keyword to specify the peak information rate (PIR).
Parent policer processing	Parent policing occurs after child policing	Packets not dropped by child policers	The child policer result is available to the parent policer when the parent policer evaluates the aggregate traffic.

Guidelines and restrictions for two-level hierarchical ingress policing

Configure the parent policer under parent class-default

Configure the parent policer under the parent class-default class.

Use only the parent class-default class in the parent policy map.
Attach the child policy map under the parent class-default class by using service-policy .
Configure the parent policer under the same parent class-default class.

This guideline applies to two-level hierarchical ingress policing.

For two-level hierarchical ingress policing, parent policer support is delivered for the default parent class.

The parent policer appears as Level1 Class = class-default in show qos interface interface input output.

Apply the parent policy in the input direction

Apply the parent policy map to the interface in the input direction.

This guideline applies when you attach a parent policy map that contains a parent policer and a child service policy to a supported interface.

Two-level hierarchical ingress policing is an ingress QoS feature.

The parent and child policers are programmed for the input policy on the interface.

Attach the parent policy by using service-policy input parent-policy-name .

Use supported platforms and interfaces

Configure two-level hierarchical ingress policing only on supported Cisco 8000 Series routers and supported interface types.

Use this feature on A100, K100, and P100- based Cisco 8000 Series routers.
Use this feature on supported physical main interfaces and subinterfaces, and on supported bundle main interfaces and bundle subinterfaces.

This guideline applies when you attach a parent policy map with a parent policer to an interface.

If you apply a policy with a parent policer to an unsupported fixed system or line card, the commit fails and the router displays this error in show configuration failed output: !!% 'DPA_QOSEA' detected the 'warning' condition 'Hierarchical policers are not supported.'

Use a supported Cisco 8000 Series router and supported interface type, or remove the parent policer from the policy.

Configure child-conform-aware policies deliberately

Configure the parent committed information rate (CIR) greater than or equal to the sum of the child CIRs when you want child-conform-aware behavior.

Configure child policers for the child classes that must participate in child-conform-aware behavior.
Configure exceed-action transmit on the parent policer when the design requires the parent policer to transmit child exceed traffic.

This guideline applies to policies designed to prioritize child-conforming traffic over child exceed or violate traffic.

A child-conform-aware parent policer honors the child policer classification when deciding whether to admit traffic.

If the parent CIR is lower than the sum of the child CIRs, the configuration is allowed, but the parent policer does not provide child-conform-aware behavior. Parent policing behavior is also not child-conform-aware if exceed-action transmit is not configured on the parent policer. Child-conform-aware behavior is not possible when one or more child classes are unpoliced.

Adjust the parent CIR, child CIRs, child policer coverage, or parent policer actions so that the configured policy matches the intended child-conform-aware behavior.

Align child transmit actions with parent transmit actions

Do not configure a child policer exceed-action transmit action when the parent policer has the corresponding drop action.

This guideline applies when a child policer is configured to transmit exceed traffic under a parent policer.

A parent drop action overrides the corresponding child transmit action.

When the child policer action has no effect because the parent policer overwrites it, the router displays a system message such as: %QOS-DPA_QOSEA-5-CHILD_POLICER_ACTION_HAS_NO_EFFECT : In policy-map parent, the class-default child class policer's configured exceed action has no effect, the action is unconditionally overwritten by the parent policer drop action

If the design requires child exceed traffic to be transmitted, configure the corresponding parent policer action to transmit. Otherwise, remove the child transmit action if you do not want to configure an action that the parent policer overrides.

If the child policer is configured with exceed-action transmit and the parent policer is configured with exceed-action drop, child transmit and drop stats may be inaccurate. The child policer counts the exceeding packets as transmitted, even though those packets are later dropped by the parent policer.

Plan discard-class marking at the parent policer

Do not rely on child policer set discard-class marking when a parent policer is configured.

This guideline applies when a child policer action sets discard-class in a two-level hierarchical ingress policing policy.

The parent policer sets the final discard-class value and unconditionally overwrites the child policer discard-class marking.

When the child policer discard-class action has no effect because the parent policer overwrites it, the router displays a system message such as: %QOS-DPA_QOSEA-5-CHILD_POLICER_ACTION_HAS_NO_EFFECT : In policy-map parent, the class-default child class policer's 'set discard-class' exceed action has no effect, the action is unconditionally overwritten by the parent policer

Replace the child set discard-class action with the transmit action to avoid the QOS-DPA_QOSEA-5-CHILD_POLICER_ACTION_HAS_NO_EFFECT system message.

Interpret child policer statistics carefully

Interpret child policer statistics carefully because parent policing can affect child policer counters in a two-level hierarchical ingress policing policy.

The configured policer actions and final traffic throughput are as expected. However, child policer counters can be inaccurate in these scenarios:

A child policer is configured with exceed-action transmit, and the parent policer is configured with exceed-action drop. In this scenario, the child policer transmit and drop counters may be inaccurate. The child policer counts the exceeding packets as transmitted, even though the parent policer later drops those packets.
The parent policer is congested, and one of these rate conditions is true: the parent committed information rate (CIR) is lower than the sum of the child policer CIRs, or the parent peak information rate (PIR) is lower than the sum of the child policer PIRs. In this scenario, the child policer conform, exceed, and transmit counters may be inaccurate.

Parent policer congestion occurs when the sum of the child conforming traffic rates is greater than the configured parent CIR, or when the sum of the child exceeding traffic rates is greater than the configured parent PIR.

In the parent policer congestion scenario, child policer conform, exceed, and transmit counters may be higher than expected for the child policer configuration. These counters may be close to the child matched counters, depending on traffic patterns. The child matched counters remain accurate.

Use show policy-map interface <interface><input> to review parent policer statistics and child policer statistics together when you verify policy behavior.

Configure two-level hierarchical ingress policing

Use this task to configure a two-level hierarchical ingress policing policy for a customer, service, or traffic aggregate.

The parent policer enforces the aggregate ingress rate.
The child policers enforce per-class committed and peak rates under the parent policer.

This example configures four child classes under a parent policer. The child committed information rates (CIRs) are 1 Gbps, 2 Gbps, 6 Gbps, and 7 Gbps. The parent CIR is 16 Gbps, which equals the sum of the child CIRs.

The complete configuration in this task uses a two-rate, three-color (2R3C) parent policer with a 16 Gbps committed information rate (CIR) and a 20 Gbps peak information rate (PIR). For a one-rate, three-color (1R3C) parent policer, retain the same child CIRs and configure the parent with a 16 Gbps CIR without a peak rate. The two variants therefore use the same child policing rates but apply different rate models at the parent level.

Replace the class names, policy-map names, interface, match criteria, and policer rates with values for your network.

Before you begin

Verify that your Cisco 8000 Series router supports two-level hierarchical ingress policing.
Identify the interface where you want to apply the parent policy map in the input direction.
Identify the child traffic classes and the committed or peak rates that each class requires.
Use only the parent class-default class in the parent policy map.
Configure the parent CIR greater than or equal to the sum of the child CIRs when you want child-conform-aware behavior.

Follow these steps to configure two-level hierarchical ingress policing.

Procedure

Enter global configuration mode.
Example:
```
Router# configure
```

Create class maps to identify the child traffic classes.

Example:

Router(config)# class-map match-all IN_CMAP_DSCP_56
Router(config-cmap)# match dscp 56
Router(config-cmap)# exit
Router(config)# class-map match-all IN_CMAP_DSCP_48
Router(config-cmap)# match dscp 48
Router(config-cmap)# exit
Router(config)# class-map match-any IN_CMAP_DSCP_40
Router(config-cmap)# match dscp 40
Router(config-cmap)# exit

This example uses DSCP values as the match criteria. Use the match criteria that apply to your QoS design.

The class maps identify the child traffic classes that the child policy map polices.

Create the child policy map and configure child policers.

Example:

Router(config)# policy-map IN_4_CHILD_TEST
Router(config-pmap)# class IN_CMAP_DSCP_56
Router(config-pmap-c)# set traffic-class 7
Router(config-pmap-c)# police rate 1 gbps
Router(config-pmap-c)# exit
Router(config-pmap)# class IN_CMAP_DSCP_48
Router(config-pmap-c)# set traffic-class 6
Router(config-pmap-c)# police rate 2 gbps
Router(config-pmap-c)# exit
Router(config-pmap)# class IN_CMAP_DSCP_40
Router(config-pmap-c)# set traffic-class 5
Router(config-pmap-c)# police rate 6 gbps peak-rate 20 gbps
Router(config-pmap-c-police)# exceed-action transmit
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# class class-default
Router(config-pmap-c)# police rate 7 gbps peak-rate 20 gbps
Router(config-pmap-c-police)# exceed-action transmit
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map

This child policy map uses the 2R3C parent policer example. For the 1R3C parent policer variant, use peak-rate 16 gbps for the two-rate child policers in classes IN_CMAP_DSCP_40 and class-default .

The child policy map defines per-class policers and marks traffic classes before parent policing.

Create the parent policy map, attach the child policy, and configure the parent policer.

Example:

Router(config)# policy-map IN_PARENT_4_CHILD_TEST
Router(config-pmap)# class class-default
Router(config-pmap-c)# service-policy IN_4_CHILD_TEST
Router(config-pmap-c)# police rate 16 gbps peak-rate 20 gbps
Router(config-pmap-c-police)# exceed-action transmit
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map

This example configures a 2R3C parent policer. To configure the 1R3C parent policer variant, use police rate 16 gbps with exceed-action transmit under the parent class-default class.

The parent policy map contains the child policy and the parent policer under parent class-default .

Apply the parent policy map to the interface in the input direction.
Example:
```
Router(config)# interface HundredGigE0/0/0/3
Router(config-if)# service-policy input IN_PARENT_4_CHILD_TEST
```
The input direction is the ingress direction.

The router applies the parent ingress QoS policy to the interface.

Commit the configuration.

Example:

Router(config-if)# commit
Router(config-if)# end

Verify the configured parent and child policy hierarchy.

Example:

Router# show policy-map pmap-name IN_PARENT_4_CHILD_TEST detail
class-map match-any class-default
 end-class-map
!
class-map match-all IN_CMAP_DSCP_56
 match dscp 56
 end-class-map
!
class-map match-all IN_CMAP_DSCP_48
 match dscp 48
 end-class-map
!
class-map match-any IN_CMAP_DSCP_40
 match dscp 40
 end-class-map
!
policy-map IN_4_CHILD_TEST
 class IN_CMAP_DSCP_56
  set traffic-class 7
  police rate 1 gbps
  !
 !
 class IN_CMAP_DSCP_48
  set traffic-class 6
  police rate 2 gbps
  !
 !
 class IN_CMAP_DSCP_40
  set traffic-class 5
  police rate 6 gbps peak-rate 20 gbps
   exceed-action transmit
  !
 !
 class class-default
  police rate 7 gbps peak-rate 20 gbps
   exceed-action transmit
  !
 !
 end-policy-map
!
policy-map IN_PARENT_4_CHILD_TEST
 class class-default
  service-policy IN_4_CHILD_TEST
  police rate 16 gbps peak-rate 20 gbps
   exceed-action transmit
  !
 !
 end-policy-map
!

The output confirms that the child policy map is attached under parent class-default and that the parent policer is configured under the same class.

Verify that the parent and child policers are programmed on the interface.

Example:

Router# show qos interface HundredGigE0/0/0/3 input
NOTE:- Configured values are displayed within parentheses
Interface HundredGigE0/0/0/3 ifh 0x780001b0  -- input policy
NPU Id:                        0
Total number of classes:       5
Interface Bandwidth:           100000000 kbps
Policy Name:                   IN_PARENT_4_CHILD_TEST
Accounting Type:               Layer1 (Include Layer 1 encapsulation and above)
------------------------------------------------------------------------------
Level1 Class                             =   class-default
Policer committed rate                   =   16000000 kbps (16 gbits/sec)
Policer peak rate                        =   20000000 kbps (20 gbits/sec)
Policer conform burst                    =   4096000 bytes (default)
Policer exceed burst                     =   4096000 bytes (default)
Policer conform action                   =   Just TX
Policer exceed action                    =   Just TX
Policer violate action                   =   DROP PKT

   Level2 Class                             =   IN_CMAP_DSCP_56
   New traffic class                        =   7
   Policer committed rate                   =   1000000 kbps (1 gbits/sec)
   Policer conform burst                    =   1024000 bytes (default)
   Policer conform action                   =   Just TX
   Policer exceed action                    =   DROP PKT

   Level2 Class                             =   IN_CMAP_DSCP_48
   New traffic class                        =   6
   Policer committed rate                   =   2000000 kbps (2 gbits/sec)
   Policer conform burst                    =   1024000 bytes (default)
   Policer conform action                   =   Just TX
   Policer exceed action                    =   DROP PKT

   Level2 Class                             =   IN_CMAP_DSCP_40
   New traffic class                        =   5
   Policer committed rate                   =   6000000 kbps (6 gbits/sec)
   Policer peak rate                        =   20000000 kbps (20 gbits/sec)
   Policer conform action                   =   Just TX
   Policer exceed action                    =   Just TX
   Policer violate action                   =   DROP PKT

   Level2 Class                             =   class-default
   Policer committed rate                   =   7000000 kbps (7 gbits/sec)
   Policer peak rate                        =   20000000 kbps (20 gbits/sec)
   Policer conform action                   =   Just TX
   Policer exceed action                    =   Just TX
   Policer violate action                   =   DROP PKT

The parent policer appears as Level1 Class = class-default . The child policers appear as Level2 Class entries.

For the 1R3C parent policer variant, the parent Level1 Class = class-default output displays the 16 Gbps committed rate and does not display a parent peak rate. The two-rate child classes display 16 Gbps as their peak rate.

The output confirms that the parent and child policers are programmed on the input policy.

Verify parent and child policer statistics.

Example:

Router#<userinput>show policy-map interface HundredGigE0/0/0/3 input</userinput>

HundredGigE0/0/0/3 input: IN_PARENT_4_CHILD_TEST

Class class-default
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :          6036378230/6036378230000        98038979
    Transmitted         :          1218109401/1218109401000        19768818
    Total Dropped       :          4818268829/4818268829000        78270161
  Policing statistics                (packets/bytes)     (rate - kbps)
    Policed(conform)    :           973485880/973485880000         15798604
    Policed(exceed)     :           244623521/244623521000         3970214
    Policed(violate)    :          4818268829/4818268829000        78270161
    Policed and dropped :          4818268829/4818268829000

  Policy IN_4_CHILD_TEST Class IN_CMAP_DSCP_56
    Classification statistics          (packets/bytes)     (rate - kbps)
      Matched             :          1509094690/1509094690000        24509737
      Transmitted         :            60817814/60817814000          987093
      Total Dropped       :          1448276876/1448276876000        23522644
    Policing statistics                (packets/bytes)     (rate - kbps)
      Policed(conform)    :            60817814/60817814000          987093
      Policed(exceed)     :          1448276876/1448276876000        23522644
      Policed(violate)    :                   0/0                    0
      Policed and dropped :          1448276876/1448276876000
      Policed and dropped(parent policer)  : 0/0

  Policy IN_4_CHILD_TEST Class IN_CMAP_DSCP_48
    Classification statistics          (packets/bytes)     (rate - kbps)
      Matched             :          1509094800/1509094800000        24509747
      Transmitted         :           121696005/121696005000         1975211
      Total Dropped       :          1387398795/1387398795000        22534536
    Policing statistics                (packets/bytes)     (rate - kbps)
      Policed(conform)    :           121696005/121696005000         1975211
      Policed(exceed)     :          1387398795/1387398795000        22534536
      Policed(violate)    :                   0/0                    0
      Policed and dropped :          1387398795/1387398795000
      Policed and dropped(parent policer)  : 0/0

  Policy IN_4_CHILD_TEST Class IN_CMAP_DSCP_40
    Classification statistics          (packets/bytes)     (rate - kbps)
      Matched             :          1509094905/1509094905000        24509746
      Transmitted         :          1509094905/1509094905000        24509746
      Total Dropped       :                   0/0                    0
    Policing statistics                (packets/bytes)     (rate - kbps)
      Policed(conform)    :           365170865/365170865000         5926650
      Policed(exceed)     :          1143924040/1143924040000        18583096
      Policed(violate)    :                   0/0                    0
      Policed and dropped :                   0/0
      Policed and dropped(parent policer)  : 0/0

  Policy IN_4_CHILD_TEST Class class-default
    Classification statistics          (packets/bytes)     (rate - kbps)
      Matched             :          1509095016/1509095016000        24509742
      Transmitted         :          1509095016/1509095016000        24509742
      Total Dropped       :                   0/0                    0
    Policing statistics                (packets/bytes)     (rate - kbps)
      Policed(conform)    :           425801627/425801627000         6909638
      Policed(exceed)     :          1083293389/1083293389000        17600104
      Policed(violate)    :                   0/0                    0
      Policed and dropped :                   0/0
      Policed and dropped(parent policer)  : 0/0

The parent class statistics show the aggregate parent policer behavior. The child policy statistics show all four child classes: IN_CMAP_DSCP_56 , IN_CMAP_DSCP_48 , IN_CMAP_DSCP_40 , and class-default . On Cisco 8000 Series routers, the Policed and dropped (parent policer) field is not supported and always displays 0/0 .

Child policer statistics can be inaccurate in specific scenarios because of parent policing behavior. The configured policer behavior and throughput are as expected, but review parent policer statistics and child policer statistics together when you verify policy behavior. For details, see Guidelines and restrictions for two-level hierarchical ingress policing.

The interface has an ingress QoS policy that enforces an aggregate parent policer rate while preserving per-class child policer behavior.

Use these traffic-rate outcomes to interpret the verified policy behavior.

Table 7. Verified behavior for parent policer variants
Parent Policer Variant	Traffic Condition	Observed Behavior	Statistics Note
1R3C parent policer	25 Gbps ingress rate for all four child classes.	All four child classes transmit at their CIRs: 1 Gbps, 2 Gbps, 6 Gbps, and 7 Gbps. The parent policer transmits at its 16 Gbps CIR.	Transmitted-rate statistics for child classes IN_CMAP_DSCP_40 and class-default , which use exceed-action transmit , can be inaccurate.
1R3C parent policer	The ingress rate is reduced to 1 Gbps for classes IN_CMAP_DSCP_48 and IN_CMAP_DSCP_40 .	Class IN_CMAP_DSCP_56 still transmits at its 1 Gbps CIR. Classes IN_CMAP_DSCP_48 and IN_CMAP_DSCP_40 transmit at their 1 Gbps ingress rate. Class class-default uses 6 Gbps of excess bandwidth and transmits at 13 Gbps. The parent policer transmits at its 16 Gbps CIR.	Transmitted-rate statistics for child class class-default can be inaccurate. Transmitted-rate statistics for child class IN_CMAP_DSCP_40 are accurate in this case because all packets are conforming.
2R3C parent policer	25 Gbps ingress rate for all four child classes.	Classes IN_CMAP_DSCP_56 and IN_CMAP_DSCP_48 transmit at their 1 Gbps and 2 Gbps CIRs. Classes IN_CMAP_DSCP_40 and class-default share 4 Gbps of excess bandwidth and each transmits about 2 Gbps above its CIR. The parent policer transmits at its 20 Gbps PIR.	Transmitted-rate statistics for child classes IN_CMAP_DSCP_40 and class-default , which use exceed-action transmit , can be inaccurate.
2R3C parent policer	The ingress rate is reduced to 1 Gbps for class IN_CMAP_DSCP_48 and to 3 Gbps for class class-default .	Class IN_CMAP_DSCP_56 still transmits at its 1 Gbps CIR. Classes IN_CMAP_DSCP_48 and class-default transmit at their 1 Gbps and 3 Gbps ingress rates. Class IN_CMAP_DSCP_40 uses all 9 Gbps of excess bandwidth and transmits at 15 Gbps. The parent policer transmits at its 20 Gbps PIR.	Transmitted-rate statistics for child class IN_CMAP_DSCP_40 can be inaccurate. Transmitted-rate statistics for child class class-default are accurate in this case because all packets are conforming.

What to do next

After you verify the policy, use clear qos counters interface interface before another verification run if you need fresh parent and child policer statistics.

Configurable burst values for ingress QoS policers

Configurable burst values for ingress QoS policers is a QoS policing capability that

enables configurable conform and exceed burst values for ingress policers
applies to supported 1R2C, 2R3C, and parent 1R3C policers, and
uses default burst values when the burst values are not explicitly configured.

Table 8. Feature History Table
Feature Name	Release Information	Feature Description
Configurable burst values for ingress QoS policers	Release 26.2.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100, A100], 8700 [ASIC: P100, K100]); Centralized Systems (8400 [ASIC: K100]); Modular Systems (8800 [LC ASIC: P100]) You can now configure conform and exceed burst values for ingress QoS policers instead of relying only on platform-calculated default burst values. This capability enables ingress policers to have granular control over short-term traffic bursts for efficient traffic congestion management. If you do not configure burst values, the router uses the default burst values. The feature introduces these changes: CLI: The burst and peak-burst keywords are introduced in the police rate command. YANG Data Model: Cisco-IOS-XR-8000-qos-oper.yang Cisco-IOS-XR-qos-ma-oper.yang (see GitHub, YANG Data Models Navigator)

Guidelines for configuring burst values for ingress QoS policers

Supported interfaces

User-configurable burst values for ingress QoS policers are supported on physical, VLAN, bundle, PWHE, and BVI interfaces.

Burst value configuration defaults

If you do not explicitly configure a burst value, the policer uses the platform-calculated default burst value.

Configure burst values for ingress QoS policers

Before you begin

Before you begin, ensure that the QoS policy is applied in the ingress direction on a supported interface and platform.

Procedure

Configure a class map for traffic classification using the ingress policer.

Example:

Router(config)# class-map match-any INGRESS_POLICER_CLASS
Router(config-cmap)# match traffic-class 5
Router(config-cmap)# end-class-map

Configure an ingress policy map with explicit burst values.

Use the burst keyword to configure the conform burst value. For a 2R3C policer, use the peak-burst keyword to configure the exceed burst value.

Configure a 1R2C policer with an explicit conform burst value.

Router(config)# policy-map INGRESS_POLICER_BURST
Router(config-pmap)# class INGRESS_POLICER_CLASS
Router(config-pmap-c)# police rate 5 gbps burst 400 kbytes
Router(config-pmap-c-police)# conform-action transmit
Router(config-pmap-c-police)# exceed-action drop
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map

Configure a 2R3C policer with explicit conform and exceed burst values.

Router(config)# policy-map INGRESS_POLICER_BURST
Router(config-pmap)# class INGRESS_POLICER_CLASS
Router(config-pmap-c)# police rate 1 gbps burst 4 mbytes peak-rate 2 gbps peak-burst 8 mbytes
Router(config-pmap-c-police)# conform-action transmit
Router(config-pmap-c-police)# exceed-action transmit
Router(config-pmap-c-police)# violate-action drop
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map

Apply the policy map to the ingress interface.

Example:

Router(config)# interface HundredGigE0/0/0/1
Router(config-if)# service-policy input INGRESS_POLICER_BURST
Router(config-if)# commit

Verify the ingress policer configuration.

Use either command depending on whether you want to verify the programmed QoS values or view policing statistics.

Verify the programmed burst values on the interface.

Router# show qos interface HundredGigE0/0/0/1 input

Interface HundredGigE0/0/0/1 -- input policy
Policy Name: INGRESS_POLICER_BURST
------------------------------------------------------------------------------
Level1 Class                             =   INGRESS_POLICER_CLASS
Policer committed rate                   =   5000000 kbps (5 gbits/sec)
Policer conform burst                    =   400000 bytes

Verify policing statistics for the policy applied to the interface.

Router# show policy-map interface HundredGigE0/0/0/1 input

HundredGigE0/0/0/1 input: INGRESS_POLICER_BURST

Class INGRESS_POLICER_CLASS
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :                   0/0                    0
    Transmitted         :                   0/0                    0
    Total Dropped       :                   0/0                    0
  Policing statistics                (packets/bytes)     (rate - kbps)
    Policed(conform)    :                   0/0                    0
    Policed(exceed)     :                   0/0                    0
    Policed(violate)    :                   0/0                    0
    Policed and dropped :                   0/0                    0

The command output displays the configured burst values or the policing statistics for the ingress policer.

Egress QoS policing

Egress QoS policing is a QoS congestion management feature that

meters outbound Layer 2 and Layer 3 traffic against configured rate and burst limits
applies to outbound traffic on interfaces with egress feature capability
supports flat and two-level hierarchical policing, and
applies conform, exceed, or violate actions according to the configured policer mode.

Table 9. Feature History Table
Feature Name	Release Information	Feature Description
Egress QoS policing	Release 26.3.1	Introduced in this release on: Fixed Systems (8700 [ASIC: K100])(select variants only); Centralized Systems (8400 [ASIC: K100])(select variants only); Modular Systems (8800 [LC ASIC: P100, K100])(select variants only) You can now enforce bandwidth limits on outbound Layer 2 and Layer 3 traffic and configure burst values to control how the policer handles short-term traffic bursts on interfaces with egress feature capability enabled. This capability helps prevent excessive outbound traffic from affecting downstream network resources while providing granular control over permitted burst traffic. This capability is achieved by applying a policy map containing a single-rate two-color (1R2C) or two-rate three-color (2R3C) policer to a supported interface in the output direction. If you do not configure burst values, the router uses platform-calculated default values. Egress feature capability is enabled by default on P100-based routers. On K100-based routers, you must enable egress feature capability by configuring the `hw-module profile edge-mode` CLI command. This feature is supported on: 8712-MOD-M  8711-48Z-M 8404-SYS-D 88-LC1-12TH24FH-E 88-LC1-52Y8H-EM

Flat egress policing

A flat egress policer is a QoS policer that meters a traffic class at a single policy level. Each class in the policy map can contain a policer that applies the configured rate, burst, and traffic actions.

Flat egress policing supports the following color-blind policer modes:

Single-rate two-color (1R2C)
Two-rate three-color (2R3C)

Two-level hierarchical egress policing

A two-level hierarchical egress policer is a QoS policy structure that

uses a parent policer to enforce an aggregate outbound traffic rate
uses child policers to enforce rate limits for individual traffic classes, and
attaches the child policy under the class-default class of the parent policy.

The parent and child policers provide separate levels of control. The parent policer meters the aggregate traffic, while the child policers meter the traffic that matches individual classes within that aggregate.

Configurable burst values on egress policer

A configurable burst value is a policer setting that specifies how much traffic can arrive in a short interval before the policer assigns a different policing result.

The burst value specifies the committed burst allowance. The peak-burst value specifies the additional burst allowance used by a supported three-color policer.

Explicit burst values provide greater control over short-term traffic bursts. If you do not configure the burst values, the router calculates and applies default values.

Benefits of egress QoS policing

Use these benefits to evaluate egress policing for outbound traffic management.

Downstream resource protection: Limits excessive outbound traffic before it reaches downstream network resources.
Aggregate and class-level control: Combines a parent policer for an aggregate traffic limit with child policers for individual traffic classes.
Short-term burst control: Uses configurable burst allowances to accommodate expected traffic bursts without changing the sustained traffic rate.
Flexible policing models: Provides 1R2C and 2R3C modes for different rate-control and traffic-treatment requirements.
Layer 2 and Layer 3 coverage: Applies egress policing to supported Layer 2 and Layer 3 traffic.
Operational visibility: Reports programmed policer values and conform, exceed, violate, and drop statistics through QoS operational commands.

Limitations for egress QoS policing

Control-packet drops with a congested default-class policer

When a flat or two-level hierarchical egress policy has a policer configured on class-default and that class is congested, control packets, such as Bidirectional Forwarding Detection (BFD) and Connectivity Fault Management (CFM) packets, can be dropped by the policer. These drops can result in control session flaps and affect end-to-end traffic.

Configure egress QoS policing with configurable burst values

Enforce rate and burst limits on outbound traffic at a single policy level or at aggregate and child-class levels.

Before you begin

Ensure that the target interface has egress feature capability on a supported router variant.
Identify the Layer 2 or Layer 3 traffic that you want to police.
Determine whether the traffic requires a flat policy or a two-level hierarchical policy.
Determine the required policing mode, rates, burst values, and actions.

Procedure

Create the child policy map and configure the child policers.

Example:

Router# configure
Router(config)# policy-map policymap_2_0_1_0
Router(config-pmap)# class classmap_2_0_1_1_0
Router(config-pmap-c)# set traffic-class 1
Router(config-pmap-c)# police rate 1770000 kbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# class classmap_2_0_1_2_0
Router(config-pmap-c)# set traffic-class 2
Router(config-pmap-c)# police rate 1770000 kbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# class classmap_2_0_1_3_0
Router(config-pmap-c)# set traffic-class 3
Router(config-pmap-c)# police rate 1770833 kbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# class classmap_2_0_1_4_0
Router(config-pmap-c)# set traffic-class 4
Router(config-pmap-c)# police rate 1770000 kbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# class classmap_2_0_1_5_0
Router(config-pmap-c)# set traffic-class 5
Router(config-pmap-c)# police rate 1770000 kbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# class classmap_2_0_1_6_0
Router(config-pmap-c)# set traffic-class 6
Router(config-pmap-c)# police rate 1770000 kbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# class classmap_2_0_1_7_0
Router(config-pmap-c)# set traffic-class 7
Router(config-pmap-c)# police rate 1770000 kbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# class class-default
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map

The child class-default has no explicitly configured policer in this example. The parent default class is configured separately.

Configure explicit burst values for a child policer.

Use burst to configure the conform burst value. For a 2R3C policer, use peak-burst to configure the exceed burst value.

Configure a 1R2C policer with an explicit conform burst value.

Router(config)# policy-map policymap_2_0_1_0
Router(config-pmap)# class classmap_2_0_1_1_0
Router(config-pmap-c)# police rate 500000 kbps burst 563200 bytes
Router(config-pmap-c-police)# conform-action transmit
Router(config-pmap-c-police)# exceed-action drop
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map

Configure a 2R3C policer with explicit conform and exceed burst values.

Router(config)# policy-map policymap_2_0_1_0
Router(config-pmap)# class classmap_2_0_1_1_0
Router(config-pmap-c)# police rate 500000 kbps burst 563200 bytes peak-rate 2000000 kbps peak-burst 4999936 bytes
Router(config-pmap-c-police)# conform-action transmit
Router(config-pmap-c-police)# exceed-action transmit
Router(config-pmap-c-police)# violate-action drop
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map

Create the parent policy map, attach the child policy, and configure the parent policer.

Example:

Router(config)# policy-map policymap_2_1_0
Router(config-pmap)# class class-default
Router(config-pmap-c)# service-policy policymap_2_0_1_0
Router(config-pmap-c)# police rate 7083000 kbps
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map

Apply the parent policy to the output interface and commit the configuration.
Example:
```
Router(config)# interface HundredGigE0/1/0/0/1
Router(config-if)# service-policy output policymap_2_1_0
Router(config-if)# commit
Router(config-if)# end
```
The committed output policy attaches the parent and child policy hierarchy to the interface.

Verify the parent and child policy map attachments.

Example:

Router# show policy-map targets

1) Policymap: policymap_2_0_1_0    Type: qos
     Targets (applied as main policy):
     Total targets: 0

     Targets (applied as child policy):
       HundredGigE0/1/0/0/1 output
     Total targets: 1

2) Policymap: policymap_2_1_0    Type: qos
     Targets (applied as main policy):
       HundredGigE0/1/0/0/1 output
     Total targets: 1

     Targets (applied as child policy):
     Total targets: 0

Confirm that the parent policy is attached as the main policy and the child policy is attached as a child policy to the same output interface.

Verify the programmed policer values.

Example:

Router# show qos interface HundredGigE0/1/0/0/1 output

NOTE: Configured values are displayed within parentheses
Interface HundredGigE0/1/0/0/1 -- output policy
Policy Name: policymap_2_1_0

Level1 Class                 = class-default
Policer committed rate       = 7083000 kbps (7083 mbits/sec)
Policer conform burst        = 8192000 bytes (default)
Policer exceed burst         = 8192000 bytes (default)
Policer conform action       = Just TX
Policer exceed action        = DROP PKT
Policer violate action       = DROP PKT

  Level2 Class               = classmap_2_0_1_1_0
  Policer committed rate     = 1770000 kbps (1770 mbits/sec)
  Policer conform burst      = 1024000 bytes (default)
  Policer conform action     = Just TX
  Policer exceed action      = DROP PKT

  Level2 Class               = classmap_2_0_1_2_0
  Policer committed rate     = 1770000 kbps (1770 mbits/sec)
  Policer conform burst      = 1024000 bytes (default)
  Policer conform action     = Just TX
  Policer exceed action      = DROP PKT

Locate the parent class-default under Level1 and the child classes under Level2. Review configured and programmed values where both are displayed. Default burst values are platform-calculated and are not explicit configuration commands.

If you selected a burst option in Step 2, check the first child class against that option's rate and burst values instead of the baseline excerpt. For the 2R3C option, also check the peak rate and exceed burst.

Verify the policing statistics.

Example:

Router# show policy-map interface HundredGigE0/1/0/0/1 output

HundredGigE0/1/0/0/1 output: policymap_2_1_0

Class class-default
  Classification statistics (packets/bytes) (rate - kbps)
    Matched             : ...
    Transmitted         : ...
    Total Dropped       : ...
  Policing statistics (packets/bytes) (rate - kbps)
    Policed(conform)    : ...
    Policed(exceed)     : ...
    Policed(violate)    : ...
    Policed and dropped : ...

  Policy policymap_2_0_1_0 Class classmap_2_0_1_1_0
    Classification statistics (packets/bytes) (rate - kbps)
      Matched             : ...
      Transmitted         : ...
      Total Dropped       : ...
    Policing statistics (packets/bytes) (rate - kbps)
      Policed(conform)    : ...
      Policed(exceed)     : ...
      Policed(violate)    : 0/0  0
      Policed and dropped : ...
      Policed and dropped(parent policer) : 0/0

The output interface has a parent and child policing policy. The verification commands identify its attachment and display programmed policing values and traffic statistics.