Ingress subinterface traffic policing
Some SR Linux-compatible hardware platforms (7220 IXR-D2/D3/D2L/D3L) 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.
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).
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.
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. 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.
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 [
unicast
]
}
exceed-action {
drop-probability medium
}
violate-action {
drop
}
}
}
}
}
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 {
policers {
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 policers 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 policers 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 policers policer 10 clear