QoS on 2960X Cisco IOS

[jduty]

I am troubleshooting QoS in relation to VoIP traffic and finding it hard to understand how the queues, queue-sets, thresholds, buffers and the CoS and DSCP mappings to queue's/thresholds on the 2960X switches actually work. Is there a way to view what queue/threshold a specific packet is going into on the switch? I have verified that the VoIP traffic in question is being seen correctly as DSCP 46, but i feel like there is no way of knowing right now which queue/threshold it is being placed into. 

A specific question I have is in the default configuration when you run the "mls qos" command, it generates the default cos-dscp mappings, the threshold and buffer mappings and queue to threshold mappings. In those queues to threshold mappings, there are things mapped to threshold 3 and 4, but in the output queue-sets, only thresholds 1 and 2 are used. What I don't understand is the traffic that is getting mapped to threshold 3 and 4 still works, but does this mean qos isn't being applied at all? I have the configuration listed below and bolded the question "area".

Thanks for your help on this...

mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos srr-queue output cos-map queue 1 threshold 3 4 5
mls qos srr-queue output cos-map queue 2 threshold 1 2
mls qos srr-queue output cos-map queue 2 threshold 2 3
mls qos srr-queue output cos-map queue 2 threshold 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 0
mls qos srr-queue output cos-map queue 4 threshold 3 1
mls qos srr-queue output dscp-map queue 1 threshold 3 32 33 40 41 42 43 44 45
mls qos srr-queue output dscp-map queue 1 threshold 3 46 47
mls qos srr-queue output dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 2 threshold 1 26 27 28 29 30 31 34 35
mls qos srr-queue output dscp-map queue 2 threshold 1 36 37 38 39
mls qos srr-queue output dscp-map queue 2 threshold 2 24
mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3 0 1 2 3 4 5 6 7
mls qos srr-queue output dscp-map queue 4 threshold 1 8 9 11 13 15
mls qos srr-queue output dscp-map queue 4 threshold 2 10 12 14
mls qos queue-set output 1 threshold 1 100 100 50 200
mls qos queue-set output 1 threshold 2 125 125 100 400
mls qos queue-set output 1 threshold 3 100 100 100 400
mls qos queue-set output 1 threshold 4 60 150 50 200
mls qos queue-set output 1 buffers 15 25 40 20
mls qos

show mls qos queue-set
Queueset: 1
Queue : 1 2 3 4
----------------------------------------------
buffers : 15 25 40 20
threshold1: 100 125 100 60
threshold2: 100 125 100 150
reserved : 50 100 100 50
maximum : 200 400 400 200
Queueset: 2
Queue : 1 2 3 4
----------------------------------------------
buffers : 25 25 25 25
threshold1: 100 200 100 100
threshold2: 100 200 100 100
reserved : 50 50 50 50
maximum : 400 400 400 400

[Joseph W. Doherty]

"Is there a way to view what queue/threshold a specific packet is going into on the switch?"

Physically, not that I'm aware of.

Logically, yes.  You need to know attributes of frame or packet, ingress port config, egress port config, and all other related config statements.

Your confusion over thresholds is due to one is egress queue thresholds, the other buffer thresholds; different things.

[jduty]

Ok, I didn't think there would be a way to verify what queue/threshold certain traffic was taking. Thanks for confirming. When I go to look out the queue-sets and the available commands when editing them, there is no option to reference threshold 3 or 4. Why are they created if they aren't used since they aren't (and apparently, can't be) referenced in the output queue-sets. 

I took a deep dive into Cisco's QoS documentation and have learned some, but still am a bit confused regarding what exactly is needed to have functioning QoS. At this point, I want to know if you can implement just the marking and classification by DSCP and CoS values (mls cos trust dscp/cos) and have that listen the the queues/thresholds/buffers that are created automatically when you run "mls qos" command. Another way to put it, are the class-maps, policy-maps and service-policies (in addition to what I have listed before) needed to just get the bare bones traffic "sorting" into the automatically generated queue's?  

[Joseph W. Doherty · Accepted solution]

"Ok, I didn't think there would be a way to verify what queue/threshold certain traffic was taking."

Yes and no.  You asked about checking for a specific packet, you cannot, again to my knowledge, "watch" a specific packet hit a queue unless all your packets are the same, or you just send one packet through the switch at a time, or if you have mixed types of packets, you have a count of each being sent through the switch.

The 2960X has commands to show packet counts for CoS/ToS matches and for hits and drops though interface egress queues.  Try show mls qos interface stat.

Again, you confusion about thresholds is that keywords means different things in different commands.

mls qos srr-queue output dscp-map queue queue-id { dscp1 ... dscp8 | threshold threshold-id dscp1 ... dscp8 }

For threshold-id, the range is 1 to 3.  (It's an egress queue drop limit, which there are just 3.

mls qos queue-set output qset-id threshold [ queue-id ] drop-threshold1 drop-threshold2 reserved-threshold maximum-threshold

queue-id

(Optional) The queue in the queue set on which the command is performed. The range is 1 to 4.

Oh, BTW, and to confuse further, the four egress queues are sometimes referred using 0..3, and sometimes as 1..4.

To have functioning QoS, on that platform, you only need to insure QoS is enabled.

Of course, whether the QoS is suitable for your needs, is an entirely different (and rather important) question.

The default QoS (which from what you've posted, appears to have been modified), basically enable 4 egress queues, each, I recall, guaranteed an quarter of the bandwidth.  IPPrec's and/or CoS's eight classes, I also recall, might just be split into pairs and directed to one of the four egress queues.  PQ (often very much recommended for VoIP bearer) is NOT enabled.

BTW, with default QoS, interfaces reset ToS/CoS to zero, and direct all traffic to one egress queue, which besides losing our ToS/CoS tag, by default, provides only 1/4 buffer resources you have with QoS disabled.  (Many have noticed performance problems on these, and similar architecture, switches when QoS enabled - this is the most common reason why.)

Another option these platforms often offer is AutoQoS.  My opinion of it, it generally will do well for VoIP (beyond that, ah, did I mention it generally does VoIP well?).

Regarding QoS documentation for this architecture being a bit confusing, perhaps I understand QoS better than most, but I never fully understood how QoS fully worked on this architecture until a Cisco engineer published a paper within these forums.  (Although that paper finally made clear the QoS architecture to me, many might still not understand it even after reading that paper.  Unfortunately, last time I looked for that document, I was unable to find it, but just found it!  C3750 QoS Explained)  

[edit - oops hit post before I intended]

My recommendation would be to first figure out what QoS policy you want/need, and then, how to come closest to it on your platforms.

I suggest that, because with QoS, it's very easy to make things worse when you don't fully understand what the platform is doing.  Or, you might try using Cisco's AutoQoS, which has the goal of providing "QoS" without needing to much understand the technolgy (oh, did I mention AutoQoS usually handles VoIP well?).

[jduty]

"Ok, I didn't think there would be a way to verify what queue/threshold certain traffic was taking."

Yeah, I should have been a bit more specific in what I was looking for. I knew that you could view the stats on an interface and see the counters change for the different queues, but was curious more if I could track traffic like a specific RTP stream for a VoIP call. But I understand what you are saying. 

"Again, your confusion about thresholds is that keywords means different things in different commands."

I think I finally got it. At least enough to continue on. There are some commands that have the word threshold in them, but they aren't neccesarily referring to a specific threshold? To be more specific, "mls qos queue-set output qset-id threshold [ queue-id ] drop-threshold1 drop-threshold2 reserved-threshold maximum-threshold"... even though the word threshold is part of the command, it is actually looking for a queue-id, not the threshold-id which is why some commands appears to have more thresholds than are actually included in the queue-sets? I also caught that piece where sometimes the queues are referred to being 0-3 and other times its 1-4. (C'mon on Cisco... )

"BTW, with default QoS, interfaces reset ToS/CoS to zero, and direct all traffic to one egress queue, which besides losing our ToS/CoS tag, by default, provides only 1/4 buffer resources you have with QoS disabled."

I read about the default CoS values in the Cisco QoS documentation, which makes sense why when interpreting the dscp-queue maps (and cos-queue maps) and comparing it to the output queue stats I see a lot of packet hits in that queue, which actually maps CoS to 0. Most of our devices aren't actually marking their packets when they transmit other than our VoIP phones which I found were sometimes (on some switches) were not being trusted correctly and were still being re-marked with a CoS value of 0. After changing it to the correct "auto trust qos dscp/cos" setting, I could then see that packets through a port mirror with the correct DSCP of 26/46 and AF/EF values.

I will definitely check out that document. Appreciate your help and expertise on the topic! We went down a bunny trail of trying to figure our why our VoIP quality was so terribly poor (we knew we had installed a new wireless infrastructure, but couldn't find any problems with that to be causing our VoIP issues) and starting digging into how the previous network administrator had configured the qos on the switches and have learned quite alot. Needless to say, most of it looks to just be relying on mostly default queues and the cos/dscp-queue mappings and then priority-queue out and auto trust qos settings. There isn't much with class-maps, policy-maps or assigning service-policies to interfaces. I wanted to understand QoS a bit more and, more specifically, see if you actually needed the class-maps, policy-maps and service-policies to make QoS work, or if the limited queue-mappings we were using would be sufficient. Apologize for the long post and extra detail, but thought it might help explain what was going on. (On a side note, it ended up being that several areas were being blasted by way too much 2.4GHz traffic that was chewing through airtime utilization and causing extremely bad latency issues which in turn killed our VoIP quality.) 

[Joseph W. Doherty]

Well, the keyword of threshold, in the various QoS config commands, does relate to some threshold settings, but they do vary between statements, and unless you check the command syntax carefully, a value immediately after the threshold command might not be the "threshold".  The queue-set command is a good example, as the queue-id is an optional value that can be entered immediately after the threshold keyword.

Actually, first time I encountered QoS on a Cisco switch, it was after doing QoS on Cisco routers.  I was really surprised that Cisco's default, when you enabled QoS on most then gen switches, was to reset the ToS/CoS unless you explicitly did something to NOT reset the value.  This, perhaps, because on a Cisco router there's no QoS effect, including resetting ToS/CoS, until you explicitly configure there to be an effect.  Whereas on the Cisco switches, there's some QoS effect when you "enable" QoS.  I.e., I suspect Cisco, when you enable QoS on a Cisco switch wants you to further "are you sure" by trusting such a marking upon ingress, this further confirming you intend a QoS effect.  (BTW, 3650/3850 and later Cisco switches' QoS, now operate much like Cisco's routers have been doing for years.)

Ah, wireless.  I love, as many do, how "convenient" it can be.  I hate, how well it does NOT (very well) guarantee any service levels.  (Heck, it can be worst then back in the ye olden shared Ethernet hubs.)  Real-time video, across wireless, can be "fun" too.

BTW, just a couple of points about wireless, that many don't seem to be aware of are: allowing "early" wireless standards clients to connect to your AP, or if using LWAPs, you probably should configure, if supported, TCP adjust-mss for the tunnel traffic between LWAP and wireless controller.