Community ForumCommunity Wiki * Blog Home  * Log in
« »

QoS Tutorial

posted in Cisco Networking, Technical
by on May 12th, 2009 tags: , , , , ,

In this article we will be using the Modular Quality of Service CLI (MQC). With MQC you first define traffic classes, then you build a policy map in which the actions are applied to your classes, finally you apply the policy to an interface. This is a 20/2 cable connection, before implementing QoS my P2P traffic was really beating up on all my other traffic.

First we’ll go over class maps. Class maps are used to match traffic. Here are my class maps:

class-map match-any NNTP
description This is the Newsgroups traffic.
match access-group name MATCH_NNTP
match protocol nntp
class-map match-any BT
description This is the Bittorrent traffic.
match protocol bittorrent
match access-group name BT_PORT
class-map match-any PRIORITY
description This is all the traffic that gets priority.
match protocol http
match protocol dns
match protocol secure-http
match protocol ssh
match access-group name MATCH_RDP

Class map NNTP is matching the port for newsgroups traffic using ACL MATCH_NNTP:

ip access-list extended MATCH_NNTP
permit tcp any eq nntp any
deny   ip any any

Class map BT is matching my bitttorrent traffic using NBAR and the port specified in ACL BT_PORT:

ip access-list extended BT_PORT
permit tcp any eq 32547 any
deny   ip any any

Class map PRIORITY is matching a lot of traffic, most of it is using Network Based Application Recognition (NBAR) (match protocol ______), we’re also using MATCH_RDP for Microsoft remote desktop traffic:

ip access-list extended MATCH_RDP
permit tcp any eq 3389 any
permit tcp any any eq 3389
deny ip any any

Next we’ll go over policy maps. Policy maps are used to specify what is done to the different classes of traffic. Here is my incoming policy:

policy-map QoS_IN
class NNTP
police 16500000
class BT
police 16500000
class class-default

This is an example of policing, which is one of the few things you can do with incoming QoS. First, we specify the NNTP class, then we police the traffic to 16500000 bps, we do the same with the BT class. The point of doing it this way is that I don’t download torrents and newsgroups content at the same time and I want to give them both the same amount of bandwidth. I could have accomplished the same thing by putting them both into a single class, but I already had the BT class with outgoing QoS applied.

Here is my outgoing policy:

policy-map SHAPER
class class-default
shape average 2097152
service-policy QoS_OUT
policy-map QoS_OUT
priority percent 30
class BT
police cir 1436000
conform-action transmit
exceed-action drop
class class-default

This probably looks a little weird. What we’re doing here is a nested policy. In the SHAPER policy we’re giving the class class-default 2097152 bps, then we’re nesting the important policy under that. The point of this is to make sure any congestion will happen on the router (a device we can control). We’re choosing shaping here because it’s gentler than policing in that it buffers the exceeding traffic instead of dropping it.

In the QoS_OUT policy we are policing the BT class to 1436000 bps, if it exceeds then it is dropped. Then we give the class PRIORITY 30% of the bandwidth (which is the usable bandwidth left over). This (Low Latency Queueing is the book term) will give priority to the PRIORITY class but will not allow it to use more than the allotted 30%, which keeps it from monopolizing the bandwidth. we have also applied the “fair-queue” command, which applies Weighted Fair Queueing (WFQ). WFQ gives priority to interactive, low bandwidth flows and divides the bandwidth fairly between the non-interactive, high bandwidth flows.

Finally, we apply the policies to the interface, in this case it is FastEthernet 0:

interface fastethernet 0
service-policy input QoS_IN
service-policy output SHAPER

We built QoS_IN for incoming traffic and SHAPER (with QoS_OUT nested) for outgoing traffic.

I didn’t address Class Based Weighted Fair Queue (CBWFQ) as I don’t use it at home. I could use it in place of the LLQ if I wasn’t concerned about the traffic having priority. This is how it could look:

policy-map QoS_OUT
bandwidth percent 30
class BT
police cir 1436000
conform-action transmit
exceed-action drop
class class-default

The class PRIORITY wouldn’t get priority, instead it would be guaranteed at least 30% of the bandwidth, meaning that with CBWFQ it can exceed the 30% unlike LLQ where it is capped. With this we’re basically just reserving a specified amount of bandwidth for a class.

Some of you will see that this is an odd QoS implementation as we’re prioritizing odd traffic and not using CBWFQ. Typically you would do things differently, critical traffic (voice, video, etc) would be prioritized while the mid-range traffic (web, ftp, etc) would be guaranteed a chunk with P2P at the bottom being policed or dropped completely. One thing I’ve learned about QoS is that there isn’t a “one size fits all” rule, everything is very subjective. I hope this has been helpful to anyone learning about QoS.


A thread has been created on the site forum specifically for commenting on this blog post.

One Response to “QoS Tutorial”

  1. Steve

    Wow, 2 home runs in a row. Great job Vito!