From owner-freebsd-questions Sun Oct 28 7:16:40 2001 Delivered-To: freebsd-questions@freebsd.org Received: from gamma.root-servers.ch (gamma.root-servers.ch [195.49.62.126]) by hub.freebsd.org (Postfix) with SMTP id 4F2E737B405 for ; Sun, 28 Oct 2001 07:16:34 -0800 (PST) Received: (qmail 4746 invoked from network); 28 Oct 2001 15:16:33 -0000 Received: from dclient217-162-128-224.hispeed.ch (HELO athlon550) (217.162.128.224) by 0 with SMTP; 28 Oct 2001 15:16:33 -0000 Date: Sun, 28 Oct 2001 16:18:38 +0100 From: Gabriel Ambuehl X-Mailer: The Bat! (v1.53bis) Educational Organization: BUZ Internet Services X-Priority: 3 (Normal) Message-ID: <172607223951.20011028161838@buz.ch> To: questions@freebsd.org Subject: IP take over approaches MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hello, for some kind of fail over cluster, I need to implement a reliable way of IP take over on FreeBSD (probably on Linux as well, but that can wait) between two servers on the same ethernet segment (for now, there's a master and a hot standby). While we generally would have the possibility to hard-reset a no more reacting box to get it from the net using custom developed reset devices, I'd like to have a solution that does work without resets since resets are bad for known reasons. I know of the vrrpd port, but first it is marked as being broken due to failure to comply with RfC2338 (although I suspect it would work when ONLY vrrpd servers are up) and second both IBM and Cisco have made IP claims to the approach used in VRRP. Basically, it should work the following way: assign each of the two hosts a distinct IP (to be able to connect to it in any case) and use a third, virtual IP for the services on the host. Now if the primary stops responding, the secondary starts sending out ARP packets advertising its own MAC address as target for the virtual IP. This will overwrite the other members ARP entry and the slave will have all IP traffic directed to it. Now the problem starts if the slave decide that the master is down (perhaps the daemon running on it went down or something like this) but the master still sends out ARP packets stating that it is the owner of the IP. Using dumb hubs and all FreeBSD boxes, this didn't seem to cause much of a problem if the slave sent out its ARP packets shortly after the master to overwrite newly changed ARP entries and hosts which had the IP in their ARP cache would access the slave. But now what's going to happen if a host which doesn't yet have the mapping in the cache sends a ARP who-has query and receives two responses with two different mappings? Or what would a switch which got ARP flooding protection do with the packets from the slave, just throw them away cause they obviously do bad things to ARP mappings in it? I'd very much appreciate any comments on this topic but also on other IP take over strategies which don't involve rebooting corrupted hosts. Best regards, Gabriel -----BEGIN PGP SIGNATURE----- Version: PGP 6.5i iQEVAwUBO9wTv8Za2WpymlDxAQHUnwf/XoWXPd07j+pKclYNe+WnnG2yAjP1+hcH VmlAyA6TXYTSM3AtbD0lmUdjyakxJ5JylSzmKnJk9Acb3SZ09GAXfxCdo7VQq0qM qu+3VzD3PZMpQ6z6GE9+rqQDuU8WX/twJSxFTVMuJGQOPmjoKgznFpNZE96E6A/k RFV+aSz1fzNb0pcjbeDml9iJRlkunRJwxJDN+mMMx9ATApz3Mdi3tGhKToTxmgCx 4YX3nA6X6Zfyr2dLr+yeuWgrTx55G5Woiv7y4ouuqans/D8HFEITEYV5xxMk9dkY zqJ9AOlZBGsTSoy/rV9yEU5I/fRgbFGNDxMPFptCH4NXHj50kzwWWA== =R0a8 -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message