I've come across an issue during a pilot implentation of QoS that I am asking for feedback on. I am observing certain behaviors that I have been unable to find documentation that supports why this is happening.
The following behaviors observerd are:
* If "mls qos trust dscp" is configured on the interface and the traffic is already marked DSCP 0 then DSCP output queue threshold map is used. (This makes sense)
For example this configuration line is used to determine the output queue:
| mls qos srr-queue output dscp-map queue 3 threshold 3 0 |
* If the interface is untrusted (incoming dscp value could be anything) then the cos-output queue threshold map is used where cos = 0. (Dont get this part)
For example this configuration linie is used to determine the output queue:
| mls qos srr-queue output cos-map queue 3 threshold 3 0 |
* If the interface is untrusted but a policy map exists on that interface that matches the default traffic (ip any any) and sets the DSCP value to 0 then the dscp output queue threshold map is used (
For example this configuration line is used to determine the output queue:
| mls qos srr-queue output dscp-map queue 3 threshold 3 0 |
I orginally only configured srr-queue output dscp-maps as I'm not using COS anywhere in the network and I trust DSCP on all uplinks. Almost all of the ports in the network have a service-policy attached to them however during testing I used a port that had no configuration on it and thus the port was untrusted. The traffic generated through this port was treated as dscp 0 and cos 0 as I could see in the output of the "show mls qos interface x/x statistics" command. However the queue that it egressed was not the queue the dscp-map was configured too. At closer look it was actually using the cos-map queue which I hadn't configured and defaulted to a different queue other that queue 3 threshold 3.
I've searched through the QoS SRND's and other QoS documents but have yet to find documentation that explains this behavior. According to what I have read the switch uses an internal DSCP value to make its decisions so I am not following why the cos-map is being used. Is there a way to have it default to dscp-mapping for choosing its hw queue when using an untrusted port so that I dont need to configure cos at all? Or can someone point me to documentation that explains that this is just how it is?
I found this in the Medianet Campus QoS Design 4.0 document.
For the most part, Cisco Catalyst switches perform QoS operations by assigning each packet (where
“packet” is being used loosely in this chapter to describe Layer 2 frames as well as Layer 3 packets) an
internal DSCP value (which is sometimes referred to as a “QoS label”, but is not to be confused with an
MPLS label). This internal DSCP value is used to determine if a packet is to be remarked or policed or
to which queue it is to be assigned or whether it should be dropped. The internal DSCP value may—or
may not be—the same as the actual DSCP value of an IP (IPv4 or IPv6) packet; furthermore, an internal
DSCP value is generated even for non-IP protocols (such as Layer 2 protocols like Spanning Tree as well
as non-IP Layer 3 protocols like IPX).
The manner in which the internal DSCP value is generated for a packet depends on the trust state of the
port on which the packet was received, which is described next.
There are four (static) trust states with which a switch port can be configured:
• Untrusted—A port in this trust state disregards any and all Layer 2 or Layer 3 markings that a packet
may have and generates an internal DSCP value of 0 (by default, unless explicitly overridden by the
[mls] qos cos interface configuration command) for all received packets.
The port in question has no qos configuration (such as trust cos or trust dscp) and the port shows that it is untrusted. Which I interpret the above text would state that the switch would generate an internal DSCP value of 0. My understanding then would be that the dscp-map statement would have taken care of the egress queue mapping and placed it in queue 3 threshold 3. However that was not the case.
The solution to my issue seems to be to just add in the line above to map cos 0 to queue 3 threshold 3 as I should never see any other cos values in the network as I trust DSCP on all trunk ports. I would just like to better understand why it chooses cos over DSCP for choosing the egress queue on untrusted ports where there is no policy.
