Dynamic policer rates and accounting statistics

By default, policer rates are configured based on Layer 2 frame length (for example, the Ethernet header plus the IP packet). This can be changed by the packet-byte-offset (PBO) command under the policer. If the policer is fed into a local queue, the PBO of the policer does not affect the PBO of the local queue it is feeding.

The rates for local subscriber queues can be independently measured based on Layer 2 or Layer 1 frame length and the queue statistics can be measured based on Layer 1, Layer 2 or Layer 3 (IP-only) frame length. The IP-only stats for queues can be configured in the sub-prof>volume-stats-type {ip|default}.

Dynamic policer (instantiated because of rate limiting or usage-monitoring action in PCC rules) statistics are not reported in RADIUS-based accounting. On egress, this has no effect on volume counters in RADIUS-based accounting, because the dynamic policers are normally fed into local queues whose statistics are reported in RADIUS-based accounting. However, on ingress, the dynamic policers are always fed into the queue-group queues which are excluded from RADIUS based accounting. The consequence is that the ingress RADIUS-based accounting lacks statistics for the traffic that is flowing via dynamic policers.

If the dynamic policer is feeding a local queue, the aggregate statistics in show commands for such queue are not reported to avoid double counting (because the traffic statistics in show commands are already reported for the dynamic policer). However, the per-queue statistics are reported in show commands, irrespective of whether the policer is mapped to the local queue or not.

To avoid losing aggregate SAP or subscriber stats in show commands, the recommendation is to have policers feed into local queues which are not already mapped to an FC. For example:

queue 4 create //Not counted since policer 2 is feeding it
exit
policer 2 create
exit
fc be create
     queue 4     //Not counted
exit
fc l1 create
     queue 4     //Not counted
exit
fc ef create
     policer 2 queue 4
exit

FC BE, FC2 L1 —> queue 4

FC EF —> policer 2, queue 4

Then, traffic from queue 4 is not counted in aggregate stats at all and consequently the aggregate accounting information is lost for FC BE and FC L1.