> 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. You can indeed send traffic out in a manner that uses all of your bandwidth (assuming your providers don't do the ingress/egress filtering that they should - a pretty safe bet at the moment, sad to say). This does introduce additional problems since packets you send are now much more likely to arrive out of order, and for that reason alone it's probably not a good idea. A more fundamental problem is that the incoming packets cannot share the different links in the same way. When you send a packet out you have to choose one IP address as its source. The reply will be sent to that address and will have to arrive on the link with that address. Thus, for example, if you have two links with the same incoming bandwidth and only one connection, you can't use more than half of your total incoming bandwidth for that connection. > 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 ?? As long as the provider does no filtering this will work, but will also cause packets to arrive out of order, which is bad for performance. > 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. Who cares about fairness in the number of routes? The important thing is the bandwidth used by those routes. And you can't balance that, since you don't know when you choose the route what bandwidth will be used by that route. > 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.
