From owner-freebsd-hackers Wed Jan 24 8:38:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B0A437B404 for ; Wed, 24 Jan 2001 08:38:40 -0800 (PST) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id JAA77841; Wed, 24 Jan 2001 09:36:18 -0700 (MST) Date: Wed, 24 Jan 2001 09:36:18 -0700 (MST) From: Nick Rogness To: Andreas Brodmann Cc: Dejvid Zaninovic , freebsd-hackers@freebsd.org Subject: Re: IP Address Overtaking In-Reply-To: <3A6EF007.9F06DBF8@gmaare.migros.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Andreas Brodmann wrote: > > On normal internetworking hosts, without the necessity of high availability > this works fine. Not all hosts do update or even flush their arp cache with > the same frequency though. Some have a cycle of less than one minute on > routers on the other hand the default arp cache timeout is a lot higher which > would force clients not in the same subnet to wait until the router flushes > its arp cache until they can access your FreeBSD machine again. > -> not ha compliant. The time it takes to flush is very small. During that time the router queue's up the request and waits for a reply. Once the router has it, everything is transparent. I would not recommend playing with MAC addresses at all. Switch things using IP and let the ARP protocol take care of itself. > There is a way to solve this problem by having a second interface in each > cluster > partner serving as standby interface. To this interface you assign the mac of > its > partner's interface and all its interfaces ip addresses. > > Just a hint: Have a look at scyld.com and Donald Becker's new Linux driver > architecture. Many new cards allow for using more than one mac per card > even without going into promiscuous mode. They can then be assigned to > different subinterfaces. I don't know wheter the FreeBSD drivers support > this. Anyway we still keep to the old fashioned way mentionned above, as the > new Linux network driver architecture is not yet as stable as it could be, but > once it is this would solve your problem. I think this is a bad idea in a clustering enviroment. You are taking the job of a switch and moving it to the card/software by fiddling with MAC addresses on the hosts. I guess I can see where this may be useful (trunking) but taking over the MAC could cause problems...like duplicate MAC's etc,etc. Of course, this is my opinion and I could be wrong. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message