Packets that are offered to an ingress policer may have three different states relative to initial profile:
Ingress policed packets are not subject to ingress queue CIR profiling within the ingress policer output queues. While the unicast and multipoint shared queues used by the system for ingress queuing of policed packets may have a CIR rate defined, this CIR rate is only used for rate-based dynamic priority scheduling purposes. The state of the CIR bucket while forwarding a packet from a policer-output-queues shared queue does not alter the packets ingress in-profile or out-of-profile state derived from the ingress policer.
Priority high and low are used in the child policer’s PIR leaky bucket to choose one of two discard thresholds (threshold-be-low and threshold-be-high) that are derived from the child policer’s mbs and high-priority-only parameters. The high threshold is directly generated by the mbs value. The low threshold is generated by reducing the mbs value by the high-priority-only percentage. A packet’s priority is determined while the packet is evaluated against the ingress classification rules in the sap-ingress QoS policy.
Packets that are offered to an egress policer may have six different states relative to their initial profile:
When an egress policer’s CIR rate is set to 0 (or not defined), the policer has no effect on the profile of packets offered to the policer. An exception to this is when enable-exceed-pir is configured under the policer. In this case, the exceed-profile state of a packet takes precedence over the hard-out/in/inplus reclassification, specifically, traffic that is reprofiled to exceed within a SAP egress policer has an exceed-profile state regardless of whether it was reclassified at egress to hard-out, hard-in, or hard-inplus.
Setting a non-zero rate for the egress policer’s CIR modifies this behavior for DSCP, IP precedence, dot1p, and DEI egress marking purposes. Hard-inplus-profile and hard-in-profile retain their inherent inplus-profile or in-profile behavior and the hard-out-of-profile and hard-exceed-profile retain their inherent out-of-profile or exceed-profile behavior.
When the egress packet state is soft-in-profile and soft-out-of-profile and the policer’s CIR is configured as non-zero, the current CIR state of the policer’s CIR bucket overrides the packet’s soft profile state. When the policer’s CIR is currently conforming, the output is in-profile. When the CIR state is currently exceeding, the output is out-of-profile.
Hard-exceed-profile packets are discarded by default by an egress policer. If enable-exceed-pir is configured, the hard-exceed-profile packets are forwarded and, when the PIR state is exceeding, all packets are forwarded with an exceed-profile state.
For egress marking decisions, the hard-inplus-profile, hard-in-profile, and hard-out-of-profile packets ignore the egress policer's CIR state. When the packet state is hard-inplus-profile or hard-in-profile, the in-profile dot1p marking is used, and when DEI marking is enabled for the packet’s forwarding class, the exceed-profile traffic is marked 0. When the packet state is hard-out-of-profile or hard-exceed-profile, the out-of-profile dot1p marking is used, unless explicit dot1p exceed-profile marking is configured, in which case the exceed-profile traffic is marked with the configured value, and when DEI marking is enabled for the packets forwarding class, the exceed-profile traffic is marked 1.
The dot1p, outerDot1p, and DEI (when DE marking is configured) reflect the CIR- and PIR-derived packet state. If the enable-dscp-prec-remarking command is enabled, the DSCP and IP precedence reflect the CIR- and PIR-derived packet state.