Interface shows Queuing strategy: FIFO even though DSCP trust-map and queue weights are configured

Hello,

Our goal is to implement QoS to prioritize voice traffic and other critical application traffic across the network. We are currently testing classification and prioritization using both DSCP and 802.1p (CoS) markings. Our IP phones mark packets using both mechanisms—DSCP at Layer 3 and 802.1p at Layer 2—so we want to ensure that the switch correctly trusts these markings and places the traffic into the appropriate high-priority queues. The objective is to guarantee low latency and minimal packet loss for voice while still allowing other application traffic to be handled according to its assigned priority.

We recently enabled trust-map dscp default on one of our switch interfaces and we can see that traffic is being classified into different queues. However, when checking the interface details, the output shows that the queuing strategy is FIFO, and we expected it to be WRR (Weighted Round Robin) so that higher-priority queues would be serviced more frequently rather than strictly in order of packet arrival.

Does the line Queuing strategy: fifo mean that QoS is not actually being applied on the interface?

Below is a sanitized example of the outputs (IPs, MAC addresses, and hostnames have been modified):

CORE-SW01# show interface ethernet 1/1/10:1

Ethernet 1/1/10:1 is up, line protocol is up
Description: EdgeRouter01-Te0/1/0
Hardware is Eth, address is 3a:7c:92:11:ab:cd
    Current address is 3a:7c:92:11:ab:cd
Pluggable media present, SFP+ type is SFP+ 10GBASE-SR
    Wavelength is 850
    Configured media fec option is none
Interface index is 42
Internet address is not set
Interface IPv6 oper status: Disabled
MTU 9216 bytes, IP MTU 9184 bytes
LineSpeed 10G
Flowcontrol rx off tx off
ARP type: ARPA
Queuing strategy: fifo

Input statistics:
     984321567890 packets, 563218765432100 octets
     12456789 Multicasts, 1532 Broadcasts, 984309111569 Unicasts

Output statistics:
     812345678901 packets, 678912345678901 octets
     15234678 Multicasts, 345678 Broadcasts, 812329098545 Unicasts

Rate Info(interval 30 seconds):
     Input 210 Mbits/sec, 40200 packets/sec
     Output 125 Mbits/sec, 25500 packets/sec

We do see differentiated traffic across queues:

CORE-SW01# show queuing statistics interface ethernet 1/1/10:1

Interface ethernet1/1/10:1
Queue Packets                  Bytes                    Dropped-Packets
0     712345678901             600123456789012          0
1     31234567890              24567890123456           0
2     0                        0                        0
3     0                        0                        0
4     145678901                15678901234              0
5     134567890                14567890123              0
6     5400                     560000                   0
7     890                      75000                    0

Configured queue weights:

CORE-SW01# show queuing weights interface ethernet 1/1/10:1

Queue    Weight(In percentage)
--------------------------------
0         1
1         2
2         3
3         4
4         5
5         10
6         25
7         50

Relevant interface configuration:

interface ethernet1/1/10:1
 description "EdgeRouter01-Te0/1/0"
 no shutdown
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30,40,50
 flowcontrol receive off
 trust-map dscp default
 sflow enable

Since traffic is clearly being classified into queues and queue weights are defined, we expected WRR scheduling to be active.

Is the Queuing strategy: fifo line simply referring to the internal behavior of each queue, or does it indicate that QoS scheduling (WRR) is not actually being used?

Thanks in advance for any clarification.