Not that this applies to this topic much, but could you elaborate as to why you are not a fan of auto qos? I use it in my switches for the phones and have no trouble with it. I have heard others say the same thing but I have never asked them why they dont want to use it. I am just curious because I would love to be doing things better if I can in all facets. Thanks if you choose to reply!
Edit: i also meant to say that i tried to go to your document to read it but i get a 404 error Article #70 not found.
Edit again: good lord, i needed to copy the whole link and past it, stupid word wrap nabbed you on this forum.
AutoQos does a reasonable job for a customer that doesn't want the time/expense/consideration that needs to be put into a QoS design. It can be tricky due to the way that QoS is implemented using different commands, terminology, queueing/shaping methods on each switch type, and when you consider that most networks have at least two different switch families in play it makes it a difficult thing to explain unless someone is willing to put in their own time to chew over the SRND that Java has referenced below (+5).
90% of the time QoS raises it's head as something that's required when we roll out a CallManager; and for a lot of them AutoQos is fine as they don't have the requisite knowledge to do it manually.
It's also perfectly possible to take the 'baseline' autoqos configuration and tweak it to work they way you need it to. The downside to that is that by the time you know what you need to change, you're getting to the point where you've read most of the SRND and don't need AutoQos; but at least that way you are learning by example.
For example, in the original implementations the 'auto qos trust cisco-phone' command relied on the extended trust/CDP mechanism to recognise a phone, and required dot1q trunked phones. Pretty typical with CIsco setups, but didn't cater for softphones, didn't cater for anything else running on PCs (CUVA etc), and wasn't much use if you didn't have Cisco phones. The cisco-softphone choice would work fine for any softphone scenario (at least where the softphone would mark DSCP appropriately), non-Cisco phones, non-converged converged LANs (where customers have seperate 'Voice VLAN' switches(!)) etc.
The last time I did a modified autoqos install, I recall that the queueing configuration that was applied catered for video traffic, but the input service-policy on the edge ports didn't classify AF41 traffic at all. Adding another class and a policy map section to police that traffic to sensible levels was required to recognize that.
Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: firstname.lastname@example.org Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...