Michael Heiming wrote:
> In comp.os.linux.networking Kevin Brown <itismekevinb-NOSPAM-@hotmail.com>:
>
>>Hello all,
>
>
>>I work for a wireless ISP and we are having some issues with
>>subscribers hogging too much bandwidth. Each customer is
>>limited to what they are paying for (128kbit,640,1024,etc)
>>but, the problem lies when people download steady for more
>>than a half hour. It seems like a wireless problem since when
>>heavy downloading occurs, it only hurts people on the same POP.
>
>
>>I'm wondering if there's a way to limit these downloaders to a
>>half decent rate when other people are trying to access the Internet.
>>I am in the process of setting up some HTB queues on our master
>>router, but I'm wondering if there's software that will track
>>bandwidth on a per IP basis and run a certain script when conditions
>>are met (i.e. after twenty minutes of 500kbit/s+, limit them to
>>100kbit/s).
>
>
>>Any ideas on howto efficiently share our bandwidth?
>
>
> I'd setup squid as transparent proxy and use its delay pools
> feature, which should allow to do that. You can even limit the
> download rate for specific file types and more.
>
> Good luck
>
Michael,
Our firewall product "Frontdoor" does this with HTB. What we do is set
a "rate" and "ceiling" on a class of traffic. ( in your case by IP )
These are nice even numbers for an example...
You might do something like:
each IP gets a "rate" (minimum) of 20 and "ceil" (max) for 128
You would assign them a priority as well if you wanted.
If there is "extra" bandwidth, they can go 128 if not they get at least 20
You can also use a SFQ to increase "fairness" so that each connection
gets one piece of the pie as opposed to first in first out (FIFO).
With some fancy scripting work you could monitor the queues and change
the shaping.
We also add custom graphs to monitor traffic. The graphing can be
impractical for large networks since there are so many IP address they
don't fit on one graph (or even several). Its more practical for subnet
vs. subnet or by protocol or application.
Here is a small primer on traffic shaping / QoS.
http://www.paisleysystems.com/produc...ntdoor/traffic
Assuming you would like to tackle this yourself, try the "see also"
links on the right side of the page.
By all means if you don't want to do it yourself try the "contact us"
form.
The transparent proxy suggestion above is also good and may have
performance benefits as well.
Scott R. Haven
Sr. Systems Engineer
Paisley Systems Inc.
www.paisleysystems.com