Confirming QoS - tags not there?

Answered Question
Aug 4th, 2010
User Badges:

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

Correct Answer by Aaron Harrison about 6 years 8 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Aaron Harrison Wed, 08/04/2010 - 05:49
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

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

billmatthews Wed, 08/04/2010 - 05:59
User Badges:

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

Correct Answer
Aaron Harrison Wed, 08/04/2010 - 07:31
User Badges:
  • Super Bronze, 10000 points or more
  • Community Spotlight Award,

    Member's Choice, May 2015

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

Actions

This Discussion

Related Content