QoS on a 2960 with no outgoing DSCP

[r.vanschendel]

Hi

We have a WS-C2960S-48TS-L switch with QoS .

I have configured 1 ports and 1 trunk port.

interface GigabitEthernet1/0/34

description

switchport access vlan 104

mls qos trust dscp

!

interface GigabitEthernet1/0/52

description

switchport mode trunk

logging event trunk-status

logging event spanning-tree

udld port

mls qos trust dscp

storm-control broadcast level 30.00

storm-control multicast level 30.00

On port Gi 1/0/34 I see incomming DSCP traffic

GigabitEthernet1/0/34 (All statistics are in packets)

  dscp: incoming
-------------------------------

  0 -  4 :         374            0            0            0            0
  5 -  9 :           0            0            0            0            0
10 - 14 :           0            0            0            0            0
15 - 19 :           0            0            0            0            0
20 - 24 :           0            0            0            0            0
25 - 29 :           0         3203            0            0            0
30 - 34 :           0            0            0            0            0
35 - 39 :           0            0            0            0            0
40 - 44 :           0            0            0            0            0
45 - 49 :           0      1574189            0            0            0
50 - 54 :           0            0            0            0            0
55 - 59 :           0            0            0            0            0
60 - 64 :  

cos: incoming
-------------------------------

  0 -  4 :     1102822            0            0            0            0
  5 -  7 :      477688            0            0

But I see no outgoing DSCP traffic on the trunk.

dscp: outgoing
-------------------------------

  0 -  4 :    13528641            0            0            0            0
  5 -  9 :           0            0            0            0            0
10 - 14 :           0            0            0            0            0
15 - 19 :           0            0            0            0            0
20 - 24 :           0            0            0            0            0
25 - 29 :           0            0            0            0            0
30 - 34 :           0            0            0            0            0
35 - 39 :           0            0            0            0            0
40 - 44 :           0            0            0            0            0
45 - 49 :           0            0            0         6519            0
50 - 54 :           0            0            0            0            0
55 - 59 :           0            0            0            0            0
60 - 64 :           0            0            0            0

What could be wrong ?

[Peter Paluch]

Hello,

Did you activate the QoS on the global configuration level? On recent Catalyst switches, the QoS support has to be enabled first in the global configuration mode using the command

mls qos

If you did use that command then please include the output of the following commands:

show mls qos interface gi1/0/34

show mls qos interface gi1/0/52

Best regards,

Peter

[Edison Ortiz]

On the trunk port, I suggest trusting COS instead of DSCP and make sure to modify the cos-dsp values with the following command:

mls qos map cos-dscp 0 8 16 24 32 46 48 56

[Peter Paluch · Accepted solution]

Edison,

I am perhaps stealing the thread, but you just hinted on an issue I wanted to ask about for a long time.

As the Catalysts can ben configured to trust either CoS or DSCP, you have to ultimately select just one of them and the second value will be rewritten accordingly. I have recommended people to go for DSCP trust because of these reasons:

• DSCP is present in each IP packet, hence its presence is ubiquitous in IP traffic and is more flexible. The CoS is present only in tagged packets or can be implicitly assumed using the mls qos cos command.
• End stations do not seem to routinely support 802.1p style of priority-tagging their traffic. Despite testing lots of software with modifiable QoS settings (IP softphones, packet generators...) at least on MS Windows, none of them ever produced an 802.1p or 802.1q tagged frame. On the other hand, they were able to set the DSCP field properly. Thus, using CoS trust with end stations is practically unusable.
• The CoS marking is preserved only on trunks and voice ports within the voice VLAN, and is limited within a single broadcast domain. Access ports always remove 802.1q tags from egress frames in their access (data) VLAN. Also, there are possible issues with the native VLAN. Routers do not respect or preserve the CoS marking unless specifically configured to do so, and even if they do, the CoS marking does not fit into the DiffServ model (think drop priorities derived from AF classes, for example).  DSCP marking is preserved end-to-end.
• Catalyst switches internally represent the priority as a DSCP code, not as a CoS value, hence the DSCP seems to me to be more "natural" even for switches.

Considering the fact that all recent Catalyst switches understand DSCP and for those which do not, the DSCP-to-CoS mapping table can modify the resulting CoS to administrator's - and those switches' - liking, I personally do not see any compelling reason to use CoS trust. But am I thinking correctly here? Please correct me - or confirm my thoughts!

Thank you!

Best regards,

Peter

[Marwan ALshawi]

Hi Peter,

just to share some knowledge with you here

as i know about the 3750 you have the ability to do what yo mentioned about having all the trust, mapping and queuing based on DSCP and it dose work if you want more details you could refer to the SRND of Telepresence QoS LAN section for more detail about this

but again if you have the trust CoS you know the DSCP will be rewritten unless you use a Command that enforce the switch to ignore re writing the DSCP even if you change the CoS

HTH

[Matthew Blanshard]

Hello Peter,

You are 100% correct in your assessment of why trusting DSCP is perfectly fine on Catalyst switches because they all support DSCP these days.  The only condition where trust COS is preferred is when you have a situation where you have a phone with a PC connected to the phone and you want to conditionally trust the phone but not the PC.  If you trust COS then the tagged traffic from the phone will be trusted and the PC's traffic never will.

This is pretty much the only scenario I can think of where you would want to do this.  Since there are many places where you want ip phones but don't trust the users this is the way they want do things.

-Matt

[Peter Paluch]

Hi Matt,

Thanks so much for answering!

Just a thought: Cisco IP phones are currently capable of rewriting the CoS value in frames sent by the PC. Would it be possible to enhance the IP phones' functionality so that they are capable of rewriting the DSCP value as well? Again, this is an enhancement request which is, in my opinion, quite logical considering the fact that CoS marking imposed by the PC is a rare thing as we've discussed earlier.

Best regards,

Peter

[Matthew Blanshard]

Hello Peter,

I think that is a very reasonable enhancement request and will look into getting that submitted if it does not already exist.

-Matt

[Edison Ortiz]

Peter,

You are correct. The DSCP-to-COS mappings will take care of having dscp trusted everywhere. The caveat is the correct mappings are entered in the switch else the translation will produce odd results.

An old fashioned and since I know the trunk will see COS values, not DSCP on the header - I don't really want to rely on the translation. However, if your customer isn't network savvy, it's best to recommend DSCP on all ports.

Regards,

Edison.

[r.vanschendel]

Hi Peter

Thanks for your answer.

I have fixed the problem with remove the auto MLS QOS  settings and configure manualy the mls QOS dscp settings on  the switch. And now it works fine.

You are 100 % correct about the statement of the DSCP field. Because I see on the LAn's  more and more softphones on the PC's ?Laptop. And than you can not use the COS field on layer-2.

Regards Rene

@ The answer is a littlebit late because I'am just back from my holoday.