[125486] in North American Network Operators' Group
Re: DSL "aggregation".... NO
daemon@ATHENA.MIT.EDU (Anton Kapela)
Sun Apr 18 07:59:26 2010
From: Anton Kapela <tkapela@gmail.com>
In-Reply-To: <g2y2ad0f9f61004151439u88da3e91m5cac634e6de5df3c@mail.gmail.com>
Date: Sun, 18 Apr 2010 07:59:00 -0400
To: Jack Carrozzo <jack@crepinc.com>
Cc: nanog@nanog.org, Bill Lewis <blewis@hottopic.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Apr 15, 2010, at 5:39 PM, Jack Carrozzo wrote:
> You can balance over DSL by putting different L2TPv3 tunnels over each
> physical device and agg it at someplace with real connections and
> such. It's possible to do it with GRE or OpenVPN too, but much less
> classy.
As Jack points out, "aggregating" xDSL links via l2tpv3 is possible. I'd =
like to suggest you consider this for a few other reasons, and mention =
that you needn't use v3 -- in fact, l2tp as implemented by Cisco IOS =
VPDN guts will transport layer-2 PPP in IP (or UDP+IP) without fuss. =
Here's a few reasons why you should consider l2 tunnel abstractions over =
your existing IP access:
a) l2tp + vpdn permits the use of MLPPP over IP -- which means, you get =
*packet sequencing* and packet ordering, for free, because this is what =
ML does when added to PPP.
b) with ML, you also get packet fragmentation support (i.e. split a =
single user 1500 byte packet into halves, each transported over l2tp =
tunnel sessions to the upstream/off-network box) -- this removes the =
need for l2tp endpoints to process fragments, at least when you have =
both DSLs (and 2 link members) up.
c) even if you were not using fragmentation + mlppp, the "inside" IP =
packet's DF field is not copied into the PPP header (it can't be), and =
so outer lt2p packet does not get its DF set either. Fragmentation would =
be confounded by an inner IP packet of a full MTU size + DF set, and =
thus, it is not supported.
Failing this, you can slum it with ECMP 0/0 route over both DSL links + =
NAT, or OER-type junk. This example doesn't suck and is easily adapted =
to "dialer" or other interfaces: =
http://www.blindhog.net/cisco-dual-internet-connections-without-bgp/
Same thing, restated in a more cisco-y way: =
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_exa=
mple09186a00808d2b72.shtml
Finally, a great full-on OER (i.e. connection aware multi-egress point =
polling + FIB adjustment) example, which maybe more in line with what =
you want or expect your "dual dsl edge router" to provide: =
http://www.netcraftsmen.net/resources/archived-articles/468.html
-Tk
