Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
!
share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
    
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 9: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
add comment

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.

share|improve this answer
    
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
show 14 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.