[AusNOG] ADSL2+ Aggregation at LNS without MLPPP HOWTO

s s.sentient at gmail.com
Mon Sep 15 15:11:15 EST 2014


I've accomplished something similar to Andrew using Zeroshell and VPN
Bonding (http://www.zeroshell.org/load-balancing-failover/#vpn-bonding).
I did it for the same reasons as Ben (twitch streaming), it worked well
enough, I was using two ADSL2 connections with 2 IPs on the other end and
static routes to properly send the traffic down both pipes.
The setup was only in use when I was streaming so I can't attest to it's
long-term reliability, but the download/upload speed was the expected
combined speed with a little overhead.


On Mon, Sep 15, 2014 at 6:05 AM, Joseph Goldman <joe at apcs.com.au> wrote:

> Very interesting idea - I have used Mikrotik with Cisco LNS trying MLPPP,
> where mostly I was lucky to re-achieve the results of a single line. It was
> production LNS so I didn't want to do too much changing to 'fiddle', but
> separate PPP with EoIP and bonding over the top is quite interesting.
>
> You say your using Mikrotik each end, are you using "balance rr" bonding
> type to get even throughput? Or are you still using say 802.3ad with
> Layer2/3 hashing (i.e. per flow balancing rather than per packet).
>
> On 14/09/14 23:46, Andrew Cox wrote:
>
>> /"bringing up three EOIP tunnels (one on each ADSL) to a server you
>> control with an additional /30 routed to it.  Then bridge the three
>> tunnels on both ends"/
>> /
>> /
>> This is achievable and nets the required gains in upload/download.
>>
>> Source: I've done it.. http://i.imgur.com/eVNPPxA.png - this is a graph
>> of 4 x ADSL2+ services (quite close to an exchange so good sync rates)
>> bonded together back to another router about 40ms away. The data rates
>> speak for themselves. Oh and this is using MikroTik gear at both ends.
>>
>> - Andrew
>>
>> On 13 September 2014 07:26, Damien Gardner Jnr <rendrag at rendrag.net
>> <mailto:rendrag at rendrag.net>> wrote:
>>
>>     What about bringing up three EOIP tunnels (one on each ADSL) to a
>>     server you control with an additional /30 routed to it.  Then bridge
>>     the three tunnels on both ends, and drop the two IP's on the /30 on
>>     each end of the bridged tunnel, and NAT your workstation out that IP?
>>
>>     Of course that's assuming Annex M isn't available on your exchange ;)
>>
>>     On 13 September 2014 00:57, Ben Cooper <ben at zeno.io
>>     <mailto:ben at zeno.io>> wrote:
>>
>>         But what if we really need the upload bandwidth? (ie id take the
>>         downstream hit if it means my upstream is improved greatly.)
>>
>>         Backstory:
>>
>>         In my spare time, I stream myself playing games either casually
>>         or competitively up to twitch. although latley None(read: 3) of
>>         my ADSL connections have had the upstream to realiably stream.
>>
>>         I have been hunting for a way to join the 3 of them to try get
>>         the upload I need to stream again, without any luck. I run
>>         PFsense as core routing, but have some microtiks here i can toss
>>         in, if it means i can get better upload.
>>
>>         Else im going to have to get a microwave connection installed.
>>
>>         i am currently for the last week using 4G prepaid dongles and
>>         just dropping $100 on the tesltra plan and then spending it all
>>         on datapack right away, netting about 8-10 gb of data.
>>
>>         If anyone has any suggestions to try, I am all ears.
>>
>>         TLDR: I need more upload, badly.
>>
>>         On Fri, Sep 12, 2014 at 8:48 PM, Jarrad Mitchell
>>         <ausnog at outlook.com.au <mailto:ausnog at outlook.com.au>> wrote:
>>
>>             /I would expect that any form of 'single ip' ADSL Bonding is
>>             impractical for you.  If you must, you are best of to use
>>             Per-Destination Load Balancing with two separate ISPs, and
>>             perhaps route specific services through the better link. /
>>
>>             /
>>             /
>>             */What follows is the technical reasoning and logical
>>             analysis that lead to the aforementioned conclusion/*
>>             */
>>             /*
>>             /
>>             /
>>             *_Why 'Bonding / Teaming Aggregating' two ADSL etc links is
>>             usually a Very Bad Idea _*
>>             *_
>>             _*
>>             ALL NETWORK INTERFACE (Including ADSL)
>>             'Aggregation/Bonding/Teaming' that results in increased
>>             throughput across a single path (a connection between two
>>             computers/IPs eg your home pc to youtube.com
>>             <http://youtube.com>) almost always results in a link that
>>             is at best just below TWICE the speed of the SLOWEST link.
>>
>>             This is not always a problem.  For example, if you have two
>>             100mbit fibre optic links over 1km, they are very unlikely
>>             to vary in their 'transmission' properties; that is to say,
>>             they are unlikely to vary considerably in how long it takes
>>             to ping the other end etc.  With a connection like this,
>>             where BOTH of the Aggregate / Team 'members' can be
>>             described as electrically/physically 'identical /
>>             significantly similar', a good quality, reliable increase in
>>             performance can be achieved.
>>
>>
>>             *_Key Insight 1_: Multiple Link Aggregates that increase
>>             Single Path Throughput ONLY EVER make sense when using
>>             IDENTICAL Aggregate Members.*
>>             */
>>             /*
>>             Knowing this, we next need to consider why ADSL Technology
>>             was developed.  Simply put, it was designed to leverage
>>             EXISTING, VERY OLD Balanced Transmission Line to deliver
>>             'high speed' internet access.  And it does a wonderful job
>>             indeed.  But just what exactly is this existing
>>             infrastructure?  The PTSN is/has in most cases (if not all):
>>
>>             - Based on old _two pair non twisted transmission line_ that
>>             was never designed for data.
>>             - Had previous network modifications (been connected and
>>             disconnected, redesigned etc)
>>             - Been previously upgraded (Pulse to DTMF Dialing for example)
>>             - Been previously re-purposed (ISDN)
>>             - Been expanded well beyond its original design,
>>             inconsistantly (Loading Coils, Pair Gain Systems & RIMS).
>>
>>
>>             *_Key Insight 2_: Any Two Pairs between an Exchange and the
>>             Customer are VERY UNLIKELY to be 'identical / significantly
>>             similar'.*
>>             *
>>             *
>>             Some people might wish to point out that EFM / SHDSL &
>>             Similar use exactly the above to deliver a good service.
>>               And they're right, from a delivered service (Marketing?)
>>             perspective. /Remember how I pointed out that a Aggregate
>>             will run at the speed of its slowest member?  EFM & SHDSL
>>             simply takes a bunch of pairs, and deliberately uses less
>>             bandwidth on all of them them than even the poorest can
>>             handle, then combines them. /
>>
>>             I have personally seen 8 PAIRS (16 wires) used to deliver
>>             10mbit / 10mbit EFM!  To put this into perspective, a single
>>             near ideal pair can deliver 20mbit Simplex (one way) over
>>             1Km using only 2MHz of bandwidth.  VDSL2+ over 500m, with
>>             its increased bandwidth would greatly exceed that!
>>
>>             *_Key Insight 3_: YOU CAN make a bunch of DISSIMILAR
>>             (electrically) Links look Similar (logically) if you are
>>             prepared to make individual BANDWIDTH SACRIFICES.*
>>             *
>>             *
>>             /
>>             /
>>             *_Conclusion_*
>>             /And there in lies the reality.  At say $30 per pair, it
>>             doesn't make sense economically to Aggregate a 18000/900
>>             Kbps pair with a 9000/850 Kbps pair.  Because to do so
>>             reliably, you're likely to end up with 17000 / 1600 Kbps!!!!/
>>             /
>>             /
>>
>>
>>
>>             _______________________________________________
>>             AusNOG mailing list
>>             AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
>>             http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>>
>>
>>         --
>>         --
>>         Ben Cooper
>>         CEO
>>         Zeno Holdings PTY LTD
>>         P: +61 7 3503 8553 <tel:%2B61%207%203503%208553>
>>         M: 0410411301 <tel:0410411301>
>>         E: ben at zeno.io <mailto:ben at zeno.io>
>>         W: _http://zeno.io_
>>
>>         _______________________________________________
>>         AusNOG mailing list
>>         AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
>>         http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>>
>>
>>     --
>>
>>     Damien Gardner Jnr
>>     VK2TDG. Dip EE. GradIEAust
>>     rendrag at rendrag.net <mailto:rendrag at rendrag.net> -
>>     http://www.rendrag.net/_
>>     _--
>>     We rode on the winds of the rising storm,
>>       We ran to the sounds of thunder.
>>     We danced among the lightning bolts,
>>       and tore the world asunder
>>
>>
>>     _______________________________________________
>>     AusNOG mailing list
>>     AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
>>     http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>>
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>  _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140915/8dad6b49/attachment.html>


More information about the AusNOG mailing list