[LARTC] limit bandwidth per host question

[LARTC] limit bandwidth per host question

[nic-lartc]

EHLO tc gurus.

New to traffic control. Unfortunately, the politicians here in Denmark 
have decided that a PC is the same as a television set - so anyone 
owning a PC and internet connection of over 255 kbit/s must pay DKR 
2200/year = EUR 300 = USD 400 in television licence fees :-( This is a 
lot of money for poor students, so we want to offer the students the 
*option* of limiting their download speed to 255 kbit/s. Limit must be 
per internal IP number (or MAC address, even better).

Situation: dorm rooms, 130 residents, Internet connection is 100 Mbit 
full duplex fiber Ethernet, never over 10% used. Router/firewall is a 
Debian/Etch box 650 Mhz, 160 Mb RAM, with kernel 2.6, iptables, 
netfilter iproute2 & everything necessary.

eth0 = internet, eth1 = DMZ, eth2 = internal NATted network, 172.16.0.0/16

As far as I can see, this should do the trick?:

# delete all existing queue disciplines
tc qdisc del dev eth2 root

# attach queue discipline HTB to interface eth2 and give it handle 1:0
tc qdisc add dev eth2 root handle 1:0 htb

# host 1
tc class add dev eth2 parent 1:0 classid 1:1 htb rate 255kbit burst 255kbit
tc filter add dev eth2 protocol ip parent 1:0 prio 1 u32 \
    match ip dst 172.16.255.132 flowid 1:1

# host 2
tc class add dev eth2 parent 1:0 classid 1:2 htb rate 255kbit burst 255kbit
tc filter add dev eth2 protocol ip parent 1:0 prio 1 u32 \
    match ip dst 172.16.255.145 flowid 1:2

# etc etc etc

Questions:

1) Is this a good way of doing it?

2) TBF or HTB? I just chose HTB because it seems more flexible and has 
sane defaults, so I don't have to think so much. Are there any 
disadvantages?

3) Any clever suggestions on how to  best implement the stupid law with 
the least harm to our users (for example, maybe we could have a 
relatively high burst bandwidth, with the real limiting to 255 Kbit/s 
only kicking in after several seconds? This might make normal web 
surfing seem almost unaffected?

Thanks,
Nicolas

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] limit bandwidth per host question

[nic-lartc]

If you mean BrazilFW? http://www.brazilfw.com.br this is not an option - 
we have a well functioning firewall with 4 interfaces, VPN, logging, an 
advanced quota system etc. We do not want a micro-floppy distro - just 
need to add traffic control to the existing Debian box.

Nicolas

