04-11-2012 01:40 PM - edited 03-07-2019 06:04 AM
Hi everyone,
I am preparing to implement QoS in our environment. For our circumstances, because the subject of QoS can be pretty vast, I've decided to break down the default auto QoS sytax generated on a 3750 and change it as needed. I understand much of it, but have always kind of found COS to DSCP mappings confusing and hopefully someone can help me understand it better.
Here is the default COS syntax generated on 3750 for auto qos;
mls qos map policed-dscp 24 26 46 to 0
mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos srr-queue input bandwidth 90 10
mls qos srr-queue input threshold 1 8 16
mls qos srr-queue input threshold 2 34 66
mls qos srr-queue input buffers 67 33
mls qos srr-queue input cos-map queue 1 threshold 2 1
mls qos srr-queue input cos-map queue 1 threshold 3 0
mls qos srr-queue input cos-map queue 2 threshold 1 2
mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3 3 5
mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7
mls qos srr-queue input dscp-map queue 1 threshold 3 32
mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48
mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56
mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output cos-map queue 1 threshold 3 5
mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 2 4
mls qos srr-queue output cos-map queue 4 threshold 2 1
mls qos srr-queue output cos-map queue 4 threshold 3 0
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
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 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7
mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400
mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242
mls qos queue-set output 1 buffers 10 10 26 54
mls qos queue-set output 2 buffers 16 6 17 61
mls qos
My question is in the first two lines;
mls qos map policed-dscp 24 26 46 to 0
mls qos map cos-dscp 0 8 16 24 32 46 48 56
The first line, seems to me, to be saying that traffic marked as CS3, AF31, and EF will be set to the IP Precedence value of 0. However, according to what I've read, this is not a very high priority;
PCP | Network priority | Acronym | Traffic characteristics |
---|---|---|---|
1 | 0 (lowest) | BK | Background |
0 | 1 | BE | Best Effort |
2 | 2 | EE | Excellent Effort |
3 | 3 | CA | Critical Applications |
4 | 4 | VI | Video, < 100 ms latency |
5 | 5 | VO | Voice, < 10 ms latency |
6 | 6 | IC | Internetwork Control |
7 | 7 (highest) | NC | Network Control |
Am I misunderstanding this?
Solved! Go to Solution.
04-11-2012 02:55 PM
As far as I'm aware you are correct, this is saying to police these values down to this level but this is ONLY if you are performing policing & your exceed action is to reference this 'policed-dscp' qos map.
It would be worth having a read of this:
Thanks,
Adam
04-12-2012 02:46 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
You're understanding is correct. As Adam described, those are DSCP conversion values if using a policing statement to "mark down" traffic that's oversubscribed. In other words, for example, for DSCP marked packets initially marked with 24, 26 or 46, if they were "too fast" (per a mark down policer), they would be remarked to just DSCP 0. The conversion table defaults to same markings, so a packet with 22 would be "remarked" to 22.
The purpose of doing this is to deprioritize their priority because such packets were out-of-profile. So for example an out-of-profile VoIP packet would be deprioritized and treated as any other BE packets. This doesn't have to be done, it's optional. Also for "too fast" packets, another option might be to drop the packet. Lastly, if you leave the packet with the same marking, the policer's stats can be used to let you know you have traffic exceeding expected transmission rate.
You didn't ask further about you confusion on the CoS statement, but what that does is map (convert) each of the CoS values to a DSCP value. What it appears to be doing is converting each CoS value to the corresponding DSCP class selector value except for CoS 5 which is converted to DSCP EF (46).
04-12-2012 09:55 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Cisco AutoQoS didn't, at least in what you posted, add a policing statement, they modified the default mark down map.
When working with real-time vs. routing control, what's most important is debatable. If a routing update is telling this router about some distance network becoming reachable or not, what's more important, keeping VoIP quality high or getting the routing update a few milliseconds sooner? Generally, we can wait a little on the routing information.
However, getting the routing update is very important, so we don't want 100% VoIP traffic to stave bandwidth such that the routing update isn't received, so we police the VoIP traffic to stay within the expected bounds. (NB: on routers running CBWFQ with VoIP in LLQ, there's an implicit policer that drops all traffic in the LLQ beyond what's expected [when there's congestion].) We also place routing updates in the highest non-priority class.
04-11-2012 02:55 PM
As far as I'm aware you are correct, this is saying to police these values down to this level but this is ONLY if you are performing policing & your exceed action is to reference this 'policed-dscp' qos map.
It would be worth having a read of this:
Thanks,
Adam
04-12-2012 02:46 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
You're understanding is correct. As Adam described, those are DSCP conversion values if using a policing statement to "mark down" traffic that's oversubscribed. In other words, for example, for DSCP marked packets initially marked with 24, 26 or 46, if they were "too fast" (per a mark down policer), they would be remarked to just DSCP 0. The conversion table defaults to same markings, so a packet with 22 would be "remarked" to 22.
The purpose of doing this is to deprioritize their priority because such packets were out-of-profile. So for example an out-of-profile VoIP packet would be deprioritized and treated as any other BE packets. This doesn't have to be done, it's optional. Also for "too fast" packets, another option might be to drop the packet. Lastly, if you leave the packet with the same marking, the policer's stats can be used to let you know you have traffic exceeding expected transmission rate.
You didn't ask further about you confusion on the CoS statement, but what that does is map (convert) each of the CoS values to a DSCP value. What it appears to be doing is converting each CoS value to the corresponding DSCP class selector value except for CoS 5 which is converted to DSCP EF (46).
04-12-2012 09:34 AM
The reasoning of policing the VoIP packets in such a way is vexxing. In a constraing situation, it seems to me that the most important packets would be the router/network's own traffic (handled with PAK priority - routing protocols, etc), then call control and RTP. Why would Cisco add a policing statement in its auto QoS baseline stating that if there's a contraint that RTP and call control be marked down to Best Effort? Maybe I'm missing something.
04-12-2012 09:55 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Cisco AutoQoS didn't, at least in what you posted, add a policing statement, they modified the default mark down map.
When working with real-time vs. routing control, what's most important is debatable. If a routing update is telling this router about some distance network becoming reachable or not, what's more important, keeping VoIP quality high or getting the routing update a few milliseconds sooner? Generally, we can wait a little on the routing information.
However, getting the routing update is very important, so we don't want 100% VoIP traffic to stave bandwidth such that the routing update isn't received, so we police the VoIP traffic to stay within the expected bounds. (NB: on routers running CBWFQ with VoIP in LLQ, there's an implicit policer that drops all traffic in the LLQ beyond what's expected [when there's congestion].) We also place routing updates in the highest non-priority class.
04-12-2012 10:21 AM
Thank, Joseph, I appreciate the input.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide