In QoS, you can use either DSCP or CoS to classify and mark your network as you wish. It is important to remember that DSCP is L3 and will be present in the IP header of a packet and CoS is L2 and will only be present in an ISL or 802.1Q VLAN frame.
Since 802.1p only exists in a VLAN tag, I was wondering if you should trust DSCP or trust CoS on the uplinks of a L2 environment. I found a lot of people on forums with contradicting arguments and opinions so I decided to investigate for myself. The question is: Do you have to trust DSCP over your trunk links or trust CoS since only VLAN tags are carried around the network?
After setting up a lab with two 3550’s and sniffing a trunk link setup between them, I finally got my answer. I was expecting the DSCP value to be dropped (because there is only a CoS value) or to be passed determined by the egress switch DSCP value. The results were unexpected and here is my analysis.
First let me share the topology I used:
We are going to be send a ping from Host2 to Host1. Host1 and Host2 are tagging frames with CoS 5 and we are using a CoS to DSCP mapping like this:
- CoS 0 => DSCP 0
- CoS 1 => DSCP 8
- CoS 2 => DSCP 16
- CoS 3 => DSCP 24
- CoS 4 => DSCP 32
- CoS 5 => DSCP 46
- CoS 6 => DSCP 48
- CoS 7 => DSCP 56
And DSCP-to-CoS mapping
- DSCP 0 => CoS 0
- DSCP 8,10 => CoS 1
- DSCP 16,18 => CoS 2
- DSCP 24,26 => CoS 3
- DSCP 32,34 => CoS 4
- DSCP 40,46 => CoS 5
- DSCP 48 => CoS 6
- DSCP 56 => CoS 7
Let’s ping from Host2 to Host1 and sniff to see what we find:
As you can see, the CoS is 5 as expected but the DSCP is not 0. It is set to 0x2e or 46 in decimal for both Request and Reply packets of ICMP. This matches the CoS to DSCP mapping that we have. But how exactly does it find this value if we are only trusting DSCP? This is a L2 only environment, so does the switch look into the packet, finds the IP header of the host and sends the DSCP value or does it do something else? To test this, let’s change our CoS to DSCP Mapping on Sw1 and Sw2 to see if these values are not actually derived from the CoS. On Switch1 let’s take out the mls qos map:
By default the CoS to DSCP mapping is 40. On Switch2, we still have CoS 5 mapped to DSCP 46, so that’s left unchanged. The DSCP to CoS mapping is also left unchanged. Our topology will look like this:
If we ping from Host2 to Host1, and the switch actually inspects the packet for DSCP then we should have a DSCP value of 46 for both Request and Reply ICMP since the mapping for CoS 5 to DSCP is 40 and the mapping for DSCP to CoS is 5. But if the switch derives the DSCP from the CoS and does not inspect the packet, then we should have a different DSCP value for the ICMP request and reply since we are only changing the mapping one way (the DSCP to CoS mapping remains unchanged). Let’s see what we get:
For the ICMP Request packet we can see the CoS is still 5 and the DSCP value is set to 0x2e or 46 in decimal, as expected. For the ICMP Reply packet we see that the CoS is also still 5 but the DSCP value is set this time to 0x20 or 40 in decimal. This indicates us that the CoS value is used, derived from the Mapping and the DSCP value is not actually beeing passed through.
In conclusion, both the trust CoS and trust DSCP command can be configured on trunk links. This will not pass a DSCP value of null or 0, but instead pass the CoS value of the VLAN 802.1p field. From this CoS value, the switch will use the CoS to DSCP mapping to derive its DSCP. For this reason, if you use the trust DSCP in a L2 environment, you must make sure that your DSCP to CoS and CoS to DSCP mappings are the same on every switch.
Hope this was informative.