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 [EMAIL PROTECTED] wrote: (Sent by: [EMAIL PROTECTED] 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
_______________________________________________ LARTC mailing list [email protected] http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
