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
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 >> >> > >
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 burst255kbit> 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 burst255kbit> 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
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.
Andy Furniss wrote:>> tc class add dev eth2 parent 1:0 classid 1:2 htb rate 255kbit burst >> 255kbit> Burst is a good ideaActually 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
Andy Furniss wrote:>> tc class add dev eth2 parent 1:0 classid 1:2 htb rate 255kbit burst >> 255kbit> Burst is a good ideaActually 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