cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
13940
Views
0
Helpful
5
Replies

Auto qos trust dscp question

sossie
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

Chad Peterson
Cisco Employee
Cisco Employee

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.

View solution in original post

5 Replies 5

Chad Peterson
Cisco Employee
Cisco Employee

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.

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.

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

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:

COSCOS binaryDSCPDSCP binary
00000000000
10018001000
201016010000
301124011000
410032100000
510140101000
611048110000
711156111000

So the changed values extend past the 3 left most bits to give us this:

COSCOS BinaryDSCPDSCP binary
301126011010
510146101110

Message was edited by: Chad Peterson

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco