Traffic shaping script (Robson's) for IP Range

Discussion in 'Tomato Firmware' started by astehn, Nov 16, 2008.

  1. astehn

    astehn LI Guru Member

    There are about 20 people sharing our internet connection on a WRT54GL running regular Tomato 1.21, generally with only 5 or so people using it at a time. Users are on a DHCP range of to Outgoing connections are managed beautifully by Tomato 1.21's built-in QoS. I'm also using scripts found on this board to limit each user in this range to 125 TCP connections and 50 UDP (and ICMP) connections.

    iptables -I FORWARD -p tcp --syn -m iprange --src-range -m connlimit --connlimit-above 125 -j DROP
    iptables -I FORWARD -p ! tcp -m iprange --src-range -m connlimit --connlimit-above 50 -j DROP
    The trouble I'm having is that there is one person who occasionally downloads HUGE files from a very fast server somewhere, completely hogging the entire 10MB/s incoming connection. I've successfully given this user a Static IP and shaped traffic for this IP using the following script from Robson's Script Generator:

    TCA="tc class add dev br0"
    TFA="tc filter add dev br0"
    TQA="tc qdisc add dev br0"
    SFQ="sfq perturb 10"
    tc qdisc del dev br0 root
    tc qdisc add dev br0 root handle 1: htb
    tc class add dev br0 parent 1: classid 1:1 htb rate 10000kbit
    $TCA parent 1:1 classid 1:10 htb rate 500kbit ceil 6000kbit prio 2
    $TQA parent 1:10 handle 10: $SFQ
    $TFA parent 1:0 prio 2 protocol ip handle 10 fw flowid 1:10     
    iptables -t mangle -A POSTROUTING -d -j MARK --set-mark 10
    The script seems to work beautifully b/c immediately after applying it while this user was downloading, the RX on the WAN dropped to near the ceiling of 6000kbit. The problem is that I can't constantly monitor the charts to keep an eye out for individuals monopolizing bandwidth, assign them static IPs, and redo the script every time.

    Is it possible to effectively apply this same limit to each individual user in the DHCP range? Looking at Robson's, I feel like if I replace the last line in the script with the following, it would treat the range as a single unit (rather than treating each individual IP within the range as a single unit):

    iptables -t mangle -A POSTROUTING -m iprange --dst-range -j MARK --set-mark 10
    Please correct me if I'm wrong, but wouldn't this try to give 500kbit to this IP range as a whole, and cap this IP range (again, as a single unit) to 6000kbit? Because what I want is for each individual IP to generally get 500kbit with a cap of 6000kbit. I thought I might do this by individually listing each IP in the range, but Robson's limits things to 32 IPs. Plus, even if I could add 50 separate lines, it would seem like that would be a really bloated script.

    The IP tables commands I'm using to limit TCP and UDP connections for the DHCP range seem so elegant. Is there a similarly elegant way to institute a bandwidth ceiling (about 3/5ths of the incoming bandwidth) for each individual IP in the DHCP range?

    Thanks for your help!
  2. Toastman

    Toastman Super Moderator Staff Member Member

    Using effective QOS rather than limiting users

    Hi Asehn

    You show two lines of script above, both are limiting tcp. UDP can't be limited by number of connections, but only by speed of opening UDP connections (not so satisfactory).


    #Limit UDP from all users to 3 per second
    iptables -A FORWARD -p UDP -s -m limit --limit 3/s -j ACCEPT

    If you have a lot of P2P users, this will slow it down, and by also putting any UDP from ports 1024-65535 into a separate class, such as E, low down in your rules list, and then applying a "choke" to it of perhaps 10kbps outgoing, it can be controlled reasonably well.

    Regarding your user, you have two options. The first is to clobber that user and the second is to use QOS rules that will allow any user to make use of that lovely bandwidth when it isn't being used. If you can identify what protocol/port/application he's using and address it, it is a more elegant solution.

    For example, there are currently 83 users here, and the whole thing has to look after itself no matter what a particular individual may do. But if the bandwidth is available, any user can take advantage of it. In most instances, this means any user attempting a download, say to install IE7, will get almost full bandwidth, dropping periodically to allow higher priority tasks such as WWW, Mail, Streaming Audio/Video and Messenger etc. to take place. The download is over quickly, the customer is happy, and life goes on as usual :)

    The net effect for most, is that they have the illusion of having full access to a 2Mbps ADSL line. Generally, they aren't aware they are sharing with dozens of other people. The recent release of TCP Vegas in Tomato variants has made the QOS work even better.

    Sorry I don't know much about Robson's SG, it has never been particularly useful whenever I've used it in conjunction with QOS.
  3. astehn

    astehn LI Guru Member

    Thanks for answering my post! I was slowly becoming convinced that no one ever would.

    I gathered that UDP connections could be limited using the code I mentioned from this post:
    From what I understood, the "!" makes the command limit all connections EXCEPT TCP to 50. Other users report that this code works, and the screenshot of iptables I've attached makes it look like some non-TCP (! tcp) connections are being dropped according to the rule.

    Technically speaking, I have no problem limiting the one user, but I'm leaving this apartment complex next year and I'd like to leave behind a solution that does not depend on me to monitor for bandwidth hogs. I've already implemented QoS rules, and they work great for outgoing traffic. The trouble is that this user (and hypothetical users in the future) is hogging all the inbound traffic. This user seems to be using some service that doesn't depend upon him uploading anything at particular speeds in order to download at the full speed of the available connection.

    That's why I'd still like a solution for creating an incoming bandwidth ceiling so that no single user in the entire IP range can exceed, e.g. 3/5ths of the incoming bandwidth. Victek's mod can apparently do this on an IP by IP basis, but it's limited to 20 IPs, and I have more than 20 users.

    Attached Files:

  4. Toastman

    Toastman Super Moderator Staff Member Member

    Thanks for the link. I just quickly pasted that command here, and then opened uTorrent with DHT and loads of files. UDP rose to 350 almost instantly and continued to rise for a minute or two before I killed it. So in my case, it did not work to limit UDP. But I am going to look into this, as that is the first time I have seen that method with the ! mentioned anywhere.

    iptables "list" shows the entry OK.

    I understand about the apartment. I admin several large blocks here, and of course anything could happen to me. Nobody else would have a clue what to do. Which is exactly why the QOS rules have to be comprehensive. I personally don't like the idea of limiting. After all, how do you set an arbitrary limit? Full bandwidth divided by 83? max of 500Mbps? (Which will overload badly if more than 4 people come on ?).

    Whatever he is using, the outgoing traffic is probably just a chain of ACKS - if he's taking the 10Mbps up then probably it must be quite high - 100k plus I'd have thought. If it's a HTTP download that will be hidden in the Web classification. A lower limit on outgoing traffic on port 80 might cure the problem, while allowing normal surfing.

    The conanxu/victek/warlock ip/mac limiter is limited in the number of users as you say. Victek has previously posted one for 30 users but your user base might rise well above - you have no way to tell. I have never had much success with this limiter and it does not work in conjunction with QOS, so not much use to me.

    I'm wondering, maybe we could do a test? PM me and I'll get back to you.


    I just read the rest of that thread, and see that Geetek has tried it on one of his systems and says that it works for him. That's good enough for me - if Geetek says it works, it works - and something is not working right here. Now to experiment some more to find out what! Thanks for making me aware of that script and thanks to u3gyxap for working it out.
  5. astehn

    astehn LI Guru Member

    After giving some thought to what you said, I’m hoping that slightly limiting incoming traffic will more or less solve the problem of my bandwidth hog for now. Before, I wasn’t shaping incoming traffic at all, but now nothing can absolutely max out the bandwidth except for the highest class (DNS requests < 2KB) and the high class (HTTP traffic < 512KB). Medium, Low, and Lowest classes are restricted to 95%, 90%, and 85% of incoming bandwidth. I’m also seriously thinking about moving to Victek’s mod, since there have been such glowing reviews of how it works even better now with TCP Vegas.

    As for the UDP limit I’ve implemented via a startup script:
    iptables -I FORWARD -p ! tcp -m iprange --src-range -m connlimit --connlimit-above 50 -j DROP 
    I just confirmed that it does work. While OUTSIDE of the specified IP range, I opened up uTorrent and watched the UDP connections in Tomato’s Conntrack counter immediately jump from about 10 to 90 or so. I then shut down uTorrent, assigned myself an address WITHIN the specified IP range, reopened uTorrent, and watched the UDP connections again. This time, they just wouldn’t go above 50. I hope you are able to get this working because I suspect it would be a lot more effective than limiting the number of UDP connections that can be made per user per second.
  6. Toastman

    Toastman Super Moderator Staff Member Member

    astehn, I've got that script working now, I had a conflict with another script. It's a good solution. The limit is being overrun a little here but I think that is probably due to old connections which have not been expired yet, I'll try to see why soon when I get time.

    Glad you got your user sorted!

    Thank you!
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice