LINUX Bandiwdht Shaping Question

Simon Hobson dhcp1 at thehobsons.co.uk
Tue Jan 29 19:32:55 UTC 2008


SYED JAHANZAiB wrote:

>I am a newbie in linux, I have succesfully setup the squid proxy, 
>althought i have setup it with the very minimal options.
>Right now the challenge for me is to manage/distribute bandwidth for 
>my client side.
>Currently on ISA SERVER, i have BSPLITTER which is distributing 
>bandwidth very effeciently and the way i wanted it to be, but how 
>Can I do it with the LINUX ?
>
>I want to setup 3 Users Groups (offcourse, base on ther ip addresses),
>
>1) 3KB Users = Free Users
>2) 6 KB Users = Low Monthly Paid Users
>3) 16KB Users = Regular Users
>
>I want that the 3KB and 6KB users, they remain restricted to there 
>bandwidth 24hours.
>But 16KB Users should get 16KB from 3:00pm day till 1:am night, 
>after that they should be able to use the full bandwidth available.
>after searching on google.com I found one script from a linux 
>expert, using tc , it implements bandwidth nicely. but few drawbacks 
>I have seen after using it.

This is not in any way related to DHCP, but I can throw some pointers 
your way anyhow.

First, do you REALLY mean 3kB, 6kB, and 16kB for user bandwidth ? 3 
or 6kB (I assume that's byte/s) isn't even dial up modem speed so you 
WILL have huge speed & latency problems whatever you do.

For a few pointers, take a look at this site :
http://lartc.org/howto/lartc.cookbook.ultimate-tc.html
The config given here is designed to control traffic on a users link 
so as to get best download speed without filling ISPs buffer and 
increasing latency.

The manual for HTB, which I find works very well is at :
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

You have a lot of options and can trade off performance against 
complexity. If you don't mind certain traffic being outside of a 
users bandwidth allowance, you can cut down the config a bit. Eg :

device--HTB Queue--HTB root class 1:---HTB class 1:10
                                      |-HTB class 1:11
                                      |
                                      |-HTB class 1:101
                                      |-HTB class 1:102
                                      |...

If you filter things like TCP ACKs into class 1:10 and give this a 
higher priority, then that will help enormously with transfer rates. 
Filter traffic from the quid proxy to class 1:11 (so you can control 
it's bandwidth separately). Then give a class to each customer 
(1:101, 1:102, and so on) that is limited to their bandwidth 
allowance. You need to do this "both ways", ie on egress out of the 
external interface to manage upstream traffic, and egress on the 
internal interface to manage downstream traffic.

For info on tc filter syntax, try 
http://lartc.org/howto/lartc.qdisc.filters.html


To change traffic rate allowances, simply load a different set of 
rules at the appropriate times.

With a large number of users you will find the config gets quite 
large quite quickly, so a script to read the user config from a 
database and build the rules would be a good idea ! When allowing the 
paying customers 'unlimited' bandwidth, I would suggest doing this by 
leaving their basic "rate" setting the same, but increase the "ceil" 
(ceiling) value to a larger amount. That way, each user is guaranteed 
their 16kB, but can use more as long as it's free - ie no one user 
can exclude others entirely.

It may be better to add another level of class like this :

device--HTB Queue--HTB root class 1:---HTB class 1:10
                                      |-HTB class 1:11
                                      |
                                      |-HTB class 1:100
                                         |-HTB class 1:101
                                         |-HTB class 1:102
                                         |...

That way you can set an overall rate limit (total of all users) on 
class 1:100 so that they can't eat into a basic allowance for proxy 
traffic.



Hope that helps, it should at least give you some ideas.


More information about the dhcp-users mailing list