From owner-freebsd-hackers Wed Jan 24 8:17:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from nyapp002.mediaondemand.com (mailhost.mediaondemand.com [208.184.36.78]) by hub.freebsd.org (Postfix) with ESMTP id 4911737B402 for ; Wed, 24 Jan 2001 08:17:30 -0800 (PST) Received: from nywst536 (nywst536.newyork.mod [192.168.10.35]) by nyapp002.mediaondemand.com (8.11.2/8.11.2) with SMTP id f0OGHOn08869; Wed, 24 Jan 2001 11:17:24 -0500 (EST) Message-ID: <000701c08620$ec9706d0$230aa8c0@newyork.mod> From: "Dejvid Zaninovic" To: Cc: Subject: Re: IP Address Overtaking Date: Wed, 24 Jan 2001 11:15:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. Hosts will not wait for the arp cache to expire because FreeBSD is broadcasting that mac address changed and all hosts must update their cache info if they want to be compliant with arp protocol. Check the arpspoof tool from the dsniff software, it is doing the same thing. > 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. Yes, you could do that if you are using hosts which are not compliant with arp protocol, but I don't plan to use such hosts, all unix boxes, routers and windows are compliant, so I don't see the reason to complicate things with the mac address changing, you rarely need this. > 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. You would probably have to change driver to support this for each card you plan to use. Again, I don't see any reason to overtake mac address. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message