Date: Sat, 18 Dec 2004 22:54:55 -0800 From: Aaron Nichols <adnichols@gmail.com> To: Hexren <me@hexren.net> Cc: FreeBSD Mailing list <freebsd-questions@freebsd.org> Subject: Re: Re[2]: combining 2 ADSL Lines Message-ID: <ac055384041218225424633d42@mail.gmail.com> In-Reply-To: <19950521916.20041218034056@hexren.net> References: <1356832694.20041217153250@hexren.net> <ac05538404121715323d6d7509@mail.gmail.com> <19950521916.20041218034056@hexren.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 18 Dec 2004 03:40:56 +0100, Hexren <me@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac055384041218225424633d42>