hareram wrote:
> Hi
>
> look at the BFW does the job of all you need
>
> hare
> ----- Original Message ----- From: <nic-lartc@studentergaarden.dk>
> To: <lartc@mailman.ds9a.nl>
> Sent: Tuesday, May 08, 2007 7:21 AM
> Subject: [LARTC] limit bandwidth per host question
>
>
>> EHLO tc gurus.
>>
>> New to traffic control. Unfortunately, the politicians here in 
>> Denmark have decided that a PC is the same as a television set - so 
>> anyone owning a PC and internet connection of over 255 kbit/s must 
>> pay DKR 2200/year = EUR 300 = USD 400 in television licence fees :-( 
>> This is a lot of money for poor students, so we want to offer the 
>> students the *option* of limiting their download speed to 255 kbit/s. 
>> Limit must be per internal IP number (or MAC address, even better).
>>
>> Situation: dorm rooms, 130 residents, Internet connection is 100 Mbit 
>> full duplex fiber Ethernet, never over 10% used. Router/firewall is a 
>> Debian/Etch box 650 Mhz, 160 Mb RAM, with kernel 2.6, iptables, 
>> netfilter iproute2 & everything necessary.
>>
>> eth0 = internet, eth1 = DMZ, eth2 = internal NATted network, 
>> 172.16.0.0/16
>>
>> As far as I can see, this should do the trick?:
>>
>> # delete all existing queue disciplines
>> tc qdisc del dev eth2 root
>>
>> # attach queue discipline HTB to interface eth2 and give it handle 1:0
>> tc qdisc add dev eth2 root handle 1:0 htb
>>
>> # host 1
>> tc class add dev eth2 parent 1:0 classid 1:1 htb rate 255kbit burst 
>> 255kbit
>> tc filter add dev eth2 protocol ip parent 1:0 prio 1 u32 \
>>    match ip dst 172.16.255.132 flowid 1:1
>>
>> # host 2
>> tc class add dev eth2 parent 1:0 classid 1:2 htb rate 255kbit burst 
>> 255kbit
>> tc filter add dev eth2 protocol ip parent 1:0 prio 1 u32 \
>>    match ip dst 172.16.255.145 flowid 1:2
>>
>> # etc etc etc
>>
>> Questions:
>>
>> 1) Is this a good way of doing it?
>>
>> 2) TBF or HTB? I just chose HTB because it seems more flexible and 
>> has sane defaults, so I don't have to think so much. Are there any 
>> disadvantages?
>>
>> 3) Any clever suggestions on how to  best implement the stupid law 
>> with the least harm to our users (for example, maybe we could have a 
>> relatively high burst bandwidth, with the real limiting to 255 Kbit/s 
>> only kicking in after several seconds? This might make normal web 
>> surfing seem almost unaffected?
>>
>> Thanks,
>> Nicolas
>>
>> _______________________________________________
>> LARTC mailing list
>> LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>
>>
>
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

RE: [LARTC] limit bandwidth per host question

[Etienne Carriere]

[-- Attachment #1.1: Type: text/plain, Size: 2393 bytes --]

Hi, 

May be you should check HTB and its 'ceil' param which can limit bandwith 
to an upper bound. Refers to HTB user guide section "4. Ceiling" 
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#ceiling 

etienne 


nic-lartc@studentergaarden.dk  wrote:
(Sent by: lartc-bounces@mailman.ds9a.nl 08/05/2007 03:51)
> EHLO tc gurus.
> 
> New to traffic control. Unfortunately, the politicians here in Denmark 
> have decided that a PC is the same as a television set - so anyone 
> owning a PC and internet connection of over 255 kbit/s must pay DKR 
> 2200/year = EUR 300 = USD 400 in television licence fees :-( This is a 
> lot of money for poor students, so we want to offer the students the 
> *option* of limiting their download speed to 255 kbit/s. Limit must be 
> per internal IP number (or MAC address, even better).
> 
> Situation: dorm rooms, 130 residents, Internet connection is 100 Mbit 
> full duplex fiber Ethernet, never over 10% used. Router/firewall is a 
> Debian/Etch box 650 Mhz, 160 Mb RAM, with kernel 2.6, iptables, 
> netfilter iproute2 & everything necessary.
> 
> eth0 = internet, eth1 = DMZ, eth2 = internal NATted network, 
172.16.0.0/16
> 
> As far as I can see, this should do the trick?:
> 
> # delete all existing queue disciplines
> tc qdisc del dev eth2 root
> 
> # attach queue discipline HTB to interface eth2 and give it handle 1:0
> tc qdisc add dev eth2 root handle 1:0 htb
> 
> # host 1
> tc class add dev eth2 parent 1:0 classid 1:1 htb rate 255kbit burst 
255kbit
> tc filter add dev eth2 protocol ip parent 1:0 prio 1 u32 \
>     match ip dst 172.16.255.132 flowid 1:1
> 
> # host 2
> tc class add dev eth2 parent 1:0 classid 1:2 htb rate 255kbit burst 
255kbit
> tc filter add dev eth2 protocol ip parent 1:0 prio 1 u32 \
>     match ip dst 172.16.255.145 flowid 1:2
> 
> # etc etc etc
> 
> Questions:
> 
> 1) Is this a good way of doing it?
> 
> 2) TBF or HTB? I just chose HTB because it seems more flexible and has 
> sane defaults, so I don't have to think so much. Are there any 
> disadvantages?
> 
> 3) Any clever suggestions on how to  best implement the stupid law with 
> the least harm to our users (for example, maybe we could have a 
> relatively high burst bandwidth, with the real limiting to 255 Kbit/s 
> only kicking in after several seconds? This might make normal web 
> surfing seem almost unaffected?
> 
> Thanks,
> Nicolas

[-- Attachment #1.2: Type: text/html, Size: 3255 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] limit bandwidth per host question

[Andy Furniss]

nic-lartc@studentergaarden.dk wrote:
> EHLO tc gurus.
> 
> New to traffic control. Unfortunately, the politicians here in Denmark 
> have decided that a PC is the same as a television set - so anyone 
> owning a PC and internet connection of over 255 kbit/s must pay DKR 
> 2200/year = EUR 300 = USD 400 in television licence fees :-( This is a 
> lot of money for poor students, so we want to offer the students the 
> *option* of limiting their download speed to 255 kbit/s. Limit must be 
> per internal IP number (or MAC address, even better).

Eww - nasty. Is the law watertight - eg pay one licence fee and run a 
proxy to workaround, maybe they thought of that :-)

> 
> Situation: dorm rooms, 130 residents, Internet connection is 100 Mbit 
> full duplex fiber Ethernet, never over 10% used. Router/firewall is a 
> Debian/Etch box 650 Mhz, 160 Mb RAM, with kernel 2.6, iptables, 
> netfilter iproute2 & everything necessary.
> 
> eth0 = internet, eth1 = DMZ, eth2 = internal NATted network, 172.16.0.0/16
> 

Another thought - do they have link layer access to each other ....

> As far as I can see, this should do the trick?:
> 
> # delete all existing queue disciplines
> tc qdisc del dev eth2 root
> 
> # attach queue discipline HTB to interface eth2 and give it handle 1:0
> tc qdisc add dev eth2 root handle 1:0 htb
> 
> # host 1
> tc class add dev eth2 parent 1:0 classid 1:1 htb rate 255kbit burst 255kbit
> tc filter add dev eth2 protocol ip parent 1:0 prio 1 u32 \
>    match ip dst 172.16.255.132 flowid 1:1
> 
> # host 2
> tc class add dev eth2 parent 1:0 classid 1:2 htb rate 255kbit burst 255kbit
> tc filter add dev eth2 protocol ip parent 1:0 prio 1 u32 \
>    match ip dst 172.16.255.145 flowid 1:2
> 
> # etc etc etc
> 
> Questions:
> 
> 1) Is this a good way of doing it?
> 
> 2) TBF or HTB? I just chose HTB because it seems more flexible and has 
> sane defaults, so I don't have to think so much. Are there any 
> disadvantages?
> 
> 3) Any clever suggestions on how to  best implement the stupid law with 
> the least harm to our users (for example, maybe we could have a 
> relatively high burst bandwidth, with the real limiting to 255 Kbit/s 
> only kicking in after several seconds? This might make normal web 
> surfing seem almost unaffected?

Burst is a good idea

I thing htb with prio on leafs could be slightly nicer - eg. with so 
little bandwidth users may want to game while downloading, so giving udp 
and common tcp game ports prio over other tcp will mean they can do both.

Another way could be to use policers - they are a bit crude but do keep 
latency low and also have burst/buffer parameter.

Maybe set up some tests to see which is nicer at 255kbit.

If you only have to shape downloads to comply, users may find most of 
their bandwidth gets used by the acks when they upload.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] limit bandwidth per host question

