Date: Mon, 10 Jul 2000 15:42:41 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: les@safety.net Cc: freebsd-hackers@freebsd.org Subject: Re: Multiple MAC addresses per NIC Message-ID: <20000710224241.9123737B6B5@hub.freebsd.org> In-Reply-To: <200007101320.GAA98379@ns3.safety.net> from Les Biffle at "Jul 10, 2000 06:20:08 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> Hello all, > > This issue was discussed last year, but I can't find any information on > a resolution. We're trying to create a high availability FreeBSD > cluster with a standby machine being able to take over for a failed host, > and need the standby machine to have its own MAC address, plus the MAC > address of the failed host. The NICs we use are RealTek and Intel > EtherExpress 100. We find hints in the NIC chip databooks but no > information for us mere programmers. So, I have two questions: > > 1. Does anybody have sample driver code that sets up the multiple hardware > address features of these NICs? > > 2. Does anybody have documentation that could help me create the driver > changes? (book, PDF, publication number, anything?) > > We have tried to get more documentation out of Intel, and the salesmen > are willing, but we need a publication number to get anything. They keep > giving us the databook, which list pinouts, various electrical specs, > and some theory, but it's no programmer reference. This is very hardware dependent. Most cheap ethernet chips offer the following receive filter options: - single perfect filter entry for one MAC address (the station address) - multicast hash table (usually 64 bits, sometimes 128 or 512) - promiscuous mode (receive everything) Other more sophisticated chips may offer additional perfect filter entries. (The ThunderLAN has 4, the Adaptec AIC-6915 "Starfire" has 16. The tulip can be programmed to use additional entries depending on the filter type you select. Not all clones support the same filter options.) The only portable thing to do is put the chip in promiscuous mode and let the software sort everything out, however this will force the OS to do extra work. I wouldn't bother with Intel. They have a bug up their ass about releasing info and you would do better to just tell them "sorry, you're giving us too much shit so we're switching to a different vendor" rather than continue playing footsie with them. Not that RealTek is much better. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000710224241.9123737B6B5>