> > 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
