Cisco QOS full solution

[Mostafa Alzareef]

Dears,
        I have a customer who has an issue with voice between two branches; the WAN link is utilized at peak hours of the day.
        I need a full QOS conf end-to-end from the access switch to the WAN router
        Does anyone have a document for this situation? 

[Joseph W. Doherty]

You'll find multiple QoS documents on Cisco's main site; more if you search the Internet.  Have you searched either?

BTW, although QoS is recommended end-to-end, if you've a major bottleneck, likely your congested WAN link, using QoS there, alone, may remediate your VoIP issue.

BTW, QoS features, and actual configuration statements, can vary much between platforms.  Cisco's AutoQoS can handle such issues and can often well handle VoIP.

[dpadill2]

Specific QoS configurations and policies cannot be created for anyone without a complete understanding of your network. This should be handled by your network architect, as they are familiar with the overall design.

However, if you do not have a network architect, and you are using a platform such as a Catalyst 9000 (Cat9k) device, you could use the Auto QoS feature as a best practice. For optimal results, it is recommended to open a case with professional services.

Below there is an official video that explains how to do it

https://www.youtube.com/watch?v=hKVbxCBqYXM

[Joseph W. Doherty]

IMO, AutoQoS should not be considered a "best practice".  However, using QoS should be considered a "best practice".

That said, using AutoQoS vs. no QoS is likely beneficial in most cases, but it can actually be worse.  More likely, AutoQoS won't be optimal.

I believe (?), later Cisco switches, like the 9k series, by default, no longer use a single egress queue, but split traffic into multiple egress queues based on traffic QoS tags, each queue given the same bandwidth ratios.  If true, a very rudimentary QoS policy, or AutoQoS, which doesn't appear to support this example case of VoIP issues.

BTW, AutoQoS can be adjusted, to meet your actual QoS needs, i.e. it can become your optimal QoS, but it's not so much "auto" then.  The question then becomes whether it's beneficial to use it at all?  The answer to that is "it depends".

Also BTW, the very first version of AutoQoS, only basically protected VoIP.  The next version, I recall (?), used Cisco's "Olympic" (gold, silver, bronze) model.  The next (and current) version uses Cisco's variant of the RFC model.  So, AutoQoS, one might say, has a history showing it's not optimal, otherwise it wouldn't need revision.  Yet, newer AutoQoS implementations don't revise configures prior AutoQoS.

So, because of the evolution of QoS, its possible inadequatecy, is why I believe using it shouldn't be considered a "best practice".  But, it certainly might be used as a method or tool using QoS as a "best practice".