From owner-freebsd-hackers Tue Oct 14 18:02:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA01628 for hackers-outgoing; Tue, 14 Oct 1997 18:02:44 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA01614; Tue, 14 Oct 1997 18:02:32 -0700 (PDT) (envelope-from brian@awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id AAA06200; Wed, 15 Oct 1997 00:46:51 +0100 (BST) Message-Id: <199710142346.AAA06200@awfulhak.demon.co.uk> X-Mailer: exmh version 2.0zeta 7/24/97 To: Charles Mott cc: Eric Feillant , ari@suutari.iki.fi, brian@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Natd In-reply-to: Your message of "Tue, 14 Oct 1997 09:24:44 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Oct 1997 00:46:50 +0100 From: Brian Somers Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [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 , , Don't _EVER_ lose your sense of humour....