Restrictions for Hierarchical Color-Aware Policing
The following restrictions apply to the Hierarchical Color-Aware Policing feature:
•
Color-aware class maps support only QoS group matching.
•
Color-aware statistics are not supported, only existing policer statistics.
•
Color-aware class map removal (using the no class-mapclass-map-name command) is not allowed while
the class map is being referenced in a color-aware policer. It must be removed from all color-aware
policers (using either the no conform-colorclass-map-name or no exceed-colorclass-map-name command
first).
•
By default, the child policer is color-blind. If any control traffic is classified as default class then it may
be dropped.
•
For dual policers in HQoS policy, if parent policer is color-aware, child level policer cannot be configured
as color-aware and is rejected.
•
When parent policer is color-aware, child cannot be configured with PIR, it can only be a 1R2C policer.
•
Conform or exceed color classification should be part of child policer conform marking action.
• When parent is color aware, status of child policer which comes under red classification based on parent’s
conform and exceed class may not work properly.
•
QoS-group can be set in child policer through tablemap, but complete child class classification should
map either to conform class qos-group or exceed class qos-group.
Information About Hierarchical Color-Aware Policing
Hierarchical Order Policing
Policers are evaluated from child to parent in QoS policies. This ordering is not configurable for both ingress
and egress directions.
The following sample configuration for a simple two-level policer would result in the changed behavior shown
in the figure below:
policy-map child
class user1
police 100k
class user2
police 100k
policy-map parent
class class-default
police 150k
service-policy child
QoS: Policing and Shaping Configuration Guide (Cisco ASR 920 Series)
52
Hierarchical Color-Aware Policing
Restrictions for Hierarchical Color-Aware Policing
To Next Page
Loading...
