cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3688
Views
0
Helpful
6
Replies

Trust COS or DSCP on switch to switch trunk

Bill19795_2
Level 1
Level 1

So I know that COS only is available in a trunk connection. My question is when configuring a trunk between two switches should I trust the COS or DSCP on the link? I would think you would trust the COS value but I have been questioning myself lately. If I have a device that only generates DSCP values such as Unity or Call Manger and it goes over this trunk how it will place the voice traffic in the correct priority queue on the interface if it is only concerned with COS values and Unity only marks DSCP.

1 Accepted Solution

Accepted Solutions

Bill19795 wrote:

OK but according to my previous post I should not have to configure the DSCP-TO-COS mapping as it is alreayd there on the 6500. Also still using my Unity example. It maks the correct DSCP value on it's port. I trust the DSCP mapping of Unity. It now goes accross the 802.1q trunk to the other switch. I have the below commands configure for queuing on the Trunk link and the port for Unity.


Now as Unit generates the traffic it will only generate DSCP markings. I trust the DSCP but will the switch conver the DSCP to COS and perform the correct queueing on the port that Unity is connected to? Also as it travels over the Layer 2 link to the other 6500 will it convert the DSCP to COS and perform the apropriate queueing? On the other side of the trunk link I am mapping the COS to DSCP and trusting the COS value so as it goes over the link it should still be correct.

Bill

You don't have to configure the DSCP-to-CoS map if you are happy with the current settings.

The switch will indeed convert the DSCP to a CoS value because otherwise it couldn't queue it on egress. So to travel over the L2 link it has to use a CoS value to queue it on the outbound trunk port.

Jon

View solution in original post

6 Replies 6

Jon Marshall
Hall of Fame
Hall of Fame

Bill19795 wrote:

So I know that COS only is available in a trunk connection.

Bill

Not necessarily. There will be a CoS value in the 802.1q tag but there might also be a DSCP value in the IP header and that can be used by most switches if you want eg. see the 3560 config guide as an example -

3560 trust states

Some switches also support mapping DSCP values to egress queues directly as the 3560 does so you can also send the traffic out of the switch based on DSCP. Other switches only allow mapping egress queues to CoS values but that is what the DSCP-to-CoS map is used for on the switch ie. you can trust the incoming DSCP value then map it to a CoS value which gets mapped to a specific egress queue.

Jon

Ok that is fine for a 3560. How about a 6500 sup 720. I don't see any DSCP queing on that device. I also don't see where I should configure the DSCP-to-COS maps according to the QOS SRND.

If I have device, Unity, that is connected to Gig 9/1 and I trust the COS values. It then has to cross an 802.1q trunk link to get to another 6500 switch. Should I trust the COS values accross the trunk? Also there is only queueing for the COS values so do I have to map the DSCP to COS in this case? Is there no queuing for DSCP values on a 6500 SUP 720?

Also is there a default DSCP to COS map? I issue the following command and get the output below

6513#show mls qos map dscp-cos
   Dscp-cos map:                                  (dscp= d1d2)
     d1 :  d2 0  1  2  3  4  5  6  7  8  9
     -------------------------------------
      0 :    00 00 00 00 00 00 00 00 01 01
      1 :    01 01 01 01 01 01 02 02 02 02
      2 :    02 02 02 02 03 03 03 03 03 03
      3 :    03 03 04 04 04 04 04 04 04 04
      4 :    05 05 05 05 05 05 05 05 06 06
      5 :    06 06 06 06 06 06 07 07 07 07
      6 :    07 07 07 07

I do not have a DSCP to COS map configured. I do have COS to DSCP configured. Is the DSCP to COS automatic?

Bill

Ok that is fine for a 3560 - well you could have been more specific with your original question and specified it was a 6500

How about a 6500 sup 720. I don't see any DSCP queing on that device. I also don't see where I should configure the DSCP-to-COS maps according to the QOS SRND.

If I have device, Unity, that is connected to Gig 9/1 and I trust the COS values. It then has to cross an 802.1q trunk link to get to another 6500 switch. Should I trust the COS values accross the trunk? Also there is only queueing for the COS values so do I have to map the DSCP to COS in this case? Is there no queuing for DSCP values on a 6500 SUP 720?

The 6500 does not support DSCP egress queue mapping except for certain modules eg. the WS-X6708-10GE. So you need to use the other approach i suggested in my previous post.

It's important to understand that all switches use an internal DSCP value for the packet while it moves through the switch. This internal value is not written into the packet header. So whatever you are trusting/using on ingress whether that be CoS/IP Precedence/DSCP the switch then derives a DSCP value to use internally, that's what the Cos-to-DSCP and IPPrec-to-DSCP maps are used for. Then the DSCP-to-CoS map uses that internal DSCP value to derive a CoS value that then tells the switch which queue to place the packet in. To modify the DSCP-to-CoS map see this -

6500 DSCP-to-CoS

As for your specific question if the Unity device only generates DSCP markings then you need to trust DSCP and then make sure that it is mapped to the correct CoS value when you come to queue it outbound from the switch. When it arrives at the other switch you can then simply trust CoS.

Jon

OK but according to my previous post I should not have to configure the DSCP-TO-COS mapping as it is alreayd there on the 6500. Also still using my Unity example. It maks the correct DSCP value on it's port. I trust the DSCP mapping of Unity. It now goes accross the 802.1q trunk to the other switch. I have the below commands configure for queuing on the Trunk link and the port for Unity.

wrr-queue queue-limit 5 25 40

wrr-queue bandwidth 5 25 70

wrr-queue random-detect 1

wrr-queue random-detect 2

wrr-queue random-detect 3

wrr-queue random-detect min-threshold 1 80 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 2 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 3 50 60 70 80 90 100 100 100

wrr-queue random-detect max-threshold 3 60 70 80 90 100 100 100 100

wrr-queue cos-map 1 1 1

wrr-queue cos-map 2 1 0

wrr-queue cos-map 3 1 4

wrr-queue cos-map 3 2 2

wrr-queue cos-map 3 3 3

wrr-queue cos-map 3 4 6

wrr-queue cos-map 3 5 7

priority-queue cos-map 1 5

Now as Unit generates the traffic it will only generate DSCP markings. I trust the DSCP but will the switch conver the DSCP to COS and perform the correct queueing on the port that Unity is connected to? Also as it travels over the Layer 2 link to the other 6500 will it convert the DSCP to COS and perform the apropriate queueing? On the other side of the trunk link I am mapping the COS to DSCP and trusting the COS value so as it goes over the link it should still be correct.

Bill19795 wrote:

OK but according to my previous post I should not have to configure the DSCP-TO-COS mapping as it is alreayd there on the 6500. Also still using my Unity example. It maks the correct DSCP value on it's port. I trust the DSCP mapping of Unity. It now goes accross the 802.1q trunk to the other switch. I have the below commands configure for queuing on the Trunk link and the port for Unity.


Now as Unit generates the traffic it will only generate DSCP markings. I trust the DSCP but will the switch conver the DSCP to COS and perform the correct queueing on the port that Unity is connected to? Also as it travels over the Layer 2 link to the other 6500 will it convert the DSCP to COS and perform the apropriate queueing? On the other side of the trunk link I am mapping the COS to DSCP and trusting the COS value so as it goes over the link it should still be correct.

Bill

You don't have to configure the DSCP-to-CoS map if you are happy with the current settings.

The switch will indeed convert the DSCP to a CoS value because otherwise it couldn't queue it on egress. So to travel over the L2 link it has to use a CoS value to queue it on the outbound trunk port.

Jon

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: