Subinterface queuing and scheduling (7250 IXR-X4)
To enable queuing and scheduling on subinterfaces (including LAG subinterfaces), you must change the traffic management mode for the system from the default value of eight priorities to two priorities. In two-priority mode, queuing and scheduling on subinterfaces operates similarly to the interface queue behavior, with some exceptions:
- Similar to interface queues, subinterface queue definitions are specified under the qos queues context.
- To enable subinterface queuing and scheduling, you must assign a buffer allocation profile to the subinterface; however, given the scale of the systems, not all subinterfaces can be enabled for subinterface queuing.
- Buffer allocation profiles operate similarly on subinterfaces as on interfaces.
- With queue scheduler policies, the default operation differs in that all queues in the subinterface policy are attached to WRR scheduler 1, rather than strict priority scheduler 0 as in the interface policy. In addition, configuration of priority levels and committed rates is supported for the subinterface input queues, and on scheduler 1, configuration of peak rates is supported for the subinterface input queues and output interfaces.
- Queue management profiles are similar for interface and subinterface queues in that they define WRED curves or alternatively enable ECN. However, if ECN is enabled for a specified subinterface queue, the ECN counters are not collected per subinterface queue. Instead aggregate ECN counters are collected per interface.
- For VOQ statistics on subinterfaces, the default setting for qos interfaces interface voq-statistics is false, while for interfaces the default setting is true.
LAG resource allocation for subinterface queuing and scheduling
On SR Linux devices, LAG interfaces rely on datapath resource pools allocated for the LAG ID and the member links. For operation of subinterface queuing and scheduling, subinterfaces on a LAG interface require internal resources that come from the same datapath resource pools. On 7250 IXR-X4 systems, the datapath resource pools are by default entirely reserved for the physical LAG scale (256 LAGs x 64 member links), leaving no resources for subinterface queuing and scheduling.
To accommodate the resource requirement for subinterface queuing and scheduling, decrease the amount of resources reserved for physical LAGs by changing the maximum number of member links per LAG from the default of 64 to a lower value. After you change the maximum value for LAG member links, a system reboot is required.
For more information see "LAG resource allocation" in the SR Linux Interfaces Guide
Enabling subinterface queuing and scheduling by configuring the traffic management mode
Switching the traffic-management-mode requires a system reboot. However, for the reboot to succeed, you must first remove any configurations that are not supported in the new target mode.
To transition from eight-priority mode to two-priority mode, you must first disable the PFC feature on all interfaces and remove the following configuration paths:
qos buffer-management buffer-allocation-profile queues queue maximum-burst-size-delay
qos buffer-management buffer-allocation-profile queues queue low-threshold-bytes
qos scheduler-policies scheduler-policy scheduler 0 input weight
qos scheduler-policies scheduler-policy scheduler 0 input peak-rate-percentTo transition from two-priority mode to eight-priority mode, you must first remove the following configuration paths for subinterfaces (interface-level configurations can remain):
qos interfaces interface output queues queue
qos interfaces interface output scheduler scheduler-policy
qos interfaces interface output buffer-allocation-profile
qos scheduler-policies scheduler-policy scheduler 0 input priority-level
qos scheduler-policies scheduler-policy scheduler [ 0 | 1 ] input committed-rate-kbps
qos scheduler-policies scheduler-policy scheduler [ 0 | 1 ] input committed-rate-percent
qos scheduler-policies scheduler-policy scheduler 1 input peak-rate-kbps
qos scheduler-policies scheduler-policy scheduler 1 output output-type
qos scheduler-policies scheduler-policy scheduler 1 output peak-rate-percentTo support queuing and scheduling on subinterfaces, use the platform qos traffic-management-mode command to set the traffic management mode for the system to two-priorities rather than the default value of eight-priorities.
Configure the traffic management mode to two-priorities
--{ candidate shared default }--[ ]--
# info with-context platform qos traffic-management-mode
platform {
qos {
traffic-management-mode two-priorities
}
}
Display reboot required status
The system maintains a status specifying whether a chassis reboot is required to complete the traffic management mode update. To view this status, use the info from state platform qos chassis-reboot-required command.
--{ candidate shared default }--[ ]--
# info from state with-context platform qos chassis-reboot-required
platform {
qos {
chassis-reboot-required true
}
}
Reboot the chassis
Use the tools platform chassis reboot command to perform a reboot.
--{ candidate shared default }--[ ]--
# tools platform chassis rebootBuffer allocation profiles for subinterfaces
To enable subinterface queuing, you must assign a buffer allocation profile to a subinterface. Similar to interface buffer allocation profiles on 7250 IXR platforms, the subinterface buffer allocation profile defines values for MBS (but not CBS).
By default, when a buffer allocation profile is applied to a subinterface, a set of eight queues is always allocated to the subinterface. All eight queues are allocated regardless of the number of queues defined under the qos queues context.
Configuring buffer allocation profiles for subinterfaces
To configure a buffer allocation profile for a subinterface, use the qos buffer-management buffer-allocation-profile command.
If you prefer to apply a buffer allocation using the default SR Linux algorithm, attach an empty buffer allocation profile to the subinterface with no explicit parameters.
Configure a buffer allocation profile for a subinterface
--{ candidate shared default }--[ ]--
# info with-context qos buffer-management buffer-allocation-profile subinterface-buffer-profile
qos {
buffer-management {
buffer-allocation-profile subinterface-buffer-profile {
queues {
queue af1 {
maximum-burst-size 256000
}
queue af2 {
maximum-burst-size 256000
}
queue best-effort {
maximum-burst-size 512000
}
queue expedited {
maximum-burst-size 128000
}
queue nc {
maximum-burst-size 28000
}
}
}
}
}
Configure subinterface queues and forwarding classes
The following example shows additional configuration for subinterface queues and forwarding classes associated with the preceding buffer allocation profile.
--{ candidate shared default }--[ ]--
# info with-context qos queues
qos {
queues {
queue af1 {
queue-index 1
}
queue af2 {
queue-index 2
}
queue best-effort {
queue-index 0
}
queue expedited {
queue-index 6
}
queue nc {
queue-index 7
}
}
}
--{ candidate shared default }--[ ]--
# info with-context qos forwarding-classes
qos {
forwarding-classes {
forwarding-class af1 {
output {
unicast-queue af1
}
}
forwarding-class af2 {
output {
unicast-queue af2
}
}
forwarding-class be {
output {
unicast-queue best-effort
}
}
forwarding-class ef {
output {
unicast-queue expedited
}
}
forwarding-class nc {
output {
unicast-queue nc
}
}
}
}
Displaying subinterface queue resource allocation
Given the scale of the systems, not all subinterfaces can be enabled for subinterface queuing. To display subinterfaces that are configured for subinterface queuing but which are currently on the pending list because of a lack of available resources, use the info from state qos interfaces interface output voq-set-pending and info from state qos interfaces interface output voq-set-statistics-pending commands. Alternatively, you can also use the show qos interface mismatches command.
These commands are also applicable to LAG subinterfaces, which can have multiple member interfaces with different resource allocation issues. In addition, to display LAG subinterfaces that are pending allocation of system LAG resources, use the info from state qos interfaces interface output lag-bundle-pending and info from state qos interfaces interface output lag-system-port-pending commands.
A retry mechanism ensures that if any voq-set or voq-set-statistics resources become available they are allocated to a pending subinterface.
Display interfaces with pending VOQ set
--{ candidate shared default }--[ ]--
# info from state /qos interfaces interface ethernet-1/1.896 output voq-set-pending
voq-set-pending [
ethernet-1/1
]Display interfaces with pending VOQ set statistics
--{ candidate shared default }--[ ]--
# info from state /qos interfaces interface ethernet-1/1.896 output voq-set-statistics-pending
voq-set-statistics-pending [
ethernet-1/1
]
Display VOQ connector sets per line-card
To display the status of voq-connector-sets per line card, forwarding complex, and core, use the info from state platform linecard forwarding-complex core command.--{ candidate shared default }--[ ]--
# info from state / platform linecard 1 forwarding-complex 0 core 1
qos {
resource voq-connector-set {
used 840
free 0
}
}
Display overall system resources for VOQ sets and statistics
To display the overall system resources for VOQ sets and VOQ statistics, use the info from state system utilization qos command.
--{ candidate shared default }--[ ]--
# info from state /system utilization qos
resource lag-bundle {
upper-threshold-set 90
upper-threshold-clear 70
}
resource lag-system-port {
upper-threshold-set 90
upper-threshold-clear 70
used-percent 0
used-entries 9
free-entries 16375
used-high-watermark 9
used-last-high-watermark-time "2026-08-03T02:59:11.726Z (25 minutes ago)"
used-upper-threshold-exceeded false
}
resource voq-set {
upper-threshold-set 90
upper-threshold-clear 70
used-percent 94
used-entries 6720
free-entries 448
used-high-watermark 6720
used-last-high-watermark-time "2026-06-09T04:02:35.675Z (6 minutes ago)"
used-upper-threshold-exceeded true
}
resource voq-set-statistics {
upper-threshold-set 90
upper-threshold-clear 70
used-percent 99
used-entries 1691
free-entries 9
used-high-watermark 1691
used-last-high-watermark-time "2026-06-09T04:04:15.009Z (5 minutes ago)"
used-upper-threshold-exceeded true
}Display pending LAG system resource allocation
--{ candidate shared default }--[ ]--
# info from state qos interfaces interface ouput lag-bundle-pending
# info from state qos interfaces interface ouput lag-system-port-pending
Queue scheduler policies for subinterfaces
Similar to interface operation, each output queue on a subinterface is mapped to either scheduler 0 or scheduler 1, as defined by the scheduler policies, with the following restrictions:
- Scheduler 0 — must have a priority setting of strict, providing strict priority scheduling behavior
- Scheduler 1 — must have no priority configuration defined, providing WRR scheduling behavior
However, when the traffic-managment-mode is set to two-priorities, by default all queues in the subinterface policy are attached to scheduler 1, which is served WRR with equal weights, providing round-robin scheduling. This differs from the operation when the traffic-managment-mode is set to eight-priorities, in which all interface queues are served by strict priority scheduler 0 by default.
Scheduler 0 on subinterfaces
Scheduler 0 operation on subinterfaces is as follows:
- Scheduler 0 supports five priority levels.
- Individual queues are mapped to a priority level based on the value of the scheduler input priority-level parameter. This configuration is supported only for scheduler 0 inputs.
- If multiple queues are mapped to the same priority level, they are served in round-robin fashion.
- Scheduler 0 also supports the configuration of a committed rate, but not a peak rate, for the input queues. You must configure a meaningful committed rate value to prevent packet loss.
- The PIR value for strict priority queues in scheduler policies is set to the same value as CIR, but this PIR value is neither enforced nor configurable for subinterfaces.
- When strict priority is enabled (priority strict), any configured weight is ignored.
Scheduler 1 on subinterfaces
The bandwidth for scheduler 1 inputs is distributed based on the assigned queue weights, committed rate, and peak rate.
Scheduler output parameters
In the subinterface scheduler policy, a scheduler output container exists for every scheduler defining an output type and peak-rate percentage. By default, output-type is set to interface and peak-rate-percent is set to 100.
- scheduler output peak-rate-percent must match for scheduler 0 and scheduler 1.
- If the peak-rate-percent parameter is defined only for scheduler 1, it is applied to both schedulers.
- If the peak-rate-percent parameter is absent for both schedulers, the default peak-rate-percent value (100) is applied.
Default subinterface queue scheduler policy
A default scheduler policy named default is attached to every subinterface that has queuing enabled, as shown in the following output.
--{ candidate shared default }--[ ]--
# info qos scheduler-policies scheduler-policy default
scheduler 1 {
input 0 {
input-type queue
queue-name queue-0
weight 1
}
input 1 {
input-type queue
queue-name queue-1
weight 1
}
input 2 {
input-type queue
queue-name queue-2
weight 1
}
input 3 {
input-type queue
queue-name queue-3
weight 1
}
input 4 {
input-type queue
queue-name queue-4
weight 1
}
input 5 {
input-type queue
queue-name queue-5
weight 1
}
input 6 {
input-type queue
queue-name queue-6
weight 1
}
input 7 {
input-type queue
queue-name queue-7
weight 1
}
output {
output-type interface
peak-rate-pecent 100
}
}Configuring queue scheduler policies for subinterfaces
Configure queue scheduler policies for subinterfaces
In the following example, strict priority scheduler 0 has queues expedited and nc as inputs with priority levels and committed rates defined. WRR scheduler 1 has queues af1, af2, and best-effort as inputs with committed rates, peak rates, and weights assigned. Both schedulers have output-type defined as interface with a peak-rate-percent value of 100.
--{ candidate shared default }--[ ]--
# info qos scheduler-policies scheduler-policy subinterface-scheduler-policy
scheduler 0 {
priority strict
input 0 {
input-type queue
queue-name expedited
priority-level 4
committed-rate-kbps 2000
}
input 1 {
input-type queue
queue-name nc
priority-level 5
committed-rate-kbps 500
}
}
scheduler 1 {
input 1 {
input-type queue
queue-name af1
weight 30
committed-rate-kbps 5000
peak-rate-kbps 10000
}
input 2 {
input-type queue
queue-name af2
weight 20
committed-rate-kbps 4000
peak-rate-kbps 10000
}
input 3 {
input-type queue
queue-name best-effort
weight 1
peak-rate-kbps 10000
}
output {
output-type interface
peak-rate-percent 100
}
}
Queue management profiles for subinterfaces
Similar to interfaces, the queue management profile for subinterface queues either defines WRED curves or alternatively enables ECN. However, if ECN is enabled for a given subinterface queue, the ECN counters are not collected per subinterface queue. Instead, aggregate ECN counters are collected per interface.
Configuring queue management profiles for subinterfaces
To configure a queue management profile for a subinterface, use the qos buffer-management queue-management-profile command.
Configure queue management profile for a subinterface
--{ candidate shared default }--[ ]--
# info with-context qos buffer-management queue-management-profile wred-ecn-1
qos {
buffer-management {
queue-management-profile wred-ecn-1 {
weight-factor 5
wred {
wred-slope all drop-probability all enable-ecn true {
min-threshold-percent 10
max-threshold-percent 25
slope-enabled true
max-drop-probability-percent 50
}
}
}
}
}Applying queue policies and profiles to subinterfaces
Apply queue policies and profiles to a subinterface
--{ candidate shared default }--[ ]--
# info with-context qos interfaces interface eth1.10
qos {
interfaces {
interface eth1.10 {
interface-ref {
interface ethernet-1/1
subinterface 10
}
output {
buffer-allocation-profile sub-if-buffer-profile
queues {
queue test-unicast-queue {
queue-management-profile wred-ecn-1
}
}
scheduler {
scheduler-policy subinterface-scheduler-policy
}
}
}
}
}VOQ statistics collection for subinterfaces
The qos interfaces interface voq-statistics command allows you to explicitly configure VOQ statistics collection on a subinterface. When voq-statistics is set to true for a subinterface, SR Linux attempts to allocate VOQ statistics collection resources from the global VOQ statistics resource pool to that subinterface. This feature allows you to prevent VOQ statistics resource exhaustion by allocating VOQ statistics resources to those subinterfaces that require them most.
This command is also supported to enable VOQ statistics per subinterface. The only difference for subinterface queuing is that the default setting is false, while for interface queuing the default setting is true.
VOQ statistics collection resources are dependent on allocation of flexible counter banks. For more information see "Flexible counter bank allocation" in the SR Linux Configuration Basics Guide.
BUM traffic handling
BUM traffic on 7250 IXR Gen 3 platforms is always replicated with a two-pass mechanism. In the first pass traffic is sent toward the fabric and then the fabric replicates packets to the eligible egress slots. In the second pass, traffic is replicated on the egress device for local subinterfaces. As a result, the ingress VOQ statistics increment on the egress slot VOQ.
Configuring statistics collection for subinterfaces
To enable VOQ statistics collection on a subinterface, use the voq-statistics command. When voq-statistics is set to true, qos_mgr attempts to allocate VOQ statistics collection resources to that subinterface from the global pool.
If voq-statistics is explicitly set to false, qos_mgr deallocates any assigned resources for that subinterface and returns the resources to the global pool.
Configure VOQ statistics collection for a subinterface
--{ candidate shared default }--[ ]--
# info with-context qos interfaces interface ethernet-1/2.1 voq-statistics
qos {
interfaces {
interface ethernet-1/2.1 {
voq-statistics true
}
}
}
Display VOQ statistics allocation status for an interface
To confirm whether VOQ statistics collection resources are allocated to an interface, use the voq-statistics-allocation-status state command. If the allocation of VOQ statistics to the interface is successful, the status is shown as complete. If the allocation is not successful (as a result of resource exhaustion), the status is shown as none.
--{ candidate shared default }--[ ]--
# info with-context from state qos interfaces interface ethernet-1/2 voq-statistics-allocation-status
qos {
interfaces {
interface ethernet-1/2 {
voq-statistics-allocation-status complete
}
}
}
Display VOQ statistics per subinterface
To display VOQ statistics per subinterface, use the same command as for interface VOQ statistics: info from state qos interfaces interface output queues queue queue-statistics aggregate-statistics virtual-output-queue.
--{ candidate shared default }--[ ]--
# info from state qos interfaces interface ethernet-1/1.1 output queues queue unicast-0 queue-statistics aggregate-statistics virtual-output-queue 1
queue unicast-0 {
queue-statistics {
aggregate-statistics {
virtual-output-queue 1 {
queue-depth {
high-threshold-bytes 0
}
low-drop-probability {
transmitted-packets 188337
transmitted-octets 263671800
dropped-packets 218160358
dropped-octets 305424501200
}
medium-drop-probability {
transmitted-packets 0
transmitted-octets 0
dropped-packets 0
dropped-octets 0
}
high-drop-probability {
transmitted-packets 0
transmitted-octets 0
dropped-packets 0
dropped-octets 0
}
}
}
}
}