Quick howto request (QoS on cisco 837)

growse · 20 Nov 2007 at 13:38

Hi all,

Can I get a quick guide on how to set up a simple QoS policy on a cisco 837 to prioritise dns, http and ssh over bittorrent? I believe this is mainly a latency issue rather than a bandwidth issue, as dns lookups and ssh sessions can get quite slow when I'm downloading a few things. I'm aware that I can only apply QoS to outbound traffic.

I've played with QoS before on cisco stuff so have a vague idea of what's what, but I'm a little sketchy on the details. Also, if there's a good way to test how effective the QoS is being, that'd be useful too

Thanks

growse · 22 Nov 2007 at 14:57

No-one?

tolien · 22 Nov 2007 at 16:25

Easiest way to test it would be to max out your connection then try one of your higher priority protocols and see how much (or if) it lags.

There's a solution to the other bit in the Cisco Cookbook: use ACLs for the three classes (dns, http and ssh; bittorrent, though you'll need to know what port it uses because AFAIK you can't make an ACL do packet inspection; everything else), then use class-based weighted fair queueing. There's probably a guide on the Cisco site.

oddjob62 · 22 Nov 2007 at 17:07

tolien said:
There's a solution to the other bit in the Cisco Cookbook: use ACLs for the three classes (dns, http and ssh; bittorrent, though you'll need to know what port it uses because AFAIK you can't make an ACL do packet inspection; everything else), then use class-based weighted fair queueing. There's probably a guide on the Cisco site.

Dunno if the 837's have NBAR functionality (probably not). Would be much better than an ACL.

wij · 22 Nov 2007 at 17:32

oddjob62 said:
Dunno if the 837's have NBAR functionality (probably not). Would be much better than an ACL.

They can have NBAR, but you need the right IOS image for it to be enabled, and also need to make sure that the router has enough RAM too.

growse · 23 Nov 2007 at 09:41

I do have NBAR:

Code:

Cisco IOS Software, C837 Software (C837-K9O3SY6-M), Version 12.3(11)YZ1, RELEASE

and 

ip nbar pdlm bittorrent.pdlm

So what I'm currently thinking is that I have three class-maps for traffic:

Code:

class-map match-any web-class
 match protocol ssh
 match protocol secure-http
 match protocol http
 match protocol dns
class-map match-all everything-else
class-map match-any bittorrent-class
 match protocol bittorrent

I then figure I need a policy that covers these three classes. My uncertainty is what options to set on each class. My options are:

Code:

#?
QoS policy-map class configuration commands:
  bandwidth        Bandwidth
  drop             Drop all packets
  exit             Exit from QoS class action configuration mode
  netflow-sampler  NetFlow action
  no               Negate or set default values of a command
  police           Police
  priority         Strict Scheduling Priority for this Class
  queue-limit      Queue Max Threshold for Tail Drop
  random-detect    Enable Random Early Detection as drop policy
  service-policy   Configure Flow Next
  set              Set QoS values
  shape            Traffic Shaping

V-Spec · 23 Nov 2007 at 11:08

Your on the right path, in terms of outbound queueing you can allocate a certain amount of bandwidth per class and stop it from clogging up your upstream when there is congestion, you could use your class-maps to define the traffic you wish to queue as below (removed the everything-else because it will be dealt with by the default class <invisible>)

class-map match-any web-class
match protocol ssh
match protocol secure-http
match protocol http
match protocol dns
class-map match-any bittorrent-class
match protocol bittorrent

To make a policy-map to queue the outbound traffic you could use the following, this will allow your web-class 300Kbps during congestion, but allow it to burst to 512Kbps if there is no traffic being queued. Bittorrent traffic will be guarenteed 150Kbps outbound,

Policy-map upstream
class web-class
bandwidth 300
police 512000 conform-action transmit exceed-action drop
class bittorrent-class
bandwidth 150
police 200000 conform-action transmit exceed-action drop

Then apply that to your interface in the outbound direction..

The harder part is inbound traffic, because you can't queue or shape inbound traffic the router is receiving on the same interface, the best way is to police your bandwidth.. The below example uses class-based policing to police any of your web traffic to 512Kbps inbound, and the bittorrent to 300Kbps.. Also, class-default is set to police everything else to 512Kbps,

policy-map inbound
class web-class
police 512000 conform-action transmit exceed-action drop
class bittorrent-class
police 300000 conform-action transmit exceed-action drop
class class-default
police 512000 conform-action transmit exceed-action drop

apply to the inbound interface, you can mess with these values how you like...

growse · 23 Nov 2007 at 13:07

Cool - what if I wanted not to limit bandwidth, but prioritise a certain class over another to reduce the latency?

V-Spec · 23 Nov 2007 at 13:44

growse said:
Cool - what if I wanted not to limit bandwidth, but prioritise a certain class over another to reduce the latency?

Well effectivley thats one in the same thing, you won't get latency unless there is congestion on the connection. For a start, no form of QOS will do anything at all, until the outbound queue on the interface starts to fill up, only then will the policy actually kick into action, until then everything is FIFO.

For example, if you have a 2Mbit syncronous connection, and your downloading at 1Mbps, and you fire up counterstrike, your ping will not be affected as there is no congestion all packets can be serviced in time because there is enough bandwidth.
If your downloading at 2Mbps and you fire up counterstrike, your ping will be affected because you are downloading at line rate, hence packets begin to get queued, the queueing on the router interface is where the latency comes in.
If you configure the QOS policy as above, there won't be latency because your not allowing any traffic type to dominate the pipe and cause congestion.

You could get rid of the policing, as the bandwidth command sets CBWFQ on the outbound connection, but that wouldn't affect your incoming traffic. In terms of prioritising the traffic going to the LAN for when there was congestion, you could have the first policy-map going outbound on the dialer interface, which would apply QOS to your upstream, you could then use the same class-maps and make a new policy map, and apply it outbound to your LAN towards your PC, which would be applied in the outbound direction but would actually be your inbound traffic.. so you could have:

policy-map inbound-to-PC
class web-class
bandwidth 1024
class bittorrent-class
bandwidth 512
class class-default
bandwidth 384

apply on your LAN or Vlan1 interface, in the outbound direction...

This would allow you to use the same outbound queueing on your LAN, as you were for your dialer interface.
By default you can only set QOS for up to 70% of the total interface bandwidth, as the IOS applies the QOS to the payload of the packet and not the finished thing when it has the headers on the end.. If you absolutley need to apply QOS for the entire traffic bandwidth, use the max-reserved-bandwidth 100 command on the interface.

growse · 26 Nov 2007 at 15:33

Sorry to bring this up again, but i've got a strange issue.

I've applied the following policy to the dialler 1 interface outbound:

Code:

class-map match-all test
class-map match-any web-class
 match protocol ssh
 match protocol secure-http
 match protocol http
 match protocol dns
class-map match-any bittorrent-class
 match protocol bittorrent

policy-map upstream-policy
 class web-class
  police rate percent 50
    conform-action transmit
    exceed-action drop
 class bittorrent-class
  police rate percent 30
    conform-action transmit
    exceed-action drop
 class test
  police rate percent 20
    conform-action transmit
    exceed-action drop

And that seems to kill all https traffic originating from outside to my webserver on my LAN. Removing this policy immediately makes it start working again. Any idea why?

WeekendOC · 26 Nov 2007 at 18:08

Sorry I missed the "match protocol secure-http" in your config. Was going to ask if you had added that.

Tui · 26 Nov 2007 at 22:13

And that seems to kill all https traffic originating from outside to my webserver on my LAN. Removing this policy immediately makes it start working again. Any idea why?

Probably because the traffic is exceeding the rate you've set so it's being dropped.
You want to weight the traffic, not police it, so instead of:
police rate percent XX

use:
bandwidth percent XX

Don't use all your bandwidth, leave some for what's left. For example, remove "class test" in your policy (I know you've matched it to all) and replace with:
class class-default
fair-queue

growse · 26 Nov 2007 at 22:52

That seems to have solved that problem, thanks. I'll have to wait and see if it's actually effective at doing what it's meant to