Today I had a strange QOS problem to solve. This article mentions the problem and hopefully gives you guys a few pointers on QOS design.
So essentially the job involved me going to a company to teach a young CCNA about QOS, luckily he had some idea of QOS already and was a very quick learner. I took him through the basics of DSCP, COS, and the various tools available to you for QOS (shaping, policing, priority, bandwidth and WRED)
So far so good right?
Like I explained to the customer though, the biggest problem with QOS has nothing to do with the syntax or the configuration. The biggest issue is DESIGN and TROUBLESHOOTING. A few people apply QOS policies to there Internet-facing interfaces on OUTPUT and then think to themselves "Jee QOS does not seem to work" when it fails to achieve anything. The problem however lies in there design.
Without going into too much detail, it is CRITICAL to remember that the QOS "tools" priority and bandwidth do not do ANYTHING unless an interface is congested, so the very first thing you must do when designing your QOS is consider the size of the interface.
For example, lets say you have an Ethernet connection that connects to your ISP (pretty common these days.) Your actual speed the ISP provides you is 2 megabits per second, but your Ethernet interface is 100 Megabits. It is important to remember when using a QOS policy on an interface that the QOS policy only works if traffic is in the software buffer, and if your actual interface SPEED is 100 meg but your ISP speed is 2 meg, then the software buffer will never be used! Because as far as your router is concerned, there is PLENTY of bandwidth available. To get around this problem you must use a hierarchical policy map. An important note here: the bandwidth command under the interface is NOT used to control the bandwidth of the interface from a QOS perspective or to speed limit the traffic on that interface.
This configuration is simply used as a metric for internal routing protocols such as OSPF to help them calculate the cost of a link so for example, if a link is 100 meg and you want to make it less desirable, you could use the bandwidth command to say it is a 1 meg link in OSPF calculations. This would not limit the speed of the interface.
A hierarchical policy map is how you solve this issue, see below a configuration example:
shape average 2048000
We then apply this policy to our interface, and our child_policy is where we put our actual QOS policy, the one that prioritizes VOIP traffic, rate-limits HTTP or whatever else we desire to do.
What this does is limit the speed of the traffic to 2 megabits per second, so that a software buffer is created for this traffic. Once the traffic is inside the software at this point we can manipulate it with our QOS policy and our policy will actually have some effect!
But wait! There is more. The second important factor to consider is WHERE to apply your QOS policy, as you may know you can only use the priority and bandwidth commands on OUTPUT and NOT on input since no software buffer can possibly exist for traffic ENTERING your interface (how can you queue traffic thats not actually going out your router?)
Therefore, when writing your QOS policy, consider in what direction the traffic is most likely to experience congestion, so for example:
internet----> Dialer1 on router <--- Router ---> fa0/0
The thinking may be to prioritize FTP over HTTP for example that you would place your policy-map on the dialer interface, but if you think about it, traffic going OUT the dialer interface is only going to be acknowledgments! So chances are you wont experience congestion on your UPLOADS and hence your QOS policy is not going to accomplish what you set out to do. Since you can't apply it on the input because you want to use priority and bandwidth, the best choice is the fa0/0 interface. By placing it here you will be controlling the traffic as it leaves the router towards your network, so you can prioritize and shape as you see fit. I guarantee this works because I do it at home.
To complete the config, here is the full details guys:
shape average 2048000
match protocol ftp
bandwidth percent 75
service-policy output parent_policy
So in this example what I am doing is guaranteeing FTP 75 percent of the 2 megabits of bandwidth during times of congestion. All other traffic is in the class default class and the fair-queue command ensures that each queue is given equal amounts of bandwidth if there is congestion on the link.
Super quickly, to check if it is working correctly you would issue
#Show policy-map interface fa0/0 (but more on the output of this tomorrow.)
Coming tomorrow: Advanced QOS Design (what to do when we add IPSEC to the picture) and troubleshooting your QOS effectively.