1

Currently designing a QoS Policy for a customer (Cat 4500 models), following the business needs, I will work on a 8-class based model definition. Cisco has several guidelines under this perspective, for example, the following: https://www.ciscopress.com/articles/article.asp?p=2159353&seqNum=3; and diagram: https://ptgmedia.pearsoncmg.com/images/chap15_9781587143694/elementLinks/15fig05.jpg

In this example, Priority Queue has 30% BW max, Control Queue has 10 BWR, etc. I'm thinking about taking these parameters or change them, in this purpose, I would like to understand, how Cisco define these BW and BWR values? Are these best practices?

6

If you are using eight classes, then you are probably overthinking it. You want most traffic to be in the default class, protect real-time traffic with a priority class and policing, make sure that things like bulk transfers cannot hog your links, have a class for control traffic, and, possibly, a class for special applications. Once you hit six classes, you are probably trying too hard, and anything beyond that needs to be rethought. You can start with four (maybe five) basic classes, then, in the future, add a class for something special if it really needs it.

QoS is all about fairness, as you need it for your network. Only you can really determine the percentages required to implement your QoS fairness policy, and you should do that from a position of knowledge about how the traffic is actually using the network. Look at things like NetFlow reports, calculate packet overhead (VoIP has a lot of very small packets with a lot of overhead, but other traffic has much less overhead because the packets are larger). Also, remember that, by default, you cannot use 100% of the interface bandwidth.

Whatever percentages you start with, be prepared to tweak them as you get your reports after implementing QoS. This process will need to be closely monitored for a while after you implement it, and then checked periodically afterwards as things change in the network.

Be sure to mark your traffic as close to the source as possible, e.g. on the access switch where the traffic enters the network, so that it can be treated in the entire network. You should be able to trust marking from VoIP phones, and do not make the mistake that many people do about marking everything on a VoIP VLAN as EF because the VoIP data and control traffic should already be properly marked, and the VoIP control traffic should not be marked EF. Also, remember that your QoS markings and policies will not be honored on the public Internet. You can treat outbound traffic from a device, but inbound traffic has already used the incoming bandwidth by the time you see it. Shape outbound and police inbound. TCP will react to the inbound policing, but UDP will not. You can also use techniques like WRED.

Simply designing classes and percentages without studying the actual network traffic is a rookie mistake that can lead to chaos on your network. Find where there is congestion, and why there is congestion there, then design the QoS markings and policies to allow under-served traffic the necessary percentage, but balance it so that you do not under-serve other important traffic. Remember that QoS is not a substitute for proper bandwidth. QoS can help you use your existing bandwidth more fairly (as you see it), but you may need more bandwidth to actually do what you want.

| improve this answer | |
  • 3
    Nice, comprehensive answer. If I could vote it up twice I would. – Ron Trunk Mar 15 at 17:17
  • QoS is all about fairness ... or, as a source I just can't remember used to put it: "QoS is a system of managed unfairness". Once a link is saturated, all traffic, even priority queued traffic, gets to suffer in one way or the other. But the network admin can set the rules of (un)fairness. – Marc 'netztier' Luethi Mar 15 at 21:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.