Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
For 6500s and 4500s, egress QoS is generally configured at the physical port interfaces. Ingress QoS can also done at the physical port interface and/or at a higher logical level, such as a VLAN.
QoS can be difficult to manage on large L3 switches, which is where AutoQoS may be extremely helpful.
Also on LANs, QoS is often not really necessary. Further, if implemented poorly, it can make problems. (NB: AutoQoS tries to adhere to good design and best practice, but note the word "tries".)
Reza's reference is excellent, and there's more like it that can be found on Cisco's main web site. However, as good as it is, it can mislead. For example, early in Reza's reference it says:
Enable queuing policies at every node where the potential for congestion exists, regardless of how rarely this in fact may occur. This principle applies to campus edge and interswitch links, where oversubscription ratios create the potential for congestion. There is simply no other way to guarantee service levels than by enabling queuing wherever a potential speed mismatch exists.
That's true on its face, but the real issue is will any such congestion be detrimental to performance/service requirements?
