Hi, A few days ago I asked you all for input on whether my P200 could handle the tasks of NAT'ing, controlling, and firewalling. The answer from a number of you was "yes". Below is current set-up that I pieced together after skimming the LARTC how-to. I'll start by describing my situation and objectives, then I'll get into the script and state how the lines contribute to the objective. SITUATION: --------- - Firewall/Router/Gateway: P200, 48MB RAM, RedHat 9 -- shares internet with all other machines through a 1.5Mbit/192Kbit cable connection (mine) - 4 WinXP Pro desktops (2 at neighbours and 2 are mine) - 1 RedHat 9 Samba server. Runs a UT2003 server that is accessible by password from internet and an Apache server for UT2003 map downloads (mine) OBJECTIVES: ---------- First and foremost I want to ensure that the UT2003 server/players and Microsoft Gamvoice have guaranteed bandwidth regardless of what is happening elsewhere. Second, I want keep the neighbour's use of Kaazaa to flood my upstream and downstream bandwidth. Third, I would like to shape my traffic to give interactive traffic priority. WHAT I'VE DONE SO FAR: ---------------------- It's not elegant, but so far it's seems to be making a difference. Your advice is welcome. ################################################################# #!/bin/bash # delete old settings #tc qdisc del dev eth0 root #tc qdisc del dev eth1 root /root/shaping/stop ############## HTB DOWNSTREAM ################# # create qdisc - eth0 is my internal nic tc qdisc add dev eth0 root handle 1: htb default 50 # -- 100MBit NIC tc class add dev eth0 parent 1: classid 1:1 htb rate 75000kbit ceil 100000kbit # neighbour's house - Class for neighbour's traffic is limited to 1/2 max downstream so they always get consistent performance tc class add dev eth0 parent 1:1 classid 1:10 htb rate 730kbit ceil 750kbit prio 1 # our house - Class for our traffic; limit is higher to allow for variability tc class add dev eth0 parent 1:1 classid 1:20 htb rate 730kbit ceil 1500kbit prio 1 # for lan only traffic between admin and firewall computer (ssh) -- class to ensure that my ssh sessions are not crippled tc class add dev eth0 parent 1:1 classid 1:30 htb rate 5000kbit ceil 15000kbit prio 2 # guaranteed pipe for voice and ut2k3 -- class for GameVoice and UT2K3 tc class add dev eth0 parent 1:1 classid 1:40 htb rate 40kbit ceil 80kbit prio 0 # everything else -- Anything that doesn't fit into either class. Don't know what it would be, but it doesn't get much bandwidth. tc class add dev eth0 parent 1:1 classid 1:50 htb rate 5kbit ceil 10kbit prio 3 # sfq -- Implement SFQ for all classes tc qdisc add dev eth0 parent 1:10 handle 110: sfq perturb 10 tc qdisc add dev eth0 parent 1:20 handle 120: sfq perturb 10 tc qdisc add dev eth0 parent 1:40 handle 140: sfq perturb 10 tc qdisc add dev eth0 parent 1:50 handle 150: sfq perturb 10 # Mark Packets # Neighbour's Packets by IP tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ dst 192.168.0.7 flowid 1:10 tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ dst 192.168.0.8 flowid 1:10 # UT2K3 and GameVoice by ports tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ dport 9110 0xffff flowid 1:40 tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ dport 7777 0xffff flowid 1:40 # ssh by port tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ sport 22 0xffff flowid 1:30 # My computers (not all exist) by IP tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ dst 192.168.0.2 flowid 1:20 tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ dst 192.168.0.3 flowid 1:20 tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ dst 192.168.0.4 flowid 1:20 tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ dst 192.168.0.5 flowid 1:20 tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip \ dst 192.168.0.6 flowid 1:20 ############ HTB UPSTREAM ######################### # create qdisc - eth1 is external nic on 192kbit upstream connnection tc qdisc add dev eth1 root handle 2: htb default 50 # limits upstream tc class add dev eth1 parent 2: classid 2:2 htb rate 180kbit ceil 180kbit # guaranteed pipe for voice and ut2k3 tc class add dev eth1 parent 2:2 classid 2:40 htb rate 40kbit ceil 80kbit prio 1 # everything else tc class add dev eth1 parent 2:2 classid 2:50 htb rate 140 ceil 180kbit prio 0 # sfq - on all classes tc qdisc add dev eth1 parent 2:40 handle 240: sfq perturb 10 tc qdisc add dev eth1 parent 2:50 handle 250: sfq perturb 10 # Mark Packets # ut2k3 and voice tc filter add dev eth1 parent 2: protocol ip prio 100 u32 match ip \ dport 59110 0xffff flowid 2:40 tc filter add dev eth1 parent 2: protocol ip prio 100 u32 match ip \ sport 7777 0xffff flowid 2:40 # not sure how to separate my upstream from neighbour's upstream ###################################################################### Any ideas, suggestions would be appreciated, but please be explicit. I'm very new at this and don't understand much of the theory yet. Thanks! N -----Original Message----- From: lartc-admin@xxxxxxxxxxxxxxx [mailto:lartc-admin@xxxxxxxxxxxxxxx] On Behalf Of lartc-request@xxxxxxxxxxxxxxx Sent: April 29, 2003 12:38 AM To: lartc@xxxxxxxxxxxxxxx Subject: LARTC digest, Vol 1 #1146 - 10 msgs Send LARTC mailing list submissions to lartc@xxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@xxxxxxxxxxxxxxx You can reach the person managing the list at lartc-admin@xxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. tcng version 9e (Werner Almesberger) 2. Re: problem: Error: Qdisc "htb" is classless. (Stef Coene) 3. Re: question about tc and ip aliasing (Stef Coene) 4. Re: Eureka! (Stef Coene) 5. Re: Eureka! (=?iso-8859-1?Q?John_B=E4ckstrand?=) 6. proxy arp problem (Don Cohen) 7. Re: Eureka! (Ricardo Jorge da Fonseca Marques Ferreira) 8. Re: Eureka! (Ricardo Jorge da Fonseca Marques Ferreira) 9. PCI IRQ conflict (Muhammad Al-Gharribeh) 10. PCI IRQ conflict (Muhammad Al-Gharribeh) --__--__-- Message: 1 Date: Mon, 28 Apr 2003 15:42:44 -0300 From: Werner Almesberger <wa@xxxxxxxxxxxxxxx> To: lartc@xxxxxxxxxxxxxxx Subject: [LARTC] tcng version 9e ... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9e.tar.gz md5sum 22db4d60a78ff8338a8cd73995c78a2c (See also http://tcng.sourceforge.net/) Another maintenance release: - fixes a regression in version 8w (tcsim_filter output change broke tcsim_plot -t delay; thanks to Dimitry Ketov for spotting this) - a few scripts in examples/ used UDP_HDR instead of IP_HDR (this error was probably introduced in version 8y) - minor compatibility fixes for RedHat 8.0 The complete list of changes is below. - Werner ----------------------------------- CHANGES ----------------------------------- Version 9e (28-APR-2003) ------------------------ - updated tests/tcng-6u to accept captialization of cpp 3.2 - put back packet ID in tcsim_filter output, which was removed in tcng-8x because I had forgotten that it was used for delay calculation in tcsim_plot (fixed by Dimitry Ketov; updated tests/basic, tests/tcng-8x, tests/tcsattpro, tests/tcsattpsv, and tests/tcsattset) - doc/tcsim.inc: updated tcsim_filter output format description accordingly - examples/dsmark+policing, examples/ef-prio, and examples/gred used UDP_HDR instead of IP_HDR - "make rpm" and "make tcsim-rpms" now use "rpmbuild" instead of "rpm" if available -- ________________________________________________________________________ _ / Werner Almesberger, Buenos Aires, Argentina wa@xxxxxxxxxxxxxxx / /_http://www.almesberger.net/___________________________________________ _/ --__--__-- Message: 2 From: Stef Coene <stef.coene@xxxxxxxxx> Organization: None To: Ana Carolina Alonso <aalonso@xxxxxxxxxxxxx>, lartc@xxxxxxxxxxxxxxx Subject: Re: [LARTC] problem: Error: Qdisc "htb" is classless. Date: Mon, 28 Apr 2003 21:19:31 +0200 On Monday 28 April 2003 15:51, Ana Carolina Alonso wrote: > Hello, I have a problem, I want to configure the htb qdisc, my > configuration scripts loke like: > > tc qdisc add dev eth0 root handle 1: htb > > tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k > tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k > tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit burst 15k > tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit burst 15k > > tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc qdisc > add dev eth0 parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev > eth0 parent 1:30 handle 30: sfq perturb 10 > > tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip > sport 80 0xffff flowid 1:10 tc filter add dev eth0 protocol ip parent > 1:0 prio 1 u32 match ip sport 25 0xffff flowid 1:20 > > When I execute my script I get: > > RTNETLINK answers: Invalid argument > Error: Qdisc "htb" is classless. > Error: Qdisc "htb" is classless. > Error: Qdisc "htb" is classless. > Error: Qdisc "htb" is classless. > RTNETLINK answers: No such file or directory > RTNETLINK answers: No such file or directory > RTNETLINK answers: No such file or directory > RTNETLINK answers: Invalid argument > RTNETLINK answers: Invalid argument > > What is wrong?. Do you have htb support in the kernel and a tc binary with htb support ? Stef -- stef.coene@xxxxxxxxx "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net --__--__-- Message: 3 From: Stef Coene <stef.coene@xxxxxxxxx> Organization: None To: Szymon Miotk <spam@xxxxxxxxxxxxx>, lartc@xxxxxxxxxxxxxxx Subject: Re: [LARTC] question about tc and ip aliasing Date: Mon, 28 Apr 2003 21:26:43 +0200 On Monday 28 April 2003 10:45, Szymon Miotk wrote: > Enric Ramos Mas wrote: > > I have implemented a traffic control / advanced router server using > > iproute2 and tc (using htb). For all my outgoing tc policies, all > > it's ok (all the traffic goes out using eth0, and therefore I'm able > > to catch it using the corresponfing tc filter). > > > > However, the incoming traffic has to be treated in eth1, which has > > several virtual ifaces (eth1:0, eth1:1, eth1:2 and so on). Even I > > have introduced all the tc rules correctly, the kernel is not > > matching any filter rule and there is no way to match any > > destination into any queue discipline. > > > > Anyone knows some way to implement that ? > > I'm also very interested about this question as I have similiar link > configuration. One question about classes on eth0: do leaf rates (1:10 > - 1:??) sum up to 3256kbit (parent rate)? > I have to split 1040 kbit for 700 users and HTB manual advices > a) that children rates should sum up to parent rate > b) that the rate should not be less than 4kbit This is the first time I hear about this rule. You can have a problem with quantum if you have a low rate. But you can overrule quantum when you add a htb class (rule : quantum > MTU). > I expect that I should go by the b) rule, as used rates will never sum > up over 1040kbit (there will never be 700 users using this link at the > same time). Am I right? Yes. The problem is that the parent rate is not respected. So if each class is sending, it will exceed the parent rate. This can be "bad" because you send more data then your router/modem can handle so it's possible that you your shaping will not be that perfect. Stef -- stef.coene@xxxxxxxxx "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net --__--__-- Message: 4 From: Stef Coene <stef.coene@xxxxxxxxx> Organization: None To: Ricardo Jorge da Fonseca Marques Ferreira <stormlabs@xxxxxxx>, <lartc@xxxxxxxxxxxxxxx> Subject: Re: [LARTC] Eureka! Date: Mon, 28 Apr 2003 21:28:31 +0200 On Monday 28 April 2003 00:20, Ricardo Jorge da Fonseca Marques Ferreira wrote: > I finally figured out what in emule was ruining my network. > > I tried everything and nothing worked. I was always getting timeouts. > Until i went into the extended settings in emule and changed > connections per 5 seconds to 5 from the default of 20. Miracle. It now > works great. > > So apparently lots of connection attempts in a few seconds is an > effective way of starving all other machines behind a linux gateway > even if you're using SFQ. Mhh. I wonder how this can be. Some tcp connection specialists out here? Is it so that after a long time the connections are fair distributed or is there always a starvation of the other connections? Stef -- stef.coene@xxxxxxxxx "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net --__--__-- Message: 5 From: =?iso-8859-1?Q?John_B=E4ckstrand?= <sandos@xxxxxxx> To: "Stef Coene" <stef.coene@xxxxxxxxx>, "Ricardo Jorge da Fonseca Marques Ferreira" <stormlabs@xxxxxxx>, <lartc@xxxxxxxxxxxxxxx> Subject: Re: [LARTC] Eureka! Date: Mon, 28 Apr 2003 22:06:23 +0200 > On Monday 28 April 2003 00:20, Ricardo Jorge da Fonseca Marques Ferreira > wrote: > > I finally figured out what in emule was ruining my network. > > > > I tried everything and nothing worked. I was always getting timeouts. Until > > i went into the extended settings in emule and changed connections per 5 > > seconds to 5 from the default of 20. Miracle. It now works great. > > > > So apparently lots of connection attempts in a few seconds is an effective > > way of starving all other machines behind a linux gateway even if you're > > using SFQ. > Mhh. I wonder how this can be. Some tcp connection specialists out here? > Is it so that after a long time the connections are fair distributed or is > there always a starvation of the other connections? > > Stef It could be because SFQ only equalizes flows. If you open lots of connections then, it means every connection will get worse. If this is the problem, this will not happen with ESFQ, afaik. --- John Bäckstrand --__--__-- Message: 6 From: don-lartc@xxxxxxxxxxxxxxxx (Don Cohen) Date: Mon, 28 Apr 2003 13:05:31 -0700 To: lartc@xxxxxxxxxxxxxxx Subject: [LARTC] proxy arp problem Proxy arp seems to be the right thing for answering arp queries but it doesn't solve the problem of decaching old cache entries. Here's the example: router --- hub --- host | firewall -- The gateway for host is router. First I use the host to communicate with the outside world, so it and the router have each other in their arp caches. Now I move the host down to the other side of the firewall, which is doing arp proxy. In order to do that, of course, I have to add a route to the firewall. At this point the host and router can not talk to each other because each is trying to use the mac address in its arp cache. Ideally I'd like to solve this problem without having to log in to either the router or host. One way, of course, is to wait for the arp caches to time out. I thought this was ok, cause I thought these were very short lived, but in the case I currently face that timeout on the router is 4 hours (!!) (Is this common? Or even reasonable? Anyone know what values are in common use?) I notice rfc1122 (p22) suggests timeouts on the order of a minute, which is what I expected. If the host has a shorter timeout then here's a possible solution: I *suspect* that when a machine sends an arp request to the router: from [senderMAC] to [BroadcastMAC] who has [routerIP] tell [senderIP] the router stores in its arp cache the association [senderIP]=[senderMAC] Of course, the client machine now sends that packet to the firewall. The firewall sees this, stores [senderIP]=[senderMAC] in its own cache, and replies [routerIP] is at [MAC of firewall interface connected to client] What I want to add is that the firewall should also send out the interface connected to the router: from [MAC of firewall interface connected to router] to [BroadcastMAC] who has [routerIP] tell [clientIP] This will then elicit a reply from the router, but in fact the firewall can ignore that since it will send its own arp request to the router. Even better would be some mechanism that, when we add the route to the firewall could figure out who on either end should be sent such packets. Perhaps it could remember all of the arp requests that it had seen (these are, after all, sent to broadcast, so it wouldn't need to be in promiscuous mode) it could see from the new route (1) which ip addresses had been used in that range, (2) which ip addresses those addresses had tried to talk to directly. I'll be interested in any other ideas, and even more interested in anything that has already been implemented to solve this problem. --__--__-- Message: 7 From: Ricardo Jorge da Fonseca Marques Ferreira <stormlabs@xxxxxxx> To: Stef Coene <stef.coene@xxxxxxxxx>, <lartc@xxxxxxxxxxxxxxx> Subject: Re: [LARTC] Eureka! Date: Mon, 28 Apr 2003 21:30:41 +0100 On Monday 28 April 2003 20:28, Stef Coene wrote: > On Monday 28 April 2003 00:20, Ricardo Jorge da Fonseca Marques > Ferreira > > wrote: > > I finally figured out what in emule was ruining my network. > > > > I tried everything and nothing worked. I was always getting > > timeouts. Until i went into the extended settings in emule and > > changed connections per 5 seconds to 5 from the default of 20. > > Miracle. It now works great. > > > > So apparently lots of connection attempts in a few seconds is an > > effective way of starving all other machines behind a linux gateway > > even if you're using SFQ. > > Mhh. I wonder how this can be. Some tcp connection specialists out > here? Is it so that after a long time the connections are fair > distributed or is there always a starvation of the other connections? In my experience the connections never get fairly distributed. I can reproduce this just increasing the number of connections per 5 seconds to 20 again. The effect is imediate. I get connection timeouts in HTTP (more apparent, i'm sure other protocols suffer too) and have to reload a series of times before the connection "goes" and even then it then fails for some other elements in the page. --__--__-- Message: 8 From: Ricardo Jorge da Fonseca Marques Ferreira <stormlabs@xxxxxxx> To: John =?iso-8859-1?q?B=E4ckstrand?= <sandos@xxxxxxx>, "Stef Coene" <stef.coene@xxxxxxxxx>, <lartc@xxxxxxxxxxxxxxx> Subject: Re: [LARTC] Eureka! Date: Mon, 28 Apr 2003 22:18:55 +0100 On Monday 28 April 2003 21:06, John B=E4ckstrand wrote: > It could be because SFQ only equalizes flows. If you > open lots of connections then, it means every > connection will get worse. If this is the problem, this > will not happen with ESFQ, afaik. Hmm, is there any info on the web about ESFQ & can it be used with tcng whi= ch=20 is what i'm using now to generate my tc scripts ? --__--__-- Message: 9 From: Muhammad Al-Gharribeh <algharri@xxxxxxxxxxxxxxx> Date: Mon, 28 Apr 2003 20:20:30 -0400 (EDT) To: <lartc@xxxxxxxxxxxxxxx> Subject: [LARTC] PCI IRQ conflict Actually, I have NetVista 4 IBM personal Computers with Linux OS Red Hat 8, my research requires installing an extra three Ethernet PCI cards on each machine and I've installed those cards on my boxes. But I have a problem that all the new NIC cards are sharing the same IRQ Number. I have been searching to solve this problem but unfortunately I coudn't find anything useful . Could you please help me to solve this problem? Thanks so much in advance for your reply and I appreciate your help. Regards Al-Gharribeh Muhammad --__--__-- Message: 10 From: Muhammad Al-Gharribeh <algharri@xxxxxxxxxxxxxxx> Date: Mon, 28 Apr 2003 20:20:42 -0400 (EDT) To: <lartc@xxxxxxxxxxxxxxx> Subject: [LARTC] PCI IRQ conflict Actually, I have NetVista 4 IBM personal Computers with Linux OS Red Hat 8, my research requires installing an extra three Ethernet PCI cards on each machine and I've installed those cards on my boxes. But I have a problem that all the new NIC cards are sharing the same IRQ Number. I have been searching to solve this problem but unfortunately I coudn't find anything useful . Could you please help me to solve this problem? Thanks so much in advance for your reply and I appreciate your help. Regards Al-Gharribeh Muhammad --__--__-- _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest
