Solved: Confirming QoS - tags not there?

billmatthews · ‎08-04-2010

We have Cisco 2960s connected to a 6905 core. We just deployed VoIP phones to our end users. On each user switchport we issued the command auto qos voip cisco-phone, which I think added these commands to the interface:

srr-queue bandwidth share 10 10 60 20
queue-set 2
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
service-policy input AutoQoS-Police-CiscoPhone

However, when I put a sniffer on my core router, I'm not sure how I can confirm that the QoS tagging is being kept. In fact, I think it might not be. I looked at an RTP packet and the Type of service is 0x00 (None), which I assume is wrong.

So I'm guessing perhaps my trunk uplinks on the 2960 or the core router could be the problem? What commands should I issue on the trunk ports?

Thanks

Bill

Aaron Harrison · ‎08-04-2010

Hi

Yes - using auto qos basically triggers a macro; first use configures a lot of global stuff, and subsequent ones generally just apply config to that port.

Often auto qos sets up queueing commands on the actual port (depending what platform it is).

So yes - if using auto qos elsewhere, do it on the uplinks.

The exceptions are where your uplinks are not dot1q or isl, or when you want to trust something on a host port (e.g. gateways or servers). In those scenarios, it's usually best to apply the auto qos trust command, and then change the resulting config to 'mls qos trust dscp'.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

Aaron Harrison · ‎08-04-2010

Hi

You'll need to configure both ends of each trunk link to trust the traffic being received:

mls qos trust cos

or

mls qos trust dscp

I typically use trust dscp; it's part of the IP header so is available on all types of links and is more granular. You should also use that for links to CCM or other servers, or to gateways.

Trust CoS can only be used on dot1q/ISL links.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

billmatthews · ‎08-04-2010

Thanks Aaron, that did the trick.

One followup question. mls qos trust cos worked, but I also so references online to auto qos voip trust. I tried that in my lab and it generated the following commands:

qos trust cos
auto qos voip trust
tx-queue 3
   bandwidth percent 33
   priority high
   shape percent 33
service-policy output autoqos-voip-policy

So the auto qos commands adds the qos trust cos, as well as some others. Would you recommend the auto qos instead?

Thanks

Aaron Harrison · ‎08-04-2010

Hi

Yes - using auto qos basically triggers a macro; first use configures a lot of global stuff, and subsequent ones generally just apply config to that port.

Often auto qos sets up queueing commands on the actual port (depending what platform it is).

So yes - if using auto qos elsewhere, do it on the uplinks.

The exceptions are where your uplinks are not dot1q or isl, or when you want to trust something on a host port (e.g. gateways or servers). In those scenarios, it's usually best to apply the auto qos trust command, and then change the resulting config to 'mls qos trust dscp'.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!