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??
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 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
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
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
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/
[LARTC] Per-connection routing for multiple uplinks/providers ??
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. 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. I could use a round-robin scheduler, which would put consecutive packets on different interfaces. I think this will run into problems when the reply packets come back. Maybe not ?? I read through Arthur Leeuwen's documentation (http://lartc.org/HOWTO//cvs/2.4routing/html/x247.html ) on a scheme for dividing the outgoing packets on a per-route basis. Packets going to the same destination will go through the same interface. This gets around the round-robin problem, but I think this is not 'fair' in the sense that one interface might accumulate more routes than the other, and there does not seem to be a mechanism (other than periodically flushing the route tables) for evening out the flows. It is pretty simple though and I will use this as a first chop solution. 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. I don't know exactly how to do this though. Perhaps marking the 'NEW' state packet and routing on the mark (even marks go to the left interface, odd marks to the right,... mod N for more than 2 interfaces). Of course, it would be nice to allocate connections on an available bandwidth basis. Also do some QoS for ftp vs interactive (am looking at the wondershaper..) Also would be nice to periodically grab statistics so that I could determine whether I need to get rid of an ISP (for non-competitive price/bw stats). The stats could also be used to 'close the loop' around the routing to ensure that the best bandwidth is being achieved. Also would be nice to energize a dial-up connection if the other 2 die for some reason. 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. Thanks for your time. 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/
