Date: Mon, 29 Jun 1998 20:36:59 -0500 From: Tim Tsai <tim@futuresouth.com> To: Bo Fussing <bmf@gateway.net.hk> Cc: Luis Munoz <lem@cantv.net>, Evren Yurtesen <yurtesen@ispro.net.tr>, freebsd-isp@FreeBSD.ORG Subject: Re: cisco Message-ID: <19980629203659.50524@futuresouth.com> In-Reply-To: <Pine.LNX.3.96.980630091855.20371D-100000@gate.gateway.net.hk>; from Bo Fussing on Tue, Jun 30, 1998 at 09:22:18AM %2B0800 References: <19980629194051.08954@futuresouth.com> <Pine.LNX.3.96.980630091855.20371D-100000@gate.gateway.net.hk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 30, 1998 at 09:22:18AM +0800, Bo Fussing wrote: > One way to counter this on the server side is to have some form of > backup server standing by and stepping in when the normal proxy dies. This is assuming that the primary server completely dies (does not answer to the IP or MAC address) - which is not necessarily the case (i.e. perhaps only the proxy application died and not the server). With policy route you can set the next-hop-ip address but the question becomes how do you get the backup server to answer to that IP address correctly, even if the primary server still answers to that IP in someway. All the setup's I know of involves another additional level (either a hardware switch that supports virtual IP's or something like Cisco's localdirector) and the actual proxy servers sit behind this localdirector type device. I suppose with some hardware help you can cut (open circuit) the ethernet connection or simply power down the failed primary server. > Another is to have some remote monitoring of the proxy and notification to > the system admin (by pager) of the failure. We do that but that's hardly what I'd call redundancy. :-) Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980629203659.50524>