Dot1p classification and marking
SR Linux supports IEEE 802.1p (dot1p) classification and marking using the Priority Code Point (PCP) field. When one or more IEEE 802.1Q VLAN tags are added to an Ethernet frame, the Class of Service (CoS) of the frame can be set using the PCP field in the outermost VLAN tag. The 3-bit PCP field can specify eight different classes of service, allowing Ethernet frames to be assigned a required service level.
Supported platforms
Dot1p classification and marking is supported on the following platforms:
- 7220 IXR-D2/D2L/D3/D3L
- 7220 IXR-D4/D5
Dot1p classification
Dot1p classification refers to classification of a frame based on the PCP field in the outermost VLAN. The system assigns a forwarding-class and drop-probability to every packet at an early point in the packet forwarding pipeline. These assignments determine which packets to schedule or drop first when congestion occurs.
Each dot1p classifier policy can contain up to eight mapping rules. Each rule binds one of the eight possible PCP values (0 to 7) to a forwarding-class (fc0 to fc7) and to a drop-probability level (low, medium, or high).
For a dot1p classifier policy to take effect, you must apply the policy to at least one bridged subinterface. SR Linux supports dot1p classifier policies on any bridged subinterface of any Ethernet port or LAG. No limit exists on the number of bridged subinterfaces that can apply the same policy. (Routed subinterfaces are not supported.) Dot1p classification is applicable for non-IP packets only.
When a dot1p classifier policy is applied to a subinterface, if the PCP value for an
incoming Ethernet frame does not match any configured dot1p rule, the frame is
classified as fc0
and drop-probability low
.
Default dot1p classifier policy
SR Linux supports a default dot1p classifier policy, which always exists and is not modifiable. It is invisibly applied to all bridged subinterfaces that do not have a configured dot1p classifier policy applied. The following table describes the rules of the default policy.
Dot1p | FC | Drop probability |
---|---|---|
0 | fc0 | Low |
1 | fc1 | Low |
2 | fc2 | Low |
3 | fc3 | Low |
4 | fc4 | Low |
5 | fc5 | Low |
6 | fc6 | Low |
7 | fc7 | Low |
Dot1p classifier policy effects
The following table describes the effects of applying the dot1p classifier policy in relation to other configuration.
Ingress sub-interface type | Ingress packet type | Default fc of ingress sub-interface | Default drop-probability of ingress subif | Default dot1p-policy | Explicit dot1p-policy (bound to ingress sub-interface) | Default dscp-policy | Explicit dscp-policy (bound to ingress sub-interface) |
---|---|---|---|---|---|---|---|
Routed, untagged | IPv4/IPv6 untagged | — | — | — | Not supported | Used if no explicit dscp-policy | Used |
Routed, untagged | IPv4/IPv6 priority-tagged | — | — | — | Not supported | Used if no explicit dscp-policy | Used |
Routed, single-tagged | IPv4/IPv6 single-tagged | — | — | — | Not supported | Used if no explicit dscp-policy | Used |
Bridged, untagged | IPv4/IPv6 untagged | — | — | — | — | Used if no explicit dscp-policy | Used |
Bridged, untagged | IPv4/IPv6 priority-tagged | — | — | — | — | Used if no explicit dscp-policy | Used |
Bridged, single-tagged | IPv4/IPv6 single-tagged | — | — | — | — | Used if no explicit dscp-policy | Used |
Bridged, untagged | Non-IP untagged | Used | Used | — | — | — | — |
Bridged, untagged | Non-IP priority-tagged | — | — | Used if no explicit dot1p-policy | Used | — | — |
Bridged, single-tagged | Non-IP single-tagged | — | — | Used if no explicit dot1p-policy | Used | — | — |
Bridged, single-tagged | Non-IP double-tagged | — | — | Used if no explicit dot1p-policy | Used | — | — |
Configuring dot1p classifiers for input traffic
To configure a dot1p classifier policy, map one or more incoming dot1p values to custom forwarding-class and drop-probability values using the qos classifiers dot1p-policy command.
default
.The following example creates a dot1p classifier policy:
--{ candidate shared default }--[ ]--
# info qos classifiers
qos {
classifiers {
dot1p-policy new-dot1p-policy {
dot1p 0 {
forwarding-class fc0
drop-probability high
}
dot1p 7 {
forwarding-class fc7
drop-probability low
}
}
}
}
Applying a dot1p policy to a subinterface
To apply a dot1p policy to input traffic on a subinterface, specify the policy using the qos input classifiers command.
The following example applies a dot1p policy to inbound traffic on a subinterface:# info interface ethernet-1/1 subinterface 1 qos input classifiers
interface ethernet-1/1 {
subinterface 1 {
qos {
input {
classifiers {
dot1p-policy new-dot1p-policy
}
}
}
}
}
Dot1p marking
Dot1p marking refers to rewriting of the PCP value in the outermost VLAN tag. The node rewrites the value in the PCP field before a packet is transmitted out an egress interface. Downstream nodes handle the remarked traffic based on the updated code point. SR Linux implements dot1p marking using dot1p rewrite policies.
Each dot1p rewrite policy contains up to eight mapping rules, and each rule associates one of the eight possible internal forwarding classes (fc0 to fc7) to a PCP value (0 to 7).
Unless explicitly configured otherwise, a new mapping rule applies to all drop-probability levels. You can optionally configure a mapping rule for a specific forwarding class and drop probability combination, as required.
For a dot1p rewrite policy to take effect, you must apply the policy to at least one subinterface. SR Linux supports rewrite policies on any bridged or routed subinterface of any Ethernet port or LAG. No limit exists on the number of subinterfaces that can apply the same policy.
When a dot1p rewrite policy is applied to a subinterface, if the forwarding class of an
outgoing packet does not match any configured dot1p rewrite rule, all pushed 802.1Q VLAN
tags on the outgoing frame are marked with a PCP value of 0
.
If a dot1p rewrite policy is not applied to a subinterface:
- For a routed subinterface, the dot1p value is taken from the forwarding class.
- For bridged subinterface, the dot1p value is 0.
No default dot1p rewrite policy
No default dot1p rewrite policy exists.
Effect of dot1p rewrite policy
Egress sub-interface type | Egress packet type | Behavior with dot1p-policy applied to egress sub-interface | Behavior without dot1p-policy applied to egress sub-interface |
---|---|---|---|
Untagged | Any | None, can be blocked. | — |
Routed, single-tagged | Non-originated, forwarded IPv4/IPv6 |
Rewrites the PCP in the VLAN tag pushed at egress by the subinterface definition. |
PCP = fc in the VLAN tag pushed at egress when no policy attached. |
Routed, single-tagged | Self-originated IPv4/IPv6 | None, ignored for self-originated traffic. | — |
Routed, single-tagged | Non-originated, forwarded after VXLAN encapsulation, Ethernet untagged payload | PCP = fc in the VLAN tag pushed at egress by the subinterface definition. | PCP = fc in the VLAN tag pushed at egress when no policy attached. |
Bridged, single-tagged | Non-originated, L2 forwarded | Rewrites the PCP in the VLAN tag pushed at egress by the subinterface
definition.
|
PCP = 0 in the VLAN tag pushed at egress when no policy attached. Does not modify the PCP of VLAN tags in the payload. A VLAN tag is carried as payload when the ingress subinterface is configured with vlan-tagging = true and vlan-id = any. |
Bridged, single-tagged | Self-originated IPv4/IPv6 | None, ignored for self-originated traffic. | — |
Bridged, single-tagged | Non-originated, L3 forwarded (IRB) | Rewrites the PCP in the VLAN tag pushed at egress by the subinterface definition. | PCP = fc in the VLAN tag pushed at egress when no policy attached. |
Bridged, single-tagged | Non-originated, forwarded after VXLAN decapsulation, Ethernet untagged payload | Rewrites the PCP in the VLAN tag pushed at egress by the subinterface definition. | PCP = fc in the VLAN tag pushed at egress when no policy attached. |
Configuring dot1p rewrite rules for output traffic
To configure dot1p rewrite rules, map internal forwarding classes (and optionally drop-probability) to the required dot1p values using the qos rewrite-rules dot1p-policy command.
The following example creates a dot1p rewrite-rule policy:
--{ candidate shared default }--[ ]--
# info qos rewrite-rules
qos {
rewrite-rules {
dot1p-policy rewrite-dot1p-example {
map fc0 {
dot1p 0
}
map fc1 {
dot1p 3
drop-probability low {
dot1p 1
}
drop-probability high {
dot1p 2
}
}
map fc3 {
dot1p 3
}
map fc7 {
dot1p 7
}
}
}
}
Applying a dot1p rewrite rule to a subinterface
To apply a dot1p rewrite rule to output traffic on a subinterface, specify the required policy using the qos output rewrite-rules command.
The following example applies a dot1p rewrite-rule policy to outbound traffic on a subinterface:
# info interface ethernet-1/1 subinterface 1 qos output rewrite-rules
interface ethernet-1/1 {
subinterface 1 {
qos {
output {
rewrite-rules {
dot1p-policy rewrite-dot1p-example
}
}
}
}
}