[Fwd: Re: 3 connections as one]

[Julian Elischer]

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 
colo.

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:
> 
> 	http://www.dragonflybsd.org/cvsweb/src/usr.sbin/vknetd/
> 
> 	(vknetd is a packet switch, complete with a MAC cache & forwarding).

ng_bridge..

> 
> 	+ 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..

> 
> 						-Matt