Re: RE: [LARTC] Per-connection routing for multiple uplinks/providers ??
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Why don't he(she) use nth patch from the pom for load ballancing? > It works fine for me. > > Regards, > > Andrew Kozachenko i haven't said it clearly but he has links to 3 DIFFERENT ISP (3 different IP), so nth packet marking isn't enough - all outgoing packets belonging to connection must be sent through same link to have uniform "external" ip regards, mikee __ ignore ads below this line - zrób sympatii niespodziankę i wyślij logo AA.101431 SMS na numer 7116 koszt 1 zl + Vat :: Idea, Era i Plus Gsm www.toplogo.pl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers ??
my cousin has 3 ISP connections (DSL, ISDN, HIS) and he made "load balancing" using iptables CONNMARK. this patch allows marking all packets belonging to connection with one mark, anyway this patch is rather outtdated but my cousin was able to make it working with 2.4.18 kernel (there's problem with connmark's mark - it doesn't work with mark-based routing, but MARK module works so packets can be marked with CONNMARK and then with MARK so thar routing works) mikee __ ignore ads below this line - zrób sympatii niespodziankę i wyślij logo AA.101431 SMS na numer 7116 koszt 1 zl + Vat :: Idea, Era i Plus Gsm www.toplogo.pl ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers
Don Cohen writes: >Bob Gustafson writes: > > But, But, - this is really just software. We are not trying to cram wine > > bottles down the internet pipe (although many would really like to do > > that!). > >The limitations I point out are inherent in tcp/ip. Yes, there are limitations in tcp/ip.. > > > >From the requestee point of view, I know how much bandwidth I need to > > listen to the BBC newscast, or to a company conference call. I can also > > request email and ftp sessions to work in the 'background' at a lower > > bandwidth allocation (cost?), but if I am talking to someone interactively, > > it would be nice if my packets were transferred at a regular rate without > > jitter or delay. IP doesn't do this, and one can argue that it cannot. But, > > the whole thing is run by software and software can change. > >All of the things above can already be done on a single link. With IP, to get decent QoS, you need a bit of excess bandwidth on the connection. With contention for the pipe at any point in the path from sender to receiver, the connection reverts to a 'best efforts' un-policed connection. Hmm, maybe I'm wandering into the Pub wearing a weird hat. After all, this is the Lartc mail list. >What cannot be done is make two links work like one with the >sum of the bandwidth. I can see your point. I didn't say that it was going to be easy. == I just 'measured' my DSL bandwidth at 632 kbits/sec and my Cable bandwidth at 897 kbits/sec (using bandwidthplace.com) == BobG ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers
Bob Gustafson writes: > But, But, - this is really just software. We are not trying to cram wine > bottles down the internet pipe (although many would really like to do > that!). The limitations I point out are inherent in tcp/ip. I think I sent a proposal to this list describing a modification to tcp that would allow one connection to use many ip addresses (for each endpoint). That would allow substantial improvement, since you would be able to switch addresses in "mid stream" (in a live connection). It would not solve all of the problems. In particular, you would not be able to efficiently use both/all addresses at once because tcp has been adapted to work well in the case where packets arrive in order. That could also perhaps be overcome with changes to tcp. Note, however, that these changes would only help you in cases where both machines are using the modified versions. > >From the requestee point of view, I know how much bandwidth I need to > listen to the BBC newscast, or to a company conference call. I can also > request email and ftp sessions to work in the 'background' at a lower > bandwidth allocation (cost?), but if I am talking to someone interactively, > it would be nice if my packets were transferred at a regular rate without > jitter or delay. IP doesn't do this, and one can argue that it cannot. But, > the whole thing is run by software and software can change. All of the things above can already be done on a single link. What cannot be done is make two links work like one with the sum of the bandwidth. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers
> > I have been digging through the Lartc documentation as well as Netfilter, > > etc. and haven't found much on per-connection routing for multiple > > uplinks/providers. > > > > What I would like to do is cleanly move packets out to the Internet over > > two (maybe 3) separate interfaces, utilizing all of the bandwidth, and > > avoiding snags. > >What you (and everyone else) would really like is to make your two or >three links act like one link with bandwidth equal to the sum of the >parts. As long as those different links have different ip addresses >(which will surely be the case if they connect to different providers) >this cannot be done. But, But, - this is really just software. We are not trying to cram wine bottles down the internet pipe (although many would really like to do that!). I contend that since we are trying to send information down the pipe(s) - ephemeral information - with no mass, only governed by Shannon's law (and perhaps some other laws, but not physical laws), we can creep up on the goal(s) I originally set out. I am not saying that it will be easy, only that it is possible. (Look at the QoS success of ATM for example) I really appreciate all of the good ideas and hints which have arrived in response to my original plea for help. My first steps are to construct a test lashup - something that will probe the pipes - determine available bandwidth in both directions on each pipe, and then tweek the connections, add queues, add QoS specs, marks, etc. to attempt to tell the cluge what I really want to do. A lab bench engineering setup. Specifying what I want to do is a significant part of the problem. Measuring how well the cluge meets the specs is also a significant part of the solution. It won't be done in an instant, it will require more tools, but I think it can be done. More kibitzing by folks on the lartc is very welcome. I need some time now to absorb all of the kind comments and suggestions which have been received so far. > > > Another approach to the problem would be to do a round-robin on a > > per-connection basis. Each new connection would go out of the 'next' > > interface. >Again, the problem is that when you have to choose you don't know what >the bandwidth of the connection will be. You'd do a little better >to measure the bandwidth being used currently on each link and assign >the next connection to the link with the most unused bandwidth. But >of course, this is still only a poor approximation of what you want. > Yeah, this is a good idea. Maybe this idea will be the 'best' possible. If we knew exactly how much bandwidth would be available/required for a connection (ATM again), then there wouldn't be any need to predict the future. With IP connections, the bandwidth available now isn't really a reliable predictor of the bandwidth available a few milliseconds into the future (unfortunately), so there is a bit of statistical uncertainty to meeting goals or specifications. >From the requestee point of view, I know how much bandwidth I need to listen to the BBC newscast, or to a company conference call. I can also request email and ftp sessions to work in the 'background' at a lower bandwidth allocation (cost?), but if I am talking to someone interactively, it would be nice if my packets were transferred at a regular rate without jitter or delay. IP doesn't do this, and one can argue that it cannot. But, the whole thing is run by software and software can change. Thanks again for all of the helpful comments. BobG ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers??
On Tue, 16 Apr 2002, Patrick McHardy wrote: > Mihai RUSU wrote: > > > I wont recommend the round robin packet load balancing as that would do > > more problems with TCP connections, asymetric routing , RTT values. > > I guess if you'd use multiple connections to the same ISP (and same > access point) that would solve the problems of different RTT values. > Otherwise i can confirm there are problems, i had a lot more (needless) > retransmits using a dsl + two isdn links which was probably due to very > different RTT on both links. > Yep, also you mentioned about that patch, which would do if having the same provider as yuo said. In theory the lower layer u do the load balancing the more equal it is (think about per destination, per packet, multilink ppp, ATM ...) > > Cisco recommends the per destination load balancing solution. I think if > > It's not always practical. For example in my case one of the links is > asymetric (256k upstresm/1mbit downstream), the other isn't. So > distributing traffic with a normal multipath route would result in some > connections (maybe downloads) beeing on the link with slow downstream. > I guess (as always) that there is a price to be paid. If this situations with traffic being routed on the slow link happens too often some static routes would help :) Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers??
Mihai RUSU wrote: > I wont recommend the round robin packet load balancing as that would do > more problems with TCP connections, asymetric routing , RTT values. I guess if you'd use multiple connections to the same ISP (and same access point) that would solve the problems of different RTT values. Otherwise i can confirm there are problems, i had a lot more (needless) retransmits using a dsl + two isdn links which was probably due to very different RTT on both links. > Cisco recommends the per destination load balancing solution. I think if It's not always practical. For example in my case one of the links is asymetric (256k upstresm/1mbit downstream), the other isn't. So distributing traffic with a normal multipath route would result in some connections (maybe downloads) beeing on the link with slow downstream. Bye, Patrick ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers??
On Mon, 15 Apr 2002, Bob Gustafson wrote: > Hi - I'm a new subscriber to this list. > > I have been digging through the Lartc documentation as well as Netfilter, > etc. and haven't found much on per-connection routing for multiple > uplinks/providers. > I wont recommend the round robin packet load balancing as that would do more problems with TCP connections, asymetric routing , RTT values. Cisco recommends the per destination load balancing solution. I think if you enable uqual cost multipath in kernel and add the proper routing entries with ip route the kernel would do the rest (building the FIB entries by a round robin per destination fashion). If you have time it would be nice to give it a try and let us know how it worked :) Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers ??
Bob Gustafson wrote: >>On Mon, 15 Apr 2002, Bob Gustafson wrote: >> >> >>>What I would like to do is cleanly move packets out to the Internet over >>>two (maybe 3) separate interfaces, utilizing all of the bandwidth, and >>>avoiding snags. >> >>[snip, lots of nice interesting wishes] >> >> >>>Does such a beast exist? Is it possible to build with current >>>ip/tc/netfilter technology? I am running a near stock RH 7.2 at the >>>moment. Each ISP line is going through a separate (proprietary/black-box) >>>firewall/router and then into the RH7.2 box. >> >>QoS and routing are basically independent of each other. Orthogonal, >>mathematicians would say. Furthermore, there *is* in fact a patch floating >>around somewhere on the internet that flushes the route cache after every >>packet... that might help. I've never used it, as I don't trust it to keep >>TCP connections intact, but still, it might prove useful. The patch is called equalize, i've adapted it to 2.4.18 and fixed some locking issued some time ago, it's available at ftp://sliepen.warande.net/pub/eql/ . I haven't found the time to experience a lot with it, but i didn't notice any broken tcp connections. Bye, Patrick ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers ??
On Tue, 16 Apr 2002, Bob Gustafson wrote: > >On Mon, 15 Apr 2002, Bob Gustafson wrote: > > > >> What I would like to do is cleanly move packets out to the Internet over > >> two (maybe 3) separate interfaces, utilizing all of the bandwidth, and > >> avoiding snags. > > > >[snip, lots of nice interesting wishes] > > > >> Does such a beast exist? Is it possible to build with current > >> ip/tc/netfilter technology? I am running a near stock RH 7.2 at the > >> moment. Each ISP line is going through a separate (proprietary/black-box) > >> firewall/router and then into the RH7.2 box. > > > >QoS and routing are basically independent of each other. Orthogonal, > >mathematicians would say. Furthermore, there *is* in fact a patch floating > >around somewhere on the internet that flushes the route cache after every > >packet... that might help. I've never used it, as I don't trust it to keep > >TCP connections intact, but still, it might prove useful. > > > >You'll have to do some digging on your own though... > > I was afraid of that. But this list was the first place to dig, yes? Yes, nowadays it is. :) At least you know there's something out there. Oh, as I recall the patch is by some weird guy in Utrecht, The Netherlands. Can't seem to find it using Google at the moment though. The stuff on http://www-2.cs.cmu.edu/~jcl/programs/ipeql/ipeql.html does seem like something you might want to look at (even though it is *old*). > > > >Doei, Arthur. (Oh, and it is Arthur van Leeuwen. The surname is > > 'van Leeuwen'. Kinda like in 'Ludwig van Beethoven') > > Ahh, learn something every day. The van *isn't* just like a middle > name then. Nope. It would've been capitalized if it were. :) > (I was pretty careful about the spelling of Leeuwen though :-) Don't computers make life *easy*? :P > Thanks much for the feedback My pleasure. Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers ??
>On Mon, 15 Apr 2002, Bob Gustafson wrote: > >> What I would like to do is cleanly move packets out to the Internet over >> two (maybe 3) separate interfaces, utilizing all of the bandwidth, and >> avoiding snags. > >[snip, lots of nice interesting wishes] > >> Does such a beast exist? Is it possible to build with current >> ip/tc/netfilter technology? I am running a near stock RH 7.2 at the >> moment. Each ISP line is going through a separate (proprietary/black-box) >> firewall/router and then into the RH7.2 box. > >QoS and routing are basically independent of each other. Orthogonal, >mathematicians would say. Furthermore, there *is* in fact a patch floating >around somewhere on the internet that flushes the route cache after every >packet... that might help. I've never used it, as I don't trust it to keep >TCP connections intact, but still, it might prove useful. > >You'll have to do some digging on your own though... I was afraid of that. But this list was the first place to dig, yes? > >Doei, Arthur. (Oh, and it is Arthur van Leeuwen. The surname is > 'van Leeuwen'. Kinda like in 'Ludwig van Beethoven') Ahh, learn something every day. The van *isn't* just like a middle name then. (I was pretty careful about the spelling of Leeuwen though :-) Thanks much for the feedback BobG ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-connection routing for multiple uplinks/providers??
On Mon, 15 Apr 2002, Bob Gustafson wrote: > What I would like to do is cleanly move packets out to the Internet over > two (maybe 3) separate interfaces, utilizing all of the bandwidth, and > avoiding snags. [snip, lots of nice interesting wishes] > Does such a beast exist? Is it possible to build with current > ip/tc/netfilter technology? I am running a near stock RH 7.2 at the > moment. Each ISP line is going through a separate (proprietary/black-box) > firewall/router and then into the RH7.2 box. QoS and routing are basically independent of each other. Orthogonal, mathematicians would say. Furthermore, there *is* in fact a patch floating around somewhere on the internet that flushes the route cache after every packet... that might help. I've never used it, as I don't trust it to keep TCP connections intact, but still, it might prove useful. You'll have to do some digging on your own though... Doei, Arthur. (Oh, and it is Arthur van Leeuwen. The surname is 'van Leeuwen'. Kinda like in 'Ludwig van Beethoven') -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
