combining 2 ADSL Lines

[Aaron Nichols]

On Sat, 18 Dec 2004 03:40:56 +0100, Hexren <me at hexren.net> wrote:

> Could this not be circumvented by using a server in the
> Internet as second Gateway. If I route all traffic (both lines) from my LAN Gateway
> through a VPN to a second Gateway NAT it there and only then go to the Internet.
> The Net should just see the second Gateways IP. Or am I talking crap ?
> *a bit confused here*
> 
> Hexren

I try not to use absolutes - and I think this idea is probably the
most likely way to do what you want. However, there are a number of
things that make me question whether this will work as you think it
should.

Depending on the type of VPN you use, you are going to be dependent
upon the routing method used by the VPN to balance the traffic. In the
case of IPSec - I'm not sure that having two SA's with the same remote
network will be balanced. I suspect one or the other SA will be used
but perhaps that's not true. To get an increase in aggregate bandwidth
(not just the ability to use both lines) you need to have per-packet
load balancing across both VPN's. I have no idea if the underlying
code supports this type of load-balancing over multiple VPN's.
Assuming this works brings me to the 2nd problem

Since the link from this "public" gateway to each DSL line is via a
number of other devices, most likely, you wont have the traditional
ability to monitor the queue for each link to determine which path a
packet takes. Normally the less congested link would be used when the
other path becomes busy, keeping the two connections relatively
balanced and providing you with higher aggregate bandwidth. How do you
determine which path is congested if you are 3 hops away via a VPN?
You can assume that it's safe to simply send every other packet over
each link, but then what if one link starts to experience packet loss
or slows down? Then you will probably severely impact your overall
bandwidth since there is no way for this upstream gateway to choose to
send more traffic over the working path.

An extreme example of a problematic scenario from above (albeit highly
unlikely) is a mix of large packets and small packets. You could have
a majority of large packets sent over one link and small packets over
the other - leaving one link relatively underutilized while the other
becomes saturated. The gateway has no way to know that one line is
underutilized and thus should send more data over that line to provide
more bandwidth.

Also, if one link goes down, how quickly will this upstream gateway
know that the VPN is not available? Again, depending on the type of
VPN, this can take from a few seconds if a keepalive is used, to a few
minutes or many minutes if not. In the case of IPSec on FreeBSD, which
I don't think implements Dead Peer Detection, it's likely to take
quite a while for the gateway to realize that a particular link is no
longer available. During this time traffic will still be sent over
both links resulting in consistent 50% packet loss.

Again, this is all theoretical - I've never done it. Some or all of
this may be able to be worked around with other tools. I'd be very
interested in whether you are able to get this working - I don't have
the facilities to try it out. This would be much easier if the two DSL
links could cooperate so that you would at least resolve the issues
above.

If you want to just use per-session load balancing (each connection
goes via one or the other DSL line and sticks with that one) there are
a number of options which will certainly link. Those options have been
suggested by others on the list and there are many threads regarding
doing this. This doesn't buy you higher aggregate throughput as far as
I know.

Aaron