[Fwd: Re: 3 connections as one]
julian at elischer.org
Thu Jun 26 17:07:52 UTC 2008
Matthew Dillon wrote:
> You can do it for outgoing connections fairly easily using the NAT
> trick (with PF), but you can't really load balance multiple links
> without support from some outside entity. If one of the tunnels goes
> down you can fail-over but any pre-existing connections will die and
> have to be re-established on the remaining link(s). That generally
> works ok for TCP but is total hell for UDP (because the source address
> will suddenly 'change' on an existing 'connection' and often trigger
> security blocks or simply break the program in question when it does).
> I've got a DSL connection and a Cable internet connection at home now,
> having replaced the T1 I had had for many years.
> I tried using the NAT trick using PF for outgoing but was never happy
> with the results under max load (and my links are typically running
> at 100% 24x7). I wasn't able to get fail-over to work properly with
> PF at all... the network was actually less reliable instead of more
> reliable and using NAT meant I had very little control over port
> selection or reverse-IP.
> I eventually gave up and now just use my DSL line for all my normal
> traffic, and my cable link for my off-site backup traffic.
> I'm planning out a new solution, one that a friend of mine implemented
> with a portable class C he owns at a colo with a single link which I
> want to extend to multiple links. The idea is to chop off a subnet from
> the colo-routed class C and run it to the home box over multiple tunnels
> (one over COMCAST, one over DSL).
> I am going to run all the tunnels through a single user program on my
> router box and backhaul it into a TUN interface (using PF on the TUN
> interface for QOS), and have the user program do all the load balancing
> and fail-over. Since the whole mess is routing a single subnet, no
> NAT tricks are needed and packets can be routed 100% dynamically.
> There would be no disconnections or UDP IP address changes.
> The only caveat is that the colo adds another 10ms to the round-trip
> time verses a direct connection. But on the plus side the home network
> can operate uninterrupted over however many discrete internet links I
> have access to, including modem dial backup or a directional WIFI link
> between friend's houses.
I've done that running mpd to split the load over the tunnels from the
if either tunnel goes down mpd hickups nd hten everything keeps going..
> I still gotta find time to write that program but there's nothing
> fancy about the concept. Maintain multiple links, route packets over
> the links that are up... simple stuff really. DragonFly has a number
> of utilities that make the job easy which FreeBSD folks might want to
> look into:
> (vknetd is a packet switch, complete with a MAC cache & forwarding).
> + SOCK_SEQPACKET support in the kernel for unix domain sockets.
> (it wouldn't be too hard for FreeBSD to implement SOCK_SEQPACKET
> and stream connection support via unix domain sockets, it took
> less then a day to get it into DFly).
> Having a packetized stream socket connection to a user program (vknetd)
> which implements a packet switch takes all the effort out of messing
> around with network routing, literally.
mpd does this for me..
More information about the freebsd-hackers