Ingress subinterface traffic policing

Some SR Linux-compatible hardware platforms (7220 IXR-D2/D3/D2L/D3L/D4/D5) support the ability to direct selected traffic flows to hardware policers. Traffic directed to a policer is metered to determine compliance with a traffic profile. At the output of the policer, every packet is marked with a color (green, yellow, or red) that represents whether it conforms, exceeds, or violates the traffic profile.

With a two-rate-three-color marker (RFC 2698), the traffic profile is defined using two traffic rates and their associated burst sizes:

  • Committed information rate (CIR) and committed burst size (CBS)
  • Peak information rate (PIR) and maximum burst size (MBS)

Token buckets

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.

Figure 1. Token buckets (trTCM)

Each policer instance operates in a non-configurable 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).
Note: A drop probability of medium or high increases the chance that the packet is discarded (or ECN marked) when it enters the egress queue, if that egress queue has a WRED/ECN slope.

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.

Table 1. Drop probability to color mapping
Drop probability at input Color associated at input
Low Green (conforming)
Medium Yellow (exceeding)
High Red (violating)

Policer template

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

  • On routed subinterfaces, all traffic is considered to match the unicast forwarding type, even if it is received with a broadcast destination IP.
  • Classification to forwarding class and drop probability occurs before policing in the ingress pipeline.
  • There is no ingress policing of traffic of a particular forwarding class and forwarding type if that traffic has no match in the associated policer template.

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 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.

This impacts policing of ingress traffic on LAG subinterfaces as follows:

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

Policer statistics

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

TCAM resources and scale

Note the following considerations related 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 will fail except for deletion of policers from the policer template and unbinding the policer template from a subinterface.

Configuring a subinterface traffic policer template

To configure a policer template, use the qos policer-templates command.

Note: For PIR and CIR, the configured value and the operational value can differ as a result of rate quantization in the hardware. The actual operational PIR and CIR rates used in the hardware are available in the state representation of each policer instance created from the template, using the following command: info from state interface <name> subinterface <index> qos input policers policer <sequence-id>.

Configure subinterface traffic policer

The following example configures a policer template containing one policer with sequence ID 100 that has a defined PIR, CIR, MBS, and CBS, and that matches unicast FC1 traffic. Yellow packets are marked with a drop-probability of medium, and red packets are dropped. The statistics-mode is set to violating-focus.

--{ candidate shared default }--[  ]--
# info qos
    qos {
        policer-templates {
            policer-template test-policer-1 {
                statistics-mode violating-focus
                policer 100 {
                    peak-rate-kbps 15000
                    committed-rate-kbps 10000
                    maximum-burst-size 100000
                    committed-burst-size 20000
                    forwarding-class fc1 {
                        forwarding-type [
                    exceed-action {
                        drop-probability medium
                    violate-action {
Table 2. Parameters for qos policer-templates
Parameter Definition
policer-template <name> Assigns a name to the policer template.
statistics-mode {violating-focus | forwarding-focus} (Optional) Defines the statistics mode (default: violating-focus).
policer <sequence-id> Assigns the sequence ID for the policer.
peak-rate-kbps <0 to 4294967295> Sets PIR in kbps. The minimum supported PIR is 8 kbps.
committed-rate-kbps: <0 to 4294967295> Sets CIR in kbps. The minimum supported CIR is 8 kbps.
maximum-burst-size <512 to 4294967295> Sets MBS in bytes (4294967295 bytes = 268 MB).
committed-burst-size <512 to 4294967295> Sets CBS in bytes.(4294967295 bytes = 268 MB).
forwarding-class <fc> [forwarding-type {broadcast|multicast|unicast|unknown-unicast}] (Optional) Matches the policer to the specified forwarding class and optionally, forwarding type. If no forwarding class is specified, all traffic is matched.

If traffic of a specific forwarding class has no mapping in your policer-template, it is not policed at ingress. To match any traffic that is not explicitly mapped, include a policer with no forwarding class specified (for example, as the lowest-priority policer in the template). This ensures that the policer template matches all traffic at ingress.

exceed-action drop-probability {high | low | medium} (Optional) Applies a drop-probability to yellow packets (default: drop-probability medium).
violate-action {drop | drop-probability {high | low | medium}} (Optional) Applies an action (drop packets or assign a drop-probability) to red packets (default: drop-probability high).

Assigning a traffic policer template to a subinterface

The following example applies policer template 100 to subinterface 1/2.1

Assign traffic policer template to a subinterface

--{ candidate shared default }--[  ]--
# info interface ethernet-1/2
    interface ethernet-1/2 {
        subinterface 1 {
            qos {
                input {
                    policer-templates {
                        policer-template test-policer-1

Displaying subinterface traffic policer statistics

The following example displays traffic policer statistics.

Display traffic policer subinterface statistics

--{ candidate shared default }--[  ]--
# info from state interface ethernet-1/1 subinterface 1 qos input policer-templates policer 1 statistics

You can use the following options to narrow the scope of the statistics output.

  • In violating-focus mode only:
    • accepted-octets
    • accepted-packets
    • violating-octets
    • violating-packets
  • In forwarding-focus mode only:
    • committed-octets
    • committed-packets
    • exceeding-octets
    • exceeding-packets

Clearing subinterface traffic policer statistics

You can reset the policer statistics counters for a subinterface.

Reset all policer statistics counters on a subinterface

The following example resets all policer statistics counters on a subinterface:

--{ running }--[  ]--
# tools interface ethernet-1/1 subinterface 1 qos input policer-templates clear

Reset statistics counters for specific policer

The following example resets statistics counters for policer 10 on ethernet-1/1.1:

--{ running }--[  ]--
# tools interface ethernet-1/1 subinterface 1 qos input policer-templates policer 10 clear