From mboxrd@z Thu Jan 1 00:00:00 1970 From: nic-lartc@studentergaarden.dk Date: Tue, 08 May 2007 14:44:41 +0000 Subject: Re: [LARTC] limit bandwidth per host question Message-Id: <46408CD9.2090101@studentergaarden.dk> List-Id: References: <463FD790.8010709@studentergaarden.dk> In-Reply-To: <463FD790.8010709@studentergaarden.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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: > To: > 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