Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Understanding the Egress Queue used on 3560/3750

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.

Everyone's tags (5)
4 REPLIES

Re: Understanding the Egress Queue used on 3560/3750

Hi,

Check out the below link hope to help !!

https://supportforums.cisco.com/docs/DOC-8093

Ganesh.H

New Member

Re: Understanding the Egress Queue used on 3560/3750

Thanks for your response Ganesh.  Very interesting and in depth article.  The article references a Qos label used to decide the output queue used on the 3750.

According to the document the "show platform qos label" command gives you the output that shows all the mappings.  Label "1" is used when QoS in enabled for untrusted ports.  Label "2" is used for trusted dscp ports when Qos is enabled and Label 42 is for Cos 0.

Label   : Rx queue-thr : Tx queue-thr : rewrite dscp-cos
1         2  - 0         1  - 0         0    - 0  
2         2  - 0         2  - 2         0    - 0  
42        2  - 0         1  - 0         0    - 0

You can see in the output above that both label 1 and label 42 have the same TX queue-thr (keep in mind you have to add 1 to both queue and threshold value).

After applying the command "mls qos srr-queue output cos-map queue 3 threshold 3 0" the values of the "show platform qos label" now change to following below.  So it would appear that changing the Cos 0 queue mapping (label 42) changes the untrusted port when QoS in enabled (label 1) as well.  It seems there is some link between the two or ... it would it be proper to say that CoS 0 is applied to an untrusted port when QoS is enabled?

Label   : Rx queue-thr : Tx queue-thr : rewrite dscp-cos
1         2  - 0         2  - 2         0    - 0  
2         2  - 0         2  - 2         0    - 0    
42        2  - 0         2  - 2         0    - 0

If I am working in a DSCP environment where I dont use COS (trust DSCP instead)  it would appear that I still need one additional mls qos configuration command to take care of any untrusted ports that could be out there.

Marc

Cisco Employee

Re: Understanding the Egress Queue used on 3560/3750

Hi,

There is a default cos applied to each interface, the default value is 0; when port is untrust, this default cos will be used, and this cos bit will be used to determine the egress queue based on cos-egress queue map.

On that case, the internal DSCP is driven by the default cos bit based on cos - dscp -map,  then this internal DSCP will be appied to the packets and over write the original DSCP if there is any. This is the the default behavior, but it can be disabled by no dscp rewrite.

HTH,

Lei Tian

New Member

Re: Understanding the Egress Queue used on 3560/3750

Thanks for your response Lei.  Can you point me to a Cisco document that states that?  I've been trying to find an official document from Cisco that says that but haven't found one yet.

4122
Views
5
Helpful
4
Replies