<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I disagree with Theo on this... thus illustrating that it's not a
"solved" problem in the industry!<br>
<br>
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...)<br>
The following sentence is equally applicable to LACP as it is to
ECMP, by the way...<br>
<br>
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.<br>
<br>
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 <i>something</i> for your money there.<br>
<br>
Then you have to run a dynamic routing protocol to make use of ECMP,
which drastically increases the solution complexity.<br>
<br>
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.<br>
<br>
-Adam<br>
<br>
<br>
<div class="moz-cite-prefix">On 15-09-29 11:28 AM, Theodore Baschak
wrote:<br>
</div>
<blockquote
cite="mid:B23FD5A5-9392-47CE-BDDB-7FCD6FAAA779@ciscodude.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="">
<div class="">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. </div>
<div class="">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.</div>
</div>
<div class=""><br class="">
</div>
<div class="">Theo</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Sep 29, 2015, at 8:09 AM, Adam Thompson <<a
moz-do-not-send="true" href="mailto:athompso@athompso.net"
class=""><a class="moz-txt-link-abbreviated" href="mailto:athompso@athompso.net">athompso@athompso.net</a></a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">This is an active area of research,
particularly with the advent of multi-path TCP.<br
class="">
Presently, however, you have to hide the two-link-ness
from the TCP layer, and essentially from the IP layer as
well.<br class="">
ECMP would work, as long as both lines are the same (this
does not hold true as a dynamic assertion with DSL
technology, *ever*).<br class="">
LACP will *not* work.<br class="">
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.<br class="">
<br class="">
Far more effective, however, would be to upgrade to a
symmetric VDSL2 setup that supports DSL bonded pairs.<br
class="">
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.<br class="">
<br class="">
I just worked with someone else on this kind of setup,
I'll see if I can find the links...<br class="">
<br class="">
-Adam<br class="">
<br class="">
<div class="gmail_quote">On September 29, 2015 4:18:54 AM
CDT, Trevor Cordes <<a moz-do-not-send="true"
href="mailto:trevor@tecnopolis.ca" class="">trevor@tecnopolis.ca</a>>
wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<pre class="k9mail">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!
<hr class="">
Roundtable mailing list
<a moz-do-not-send="true" href="mailto:Roundtable@muug.mb.ca" class="">Roundtable@muug.mb.ca</a>
<a moz-do-not-send="true" href="http://www.muug.mb.ca/mailman/listinfo/roundtable" class="">http://www.muug.mb.ca/mailman/listinfo/roundtable</a>
</pre></blockquote></div>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.</div>_______________________________________________
Roundtable mailing list
<a moz-do-not-send="true" href="mailto:Roundtable@muug.mb.ca" class="">Roundtable@muug.mb.ca</a>
<a class="moz-txt-link-freetext" href="http://www.muug.mb.ca/mailman/listinfo/roundtable">http://www.muug.mb.ca/mailman/listinfo/roundtable</a>
</div></blockquote></div>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre wrap="">_______________________________________________
Roundtable mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a>
<a class="moz-txt-link-freetext" href="http://www.muug.mb.ca/mailman/listinfo/roundtable">http://www.muug.mb.ca/mailman/listinfo/roundtable</a>
</pre>
</blockquote>
</body></html>