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

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

For an introduction to the new site, click here. And see here for current known issues.

New Member

qos trust cos on a non-trunk


I am trying to understand the QoS configuration for VOIP that I find on one of my 4500 series switches.

I see that configuration was done using "auto qos voip trust" which applied the following configuration:

Initial configuration applied by AutoQoS:


qos map cos 3 to dscp 26

qos map cos 5 to dscp 46

qos map dscp 24 25 26 27 28 29 30 31 to tx-queue 4

qos map dscp 32 33 34 35 36 37 38 39 to tx-queue 4

qos dbl

policy-map autoqos-voip-policy

class class-default



interface GigabitEthernet2/2

qos trust cos

tx-queue 3

priority high

shape percent 33

service-policy output autoqos-voip-policy


(It has been done on more interfaces, but they are all the same as this Gi2/2.)

Now, this is the entire configuration of this interface:


interface GigabitEthernet2/2

switchport access vlan 11

switchport mode access

service-policy output autoqos-voip-policy

qos trust cos

auto qos voip trust

tx-queue 3

priority high

shape percent 33

spanning-tree portfast


For completeness, here's the CoS to DSCP map:

CoS-DSCP Mapping Table

CoS: 0 1 2 3 4 5 6 7


DSCP: 0 8 16 26 32 46 48 56

And the DSCP to tx-queue map:

DSCP-TxQueue Mapping Table (dscp = d1d2)

d1 : d2 0 1 2 3 4 5 6 7 8 9


0 : 01 01 01 01 01 01 01 01 01 01

1 : 01 01 01 01 01 01 02 02 02 02

2 : 02 02 02 02 04 04 04 04 04 04

3 : 04 04 04 04 04 04 04 04 04 04

4 : 03 03 03 03 03 03 03 03 04 04

5 : 04 04 04 04 04 04 04 04 04 04

6 : 04 04 04 04

The only DSCP relevant to tx-queue 3 (which we are prioritising) that has an entry in the CoS-to-DSCP map is DSCP 46, being CoS 5.

Since all ports are configured as "qos trust cos", they are trusting the CoS values of frames on ingress. I hope I am still interpreting this correctly when I conclude that this means that frames that have CoS set to 5 on ingress will be prioritised on egress.

Now, onto my "real" question; our QoS here is based on CoS, which is a classification on layer 2, more specificly the CoS is defined in the User field of layer 2 frame with trunk encapsulation. So for my switch to actually find a CoS value the received frame has to tagged either as 802.1Q or ISL. But my switchports aren't trunks, they are access ports.

Does this mean that QoS isn't working or is it possible to receive trunk frames on an access port and the switch will know how to deal with this?

Thanks for reading so far!

With kind regards,



Re: qos trust cos on a non-trunk

Hi Kevin,

While this may sound strange, it is possible to receive tagged frames on access ports. You can enable this by using the Voice VLAN feature. You can configure the port so that an attached IP phone sends voice frames tagged with the Voice VLAN ID and also sends data from any attached PC as untagged frames. That is a scenario in which the 'qos trust cos' may come in useful.

Here's a link to more info on configuring voice vlans:

Hope that helps - pls rate the post if it does.


New Member

Re: qos trust cos on a non-trunk

Hi Paresh,

Thank you for clarifying that it is possible to receive tagged frames on access ports. That helps.

I do not have Voice VLAN activated on any of my ports though, am I correct in assuming that activing the Voice VLAN feature is not required for me to be able to receive tagged frames on that access port?

We are actually using some third party software (Vocalcom) of which I do not (yet) have any specs. It is entirely possible that this is functioning similar to the Cisco IP phones though, sending data without a tag and voice tagged and classified as CoS 5.

kind regards,



Re: qos trust cos on a non-trunk

If you have not activated that voice vlan feature, that means that your switch will expect to see only untagged frames on that port. In such a case, 'qos trust cos' really has no meaning, since there is no CoS field without an ISL/802.1q tag.

If this application of yours is sending tagged traffic, you will need to configure a voice vlan on the port so that the switch knows what to do with the tagged traffic...


Re: qos trust cos on a non-trunk

On an access port without trunk and "mls trust cos" you can actually destroy your QoS...

Set it to "mls trust dscp" on access ports.

(CCM, WAN router, PSTN gateway ports...)

Check this out:

"When the interface trust state is not configured to trust dscp using the qos trust dscp command, the security and QoS ACL classification will always use the interface DSCP and not the incoming packet DSCP. "

The interface DSCP is "0".



New Member

Re: qos trust cos on a non-trunk


Regarding my understanding you must have an 801.Q trunk, for handling CoS in a port, because the field CoS only is present over this encapsulation method. In fact, if you review the Ethernet encapsulation there is not any Cos field, that means that you need a trunk always for handle CoS over a trunk.



CreatePlease login to create content