[Andy Furniss]

Andy Furniss wrote:

>> tc class add dev eth2 parent 1:0 classid 1:2 htb rate 255kbit burst 
>> 255kbit

> Burst is a good idea

Actually you need to specify burst and cburst for it to work and I 
suppose the law doesn't stop you being more generous than 255kbit - I 
just tried 100k (= 100k byte) and browsing isn't too bad.

Browsing and downloading together with just fifo is horrible though. I 
tried htb with the prio qdisc and it was dissapointing WRT latency. HTB 
class prio was far better. In both cases I also had sfq on the leaf of 
the tcp class, which makes browsing while downloading nicer and for tcp 
games didn't hurt latency too much.

I was only testing with one user though I scripted two, I'll get round 
to playing with curl loader one day. There's bound to be a mistake 
somewhere, but I paste below what I did. class/flowids are hex and you 
have 0-ffff after : (minor) to play with - you'll need a more sensible 
numbering system that I chose.

Policing was also not too bad.

Andy.

cat htb-255-eth0-prio-htb

set -x
IP=/sbin/ip
TC=/sbin/tc

$TC qdisc del dev eth0 root &>/dev/null

if [ "$1" = "stop" ]
then
         echo "stopping"
         exit
fi

$TC qdisc add dev eth0 root handle 1: htb

