Re: [LARTC] Promisc routing
On Sat, 2004-08-28 at 05:32, Roy wrote: > I want to set interface to promisc mode and do all routing with iptables. You don't need to set an interface in promisc mode to do routing. You need the clients to have you configured as a router (easily acheived via dhcp). Routing isn't actually done with netfilter, although the routed packets are available for filtering. > Is it somehow possible? Is it possible to use netfilter to make a routing decision? I suppose it _might_ be (using the MARK target and iproute2), but it would be overly convulted, esp compared to doing it "the normal way". > I see now kernel do not pass everything to ipables. I think you'll find that netfilter _does_ see all packets it's supposed to see - it's just a matter of what chains they pass through. Routed packets will pass through the FORWARD chains. Of course, this won't happen unless you have configured your machine as a router, and you have clients actually using it as a router (see above). > Basicaly I want to ignore ethernet addess and use only ip for routing. Um, that's what routing is (at least, in my understanding). You're talking about a Layer 3 router, which makes routing decisions based on IP addreses/subnets. Cheers Andrew ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] shaping outbound ftp without affecting inbound with 1 nic
Hi, I am using the following script to limit my outbound traffic. This scipt runs on a box behind my firewall. It limits my outbound passive ftp traffic to 39K perfectlyjust like i want. However, i just noticed that it is also limiting uploads coming to my server. Is there something I can change to make it not limit uploads to my server? #!/bin/bash #shaping passive ftp traffic # mark the outbound passive ftp packets on ports 5-51000 iptables -t mangle -D POSTROUTING -o eth0 -j MYSHAPER-OUT 2> /dev/null > /dev/null iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null iptables -t mangle -N MYSHAPER-OUT iptables -t mangle -I POSTROUTING -o eth0 -j MYSHAPER-OUT iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 65437 -j MARK --set-mark 20 iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 5:51000 -j MARK --set-mark 20 #iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 5:65437 -j MARK --set-mark 20 iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26 # clear it tc qdisc del dev eth0 root #add the root qdisk tc qdisc add dev eth0 root handle 1: htb default 26 #add main rate limit class tc class add dev eth0 parent 1: classid 1:1 htb rate 1mbps #add leaf classes tc class add dev eth0 parent 1:1 classid 1:26 htb rate 1mbps tc class add dev eth0 parent 1:1 classid 1:20 htb rate 39kbps #filter traffic into classes tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20 tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26 ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Promisc routing
El Viernes 27 Agosto 2004 20:32, Roy escribió: > HI, > > I want to set interface to promisc mode and do all routing with iptables. > Is it somehow possible? as I see now kernel do not pass everything to > ipables. > > Basicaly I want to ignore ethernet addess and use only ip for routing. > > I suppose this may require writting special kernel driver or it is possible > in other way? What are you trying to do?, what you have said is not posible, first because TCP/IP are not physical-layer protocols, that means that speaking about ethernet cards, you could not ignore ethernet adress. You have to take into account on with ISO Network layer level you are speaking. By the way .. what do you want to do? Best regards ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Promisc routing
HI, I want to set interface to promisc mode and do all routing with iptables. Is it somehow possible? as I see now kernel do not pass everything to ipables. Basicaly I want to ignore ethernet addess and use only ip for routing. I suppose this may require writting special kernel driver or it is possible in other way? ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Large number of HTB classes
On 27 August 2004 pm 15:46, Simon Lodal wrote: > I am planning a setup with thousands of classes in a HTB qdisc, say from > 1:1000 to 1:2000, each with a very small rate and a big ceil, for fair > sharing of a 45mbit link. > I suspect some problems could be lurking in there. > Anyone having good/bad experience with such number of classes? > Simon I tried with 1: as parents and child classes from 1:1000 until .. 1:9900 increments by 10, ... phuff .. nothin to worry about although checking it one by one will make ur head dizzy .. :)) - Rio.Martin - Powered by HTB since early 2003. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] imq patch question
hello list, i have a small question regarding the imq patch from www.linuximq.net by default it makes only 2 devices. how can i add interfaces (imqX)? applying the patch to a linux kernel doesn't let me build it as a module. thanks in advance, adrian ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] LARTC HOWTO: Page not found error on a link
On Fri, Aug 27, 2004 at 08:14:09PM +0530, Sanjay Arora wrote: > LARTC HOWTO > > 2.2. Prior knowledge > > Link: > Rusty Russell's networking-concepts-HOWTO > > Not Found > The requested URL > /~rusty/unreliable-guides/networking-concepts-HOWTO/index.html was not > found on this server. > > Just FYI. > > Best Regards. > Sanjay. It is here: http://www.netfilter.org/documentation/HOWTO/networking-concepts-HOWTO.html -Eric Rz. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] LARTC HOWTO: Page not found error on a link
LARTC HOWTO 2.2. Prior knowledge Link: Rusty Russell's networking-concepts-HOWTO Not Found The requested URL /~rusty/unreliable-guides/networking-concepts-HOWTO/index.html was not found on this server. Just FYI. Best Regards. Sanjay. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Large number of HTB classes
[back from reading up on HFSC] I am much tempted to go with HFSC. But I am also much tempted to stay with HTB only because HFSC is so complex, and randomly documented. Understanding the shortcomings of algorithms is key to using them. What a shame, it seems like there is some real smartness in there. Would you like to share your HFSC configuration? (less than the 27k lines you refer to in other places will also do :) Thanks for the pointers, I will look into them. Simon Tomasz Paszkowski skrev: On Fri, Aug 27, 2004 at 12:22:13PM +0200, Simon Lodal wrote: HFSC seems interesting, but does it really work well? I am not afraid of new stuff, but bleeding edge is probably too risky. I'am running HFSC for network with 4,5k users, handling about 100Mb/s internet traffic with 25kpacket/s without any problems. That HTB problem, I guess you mean it is possible to have available bandwidth, but when some of it has been distributed between users, all users' ceils go below their quantums? no But that implies that users have low ceils? Wouldn't it be solved by setting all users' ceil to the full link bandwidth? ceil is set to the full link bandwidth. I dosen't help. The doubly linked list patch you mention, I believe it should be in vanilla kernel since 2.4.20-22 or something? I use 2.4.27 here. If not, do you have a link for it? http://oss.sgi.com/projects/netdev/archive/2004-08/msg00348.html Consider also using rbtree HFSC patches. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Large number of HTB classes
On Fri, Aug 27, 2004 at 12:22:13PM +0200, Simon Lodal wrote: > > HFSC seems interesting, but does it really work well? I am not afraid of > new stuff, but bleeding edge is probably too risky. I'am running HFSC for network with 4,5k users, handling about 100Mb/s internet traffic with 25kpacket/s without any problems. > > That HTB problem, I guess you mean it is possible to have available > bandwidth, but when some of it has been distributed between users, all > users' ceils go below their quantums? no > > But that implies that users have low ceils? Wouldn't it be solved by > setting all users' ceil to the full link bandwidth? ceil is set to the full link bandwidth. I dosen't help. > > The doubly linked list patch you mention, I believe it should be in > vanilla kernel since 2.4.20-22 or something? I use 2.4.27 here. If not, > do you have a link for it? http://oss.sgi.com/projects/netdev/archive/2004-08/msg00348.html Consider also using rbtree HFSC patches. -- Tomasz Paszkowski pgp60NLTpvumP.pgp Description: PGP signature
Re: [LARTC] RE: [LARTC] Load Balance simply doesn´t work...
Cytowanie Julian Anastasov <[EMAIL PROTECTED]>: > > Hello, > > On Fri, 27 Aug 2004, [EMAIL PROTECTED] wrote: > > > You mean that using NAT its impossible to do load balance or > > this is the worng command? If its the wrong command, what´s > > the right one? > > Don't disappoint, you can check the following patches > and howtos: > > http://www.ssi.bg/~ja/#routes > > > Tks A LOT for the response! > > Fernando Favero > > Regards > > -- > Julian Anastasov <[EMAIL PROTECTED]> > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > Hi, everybody again:) As this subject comes and goes from time to time, I have some personal observations. I'm personally using such a solution :) Although this solution works perfectly (in bigger setup like few hundred machines) it has some drawbacks. One of the biggest is that some applications WILL NOT WORK. It doesn't just matter if it is connectionless or not, it just depends on security flavour used by the internet side application. For example I've found this: 1. Home Banking - typically online banks are verifying source IP of the connecting client, so it just breaks almost every connection :( 2. phpBB - depending on setup, this forum also verifies the origin. etc. I've found some misunderstanding in letters at the list: If you use Julian's patches and the script I've proposed single connection goes through single link only! during single connection source address and source interface will not be changed. But different connections with the same target can start from different interfaces and that is the source of problems mentioned above. If you login with one source, get the page and in next connection try to get it from another ip you are lost :(. But not everything is lost - policy routing comes as a helper. You can route some applications via only one connection. But this makes things more complicated as some BW management may be needed, and performance decreases. I can say that it works, because for me it works with 4 uplinks, but tuning the correct settings took some time. >From my point of view using equal cost multipath routing blindly without provider help is a bit complicated thing. But it is some kind of workaround when you can't buy a bigger, single link. PS. Sorry for this long long letter, but I hope it helps. PS. Julian, thanks for linking my script mpath2.sh from your hotwo, as I haven't got ocassion earlier :) -- Robert Kurjata mailto:[EMAIL PROTECTED] - This mail sent through IMP: http://horde.org/imp/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] qdisc/filter to drop all packets
I'm looking for a way to configure a qdisc or filter to drop all packets. The logic behind this is that I'm using the u32 hashing tables to get move my filters from iptables to tc filters. This will translate into much less per-packet processing for me. However, I need a way to drop any packets that don't match any of the filters. Get a 2.6.8.1 kernel and last iproute2 from http://developer.osdl.org/dev/iproute2/ and then: tc qdisc add dev dummy0 root netem loss 100 100 means 100% Let me know it it works correctly. Paul C. Diem [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Large number of HTB classes
HFSC seems interesting, but does it really work well? I am not afraid of new stuff, but bleeding edge is probably too risky. That HTB problem, I guess you mean it is possible to have available bandwidth, but when some of it has been distributed between users, all users' ceils go below their quantums? But that implies that users have low ceils? Wouldn't it be solved by setting all users' ceil to the full link bandwidth? The doubly linked list patch you mention, I believe it should be in vanilla kernel since 2.4.20-22 or something? I use 2.4.27 here. If not, do you have a link for it? Simon Tomasz Paszkowski skrev: On Fri, Aug 27, 2004 at 10:46:59AM +0200, Simon Lodal wrote: I am planning a setup with thousands of classes in a HTB qdisc, say from 1:1000 to 1:2000, each with a very small rate and a big ceil, for fair sharing of a 45mbit link. Consider using HFSC. HTB is not the best solution for such a number of classes with small rate. Users will not be able to get the whole ceil even if there will be avaliable bandwidth. Secondly make sure your're using kernel with double linked list patch applied to qdisc api. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Large number of HTB classes
On Fri, Aug 27, 2004 at 10:46:59AM +0200, Simon Lodal wrote: > > I am planning a setup with thousands of classes in a HTB qdisc, say from > 1:1000 to 1:2000, each with a very small rate and a big ceil, for fair > sharing of a 45mbit link. Consider using HFSC. HTB is not the best solution for such a number of classes with small rate. Users will not be able to get the whole ceil even if there will be avaliable bandwidth. Secondly make sure your're using kernel with double linked list patch applied to qdisc api. -- Tomasz Paszkowski pgp6suZVgTBMn.pgp Description: PGP signature
[LARTC] Large number of HTB classes
I am planning a setup with thousands of classes in a HTB qdisc, say from 1:1000 to 1:2000, each with a very small rate and a big ceil, for fair sharing of a 45mbit link. I suspect some problems could be lurking in there. Anyone having good/bad experience with such number of classes? Simon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/