Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Jun 2008 10:08:04 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-hackers@freebsd.org, martes@mgwigglesworth.com, Luiz Otavio O Souza <luiz@aonet.com.br>
Subject:   Re: [Fwd: Re: 3 connections as one]
Message-ID:  <4863CCF4.3000200@elischer.org>
In-Reply-To: <200806261653.m5QGrasG020325@apollo.backplane.com>
References:  <1214430974.26401.0.camel@devstation>	<4862DCB5.6080005@elischer.org> <001901c8d78d$8180c680$5e00a8c0@note4c47> <200806261653.m5QGrasG020325@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4863CCF4.3000200>