A policer has multiple types of input traffic and multiple possible output states for each input traffic type. These variations differ between ingress and egress.
For ingress policing, each offered packet has a priority and a profile state. The priority is used by the policer to choose either the high- or low-priority PIR threshold-be. Every offered packet is either priority high or priority low. The offered profile state defines how a packet interacts with the policers CIR bucket state. The combinations of priority and initial profile are as follows:
offered priority low, undefined profile
offered priority low, explicit profile in
offered priority low, explicit profile out
offered priority high, undefined profile
offered priority high, explicit profile in
offered priority high, explicit profile out
The possible output results for the ingress policer are:
output green (in-profile)
output yellow (out-of-profile)
output red (discard)
To conserve counter resources, the system supports a policer stat-mode command that is used to identify what counters are actually needed for the policer. Not every policer has a CIR defined, so the output green/yellow states do not exist. Also, not every policer has both high- and low-priority or explicit in-profile or out-of-profile offered traffic types. Essentially, the stat-mode command allows the counter resources to be allocated based on the accounting needs of the individual policers.
Setting the stat-mode does not modify the packet handling behavior of the policer. For example, if the configured stat-mode does not support in-profile and out-of-profile output accounting, the policer is not blocked from having a configured CIR rate. The CIR rate is enforced, but the amount of in-profile and out-of-profile traffic output from the policer is not counted separately (or maybe not at all based on the configured stat-mode).
A policer is created with minimal counters sufficient to provide total offered and total discarded (the total forwarded is computed as the sum of the offered and discarded counters). The stat-mode is defined within the sap-ingress or sap-egress QoS policy in the policer context. When defining the stat-mode, the counter resources needed to implement the mode must be available on all forwarding planes where the policer has been created using the QoS policy unless the policer instance has a stat-mode override defined. Use the tools dump resource-usage card fp command to see the resources used and available. If insufficient resources exist, the change in the mode fails without any change to the existing counters currently applied to the existing policers. If the QoS policy is being applied to a SAP or subscriber or multiservice site context and insufficient counter resources exist to implement the configured modes for the policers within the policy, the QoS policy is not applied. For SAPs, this means the previous QoS policy stays in effect. For subscribers, it could mean that the subscriber host event where the QoS policy is being applied fails and the subscriber host may be blocked or removed.
A stat-mode with at least minimal stats is required before the policer can be assigned to a parent arbiter using the parent command.
Successfully changing the stat-mode for a policer causes the counters associated with the policer to reset to zero. Any collected stats on the object the policer is created on also reset to zero.
The system uses the forwarding plane counters to generate accounting statistics and for calculating the operational PIR and FIR rates for a set of children when they are managed by a policer-control-policy. Only the offered counters are used in hierarchical policing rate management. When multiple offered stats are maintained for a child policer, they are summed to derive the total offered rate for each child policer.
All ingress policers have a default CIR value of 0, meaning that by default, all packets except packets classified as profile in is output by the policer as out-of-profile. This may have a negative impact on egress marking decisions (if in-profile and out-of-profile have different marking values) and on queue congestion handling (WRED or queue drop tail decisions when out-of-profile is less preferred). The following options exist to address this potential issue:
If all packets handled by the policer must be output as in-profile by the policer, either the packet's forwarding class or subclass can be defined as profile in or the CIR on the policer can be defined as max
If some packets must be output as in-profile while others output as out-of-profile, three options exist:
The CIR may be left at '0' while mapping the packets that must be output as in-profile to a forwarding class or subclass provisioned as profile in.
The CIR may be set to max while mapping the packets that must be output as out-of-profile to a forwarding class or subclass provisioned as profile out.
Ignore the CIR on the policer and solely rely on the forwarding class or subclass profile provisioning to the correct policer CIR output.
Make sure to use the correct stat mode if the policer’s CIR is explicitly not set or is set to 0. The no-cir version of the stat-mode must be used when the CIR has a non-zero value. Also, when overriding the policer’s CIR mode, make sure to override the stat-mode instance (CIR override can be performed using SNMP access).
Ingress supported stat-modes are:
no-stats
minimal - default
offered-profile-no-cir
offered-priority-no-cir
offered-limited-profile-cir
offered-profile-cir
offered-priority-cir
offered-total-cir
offered-profile-capped-cir
offered-limited-capped-cir