Slashdot Mirror
Affordably Aggregating ISP Connections?
An anonymous reader writes "Has anyone setup a system to aggregate multiple ISP connections to form a high bandwidth site-to-site link? Load Sharing SCTP looked interesting, but it doesn't look like it has been widely adopted. Multi-Link PPP appears to be more widely supported for clients, but I can't find any good guides for setting up both sides of the connection for a site-to-site link. The hardware solutions I've found are expensive for a small business. Does anyone have experience using hardware solutions from Mushroom Networks (Virtual Leased Line, p2 of this document), Ecessa (site-to-Site Channel Bonding), or others?"
I have bonded 2 IPSec VPNs running over 2 ISP's to create a bigger (and cheaper) site-to-site link on the cheap.
http://www.zeroshell.net/eng/faq/vpn/
Read Point 5 in the link
What you have presented us with here is a "B C" problem. You want to achieve C, so you ask us how to do B. Unfortunately, you never specify what A is, so the best we can do is give you some pointers for B which are probably going to be irrelevant and useless to what you are really trying to achieve.
Most of the comments will probably be about trying to figure out what your A problem is. To that end, why don't you just get a faster line in the first place and forget about this line aggregation stuff you're asking about?
Sure you can.
http://www.openbsd.org/faq/pf/pools.html
One simple example. Plenty of other options available with other software. As long as you load-balance per connection instead of per packet there aren't many issues with this, and those often don't apply outside of special use cases.
a fucking book on how routing works
Now there's a fetish you'll only run across on Slashdot.
This side up.
Only works if you've got DSL, and then again only if they use PPPoE. Then the remote DSLAM needs to support mlppp as well.
I would suggest OpenBSD + PF and just load balance the connections using PF. Takes all of 10 lines of code to get it up and going and is well documented. This won't aggregate your bandwidth, however if you have multiple streams open, it'll bounce those between two or more connections. I've personally done 4 lines like this (2x adsl2+ and 2x DOCSIS 2) and hit about 95% utilization across all lines.
Also with PF, both lines don't need to be the same speed, or even with the same provider, which gives you some additional fault tolerance.
Wired has an article on Willie Nelson's setup in his tour bus running, http://www.wired.com/epicenter/2009/10/willie-nelson-broadban/ "Willie Nelson has tossed the satellite dish off the back of his corn-powered tour bus in favor of a little box that fuses wireless data cards from a variety of networks into a single connection."[Mushroom Networks PortaBella 141]
"TCP/IP doesn't allow for that, that I know of"
It sure does - it doesn't care what route the packets took - just that they got there. THe problem is if you split the stream over 3 links with varying latency - you won't see the performance gains you wan t- it'll more likely hurt.
If the goal is to end up with a virtual point-to-point link between two offices using multiple ISPs, you can certainly leverage multiple connections to do that. It also depends on the nature of the traffic.
You can set up multiple VPN tunnels and then run whatever protocol you want - you could do MLPPP - but that'll get ugly if the links don't have very similar characteristics.
The solution you mentioend in the end - Iv'e found that' susually the best - you can get most common *nix systems to do some kind of weighted load balancing of outgoing sessions... whether it's per-source, per-destination, per-protcol, or based on any other weird usage combination you had.
For an office situation Iw as once in - we had 1 2mbps and 1 x 4mbps lines (from separate providers) and a very high latency 1Mbps satellite connection.
I gave them a web page that had four buttons on it.
The first was "normal operation - 2MB + 4 MB". TCP sessions would be randomly routed over one orhte other, with double rpeference given to the 4 meg line.
The ohters were "ISP1, ISP2, and Satellite" respectively. At the push of a button the routes would flip, the state tables would flush, and everything would work. For practical puproess, it worked really well.
There is no magic way to simply aggregate bandwidth from separate providers over consumer connections with meaningful results... not like bonding multiple direct lines or anything like that.... 2 + 2 won't equal 4.... but depending on the use case, it can be just about as good.
Admittedly, I have no idea if it works, nor do I have any idea how it decides to load balance between the connections.. But I ran across the feature the other day and it looked pretty cool.
In Mac OS X you can create a new "Aggregate" network device from any other devices and, in theory, do exactly what your describing. Again, I just ran across this the other day in Network Preferences and have no idea if/how it works, but it might be worth a shot (especially since it seems a lot easier to configure than a roll your own router with dd-wrt or tomato, though those likely offer more fine-tuned configuration).
appleguru.org