$TC class add dev eth0 parent 1: classid 1:1 htb rate 255kbit burst 100k 
cburst 100k
$TC class add dev eth0 parent 1:1 classid 1:11 htb prio 0 rate 200kbit 
ceil 255kbit burst 10k cburst 10k
$TC qdisc add dev eth0 parent 1:11 bfifo limit 50k
$TC class add dev eth0 parent 1:1 classid 1:12 htb prio 1 rate 55kbit 
ceil 255kbit burst 90k cburst 90k
$TC qdisc add dev eth0 parent 1:12 sfq limit 30

$TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 
192.168.0.3 flowid 1:1
$TC filter add dev eth0 parent 1:1 protocol ip prio 1 u32 match ip 
protocol 6 0xff flowid 1:12
$TC filter add dev eth0 parent 1:1 protocol ip prio 2 u32 match u32 0 0 
flowid 1:11

$TC class add dev eth0 parent 1: classid 1:2 htb rate 255kbit burst 100k 
cburst 100k
$TC class add dev eth0 parent 1:2 classid 1:21 htb prio 0 rate 200kbit 
ceil 255kbit burst 10k cburst 10k
$TC qdisc add dev eth0 parent 1:21 bfifo limit 50k
$TC class add dev eth0 parent 1:2 classid 1:22 htb prio 1 rate 55kbit 
ceil 255kbit burst 90k cburst 90k
$TC qdisc add dev eth0 parent 1:22 sfq limit 30

$TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 
192.168.0.99 flowid 1:2
$TC filter add dev eth0 parent 1:2 protocol ip prio 1 u32 match ip 
protocol 6 0xff flowid 1:22
$TC filter add dev eth0 parent 1:2 protocol ip prio 2 u32 match u32 0 0 
flowid 1:21


cat htb-255-eth0-prio


set -x
IP=/sbin/ip
TC=/sbin/tc

$TC qdisc del dev eth0 root &>/dev/null

if [ "$1" = "stop" ]
then
         echo "stopping"
         exit
fi

$TC qdisc add dev eth0 root handle 1: htb

$TC class add dev eth0 parent 1: classid 1:1 htb rate 255kbit burst 100k 
cburst 100k
$TC qdisc add dev eth0 parent 1:1 handle 2: prio bands 2 priomap  1 1 1 
1 1 1 1 1 1 1 1 1 1 1 1 1
$TC qdisc add dev eth0 parent 2:1 bfifo limit 50k
$TC qdisc add dev eth0 parent 2:2 sfq limit 30

$TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 
192.168.0.3 flowid 1:1
$TC filter add dev eth0 parent 2: protocol ip prio 1 u32 match ip 
protocol 6 0xff flowid 2:2
$TC filter add dev eth0 parent 2: protocol ip prio 2 u32 match u32 0 0 
flowid 2:1

$TC class add dev eth0 parent 1: classid 1:2 htb rate 255kbit burst 100k 
cburst 100k
$TC qdisc add dev eth0 parent 1:2 handle 3: prio bands 2 priomap  1 1 1 
1 1 1 1 1 1 1 1 1 1 1 1 1
$TC qdisc add dev eth0 parent 3:1 bfifo limit 50k
$TC qdisc add dev eth0 parent 3:2 sfq limit 30

$TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 
192.168.0.99 flowid 1:2
$TC filter add dev eth0 parent 3: protocol ip prio 1 u32 match ip 
protocol 6 0xff flowid 3:2
$TC filter add dev eth0 parent 3: protocol ip prio 2 u32 match u32 0 0 
flowid 3:1


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] limit bandwidth per host question

[Andy Furniss]

Andy Furniss wrote:

>> tc class add dev eth2 parent 1:0 classid 1:2 htb rate 255kbit burst 
>> 255kbit

> Burst is a good idea

Actually you need to specify burst and cburst for it to work and I
suppose the law doesn't stop you being more generous than 255kbit - I
just tried 100k (= 100k byte) and browsing isn't too bad.

