From owner-freebsd-hackers Fri Jan 28 17:20: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by hub.freebsd.org (Postfix) with ESMTP id 87DB614BF1 for ; Fri, 28 Jan 2000 17:19:56 -0800 (PST) (envelope-from fanf@demon.net) Received: from fanf.eng.demon.net (fanf.eng.demon.net [195.11.55.89]) by internal.mail.demon.net with ESMTP id BAA20637; Sat, 29 Jan 2000 01:19:55 GMT Received: from fanf by fanf.eng.demon.net with local (Exim 3.12 #3) id 12EMYL-000Bzo-00; Sat, 29 Jan 2000 01:19:53 +0000 To: bright@wintelcom.net From: Tony Finch Cc: freebsd-hackers@freebsd.org Subject: Re: downed IP addresses/redundancy In-Reply-To: <20000128120410.G7157@fw.wintelcom.net> References: <20000128045440.F7157@fw.wintelcom.net> <3891B307.620A684F@rci.net> <3891B307.620A684F@rci.net> Message-Id: Date: Sat, 29 Jan 2000 01:19:53 +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > >Once you tell an application to bind to a particular IP address >I'm pretty sure most don't have an option to bind another listen >socket. > >The customer can't fail over properly because even when the alias >for the box that dies comes up, thier daemon won't get requests on >the added IP. What would be cool is if FreeBSD could do VRRP. This is usually used for providing a default route handled by two physical boxen, but if you turn it around and provide a route to a service IP address that may be handled by two boxen that deal with fail-over using VRRP then this solves the problem discussed in this thread. I'd be interested to know of a free implementation of VRRP for the BSD network stack. Tony. -- dot it thus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message