VoIP Traffic QoS in Campus for C2960X and C9200L

[OBD]

Hello Guys,

I am sorry but my blind side is QoS . Since  Simulation programs (Eve-Ng , GNS3) has no emulate QoS features , I can not see the real logic of the QoS by my own by capturing packets. 

Now , I need to implement QoS for ip voice traffic from the scratch in our Campus sides. We have no any template or exist QoS . I read lots of documents about QoS but I have no idea in terms of deployment. If you have template for VoIP Qos could you kindly share me ?  There are lots of QoS techniques but I do not know which one is the best for Campus Users

Thank you

Note: Our IP Telephones are not Cisco Device

[balaji.bandi · Accepted solution]

You have 2 different models of switches, the QoS config may vary here

QoS - is the defination you need to define what kind of bandwidth yoou looking to reserve

2960 - 15.X IOS running refer below guide :

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-0_2_EX/qos/configuration_guide/b_qos_152ex_2960-x_cg/b_qos_152ex_2960-x_cg_chapter_010.html

something similar on Cat 9200

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9200/software/release/16-10/configuration_guide/qos/b_1610_qos_9200_cg/configuring_qos.html

there is good video :

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

Good presentation help you :

https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKCRS-2501.pdf

[Joseph W. Doherty · Accepted solution]

---

@balaji.bandi wrote:

You have 2 different models of switches, the QoS config may vary here

BTW, OP shows 3 different models of switches, 2960X, 9200L and 4500.  (Also BTW, 4500 QoS varies based on sup architecture.)

---

@balaji.bandi wrote:

QoS - is the defination you need to define what kind of bandwidth yoou looking to reserve

---

Also BTW, often QoS is a bit more broad in its definition then reserving bandwidth (which might be done under the QoS banner).

Before getting deep into all the information @balaji.bandi provided, it might be helpful to read the following references, to get a better understanding of the context of QoS.

https://www.fortinet.com/resources/cyberglossary/qos-quality-of-service

https://en.wikipedia.org/wiki/Quality_of_service

The above Fortinet reference, describes how many see the purpose of QoS, preferential treatment of "special" traffic, VoIP being a "poster child" example. 

The Wiki reference is better as presenting how broad QoS can be, and many of the pros and cons, which can be contentiously debated.

Yes even the above, doesn't, I believe, convey that QoS is just a "tool" in our network toolbox for building/maintaining well working networks.  Sometimes it's the ideal tool, sometimes not.  In the former, using QoS can make a huge improvement, in the latter, using QoS can degrade the network.

Unfortunately, most QoS literature doesn't really make clear when it's good vs. not good to use QoS, or when you use QoS, how "much" of it to use.

Simple example:  before VoIP, QoS was generally ignored.  After VoIP, we now should use a QoS policy for 20 or so different DSCP tag treatments.  (The latter treatments often being imprecise.)

@OBD as you wade through the excellent reference documentation @balaji.bandi provided, before your head explodes, or after, AutoQoS will likely start to look very attractive.  Again, generally it will do well for VoIP, it's just what else it does may, or may not, be beneficial.

As you continue down the QoS rabbit hole, feel free to post new questions within these forums.

[OBD]

Thank you so much for you kind answers. They are so beneficial for me.. I will keep continue to study .

I appreciate your all answers !

[Joseph W. Doherty]

If your concern is only VoIP, Cisco's AutoQoS, generally, will insure VoIP works well.  Since your VoIP phones are non-Cisco, you would need to also insure those phones tag their traffic as AutoQoS expects, and that AutoQoS "trusts" your VoIP phone tagged traffic.

The downside to AutoQoS, it implements a very extensive set of changes which can be detrimental to all your other traffic (although it's literature will likely imply the opposite).

Your alternatives include not implementing QoS, on the LAN, until it really is needed (and even when really needed, you might only need on a few interfaces).

You can also create your own custom, QoS, which IMO is often actually and often quite simple, but requires lots (and lots) of QoS knowledge.

". . . I can not see the real logic of the QoS by my own by capturing packets."

Yea, not an uncommon observation.  Truthfully, on a LAN, you often do NOT need QoS "insurance", but like on ships, most often you don't need a lifeboat for everyone.

[MHM Cisco World]

which QoS tech. you mention here?

[OBD]

Thank you so much all for your helps . I will take your comments into consideration.  

Apparently , there is no accepted global campus  QoS template. I will check the videos and read more papers that you mentioned .

[Joseph W. Doherty]

"Apparently , there is no accepted global campus  QoS template."

Actually, that's what AutoQoS tries to provide, i.e. an one-size fits all QoS template.  Also, for the same vintage IOS release, across platforms, AutoQoS will try to provide the "same" QoS across platforms (NB: QoS support/capabilities can vary much between devices; likely the case between your 4500 [sup dependent], 2960X and 9200L).

IMO, it's not a bad model for traffic classification.  Where it breaks down, IMO, it how to handles its classified traffic.

"I will check the videos and read more papers that you mentioned ."

Who mentioned?  What videos and papers?

Regardless, IMO, unfortunately, most such QoS information may appear to be helpful, but the end result, except in cases like for VoIP, is often disappointing.

Addendum - update

Ah, didn't see @balaji.bandi's reply when I wrote above.  So, that answers the who and what video and papers.

Otherwise, don't believe I need to further amend the above.

[Elliot Dierksen]

If AutoQoS doesn't meet your needs, you can use that as a platform specific jump start. Enable AutoQoS on a single port, and it will build all the global config items. You can then edit them to meet your needs. @Joseph W. Doherty is very correct that it is very platform specific, so keep in mind that you need different config templates for each different switching platform.