08-18-2010
09:23 PM
- last edited on
03-25-2019
04:11 PM
by
ciscomoderator
Hi all,
I am setting up my first voip network and am using Autoqos. I have a couple of questions and hope an experienced engineer can confirm my assumptions.
We are using Shoretel phones which I am advised set DSCP "ef" in the TOS byte. Apparently they don't set cos
This means I can trust the phone to mark the packtes, so I use this command to configure auto qos:
"auto qos voip trust"
normally auto qos sets:
"mls qos trust cos"
But I assume that because my phone set DSCP I should change this to:
"mls qos trust dscp"
Does this sound correct so far?
Next quesiton is:
Once a frame has entered a switch port where a phone is plugged in, does the cos get set automatically according to the dscp - cos map?
If so am in correct in my assumption that all switch 802.1q trunk/uplinks I can leave as the default:
"mls qos trust cos"
Thanks, Simon.
Solved! Go to Solution.
08-19-2010 11:02 AM
Hi Simon, your correct on all accounts here.
You'll want to change your switch to trust DSCP.
Once the frame comes into the switch and you have DSCP trusted, when it egresses a trunk we will use the DSCP -> Cos mapping table to mark COS.
Also keep in mind that the 'trust' statement only applies to ingress traffic on that port. Not that it really matters here in your example, just stating that regardless of your egress trunk link trusting cos or dscp...it won't change the fact that we will still do a DSCP->COS mapping and mark the traffic. Its whats on the other side that matters, it will determine whether or not to trust dscp vs cos.
One think to keep in mind is that traffic egressing a trunk on the native vlan will not have an 802.1q tag, so therefor won't have a COS value. If the receiving end is trusting COS, we interpret this as the packet having COS 0. Just something to keep in mind. You can also set your trunks to trust DSCP if you may have traffic that needs to be marked crossing your native vlan.
08-19-2010 11:02 AM
Hi Simon, your correct on all accounts here.
You'll want to change your switch to trust DSCP.
Once the frame comes into the switch and you have DSCP trusted, when it egresses a trunk we will use the DSCP -> Cos mapping table to mark COS.
Also keep in mind that the 'trust' statement only applies to ingress traffic on that port. Not that it really matters here in your example, just stating that regardless of your egress trunk link trusting cos or dscp...it won't change the fact that we will still do a DSCP->COS mapping and mark the traffic. Its whats on the other side that matters, it will determine whether or not to trust dscp vs cos.
One think to keep in mind is that traffic egressing a trunk on the native vlan will not have an 802.1q tag, so therefor won't have a COS value. If the receiving end is trusting COS, we interpret this as the packet having COS 0. Just something to keep in mind. You can also set your trunks to trust DSCP if you may have traffic that needs to be marked crossing your native vlan.
08-19-2010 03:15 PM
Thanks Chad,
I have one more question now I am on track. Auto QoS adds:
"mls qos map cos-dscp x x x x "
Since I am working with and trusting DSCP, do I need a "mls qos map dscp-cos x x x x"?
Or maybe it is not really required as I'm nore really interested in cos anyway?
Cheers, Simon.
08-19-2010 03:35 PM
It's ideal to have the mappings from cos-to-dscp configured on the switch as the default internal mapping are incorrect for EF and DSCP 26.
If you configure trunk on a port, the value that is read from the incoming frame will be the COS value and this will be mapped to the DSCP value configured by the switch.
By default, the mapping is 0 8 16 24 32 40 48 56 while the correct mapping should be 0 8 16 26 32 46 48 56
Please note how 24 is being replaced with 26 and 40 with 46. If you receive a COS value of 5, then the DSCP will be mapped to DSCP 40 causing a breakup on end-to-end QoS design.
Regards,
Edison
08-19-2010 03:47 PM
Exactly. If you are wondering its because we are just doing a straight mapping of COS bits to IP Prec bits (3 left most bits of the TOS Byte) and then just giving the value read as dscp decimal (6 left most bits of TOS Byte)
So Original Settings:
COS | COS binary | DSCP | DSCP binary |
---|---|---|---|
0 | 000 | 0 | 000000 |
1 | 001 | 8 | 001000 |
2 | 010 | 16 | 010000 |
3 | 011 | 24 | 011000 |
4 | 100 | 32 | 100000 |
5 | 101 | 40 | 101000 |
6 | 110 | 48 | 110000 |
7 | 111 | 56 | 111000 |
So the changed values extend past the 3 left most bits to give us this:
COS | COS Binary | DSCP | DSCP binary |
---|---|---|---|
3 | 011 | 26 | 011010 |
5 | 101 | 46 | 101110 |
Message was edited by: Chad Peterson
03-11-2011 12:19 PM
Sorry to revive an old thread, but I wanted to point out that in the SRND for both UCM 8.0 (and now 8.5), Cisco states that they are moving from DSCP 26 to DSCP 24.
For example, in both guides, page 3-40 has a note - "Note Cisco has transitioned the marking of voice control protocols from DSCP 26 (PHB AF31) to DSCP 24 (PHB CS3). However, some products still mark signaling traffic as DSCP 26 (PHB AF31); therefore, Cisco recommends that you reserve both AF31 and CS3 for call signaling."
You mention that Cisco is replacing 26 with 24 - the opposite of what the SRND guide states. I'm not sure if this adds any value to the thread, but it certainly confused me and since I remember reading that, I went back and tracked it down
Even back as 2007 (when I first got involved in QoS configs), I remember reading that DSCP 24 was the 'preferred' value to set, even though the defaults were at 26.
Thanks,
Rob.
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