Ingress subinterface traffic policing

To determine compliance with the traffic profile, each policer uses two token buckets:

• CIR bucket (Tc)

  Tc has a fill rate equal to the CIR and a maximum depth of CBS bytes (with current depth at time t of C bytes).

• PIR bucket (Tp)

  Tp has a fill rate equal to the PIR and a maximum depth of MBS bytes (with current depth at time t of P bytes).

Initially (at time 0) the token buckets Tp and Tc are full, so that P = MBS and C = CBS. From then onwards, each bucket is continuously refilled at the rate of PIR and CIR.

The following diagram shows the token bucket process for each packet that arrives at the policer.

Each policer instance operates in a nonconfigurable color-aware mode. When a packet of size B bytes arrives at time t, the policer processes the packet as follows:

• If the packet is precolored as red or if P – B < 0, the packet is red (violating) and no tokens are drained from Tp or Tc. The policer either drops the packet or updates its drop probability as defined in the policer template (low, medium, or high).
• If the packet is precolored as yellow or if C – B < 0, the packet is yellow (exceeding), and B bytes are drained from Tp. The policer assigns the packet an updated drop probability as defined in the policer template (low, medium, or high).
• Otherwise, the packet is green (conforming), and B bytes are drained from Tp and Tc. The policer forwards the packet with no modifications, and drop probability remains unchanged (low).

Pre-coloring based on drop probability

All packets arrive at the input of the policer with an assigned drop probability, based on the DSCP classifier policy. Each policer treats these packets as pre-colored as described in the preceding section. The following table describes the colors associated with each packet based on the drop probability at input.

To assign policers to subinterfaces, you must first configure policer templates. A policer template specifies a group of 1 to 32 policers, each with a specified sequence ID. Policers with lower sequence IDs are evaluated before policers with higher sequence IDs. You can configure each policer to match a forwarding class and optionally, forwarding type.

You can apply policer templates to the following subinterface types:

• bridged subinterfaces of Ethernet ports or LAGs on a mac-vrf network instance

• routed subinterfaces of Ethernet ports or LAGs on either the default network instance or an ip-vrf network instance

IRB subinterface

Attachment of a policer template to an IRB subinterface is not currently supported.

Multiple subinterfaces referring to same policer template

Subinterfaces cannot share the same policer. If two or more different subinterfaces (routed or bridged) of the same port, same line card, or same chassis refer to the same policer template, each subinterface applies a separate instance of the template, consuming an equal number of TCAM entries.

Policing on LAG subinterfaces

Policers applied to subinterfaces are instantiated on each pipeline. The 7220 IXR-D2/D3/D2L/D3L platforms each have two pipelines, with half the ports mapping to pipeline 0 and the other half of the ports mapping to pipeline 1. The 7220 IXR-D4 has four pipelines and 7220 IXR-D5 has eight pipelines, with each pipeline supporting a variable number of ports.

These pipelines impact policing of ingress traffic on LAG subinterfaces as follows:

• The actual PIR for LAG subinterface traffic is: N × the quantized PIR, where N is the number of pipelines spanned by the LAG.
• The actual CIR for LAG subinterface traffic is: N × the quantized CIR, where N is the number of pipelines spanned by the LAG.

For each policer template, you can choose between two statistics modes:

• violating-focus

  Collects the number of:

  • accepted (not dropped) packets and octets (counting all drop probabilities at policer output).
  • violating packets and octets.

• forwarding-focus

  Collects the number of:

  • committed packets and octets (conforming traffic only).
  • accepted (not dropped) exceeding packets and octets.

The following considerations apply to traffic policers and Ternary Content Addressable Memory (TCAM) resources:

• If a policer template is configured on a subinterface, and any linecard supporting that subinterface cannot program all the TCAM rules of all the policers defined in that policer template, then policing is not activated on the subinterface. In this case, the info from state output for the subinterface shows no policer template bound to the subinterface.
• When a policer template bound to a subinterface is in a failed state due to TCAM resource exhaustion, all further configuration of the policer template fails except for deletion of policers from the policer template and unbinding the policer template from a subinterface.