said by mplex :

---

Since I have done a lot of QoS at work lately, I wanted to post a good solution that home users can use to improve the performance of their high speed connection when your outbound traffic rate is congested. It could be congested due to P2P traffic, a home server or anything. Regardless, if your upstream traffic is congested (and that is likely with the pathetic upload speeds on most home connections), latency will increase and everything will be sluggish. Hopefully, this will help.

Below are two qos queuing strategies for home users with slow uplinks on cable and DSL Internet. The first one is simple to implement generally performs well (fair queuing). Fair queuing is complicated to explain but easy to understand. It divides traffic in to flows and throttles heavy flows to allow room for smaller ones. In general, this will keep pings, ssh/telnet, VPN traffic etc responsive while cutting back P2P traffic and other aggressive traffic to make room.

For all of this to work, you have to tell the router how much upstream bandwidth you have, otherwise it will think you have a 10mbit or 100mbit link rather than a 256k WAN link. The best way to achieve this that I have found is Hierarchical Class Based Weighted Fair Queuing (CBWFQ). It's a mouth-full for sure, but in reality it is a simple flexible system for implementing QoS.

The first solution does no classification at all, rather it implements the fair queueing strategy in hopes that it can differentiate between different traffic and give everything a fair share.

!! This policy sets up your general queuing strategy for your WAN interface, which is only fair-queue in this case

policy-map fair-queue-child
class class-default
fair-queue 128 !! 128 allows more active flows than default

!! This policy queues the above policy at a specified rate of 200k

policy-map fair-queue-parent
class class-default
shape average 200000
service-policy fair-queue-child

!! Apply the policy to the physical outbound interface on your router
interface Fa0
service-policy output fair-queue-parent

If you need to change the shape average rate to a lower number, you have to first remove and reapply the policy on the interface for it to take effect.

Note: The command shape average 200000 is extremely important. This is the rate at which outbound traffic will leave your router. This only takes in to account IP packets, and none of the Ethernet/DOCSIS/PPP overhead that is included in that number your ISP quotes as your upload speed. You may also find that the amount of upstream bandwidth you can reliably get may very depending on time of day. This is just your ISP cheating you and the downside of shared bandwidth. Regardless, you will need to tweak your speed to a rate you are happy with. I usually load up a P2P program, then start pinging a reliable router upstream. When it's all said and done, with my 384k connection, the above number of 200k is the only reliable amount of bandwidth I get in the area I live now so don't be suprised to find out your ISP is no good. Here are the results I get without the fair-queue-parent policy applied:

60 packets transmitted, 60 received, 0% packet loss, time 59030ms
rtt min/avg/max/mdev = 371.506/989.091/1625.488/328.546 ms, pipe 2

As you can see, no packet loss, but performance was horrible

Now here are the results with the policy applied:

60 packets transmitted, 60 received, 0% packet loss, time 59080ms
rtt min/avg/max/mdev = 41.084/150.854/614.971/123.688 ms

Here's the applied policy output: sh policy-map int fa0

FastEthernet0

Service-policy output: fair-queue-parent

Class-map: class-default (match-any)
2888 packets, 1763229 bytes
30 second offered rate 185000 bps, drop rate 2000 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
200000/200000 2000 8000 8000 40 1000

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 63 2780 1638576 2768 1635385 yes

Service-policy : fair-queue-child

Class-map: class-default (match-any)
2888 packets, 1763229 bytes
30 second offered rate 185000 bps, drop rate 2000 bps
Match: any
Queuing
Flow Based Fair Queuing
Maximum Number of Hashed Queues 128
(total queued/total drops/no-buffer drops) 63/43/0

The average pings dropped to 150ms; that would be voice quality if it wasn't for the jitter. Still, most people will see a marked improvement implementing fair queuing. If you are a hardcore gamer or remote shell user, you won't be happy until performance is a consistent sub 100ms. For that, it gets a little more complicated.

You could do something like this:

!! Make an access list to match your game/shell traffic etc (This isn't enough to do it)
access-list 101 permit icmp any any
access-list 101 permit udp any any

!! Make a class for that traffic to match your ACLs
class-map match-any important
match access-group 101

!! Edit your existing policy to add the new class
policy-map fair-queue-child
class important
priority [or bandwidth] percent 50

Then remove and re-add the policy to the interface. See it working with the sh policy-map interface fa0 command.

That will setup a strict priority queue for that traffic and always service it first. The downside to using priority is that during times of congestion, priority acts as a policer and caps the traffic class to 50% of the total bandwidth under the parent policy. One way to get around this is setting priority at something like 80%. All the unused bandwidth will be shared proportionally among other classes including the default class. One thing to remember is that you can only have one priority queue. You need to use the bandwidth command under all other classes (otherwise, everything using priority will share the same queue). The bandwidth command uses a round robin mechanism to service the queues proportional to the percentage of bandwidth they have. The default class always gets what's left.

In the real world, the difference between priority and bandwidth is small and some routers don't support it. The policing action is enough to scare me away from using it for anything but udp traffic and small tcp traffic if at all. I also would not use it for large TCP packets since it will share space with your low latency traffic like game traffic and slow it down if it gets ahead of it in the queue.

Using a similiar but more complicated strategy (it still queues low latency for icmp), I get these results with a fully congested link:

60 packets transmitted, 60 received, 0% packet loss, time 59075ms
rtt min/avg/max/mdev = 30.732/60.634/107.809/17.917 ms

So I cut my ping rates by more than half. The average ping rates with no traffic is about 40ms to that location so there is roughly 20ms of overhead on a congested link. Those delays are more likely to be from the docsis timings rather than my router so this is likely the best performance I would think you could get. I can get a little better if I police my P2P traffic at a lower rate as seen below.

The policy below is the one I use. To be honest, it's a mess. Some of the descriptions are wrong and some traffic is probably in the wrong place, but that's because I've edited it so many times for my setup. I would only base your own policy loosly on this one and make your own classes. Just remember to have a maximum of 4 or so classes. Anymore will have strange results. You have to think of how the your traffic will compete for different classes at different times and whether you want that.

access-list 110 remark Management
access-list 110 permit icmp any any echo
access-list 110 permit icmp any any echo-reply
access-list 110 permit tcp any any range 22 telnet
access-list 110 permit tcp any range 22 telnet any
access-list 110 permit tcp any any eq 3389
access-list 110 permit tcp any eq 3389 any
access-list 110 deny udp any eq 10000 any !! I want VPN in a seperate class
access-list 110 deny udp any any eq 10000
access-list 110 permit udp any any
!
access-list 120 remark VPN
access-list 120 permit udp any any eq 10000
!
access-list 130 remark Web
access-list 130 permit tcp any any eq www
access-list 130 permit tcp any eq www any
!
access-list 140 remark File Sharing (FS)
access-list 140 permit tcp any any range 6881 6886
access-list 140 permit tcp any range 6881 6886 any
access-list 140 permit tcp any any eq 2234
access-list 140 permit tcp any eq 2234 any
access-list 140 permit tcp any range 4661 4662 any
access-list 140 permit tcp any any range 4661 4662
access-list 140 permit tcp any any eq 1214
access-list 140 permit tcp any any eq 6880
access-list 140 permit tcp any eq 6880 any

class-map match-any nbar-fs
match protocol bittorrent
match protocol kazaa2
match protocol gnutella
match protocol fasttrack
match protocol edonkey
match access-group 140

class-map match-all class2
description [VPN/UDP]
match access-group 120

class-map match-all class3
description [web traffic/other tcp]
match access-group 130

class-map match-all class1
description [SSH/ICMP/RDP]
match access-group 110

policy-map shaped
class nbar-fs
bandwidth percent 5
police cir 140000 bc 1500
conform-action transmit
exceed-action drop
violate-action drop
class class1
priority percent 30
class class2
bandwidth percent 30
queue-limit 16
class class3
bandwidth percent 25
queue-limit 32
class class-default
fair-queue

policy-map shaper
class class-default
shape average 220000
service-policy shaped

interface FastEthernet0
description [WAN-Comcast]
service-policy output shaper

---

feedback form

feedback form

Any feedback you provide (corrections, updates or suggestions) are sent to the owner of this FAQ
and anyone else involved in writing or editing this item.

by aryoba
last modified: 2007-12-10 16:20:25