'priority queue out' - how does it work ?

[tedauction]

Hello, on my WS-C2960-48PST-L I have an interface has the command 'priority-queue out' configured on it.

This interface shows that the queuing strategy is FIFO. Is this normal ? I am concerned that my 'EF' marked traffic may not be getting priority treatment and that the command 'priority-queue out' is actually doing nothing ?

I thought that when you configured 'priority-queue out' the queuing strategy of the interface would show something different to just ''Queueing strategy: fifo' ?

Thank you for any explanation.

Router#sh queueing int fa0/1
Interface FastEthernet0/1 queueing strategy: none

interface FastEthernet0/1
description Connection to Router
switchport trunk allowed vlan 10,11,30,80,99,110,111
switchport mode trunk
srr-queue bandwidth share 1 70 25 5
srr-queue bandwidth shape 3 0 0 0
priority-queue out
mls qos trust dscp

FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0026.0a85.4332 (bia 0026.0a85.f334)
Description: Connection to Router
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 8/255, rxload 9/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:17, output 00:00:00, output hang never
Last clearing of "show interface" counters 2d18h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 12759
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 3808000 bits/sec, 495 packets/sec
5 minute output rate 3150000 bits/sec, 836 packets/sec
84572114 packets input, 80790424446 bytes, 0 no buffer
Received 49010 broadcasts (4849 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 4849 multicast, 0 pause input
0 input packets with dribble condition detected
172766975 packets output, 89604731550 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

[Joseph W. Doherty]

For PQ to work, I believe QoS must be globally enabled on a 2960.  Is it on yours?  (You'll also need to insure your using DSCP values [as you mentioned EF] are what's being used for QoS treatment and that you trust them upon ingress, otherwise I believe a 2960 will reset the ToS to BE.)

Assuming QoS is correctly configured, I don't recall whether the interface will show a different queuing methodology.  It might not, as sometimes there's a bit of a "disconnect" between high order interface stats shown by IOS and what the hardware is doing.  Sometimes you need to issue additional show commands to find out more about what the hardware is doing.

BTW, I see you're also shaping the PQ, which could negate PQ treatment if your PQ rate is above the shaped rate.

[Francesco Molino · Accepted solution]

Hi

the fifo information will remains as is even when you're setting priority-queue out. This allows the Q1 to take all bandwidth when a traffic in Q1 is still present. With this commande the value of shape and share for Q1 are also useless. 

Now regarding your drops, you need to use the show mls output commands to see which type of traffic has been dropped but quite sure that nothing to do with EF traffic in a normal traffic congestion. 

Thanks

PS: Please don't forget to rate and mark as correct answer if this answered your question 

[Joseph W. Doherty · Accepted solution]

PQ will override the share setting; but I thought (?) I recall shape will still be active.

[Francesco Molino]

PQ will override share and shape for queue 1 only.