Date: Sun, 12 Aug 2001 10:50:33 +0100 (BST) From: Joshua Goodall <joshua@roughtrade.net> To: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> Cc: John Van Boxtel <jvb@whoowl.com>, <freebsd-security@FreeBSD.ORG> Subject: Re: distributed natd Message-ID: <Pine.LNX.4.33.0108121042260.13034-100000@elm.phenome.org> In-Reply-To: <Pine.BSF.4.21.0108111626001.635-100000@lhotse.zaraska.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33.0108121042260.13034-100000>