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
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
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.
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
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.
No IMA over DSL? (IMA = Inverse Multiplexing over ATM). Used IMA over T1
before on an 8510.....
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_example09186a00808d2b72.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