Auto qos trust dscp question

Answered Question
Aug 18th, 2010

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.

I have this problem too.
0 votes
Correct Answer by Chad Peterson about 3 years 7 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
Correct Answer
Chad Peterson Thu, 08/19/2010 - 11:02

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.

simonosullivan Thu, 08/19/2010 - 15:15

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.

Edison Ortiz Thu, 08/19/2010 - 15:35

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

Chad Peterson Thu, 08/19/2010 - 15:47

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

robdog01 Fri, 03/11/2011 - 12:19

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.

Actions

Login or Register to take actions

This Discussion

Posted August 18, 2010 at 9:23 PM
Stats:
Replies:5 Avg. Rating:5
Views:3129 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 14,997
2 8,150
3 7,720
4 7,078
5 6,710
Rank Username Points
195
80
59
57
57