From owner-freebsd-security Sun Aug 12 2:50:43 2001 Delivered-To: freebsd-security@freebsd.org Received: from elm.phenome.org (elm.phenome.org [194.153.169.3]) by hub.freebsd.org (Postfix) with ESMTP id 4B53E37B405 for ; Sun, 12 Aug 2001 02:50:40 -0700 (PDT) (envelope-from joshua@roughtrade.net) Received: from localhost (joshua@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f7C9oXCC016124; Sun, 12 Aug 2001 10:50:33 +0100 Date: Sun, 12 Aug 2001 10:50:33 +0100 (BST) From: Joshua Goodall X-X-Sender: To: Krzysztof Zaraska Cc: John Van Boxtel , Subject: Re: distributed natd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If you want to do failover between two NAT gateways, you can avoid reinventing much of the high-availability wheel with the net/vrrp port and taking things from there. VRRP was defined specifically to support router failover. Perhaps you can piggyback state onto the advertisements? You realise this generalises to high-availability aliased cluster services with distributed locking & shared state, dontcha? [1] J [1] also known as vms clustering :) On Sat, 11 Aug 2001, Krzysztof Zaraska wrote: > > Keeping with the above ping pong idea, maybe instead of icmp packets you can > > stick with TCP and have the data in the packet have some sort of "upstream > > ok" / "upstream down" bit in it... > By "ping" I did not mean sending ICMP to peer gateway, but sending a > special command over this TCP/UDP link between gateways forcing the other > end to issue a reply. However it came up to me later, that if we have > traffic, then we have state tables updated constantly, thus alive gateway > should send the others notifications all the time. So we should try to > "ping" it only it case it goes silent (=no update request within given > interval) to see if it died or workstation users went home ;) "Upstream > up/down" flag is a good idea. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message