15. Quality of service
15.1. Overview
Quality of Service (QoS) provides an appropriate level of service for packets as they flow inside the switch and between switches in the network. The required level of service depends on the application that generates the flow of packets, and can be defined by the application’s sensitivity to packet loss, delay, and jitter.
Packets that require a similar treatment (per-hop behavior) are grouped into a Forwarding Class (FC), also known as a behavior aggregate. Up to eight forwarding classes can be specified. Traffic is scheduled and can optionally be marked based on its forwarding class.
A configurable drop probability expresses the sensitivity of packets to packet loss. Packets should be assigned a low drop probability when they are sensitive to loss. Proper congestion management relies on a balance of traffic that is classified as low, medium, and high drop probability so that discard decisions can be made intelligently when there is congestion.
QoS functionality is supported on the 7250 IXR, 7220 IXR-D2 and D3, and the 7220 IXR-H2 and H3.
15.2. How QoS works for transit traffic
This section describes how QoS applies to transit packets on the SR Linux.
- Packets are received on a subinterface.
- Each received packet is classified as belonging to one of eight forwarding classes (fc0 to fc7) and one of three drop probabilities (low, medium, or high).
- If the configuration of the ingress subinterface refers to a DSCP classifier policy, then the forwarding class and drop probability level are determined from that policy.
Note: If there is no entry of this policy matching the received DSCP, then the assigned forwarding class is fc0 and the assigned drop probability is low. This FC and drop probability classification corresponds to a best effort treatment.
- If there is no DSCP classifier policy bound to the ingress subinterface, then the FC and drop probability are determined from the default DSCP classifier policy. See Table 18.
Table 18: System default DSCP classifier policy
DSCP values
Included DSCP names
Forwarding class
Drop probability
0, 2 to 7
CS0/BE
fc0
Low
1
LE
fc0
High
8 to 11
CS1, AF11
fc1
Low
12 to 13
AF12
fc1
Medium
14 to 15
AF13
fc1
High
16 to 19
CS2, AF21
fc2
Low
20 to 21
AF22
fc2
Medium
22 to 23
AF23
fc2
High
24 to 27
CS3, AF31
fc3
Low
28 to 29
AF32
fc3
Medium
30 to 31
AF33
fc3
High
32 to 35
CS4, AF41
fc4
Low
36 to 37
AF42
fc4
Medium
38 to 39
AF43
fc4
High
40 to 47
CS5, EF
fc5
Low
48 to 55
CS6/NC1
fc6
Low
56 to 63
CS7/NC2
fc7
Low
Note: On all VLAN-based subinterfaces the 802.1p bits are currently ignored for purposes of forwarding class and drop-probability classification.
- A forwarding lookup on the packet determines its egress port.
- On the 7250 IXR, if the packet is a unicast packet, it is associated with a Virtual Output Queue (VOQ) based on the ingress port, egress port, and FC.On a 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3, the packet is associated directly with an Egress Queue (EGQ) of the egress port, based on the FC of the packet and its type (either unicast or multicast).
- While it waits for its VOQ or EGQ to be serviced, the packet is stored in buffer memory. The total amount of buffer memory varies by platform.
- The packet is dropped if the buffer memory is close to full or if the Maximum Burst Size (MBS) of the VOQ or EGQ is exceeded. The MBS is one of the parameters that is configurable in a queue template. When a queue template is applied to a set of queues, all of those queues have the MBS value specified in the template. If the MBS is not specified in a queue template, then the default value is platform dependent. The MBS is not a guaranteed allocation of buffer memory.
- When the packet is Explicit Congestion Notification (ECN)-capable, and ECN is enabled globally with the qos explicit-congestion-notification command, and the VOQ or EGQ has an active ECN slope that applies to the packet, then the ECN field may be remarked depending on the current (weighted) queue depth.
- If the current queue depth is below the configured min-threshold-percent of the ECN slope, the ECN field of the packet is unchanged.
- If the current queue depth is above the configured max-threshold-percent of the ECN slope, the ECN field of the packet is (re)marked as Congestion Experienced (CE), ECN=11.
- If the current queue size is between the min-threshold-percent and max-threshold-percent of the ECN slope, then the ECN field of the packet is (re)marked as CE, ECN=11, based on a probability function that increases linearly from 0% at the minimum threshold to n% at the maximum threshold, where n is the operational max-probability of marking the packet.
Note: The operational values of the max-probability may be significantly different from the configured values due to internal hardware calculations. You can check the hardware configured values for any slope calculations.
- When the packet is non-ECN-capable (the ECN field is zero) and the egress queue has an active WRED slope for the drop probability of the packet, then the packet may be dropped by the WRED algorithm, which operates as follows:
- If the current queue depth is below the configured min-threshold-percent of the WRED slope, then the packet is admitted to the queue.
- If the current queue depth is above the configured max-threshold-percent of the WRED slope, then the packet is dropped.
- If the current queue size is between the minimum threshold and maximum threshold of the WRED slope, then the packet is dropped based on a probability function that increases linearly from 0% at the minimum threshold to n% at the maximum threshold, where n is the operational max-probability of dropping the packet.
Note: The operational values of the max-probability may be significantly different from the configured values due to internal hardware calculations. You can check the hardware configured values for any WRED slope calculations.
- Each unicast queue and each multicast queue of an egress port is associated with a scheduler node. The mapping of queues to scheduler nodes is platform-dependent and cannot be configured. See Configuring output queue scheduling.
- Each egress queue can be individually configured with a Peak Information Rate (PIR). The PIR is configured as a percentage of the egress port bandwidth. By default, the PIR of each queue is 100%. The operational PIR is stored by the peak-rate-bps leaf in bits per second. The bits counted in this rate include the Layer 2 framing of the packet (including the 14 byte Ethernet header, the 4-byte VLAN header, and the 4-byte CRC) but exclude the 20-byte Layer 1 overhead (SFD, preamble, IPG).
- The DSCP field in the IPv4/IPv6 header of the outgoing packet can be rewritten. On the 7250 IXR, the DSCP field must be rewritten when ECN is enabled and the packet ECN field is non-zero. When there is a rewrite policy applied, the DSCP in the outgoing packet is based on the FC (and potentially also the drop probability) of the packet. If the FC (and drop-probability) matches an entry in the applied policy, then the new DSCP value is based on the policy entry. If there is no matching entry in the applied policy, then the new DSCP value is 0.
15.3. How QoS works for VXLAN traffic
When the 7220 IXR-D2 and D3 receives a terminating VXLAN packet on a subinterface, it classifies the packet to one of eight forwarding classes and one of three drop probabilities (low, medium, or high). The classification is based on the following considerations.
- The outer IP header DSCP is ignored.
- If the payload packet is non-IP, the classified FC is fc0 and the classified drop probability is low.
- If the payload packet is IP, and there is a classifier policy referenced by the qos classifiers vxlan-default command, that policy is used to determine the FC and drop probability from the header fields of the payload packet.
- If the payload packet is IP, and there is no classifier policy referenced by the qos classifiers vxlan-default command, the default DSCP classifier policy is used to determine the FC and drop probability from the header fields of the payload packet.
When the 7220 IXR-D2 and D3 adds VXLAN encapsulation to a packet and forwards it out a subinterface, the inner header IP DSCP value is not modified if the payload packet is IP, even if the egress routed subinterface has a DSCP rewrite rule policy bound to it that matches the packet FC and drop probability. The outer header IP DSCP is modified by the DSCP rewrite rule policy that is bound to the egress routed subinterface, if such a policy exists.
15.4. How QoS works for router-terminated traffic
This section describes how QoS applies to traffic that terminates on the SR Linux.
- A packet is received on a subinterface and is determined to need extraction toward the CPM. The packet is directed to one of the queues associated with the CPM as a destination “physical port” based on its protocol and type. The following traffic types have their own independent queue.
- sflow
- ICMPv4 ping
- BFD
- ARP
- ICMPv6 neighbour solicitation and neighbor advertisement
- BGP
- gRPC
- LLDP
- IPv4 packets with IP options and IPv6 packets with extension headers
- DHCPv6
- IS-IS hello PDUs
- OSPF/OSPFv3 hello PDUs
- Some of the queues toward the CPM have a PIR shaping rate designed to prevent an overload of one type of traffic. The PIR shaping rates vary by platform.
15.5. How QoS works for router-originated traffic
This section describes how QoS applies to traffic that originates on the SR Linux.
- An application on the SR Linux CPM has an IPv4 or IPv6 packet to send to another system.
- The CPM datapath assigns a DSCP to the self-generated packet based on its protocol and the hard coded mapping shown in Table 19.Except for ICMP and ICMPv6 echo-request packets, the DSCP values cannot be overridden. For originated echo-request packets, the DSCP override value can be configured as an optional parameter of the ping command.
Table 19: Default forwarding class and DSCP marking for router-originated traffic
Protocol / message type
Forwarding class
Drop probability
DSCP marking
IPv4 ARP request/reply
6
Low
N/A
ICMPv4 including echo-request 1, echo- reply 2, dest-unreachable, redirect, time-exceeded, parameter-problem
0
Medium
0
ICMPv4 echo-request with ToS/DSCP override = x
look up X in system-default DSCP classifier
look up X in system-default DSCP classifier
x
ICMPv4 echo-reply to echo-request with non-zero DSCP x
look up X in system-default DSCP classifier
look up X in system-default DSCP classifier
x
UDP traceroute
0
Low
0
IPv6 neighbor solicitation
6
Low
48 (CS6/NC1)
IPv6 neighbor advertisement
6
Low
48 (CS6/NC1)
All other ICMPv6 including dest unreachable, packet-too-big, time-exceeded, parameter-problem, echo-request, echo-reply, router-solicitation, redirect
0
Medium
0
ICMPv6 echo-request with DSCP override = x
look up x in system-default DSCP classifier
look up x in system-default DSCP classifier
x
ICMPv6 echo-reply to echo-request with non-zero DSCP x
look up x in system-default DSCP classifier
look up x in system-default DSCP classifier
x
BFD
6
Low
48 (CS6/NC1)
BGP
6
Low
48 (CS6/NC1)
DNS query
4
Low
34 (AF41)
FTP/TFTP
4
Low
34 (AF41)
gNMI
4
Low
34 (AF41)
JSON RPC
4
Low
34 (AF41)
LLDP
N/A
Low
N/A
NTP
4
Low
34 (AF41)
sFlow
0
Low
0
SNMP
4
Low
34 (AF41)
SSH
4
Low
34 (AF41)
Syslog
4
Low
34 (AF41)
TACACS+
4
Low
34 (AF41)
- Echo-request generated by a ping command with no DSCP parameter specified.
- Echo-reply to an echo-request packet with DSCP=0.
Notes:
- The CPM datapath looks up the DSCP from the previous step (either the fixed value or the override value for echo-request) in the default DSCP classifier policy (see Table 18) in order to determine the FC and drop probability level.
- A forwarding lookup determines the egress port.
- On the 7250 IXR, the packet is sent to the egress line card and added to a Virtual Output Queue (VOQ) appropriate for its forwarding class and the egress port. The decision to drop or enqueue the packet in the VOQ and the scheduling of the VOQ follows the previous description for transit traffic. There is no scheduling differentiation between router-originated traffic and transit traffic of the same FC on the egress IMM.
- The packet is directed to the egress queue appropriate for its forwarding class and packet type. On the 7220 IXR-D2 and D3 and the 7220 IXR-H2 and H3, the decision to drop or enqueue the packet in the egress queue and the scheduling of the egress queue follows QoS treatment of transit traffic described in section 15.2.
- The DSCP field in the IPv4 or IPv6 header is always written based on the hard coded mapping described in Table 19. If the packet also matches a dscp-policy rewrite-rule applied to the output subinterface, the rewrite-rule policy is ignored.
15.6. Configuring QoS
QoS configuration on the SR Linux involves tasks such as creating classifier policies for incoming packets, creating rewrite-rule policies for outgoing packets, creating queue-templates, and applying these different constructs to the appropriate objects.
15.6.1. Configuring classifier and rewrite policies
15.6.1.1. DSCP classifier policies
When a DSCP classifier policy is applied to a subinterface, the policy attempts to match the 6-bit DSCP value in the IP header of incoming packets to one of its entries. If there is a match, the incoming packet is assigned to the specified forwarding class and drop probability; otherwise, the assigned forwarding class is 0 and the assigned drop probability is low.
Packets that require a similar treatment (per-hop behavior) are grouped into an FC, also known as a behavior aggregate. The SR Linux differentiates up to eight forwarding classes.
The drop probability can be one of high, medium, or low. If a queue-template with different WRED slopes is bound to a queue, then packets in that queue with a high drop probability are the first to be dropped when the queue experiences congestion, followed by packets with a medium drop probability, then by packets with a low-drop probability. The default is low.
Example:
The following example creates a DSCP classifier policy:
| Note: To create a new DSCP classification policy based on the default policy, you can copy the default policy from state in candidate mode. |
Example:
# copy from state /qos classifiers dscp-policy default to /qos classifiers dscp-policy test
For information about how to apply a classifier policy, see section 15.6.3.1.
15.6.1.2. DSCP rewrite policies
When a DSCP rewrite-rule policy is applied to a subinterface, the policy attempts to match the forwarding class (and optionally, also the drop-probability) of outbound packets to one of its entries. If there is a match, the DSCP value of the outbound packet is changed to the value specified by the policy. If the forwarding class of the packet does not match a rule of the rewrite-rule policy, the DSCP value is changed to 0.
On 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 systems, if no DSCP rewrite-rule policy is applied to a subinterface, the incoming packet's DSCP remains unchanged at egress.
Example:
The following example creates a rewrite-rule policy:
For information about how to apply a DSCP rewrite policy, see section 15.6.3.2.
15.6.1.3. Using a DSCP classifier for VXLAN traffic
On a 7720 IXR-D2 and D3, you can use a classifier policy to classify ingress packets received from any remote VXLAN VTEP. The policy applies to payload packets after VXLAN decapsulation has been performed.
Example:
The following example shows how the DSCP classifier policy created in the example in section 15.6.1.1 can be used for VXLAN traffic:
15.6.2. Configuring queue templates
Queue-template are groups of configuration information that apply to a set of queues. On 7250 IXR systems, the controlled set of queues are VOQs; on 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 systems, the controlled set of queues are egress queues.
The maximum number of queue-templates per system varies by platform. On 7250 IXR systems, the maximum is 8 queue-templates; on 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 systems, the maximum is 62 queue-templates.
The following parameters are configurable inside a queue template:
- The MBS of each queue; this essentially defines the length of each queue. When the queue builds to the MBS level, further packets are dropped. Note that discards may occur prior to the queue reaching MBS (for example, due to shared buffer exhaustion, or due to the effects of WRED slopes defined for the queue).
- WRED slopes that define probability curves for discarding packets as a function of (weighted) average queue depth. Note that WRED slopes are not supported for multicast queues.
- ECN slopes that define probability curves for marking ECN-capable packets as having experienced congestion, rather than discarding them. Note that ECN slopes are not supported for multicast queues.
If a queue (VOQ or egress queue) does not have a queue-template binding, it inherits the settings of a default queue-template. The default queue-template has a platform-specific MBS default value, no defined queue utilization thresholds, no WRED slopes, and no ECN slopes. The default queue-template cannot be displayed, but its effect is visible by reading the state of individual queues that lack a queue-template binding.
Example:
The following example creates a queue template that you could use for any of the following:
- a set of VOQs on a 7250 IXR
- an egress queue on a 7220 IXR-D2 and D3
- an egress queue on a 7220 IXR-H2 and H3
| Note: This example is only the starting point of a full configuration. Subsequent sections build on this example to create a full configuration. |
15.6.2.1. Configuring queue depth
In a queue-template, the maximum-burst-size parameter sets the maximum length of an egress queue or set of VOQs. The queue depth is also known as the Maximum Burst Size (MBS). The maximum-burst-size parameter must be configured with a non-zero value in order to configure WRED slope and ECN slope parameters.
On the 7250 IXR, the maximum-burst-size parameter applies to a set of VOQs. If the parameter is not configured, or is set to 0, the effective MBS of these VOQs is 256MB.
On the 7220 IXR-D2 and D3 or the 7220 IXR-H2 and H3, the maximum-burst-size parameter applies to a set of egress queues. If the parameter is not configured or is set to 0, the effective MBS of these egress queues is calculated based on a fair allocation algorithm. You can assign a non-zero MBS value to multicast queues, but this configuration is not recommended (especially if multicast traffic is being shaped by configuring peak-rate-percent), since it can lead to a shortage of multicast-related buffering resources on 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 systems.
Example:
The following example specifies the queue depth with a set maximum-burst-size:
15.6.2.2. Configuring a WRED slope
In a queue template, WRED policies can be configured to handle congestion when queue space is depleted. Without WRED, once a queue reaches its maximum fill size, the queue discards any packets arriving at the queue (known as tail drop).
WRED policies manage queue depth. They help to prevent congestion by starting random discards once the queue reaches a user-configured threshold value. This avoids the impact of discarding all the new incoming packets. By starting random discards at this threshold, an end-system can adjust its sending rate to the available bandwidth.
The WRED curve algorithm is based on two user-configurable thresholds (min-threshold-percent and max-threshold-percent) and a discard probability factor (max-probability).
On the 7220 IXR-D2 and D3 or the 7220 IXR-H2 and H3, a WRED slope can be configured to apply only to TCP or to non-TCP traffic. This can be useful because TCP has built-in mechanisms to adjust its sending rate in response to packet drops. TCP-based senders lower the packet transmission rate when some of the packets fail to reach the far end.
Example:
The following example specifies a WRED slope for low drop probability traffic flowing through a set of VOQs on a 7250 IXR. This WRED slope applies to both TCP and non-TCP traffic.
Example:
The following example specifies a WRED slope for TCP traffic that is classified as low drop-probability flowing through an egress queue on the7220 IXR-D2 and D3 or the 7220 IXR-H2 and H3.
15.6.2.3. Configuring an ECN slope
Some IP applications support the ECN mechanism. With ECN, IP packets originated by such applications are not discarded when they enter a congested queue; instead, they are marked in a special way. The marking uses the two ECN bits in the traffic class field of the IPv4 or IPv6 packet header. The receiver of IP packets marked as having experienced congestion can signal to the sender (through Layer 4 or higher protocols) that it should reduce its sending rate. The advantage of this feedback mechanism is that the sending rate can be dropped more gradually than the normal response of a TCP sender to packet discards. A more gradual back-off can result in higher effective throughput in the network.
An ECN slope is similar to a WRED slope. It is based on two user-configurable thresholds (min-threshold-percent and max-threshold-percent) and a marking probability factor (max-probability).
On the 7220 IXR-D2 and D3 or the 7220 IXR-H2 and H3, you can have one ECN slope per drop-probability level of traffic flowing through an egress queue. On the 7250 IXR you can only have one ECN slope per queue and it applies to all drop-probability levels.
For an ECN slope to be used, explicit-congestion-notification must be configured. On 7250 IXR systems, this configuration also requires you to specify an ecn-dscp-policy; this is the DSCP rewrite policy that will be used when an ECN field rewrite must be performed.
Example (7250 IXR):
The following example specifies an ECN slope applicable to a 7250 IXR system:
Example (7220 IXR-D2 and D3 or 7220 IXR-H2 and H3):
The following example specifies an ECN slope applicable to a 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 system:
15.6.2.4. Configuring queue utilization thresholds
When a burst of traffic arrives at a router, and the incoming rate exceeds the available transmission rate, the excess traffic is queued. If the burst lasts long enough, or it is followed by additional bursts, the queues may overflow, resulting in traffic loss.
To respond to onsets of congestion, you can subscribe to telemetry information that generates an event when specific queues exceed a specified occupancy level.
To assign a utilization threshold to a queue, you must apply a non-default queue template to the queue, and that queue template must specify a non-zero high-threshold-bytes value. When the utilization of the queue crosses the specified high-threshold-bytes value, a hardware interrupt is raised. XDP records the current system-time and clears the interrupt. In a scaled setup, XDP may take 10-15 ms to process and clear each interrupt, meaning multiple threshold crossings within a very short period of time across one or more queues using the same queue-template may appear as only a single event in the telemetry stream. When the high-threshold-bytes value is 0, the functionality is disabled and no threshold events are generated for the queues covered by the queue template.
SR Linux supports queue utilization thresholds on 7250 IXR, 7220 IXR-D2 and D3, and 7220 IXR-H2 and H3 systems; however, the behavior varies by system.
| Note: Queue utilization thresholds can only be configured for unicast queues. They cannot be configured for multicast queues. |
15.6.2.4.1. Queue utilization thresholds on 7250 IXR systems
On a 7250 IXR system, binding a queue template with a non-zero high-threshold-bytes value to an egress queue assigns that threshold value to all the VOQs that logically feed this egress queue.
Each queue-template supported by the system can be configured with a different high-threshold-bytes value if desired.
Example:
The following example configures the high-threshold-bytes value to 252655:
Each configured threshold value is rounded up to the nearest multiple of 256 bytes, up to a maximum capped value of MBS. You can observe the rounding (on a per VOQ-set basis) using the info from state interface queue-statistics unicast-queue virtual-output-queue queue-depth output. (A VOQ-set is comprised of the VOQ for core 0 and the VOQ for core 1.)
Example:
In the following example, the high-threshold-bytes value was configured to 252655, but is rounded to a lower 256000 value (that is, a multiple of 256 bytes):
The state tree maintains the time of the last threshold crossing in the interface queue-statistics unicast-queue virtual-output-queue queue-depth leaf. This represents the last time when either VOQ in the VOQ-set (core0/core1) exceeded the operational threshold. The value of this leaf is not cleared when the queue template that is bound to the queue/VOQs is deleted or modified, or when the high-threshold-bytes configuration in the applied queue template is deleted or modified.
15.6.2.4.2. Queue utilization thresholds on 7220 IXR-D2 and D3 systems
On 7220 IXR-D2 and D3 systems, binding a queue template with a non-zero high-threshold-bytes value to an egress queue causes that threshold value to be used for that specific queue, as long as it is a unicast queue. The configuration of this leaf is ignored when this queue template is attached to a multicast queue.
No more than seven different configured high-threshold-bytes values are allowed across all of the queue templates used. The management server rejects a commit that would leave more than seven different values after all adds, deletes, and modifies are processed.
Example:
The following example configures the high-threshold-bytes value to 2048999:
Each configured threshold value (that is accepted by the management server) is rounded up to the nearest multiple of 2048 bytes, up to a maximum capped value of MBS. (For this reason, you should not configure values that round to the same multiple of 2048 bytes. This will cause duplication among the high-threshold-bytes values, of which only seven are allowed.) You can observe the rounding using the info from state interface qos output unicast-queue queue-depth output.
Example:
In the following example, the high-threshold-bytes value was configured to 2048999, but is rounded to a lower 2048000 value (that is, a multiple of 2048 bytes):
The state tree maintains the time of the last threshold crossing in the interface qos output unicast-queue queue-depth last-high-threshold-time leaf. This represents the last time the queue exceeded the operational threshold. The value of this leaf is not cleared when the queue template that is bound to the queue is deleted or modified, or when the high-threshold-bytes configuration in the applied queue-template is deleted or modified.
15.6.2.4.3. Queue utilization thresholds on 7220 IXR-H2 and H3 systems
On 7220 IXR-H2 and H3 systems, binding a queue template with a non-zero high-threshold-bytes value to an egress queue causes that threshold value to be used by each ITM that serves the queue. For a high-threshold event, the queue utilization threshold must be exceeded on either ITM.
No more than seven different configured high-threshold-bytes values are allowed across all of the queue templates used. The management server rejects a commit that would leave more than seven different values after all adds, deletes, and modifies are processed.
Example:
The following example configures the high-threshold-bytes value to 254255:
Each configured threshold value (that is accepted by the management server) is rounded up to the nearest multiple of 254 bytes, up to a maximum capped value of MBS. (For this reason, you should not configure values that round to the same multiple of 254 bytes. This will cause duplication among the high-threshold-bytes values, of which only seven are allowed.) You can see the effect of the rounding using the info from state interface qos output unicast-queue queue-depth output.
Example:
In the following example, the high-threshold-bytes value was configured to 254255, but is rounded to a lower 254255 value (that is, a multiple of 254 bytes):
The state tree maintains the time of the last threshold crossing in the interface qos output unicast-queue queue-depth last-high-threshold-time leaf. This represents the last time when either ITM exceeded the operational threshold. The value of this leaf is not cleared when the queue-template that is bound to the queue is deleted or modified, or when the high-threshold-bytes configuration in the applied queue-template is deleted or modified.
15.6.3. Applying QoS policies to subinterfaces
15.6.3.1. Applying a DSCP classifier policy to input traffic
If you apply a DSCP classifier policy to input traffic on a subinterface, incoming packets are evaluated against the policy, and matching packets are assigned to the forwarding class and drop probability specified by the policy. If no classifier policy is applied to the subinterface, the system default DSCP classifier (with the reserved name default) is used.
| Note: On 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 systems, separate classifier policies for IPv4 and IPv6 traffic are not supported, but you can apply a common policy that applies to both IPv4 and IPv6 traffic. |
Example (7250 IXR):
The following example applies a DSCP classifier policy to inbound IPv6 traffic on a subinterface with a 7250 IXR system:
Example (7220 IXR-D2 and D3 or 7220 IXR-H2 and H3):
The following example applies a DSCP classifier policy to inbound traffic on a subinterface with a 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 system:
15.6.3.2. Applying a rewrite-rule policy to output traffic
When a rewrite-rule policy is applied to output traffic on a subinterface, outbound packets are evaluated against the policy. All packets, with some exceptions, are subject to DSCP remarking by this policy. If no rewrite-rule policy is applied to the subinterface, the DSCP marking of the traffic leaving the subinterface is unchanged, unless it is ECN-capable traffic forwarded by a 7250 IXR system or VXLAN traffic originated by a 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 system. For these exceptions, DSCP may be remarked even in the absence of a rewrite-rule policy applied to the egress subinterface. Note that on all platforms the DSCP marking of self-generated traffic is not affected by rewrite rule policies.
| Note: Separate rewrite policies for IPv4 vs IPv6 egress traffic are supported on 7250 IXR systems. Common rewrite policies that apply to both IPv4 and IPv6 traffic are supported on 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 systems. |
Example (7250 IXR):
The following example applies a rewrite-rule policy to outbound IPv4 traffic on a subinterface with a 7250 IXR system:
Example (7220 IXR-D2 and D3 or 7220 IXR-H2 and H3):
The following example applies a rewrite-rule policy to outbound traffic on a subinterface with a 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 system:
15.6.4. Configuring output queue scheduling
Each unicast queue and each multicast queue of an egress port is associated with a scheduler node. The mapping of queues to scheduler nodes is platform-dependent and cannot be configured.
On 7250 IXR systems, there are two scheduling nodes per port; one for unicast traffic and one for multicast traffic. The two scheduling nodes have a WRR relationship, but the parameters cannot be adjusted. There is one PIR scheduling loop per scheduling node. The scheduling loop serves the strict priority classes first (in descending order of FC), and then the WRR classes (by weight), limiting each forwarding class to its PIR (expressed as a percentage of the egress port bandwidth). By default, the PIR of each forwarding class is 100%. Note that multicast traffic handled by the multicast scheduler node is unscheduled and is not subject to the ingress VOQ buffering that applies to unicast traffic.
On 7220 IXR-D2 and D3 systems, the unicast queue and multicast queue for a particular forwarding class make up a queue pair. Each of the eight possible queue pairs of an egress port are associated with a scheduler node. Each scheduler node is served as strict priority (SP) or weighted round robin (WRR). If it is served as WRR, then the scheduler node also has an associated weight. The scheduling loop serves the SP nodes first and then the WRR nodes by weight. The serving order of SP queues is in descending order of FC: fc7 first, then fc6, then fc5, and so on.
On 7220 IXR-H2 and H3 systems, there is a one-to-one mapping of queues to scheduler nodes. Each scheduler node can be served as SP or WRR. A WRR node has a configurable weight. The scheduling loop serves the SP nodes first and then the WRR nodes by weight. The serving order of SP queues is as follows:
- unicast queue 7 serving fc7
- unicast queue 6 serving fc6
- multicast queue 3 serving fc6 and fc7
- unicast queue 5 serving fc5
- unicast queue 4 serving fc4
- multicast queue 2 serving fc4 and fc5
- unicast queue 3 serving fc3
- unicast queue 2 serving fc2
- multicast queue 1 serving fc2 and fc3
- unicast queue 1 serving fc1
- unicast queue 0 serving fc0
- multicast queue 0 serving fc0 and fc1
The following examples configure a queue or scheduler node for strict priority. Note that when strict priority is set to false, the associated queue or scheduler node is configured as WRR. When strict priority is set to true, any configured weight is ignored.
Example (7250 IXR):
Example (7220 IXR-D2 and D3 or 7220 IXR-H2 and H3):
The following examples configure a queue or scheduler-node for WRR. Queues or scheduler nodes that are not configured with a specific weight have a weight of 1.
Example (7250 IXR):
Example (7220 IXR-D2 and D3 or 7220 IXR-H2 and H3):
The following example sets the maximum percentage of port bandwidth that is available to traffic of a particular forwarding class. By default traffic belonging to any FC can use up to 100% of port bandwidth. The example is applicable to 7250 IXR, 7220 IXR-D2 and D3, or 7220 IXR-H2 and H3 system.
Example:
15.7. Viewing buffer utilization
Buffer utilization differs between the 7250 IXR, 7220 IXR-D2 and D3, or 7220 IXR-H2 and H3. See Table 20.
Table 20: Buffer utilization
Hardware | Buffer memory |
7250 IXR |
|
7220 IXR-D2 and D3 |
|
7220 IXR-H2 and H3 |
|
The following examples show overall buffer usage. Depending on the hardware deployed, the output will vary.
Examples:
The following example shows overall buffer usage on a 7250 IXR system:
The following example shows overall buffer usage on 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 systems:
15.8. Displaying QoS statistics
To display traffic statistics for each output queue on an interface, use the show interface <id> queue-detail command in running or candidate mode.
Example:
The following example displays output queue statistics for an interface on a 7250 IXR system. The output on a 7220 IXR-D2 and D3 or 7220 IXR-H2 and H3 system is similar, but will show slightly different information.
15.8.1. Clearing QoS statistics
You can reset the queue statistics counters for an interface.
Examples:
The following example resets all statistics counters on an interface:
The following example resets statistics counters for a specified egress queue (multicast) on an interface:
15.8.2. Displaying QoS profile resource usage on a 7250 IXR system
A QoS profile resource refers to the number of classifier and rewrite policies that are applied to interfaces on a line card. Each classifier or rewrite policy that is applied to an interface on a line card counts as one profile resource used.
For example, if you create classifier policy dscp1 and apply it to input IPv4 traffic on an interface, and apply the same dscp1 policy to input IPv6 traffic on a different interface on the same line card, it counts as two classifier profile resources used.
The SR Linux supports up to 15 classifier profile resources and up to 32 rewrite profile resources per line card. You can display the number of QoS profile resources in use for each line card.
Example:
The following example displays the number of used and free classifier and rewrite profile resources for a line card: