0

I'm trying to get a fairly simple QoS policy up and running on my DSL line using a Cisco 877. My aims are fairly simple - make sure that realtime and management stuff like RTP and SSH works regardless of congestion, then make sure that HTTP, FTP, SMTP etc. protocols get a good shout in times of congestion and throttle back things like bittorrent when things get busy.

I've tried applying the config below, but it seems to have no effect. If I pull down a couple of ubuntu torrents, and also download a large file via HTTP, the HTTP download slows to a crawl, whereas the torrents merilly carry on downloading at 300kbps+. The only effect it seems to have is upstream bittorrent slows to about 0.1kbps.

My understanding is that I need to have a policy applied outbound on my ATM subinterface, and inbound on the VLAN so the router knows how to deal with the different packets flowing in both ways. I tried adding a police only policy inbound on the ATM subinterface, but again, this seemed to make no difference. Bittorrent incoming traffic romps over everything.

Oddly, no matter how much I try and configure it, I can't get the Packet-Queueing policy to show up outbound on the ATM0.1 interface. The inbound one shows up fine.

Any ideas?

class-map match-any BESTEFFORT
 match protocol http
 match protocol secure-http
 match protocol icmp
 match protocol secure-imap
 match protocol smtp
 match protocol ipsec
 match protocol dns
class-map match-any REALTIME
 match protocol rtp
 match protocol rtcp
 match protocol sip
 match protocol ssh
class-map match-any SCAVENGER
 match protocol bittorrent
!
!
policy-map Packet-Queueing
 class REALTIME
    priority 400
 class BESTEFFORT
    bandwidth percent 50
     random-detect
 class SCAVENGER
    bandwidth percent 5
     random-detect
 class class-default
    fair-queue
     random-detect
!
policy-map Input-Police
 class SCAVENGER
   police rate 8000 bps
     conform-action transmit
     exceed-action drop
!
policy-map Packet-Tagging
 class REALTIME
  set precedence 5
 class BESTEFFORT
  set precedence 4
 class SCAVENGER
  set precedence 0
!
!
interface ATM0
 description ATM ADSL Interface
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 no atm ilmi-keepalive
 dsl operating-mode adsl2
 dsl enable-training-log
 !
!
interface ATM0.1 point-to-point
 pvc 0/38
  vbr-rt 886 886
  encapsulation aal5mux ppp dialer
  dialer pool-member 1
  service-policy in Input-Police
 !
interface Vlan1
 description internal private VLAN
 ip address 192.168.0.1 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip flow ingress
 ip nat inside
 ip virtual-reassembly
 ip route-cache same-interface
 ip tcp adjust-mss 1452

 service-policy input Packet-Tagging
 hold-queue 100 out
!
growse
  • 7,830
  • 11
  • 72
  • 114

2 Answers2

3

The fundamental problem you have is that QoS in the inbound direction (in to your router) to control traffic headed in your direction is relatively useless.

The congestion is occurring at the egress of the ISP device to which your Router attaches. That ISP interface has no relevant QoS applied - it is most certainly a FIFO queue. Thus if the bittorrent end points are sending you data faster than your HTTP end point, bittorrent wins in a classic FIFO queue and your HTTP download is starved.

This is a very common problem in almost every home networking setup. Bittorrent can easily starve not only SSH or RTP traffic, but VoIP traffic as well.

Use your Bittorrent software's built in rate limiting to cap up and down speeds at a rate lower than what is available.

Jason Seemann
  • 1,120
  • 6
  • 9
  • Thanks - I've got a relatively friendly ISP, is it worth giving them a call and asking about QoS policies their end? – growse Mar 14 '11 at 09:06
  • I highly doubt it. Problem #1 would be finding someone who understands what you're asking, Problem #2 would be getting that someone to make a one-off change, and Problem #3 would be having that change even be possible on the hardware they use to connect up hundreds of customer devices. If you do try I'd be interested to hear back what they say (or what they try to sell you) =) – Jason Seemann Mar 14 '11 at 16:30
  • Well, I've asked - they appear to be 'thinking about it'. – growse Mar 22 '11 at 18:38
1

You could rate-limit bittorrent outgoing, though this will probably need:

(i) use a bittorrent client which can use predictable source ports. Transmission can be made to at least via a patch written for this purpose.

(ii) use a service-policy incoming on vlan1 to mark these packets as ip precedence 1 or something

(iii) do something so that ip precedence 1 packets outgoing get treated pretty badly if anything else is happening.

As for the outgoing policy, I'm not sure. If you ditch the incoming one does that make it possible to put the outgoing one on? When I first set mine up I got strange messages about it not being possible in the presence of a virtual interface. Two things which worked for colleagues and myself were:

(i) put the outgoing service policy on then use "do copy run start" from within the interface config menu. This worked for me in the sense that when I typed "exit" it complained and removed the policy but the startup-config had it in place and a reboot made it work.

or what a colleague did:

(ii) edit the config elsewhere and do "copy tftp start" or similar. and reboot.

It could be this was a silly way to do it but several of us had problems with this. It could be specific to particular software or platforms: I've been able to apply policies on 2821 routers with ADSL interfaces with no problem.

Adam Atkinson
  • 11
  • 3
  • You're right - I can slow outgoing to a crawl, but that doesn't seem to affect incoming packets at all. – growse Mar 23 '11 at 12:11
  • add "tx-ring-limit 3" under the pvc as well as your vbr-nrt. also, the bit about predictable source ports is fairly important: if you use "show ip cache flow" or wireshark on your computer you may see that there's a lot of stuff not using the ports you told your bittorent client to use. hence the transmission patch to force this. could be other clients support this too. – Adam Atkinson Mar 23 '11 at 12:48
  • I'm pretty sure "match protocol bittorrent" won't catch ports it's not expecting to see and I'm very sure it doesn't pick up encrypted bittorrent traffic so you can't really rely on just that. – Adam Atkinson Mar 23 '11 at 13:11
  • Just saw your edit. Yes, I've had strange issues about applying policies in the config, but managed to work around them. My main concern is that what I'm trying to do isn't possible just through configuring my router - I can't control what packets the ISP throws at the router. If 99% of packets the ISP sends me are bittorrent, then SIP packets won't get a chance to get through, regardless of my QoS settings. At least, that's how I understand it. – growse Mar 23 '11 at 13:53
  • It is true that you can't control what your ISP sends you and I'd be surprised if they were actually willing to put QoS on their stuff to you. However, if you are able to catch _all_ bittorrent related stuff outbound including ACKs to inbound stuff, the inbound stuff will slow down pretty fast. FYI I have "bandwidth percent 1" on my outbound bittorrent class. If there's nothing else going on it of course takes more. – Adam Atkinson Mar 23 '11 at 13:57
  • Interesting - delaying the ACKs to throttle the TCP speed is a fairly neat way around it. I'll have a play tonight and try to implement some of your suggestions. I think you're probably right in that I'm perhaps putting a little too much faith in the class-map protocol matching and should look at the catching the source ports as well. – growse Mar 23 '11 at 14:00
  • "show ip inspect sessions", "show ip nat translations", and "show ip cache flow" and some use of tcpdump/wireshark could be called for. If you do find out about bittorrent clients other than a patched version of Transmission that support a fixed source port range for _everything_ do let me know. – Adam Atkinson Mar 23 '11 at 14:47
  • and you can't just do the policy outbound on adsl because NAT can change port numbers and will definitely change source IP addresses if you're treating those differently as well. hence the palaver with inbound policy on vlan1 and marking packets. – Adam Atkinson Mar 23 '11 at 14:57
  • Quick follow-up, I've set things up roughly as you've described - I've got an access-list covering bittorrent traffic internally on the relevant ports, an internal class-map matching bittorrent protocol and the access list and an external class-map matching ip prec 1. A policy on vlan1 in marks the internal class ip prec 1 and and policy on ATM0.1 polices the external class out down to 8000bps. Doing a sh policy-map sees the right numbers going up (http://pastebin.com/dcUrLqXu). However, pulling 2x ubuntu iso, uploads are crawling (~1kBps) and downloads are still swamping everything else-Argh. – growse Mar 23 '11 at 21:47
  • what's the other 100k+ of incoming stuff in vlan1? have you checked with "show ip nat translations" that with just bittorrent running all the bittorrent traffic you send is using source ports from your end that you expect? My suspicion/fear is that you'll find when you initiate connections to other people you use random source ports. (This was the last step when I was trying to get this working too). I should also mention that as Jason says limiting the output in the client to something you can really send is a good idea too. – Adam Atkinson Mar 24 '11 at 04:38
  • However, if I do e.g. a large scp copy to an outside address my bittorrent traffic drops to almost 0 and stays that way, so I think I've got this stuff working satisfactorily. – Adam Atkinson Mar 24 '11 at 04:40
  • I ran out of characters in my last comment, but I'm using uTorrent configured as follows: listen port is 987 (987 is nat'd from an ext. ip) and outgoing source ports are range 23000-23300. The ACL matches both these ports. Using TCPView on windows, I can see the majority of connections are from uTorrent port 987, but there are quite a few in the 2300-23300 range. The other traffic is just me pulling some other data down (web etc.) Would you mind pastebinning parts of your config just so I can compare to mine? It's probably something I've missed in the configuration. Thanks :) – growse Mar 24 '11 at 13:09
  • I have to admit it sounds like you've done everything right, and thanks for the uTorrent ref. What is your downstream bandwidth? It seems hard to believe that there can be enough incoming stuff in response to your throttled stuff to inconvenience you. – Adam Atkinson Mar 24 '11 at 14:11
  • Current downstream sync is around 3100kbps. Max torrent downstream I've seen is around 350kB/s, which is around 2800kbps. I'm thinking for my next trick to try and match ACK packets specifically and rate-limit them. If that doesn't work, I'll just drop the traffic altogether and see if that stops things. If I can't drop the traffic by putting a drop action on the conform-action police, then something's wrong somewhere. – growse Mar 24 '11 at 14:24
  • 800+ up with only 3100 down? hmm. I had 8128 down, 448 up until yesterday so as you can imagine the A in ADSL was so extreme for me that flattening the incoming bandwidth was actually quite hard. I'm still trying to work out what is happening now that I supposedly have about 15 meg down 1 meg up: I don't seem to be able to get anything approaching either of those values but it has only been one day. – Adam Atkinson Mar 24 '11 at 14:38
  • I don't know if this is relevant but I also have "priority percent 55" on a class matching packets up to 200 bytes. It comes after the bittorrent class on the outbound policy so bittorrent acks don't reach it. also, are you running 12.4(20)T or later? the rules about what happens to classes with no explicit bandwith set changed in that patch level. – Adam Atkinson Mar 24 '11 at 15:28
  • Actually sitting at 3435/1092 right now, running IOS 15.0(1)M1. Don't know if that makes a difference. Does your class-map giving priority 55 aim to prioritise the ACK packets of other connections over BT? – growse Mar 24 '11 at 15:42
  • M5 seems to be nice. I feel a bit burned by several of the recent Ts which is why I dropped back to 15.0. Actually I want to prioritise ACKs and other small things like telnet, ntp, dns queries and VOIP if I'm lucky over larger outbound packets in general. BT of any size is the first class and gets "bandwidth percent 1". then small packets get pri percent 55. actually there are other classes but let's say class default has no bandwidth assigned, random-detect and fair-queue. bandwidth vs no bandwidth changed from 12.4(20)T onwards. look for "HQF" docs. – Adam Atkinson Mar 24 '11 at 16:29
  • Even though I may be syncing at 1000+ it looks as though my ISP may be policing me at some substantially lower speed, like the 448 I used to sync at. If this persists, clearly I should traffic shape to that in a parent policy with just a default-class or set my vbr-nrt lower. – Adam Atkinson Mar 24 '11 at 19:19