I disagree with Theo on this... thus illustrating that it's not a "solved" problem in the industry!
What I've encountered using ECMP for point-to-point connections over non-deterministic paths is packet-ordering problems so bad that I'm better off using only one of the two links in the first place! (Remember that one packet arriving too soon or too late nullifies the entire TCP in-flight window...) The following sentence is equally applicable to LACP as it is to ECMP, by the way...
WiFi links are the worst for bonding via ECMP, other types of wireless second-worst, DSL third-worst, and cable modems fourth-worst. Over plain old Ethernet, of course, ECMP works beautifully nearly all the time.
Then you have to deal with the fact that not all ECMP implementations are equal; the Linux kernel still either hashes the traffic (thus NOT giving you a 2x speed boost) or treats is more like an active/passive failover pair (again, no speed boost). As far as routers go, MikroTik appears to be the worst offender... it *looks* like it does full ECMP but it doesn't. Cisco and Juniper routers, naturally, do it right 99.999% of the time... at least you get /something/ for your money there.
Then you have to run a dynamic routing protocol to make use of ECMP, which drastically increases the solution complexity.
Pushing redundancy (and multi-path, and complexity in general) as far down the OSI stack as it can go has worked for me much better in all cases *EXCEPT* where it's impossible, and then pushing the multi-path capability right up to the application becomes necessary. Doing it in the middle... tends to break, in my experience.
-Adam
On 15-09-29 11:28 AM, Theodore Baschak wrote:
To get a single TCP connection/thread going over two or more equal bandwidth connections you just need equal cost routing to use all paths. An actual router (not firewall, or nat gateway) with two equal cost routes will load balance packets over both connections as long as you're not firewalling. If you're trying to do this multi-connection extension at layer2 though instead of at layer3, you'll probably have a lot more hair-pulling fun, and less success.
Theo
On Sep 29, 2015, at 8:09 AM, Adam Thompson <athompso@athompso.net mailto:athompso@athompso.net> wrote:
This is an active area of research, particularly with the advent of multi-path TCP. Presently, however, you have to hide the two-link-ness from the TCP layer, and essentially from the IP layer as well. ECMP would work, as long as both lines are the same (this does not hold true as a dynamic assertion with DSL technology, *ever*). LACP will *not* work. If you have Linux boxes at both ends, you can use mod_bonding in its round-robin mode... I've done that in the past and it does work.
Far more effective, however, would be to upgrade to a symmetric VDSL2 setup that supports DSL bonded pairs. That'll set you back around $600+ per end, IIRC, replaces both the DSLAM and the DSLR, but makes your problems go away by turning all the copper into a single Ethernet link.
I just worked with someone else on this kind of setup, I'll see if I can find the links...
-Adam
On September 29, 2015 4:18:54 AM CDT, Trevor Cordes <trevor@tecnopolis.ca mailto:trevor@tecnopolis.ca> wrote:
Is it possible to aggregate DSL lines, to combine them to get X-times the bandwidth on a single link? In this situation, I control both ends, the DSLAM and the DSL modem side on the other end of some POTS runs (CAT3-ish I assume, or worse). Note, I don't want load balancing or fancy routing/sharing. I need double (or more) the bandwidth for a single application (single TCP connection). If required, we can have linux/bsd boxes we control at either end of the links. If it's not possible, does anyone have any other ideas for somehow getting better bandwidth out of 500m POTS wires (quantity 4)? Thanks! ------------------------------------------------------------------------ Roundtable mailing list Roundtable@muug.mb.ca <mailto:Roundtable@muug.mb.ca> http://www.muug.mb.ca/mailman/listinfo/roundtable-- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca mailto:Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable