Here’s a slightly different way of thinking about it. When you issue the mls qos command on a switch, it will, by default, not trust any DSCP or CoS values on packets/frames it receives. It will therefore set the DSCP and CoS values of those packets/frames to zero. Now in order to change this behavior and keep the DSCP values on the packets received, we can issue the global configuration command no mls qos rewrite ip dscp.
Now, the next command that Rene added, and on the interface this time, is mls qos trust cos. This command simply says that we will trust the CoS values on that particular interface. Now switches have a default cos-to-dscp map, where particular CoS values correspond to DSCP values. If no additional commands are issued, then this cos-to-dscp mapping will be applied by default on all traffic on this particular interface. You can exempt traffic from this mapping by issuing the mls trust cos pass-through.
Yes, but the first default behavior pertains to the whole switch globally when the mls qos command is applied, and the second default behavior pertains to a specific interface and only when the mls qos trust cos command is issued on the interface. These are two different scenarios, but they are related. Does that make sense?
Well, not quite. Although they are related, trusting and not modifying DSCP field are two different things. You can instruct a switch to never modify the DSCP field using this command, but that does not mean that a particular interface will trust traffic. This command is simply an exception to the untrusting of traffic. You must individually configure interfaces to trust or untrust, and those characteristics affect not only DSCP, but also CoS values. So you see, you have a more granular control over how traffic is handled.
In this case, you are essentially saying that you only trust CoS values, and yes, by default, all DSCP values will be rewritten using the cos-to-dscp map.
The above commands (assuming you haven’t issued the no mls qos rewrite ip dscp command, will keep the CoS values as they are, but will erase the DSCP values.
If no QoS configuration change is made to a brand new Catalyst 3850 switch (with default QoS configuration), how does it (Catalyst 3850) treat QOS marking on its inbound Access Ports (end device is marking the packets)? Does the switch erase the marking and set it to all 0s (best effort)?
Does a Cisco IP camera or Cisco IP phone mark traffic with COS (L2) value or TOS (L3) value or both?
Can a router’s LAN L3 interface (inbound) be configured to mark traffic with COS (L2) value?
Can a QoS Shaper be configured on a router’s WAN L3 interface (outbound) based on the COS marking (L2)?
What is the use of using COS marking? To my understanding, COS value can be used only to manipulate traffic in terms of QoS on the trunk links; is this correct? Can you please provide a configuration example for a Catalyst 3850 switch?
According to Rene’s one of the posts, only L2 trunk ports are capable of marking traffic with COS value. If that is the case, in the scenario below where end devices are marking traffic with DSCP value, how some traffic can be prioritized over others through the trunk link from Cat-3850-SW2 to Cat-3850-SW1?
By default, a Cisco Catalyst 3850 switch does not change or erase any QoS markings on incoming packets on its access ports. It trusts the QoS markings and forwards the packets accordingly.
Concerning the rest of your questions, I will address them one by one. But first I wanted to say a couple of words about CoS. CoS values only exist within VLAN tags. That means that such values can only be assigned on trunk ports on switches, or on router ports configured with subinterfaces and 802.1q encapsulation. These are the only ports that add a VLAN tag within which the CoS value can be assigned. Once the tag is stripped, that CoS value disappears. On to your questions…
IP phones can add both CoS values and ToS values. Using a voice VLAN, the VLAN tag is present in frames sent from the phone which is where the CoS values “lives”. IP cameras can assign ToS values, but unless the camera terminates a trunk, it will not assign CoS values.
Only if it is configured with subinterfaces and 802.1q encapsulation.
Not directly since there is no VLAN tag on the frame exiting the L3 WAN interface. You can do a CoS to DSCP mapping at the upstream interface where the VLAN tag exists (before it is stripped) to affect the ToS values based on the assigned CoS.
I explained the use of the CoS value above. It is the value that provides priorities on a trunk link or a subinterface on a router configured with 802.1q encapsulation. More info on CoS configuration can be found at this Cisco documentation:
The CoS value is only assigned whenever an 802.1q tag is added. You can use direct configuration of CoS value as the frame is tagged and placed on the trunk (using class maps) or you can do a DSCP to CoS mapping. This puts a value in the VLAN tag for CoS that is used for prioritization on the trunk.
Hello Laz,
Thanks for your reply. Since a Cisco switch by default trusts all the QoS marking on inbound frames, what is the use case for auto qos trust command?
A Cisco switch does indeed trust QoS markings on its access ports by default. This behavior however, is not related to the auto qos trust command.
The auto qos trust command actually generates a set of predefined QoS parameters for all trusted interfaces within the QoS domain. These parameters are the most commonly deployed QoS mechanisms to ensure that VoIP, routing protocol traffic, STP traffic, and real time video traffic are treated appropriately. The command will create a series of policy maps and class maps with the prefix “AutoQos”. These are actually generated as if they were all entered from the CLI. More information about the auto qos trust command and what it generates can be found at the following Cisco command reference:
