In this article we will be using the Modular Quality of Service CLI (MQC). This article will be useful for CCNP (ONT) or CCIP (QoS) studies.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
 class PRIORITY
  priority percent 30
 class BT
  police cir 1436000
  conform-action transmit
  exceed-action drop
 class class-default
  fair-queue

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
 class PRIORITY
  bandwidth percent 30
 class BT
  police cir 1436000
  conform-action transmit
  exceed-action drop
 class class-default
  fair-queue

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.

Related Posts: