Date: Fri, 03 May 2002 10:03:38 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: freebsd-net@FreeBSD.org Cc: andrew mejia <mejia_bsd@yahoo.co.uk> Subject: Re: network design Message-ID: <3CD2C2EA.334B5629@mindspring.com> References: <3CD17557.7BC1F7C0@mindspring.com> <20020503073501.67347.qmail@web14802.mail.yahoo.com> <20020503082737.GN688@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fumerola wrote: > this is about representing within the freebsd network stack ethernet > cards that support multiple (>1) unicast mac addresses through either > multiple perfect filter entries or a multicast filter borrowed to serve > such a purpose. until freebsd has a way of supporting this, failover > technologies like vrrp (or any where members 'share' a common lladdr) > will be impossible to implement properly. There is a VRRP implementation for FreeBSD that uses raw sockets and puts the interface into promiscuous mode. It manually handles whether or not it responds to ARPs. So it's possible. I think that the use of promiscuous mode is ugly, but... it works. http://www.bsdshell.net/ It's in ports/network. > i believe the hangup is that adding an interface to network drivers is > the easy part relative to teaching the network stack about network cards > with more then one lladdr. specifically, which mac address do you use > when putting a frame onto the wire that was locally generated? forwarded? I think this is mostly a card feature; Intel Gigabit Ethernet supports 16m Tigon III supports 4, and Tigon II supports 1 additional MAC address. I think the drivers, in these cases, need to export more than one single interface. If you do that, it's not a stack problem at all, it's an interrupt processing problem in the driver, since you have to differentiate inbound packets. The MAC address you use when sending or forwarding... is the MAC address for the virtual interface pointed to by the route. This probably needs to be virtualized as well, so that you can get the same effect by sticking a card in promiscuous mode; I would *not* suggest using the Linux VRRP implementation approach (implemented on the fxp driver) with the multicast hack. My reasoning for disdaining the multicast hack is that it can only ever work for one address, and when you lose it, you lose multicast support, which is mostly unacceptable. I think that things like SLPv2 are only going to become more common (SLP is one of the base protocols for some of Sun's Java Services platform), and losing multicast in trade for VRRP will eventually be a bad tradeoff. If not now, then when more cards support additional MAC addresses. When I posted on this, it was really to encourage someone to want to work on making cards that support it export more than one MAC address. I currently don't have the hardware needed to do the hacking on the drivers for this one. I would be more than willing, though, once the hardware version was happy, to work on the promiscuous mode software version on top of other cards that didn't support it in hardware. The constraint, to my mind, is the hardware interfaces, so any design has to permit hardware support before it can permit emulated hardware support (or emulation of more MACs than the hardware can support on hardware that supports more than one MAC, but fewer than the desired amount -- e.g. the Tigon II support for a single additional MAC doesn't allow more than two routers in a redundancy domain). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD2C2EA.334B5629>