Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Oct 1997 00:46:50 +0100
From:      Brian Somers <brian@awfulhak.org>
To:        Charles Mott <cmott@srv.net>
Cc:        Eric Feillant <Eric.Feillant@EUnet-Bretagne.fr>, ari@suutari.iki.fi, brian@freebsd.org, freebsd-hackers@freebsd.org
Subject:   Re: Natd 
Message-ID:  <199710142346.AAA06200@awfulhak.demon.co.uk>
In-Reply-To: Your message of "Tue, 14 Oct 1997 09:24:44 PDT." <Pine.BSF.3.96.971014091338.11454B-100000@darkstar.home> 

next in thread | previous in thread | raw e-mail | index | archive | help
[cross-posted to -hackers so that others (including *@whistle.com) 
can (dis)agree]

Charles Mott wrote in reply to Eric Feillant:
> For load balancing, a single natd process would have to exist and all
> traffic from multiple interfaces would have to be diverted to this single
> process.  I don't know if this is possible, and what modifications to natd
> might be required. 
> 

The way I'd see this sort of thing working is with one or more 
"auxiliary" interfaces.  Say we have two physical links to the 
Internet called 10.0.1.1 and 10.0.2.1:

Destination        Gateway            Flags     Refs     Use     Netif Expire
10.0.1.1/32        0:0:c0:b5:ca:ae    UCLW        0        0       lo0
10.0.2.1/32        0:0:c0:52:2:6e     UHLW        0        0       lo0

We then create a default:

default            10.0.1.1           UGSc        4       22       ed0

The 10.0.2.1 interface is our "auxiliary" in that nothing really ever 
goes to it directly.

We then create a "multiplex daemon" that picks up traffic going out 
on 10.0.1.1 and sends it via either 10.0.1.1 or 10.0.2.1 depending on 
some balancing factor (you may want to weight the interfaces).  

No address translation is necessary as all outgoing packets from the 
local machine will have an IP of 10.0.1.1 irrespective of the 
interface they're actually transmitted on.  The only thing we need to 
make sure of is that we've got the same setup on the other end.  
Without it, we get all our replies down the 10.0.1.1 route ('cos the 
other side will think this is a good idea (but then, we could 
dynamically load-balance to compensate for this)).

The only "missing piece" is that we can't "divert" the packet onto 
the correct interface because the divert mechanism does not allow you 
to choose where you're sending the data.... there's no way of writing 
raw IP onto a specific interface - the kernel will pick the interface 
and will find 10.0.1.1 because of the default route.

Hmmm, I suspect this capability - if it is ever added - would have 
to be done in the kernel.

-- 
Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <bri@OpenBSD.org>
      <http://www.Awfulhak.org>;
Don't _EVER_ lose your sense of humour....





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