DSL "aggregation".... NO
Group, Since I'm told that DSL aggregation / mux is currently not possible, we are looking at doing stream splitting via a technology like FatPipe uses. Anyone have this in production usage? Or something similar? Cisco has offered some ways to split via CEF, but most DSL carriers do not have this turned on / available. Thank you, Bill Network dude
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. Clearly the downside of this is that you need an agg machine on your end somewhere, but it gives you lots of control for sure. -Jack Carrozzo On Thu, Apr 15, 2010 at 5:05 PM, Bill Lewis <blewis@hottopic.com> wrote:
Group,
Since I'm told that DSL aggregation / mux is currently not possible, we are looking at doing stream splitting via a technology like FatPipe uses. Anyone have this in production usage? Or something similar?
Cisco has offered some ways to split via CEF, but most DSL carriers do not have this turned on / available.
Thank you,
Bill
Network dude
On Thu, 15 Apr 2010 17:39:54 -0400 Jack Carrozzo <jack@crepinc.com> 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.
Depends a bit on the tunnel overhead you're willing to pay. I've done this, and I'd have preferred to use pure IP in IP, however Cisco's have GRE keep alives to monitor tunnel state, so I used that, at the cost of extra 4 bytes. As the tunnel creates a dumbbell path MTU (1500 Inet, <1500, 1500 LAN), you need to pay attention to PMTU issues, such as destination unreachable rate limitting, MSS hacks, and copying the DF bit from the tunnelled packet to the outer encapsulating tunnel packet. Depending on your traffic profile, and the latency of the paths the tunnels take (i.e. if they're very similar), per packet rather than the default per src/destination CEF load balancing is worth considering.
Clearly the downside of this is that you need an agg machine on your end somewhere, but it gives you lots of control for sure.
-Jack Carrozzo
On Thu, Apr 15, 2010 at 5:05 PM, Bill Lewis <blewis@hottopic.com> wrote:
Group,
Since I'm told that DSL aggregation / mux is currently not possible, we are looking at doing stream splitting via a technology like FatPipe uses. Anyone have this in production usage? Or something similar?
Cisco has offered some ways to split via CEF, but most DSL carriers do not have this turned on / available.
Thank you,
Bill
Network dude
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_examp... 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
Hi Bill, You can do this in JUNOS as well with filter-based-forwarding. The key here is that you want to balance traffic out and in on the two uplinks. I suspect you will need to src-NAT all the traffic unless you are announcing your own network to the two DSL providers. You could also do some rudimentary (ie. hack) balancing by having a route for 0/1 and 128/1 with different next-hops. It's pretty easy to setup balancing on an OpenBSD box with PF as well. Truman On 15/04/2010, at 5:05 PM, Bill Lewis wrote:
Group,
Since I'm told that DSL aggregation / mux is currently not possible, we are looking at doing stream splitting via a technology like FatPipe uses. Anyone have this in production usage? Or something similar?
Cisco has offered some ways to split via CEF, but most DSL carriers do not have this turned on / available.
Thank you,
Bill
Network dude
On Thu, Apr 15, 2010 at 2:05 PM, Bill Lewis <blewis@hottopic.com> wrote:
Group,
Since I'm told that DSL aggregation / mux is currently not possible, we are looking at doing stream splitting via a technology like FatPipe uses. Anyone have this in production usage? Or something similar?
It depends very much on what your traffic looks like, and what you're trying to accomplish. If you're trying to build a pipe from Point A to Point B, and are really picky about how balanced it is (in spite of it being ADSL), then maybe you need something fancy on each end, whether that's FatPipe or Fancy BSD Tricks. If you're mainly fetching web traffic from the public Internet, then all you really need to do is spread out your queries between the DSL lines, using NAT to make sure each query goes back to the DSL that sent it, and that'll be close enough. If you're trying to balance inbound re ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Hmm, fat fingered that.
If you're trying to balance inbound re If you're trying to balance inbound requests, use a DNS load balancer.
-- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
On Thursday 15 April 2010 05:05:05 pm Bill Lewis wrote:
Since I'm told that DSL aggregation / mux is currently not possible, we are looking at doing stream splitting via a technology like FatPipe uses. Anyone have this in production usage? Or something similar?
No IMA over DSL? (IMA = Inverse Multiplexing over ATM). Used IMA over T1 before on an 8510.....
participants (7)
-
Anton Kapela -
Bill Lewis -
Bill Stewart -
Jack Carrozzo -
Lamar Owen -
Mark Smith -
Truman Boyes