Browsing and downloading together with just fifo is horrible though. I
tried htb with the prio qdisc and it was dissapointing WRT latency. HTB
class prio was far better. In both cases I also had sfq on the leaf of
the tcp class, which makes browsing while downloading nicer and for tcp
games didn't hurt latency too much.

I was only testing with one user though I scripted two, I'll get round
to playing with curl loader one day. There's bound to be a mistake
somewhere, but I paste below what I did. class/flowids are hex and you
have 0-ffff after : (minor) to play with - you'll need a more sensible
numbering system that I chose.

Policing was also not too bad.

Andy.

cat htb-255-eth0-prio-htb

set -x
IP=/sbin/ip
TC=/sbin/tc

$TC qdisc del dev eth0 root &>/dev/null

if [ "$1" = "stop" ]
then
         echo "stopping"
         exit
fi

$TC qdisc add dev eth0 root handle 1: htb

$TC class add dev eth0 parent 1: classid 1:1 htb rate 255kbit burst 100k
cburst 100k
$TC class add dev eth0 parent 1:1 classid 1:11 htb prio 0 rate 200kbit
ceil 255kbit burst 10k cburst 10k
$TC qdisc add dev eth0 parent 1:11 bfifo limit 50k
$TC class add dev eth0 parent 1:1 classid 1:12 htb prio 1 rate 55kbit
ceil 255kbit burst 90k cburst 90k
$TC qdisc add dev eth0 parent 1:12 sfq limit 30

$TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst
192.168.0.3 flowid 1:1
$TC filter add dev eth0 parent 1:1 protocol ip prio 1 u32 match ip
protocol 6 0xff flowid 1:12
$TC filter add dev eth0 parent 1:1 protocol ip prio 2 u32 match u32 0 0
flowid 1:11

$TC class add dev eth0 parent 1: classid 1:2 htb rate 255kbit burst 100k
cburst 100k
$TC class add dev eth0 parent 1:2 classid 1:21 htb prio 0 rate 200kbit
ceil 255kbit burst 10k cburst 10k
$TC qdisc add dev eth0 parent 1:21 bfifo limit 50k
$TC class add dev eth0 parent 1:2 classid 1:22 htb prio 1 rate 55kbit
ceil 255kbit burst 90k cburst 90k
$TC qdisc add dev eth0 parent 1:22 sfq limit 30

$TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst
192.168.0.99 flowid 1:2
$TC filter add dev eth0 parent 1:2 protocol ip prio 1 u32 match ip
protocol 6 0xff flowid 1:22
$TC filter add dev eth0 parent 1:2 protocol ip prio 2 u32 match u32 0 0
flowid 1:21


cat htb-255-eth0-prio


set -x
IP=/sbin/ip
TC=/sbin/tc

$TC qdisc del dev eth0 root &>/dev/null

if [ "$1" = "stop" ]
then
         echo "stopping"
         exit
fi

$TC qdisc add dev eth0 root handle 1: htb

$TC class add dev eth0 parent 1: classid 1:1 htb rate 255kbit burst 100k
cburst 100k
$TC qdisc add dev eth0 parent 1:1 handle 2: prio bands 2 priomap  1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1
$TC qdisc add dev eth0 parent 2:1 bfifo limit 50k
$TC qdisc add dev eth0 parent 2:2 sfq limit 30

$TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst
192.168.0.3 flowid 1:1
$TC filter add dev eth0 parent 2: protocol ip prio 1 u32 match ip
protocol 6 0xff flowid 2:2
$TC filter add dev eth0 parent 2: protocol ip prio 2 u32 match u32 0 0
flowid 2:1

$TC class add dev eth0 parent 1: classid 1:2 htb rate 255kbit burst 100k
cburst 100k
$TC qdisc add dev eth0 parent 1:2 handle 3: prio bands 2 priomap  1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1
$TC qdisc add dev eth0 parent 3:1 bfifo limit 50k
$TC qdisc add dev eth0 parent 3:2 sfq limit 30

$TC filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst
192.168.0.99 flowid 1:2
$TC filter add dev eth0 parent 3: protocol ip prio 1 u32 match ip
protocol 6 0xff flowid 3:2
$TC filter add dev eth0 parent 3: protocol ip prio 2 u32 match u32 0 0
flowid 3:1



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc