Date: Thu, 26 Jul 2001 23:47:05 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Wemm <peter@wemm.org> Cc: Julian Elischer <julian@elischer.org>, "Eugene L. Vorokov" <vel@bugz.infotecs.ru>, Soren Kristensen <soren@soekris.com>, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Why two cards on the same segment... Message-ID: <3B610E69.74C105AB@mindspring.com> References: <20010726204052.7D4BB38CC@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote: > Terry Lambert wrote: > [..] > > > At a guess, he's attempting to implement VRRP, which requires > > that the virtual interface have a differen MAC address, > > Dont guess, ask. He said he needed it for testing. Personally, I need it for VRRP, and to compete with NT, which tests file server configurations with 4 cards with interrupts vectored, one each, to each of 4 CPUs, and tends to kick both Linux and FreeBSD's butts. > > and FreeBSD fails to support programming of MAC addresses, > > Damn, then I must be imagining the fact that I change MAC addresses > with 'ifconfig ether' on a regular basis. (see: SIOCSIFLLADDR) Look at the plural there: Intel Gigabit cards support 16 programmable MAC addresses, while the Tigon II supports 4, and the Tigon II supports one. Read RFC 2338: VRRP requires that each VID ends up with a MAC address in the VRRP address space, so that you can do transparent takeover, should one of your routers fail. Using the host MAC address is actually broken: it will fail to do the right thing on things like Alpine L2 switches: you end up needing to go all the way to L3 or L4 switching before you get correct behaviour again. The problem with this, of course, is that most L3/L4 switches have a limited depth ARP cache, and also have a limited number of addresses (sometimes only one) which they are able to cache on the switch to identify the card on the client side of the port. To resolve this, you pretty much need to implement virtual interfaces, one per programmable MAC. If you look at the Linux VRRPd project, you;ll see that they punted: they program the multicast address to the real MAC address on the card, and then they reprogram the original MAC to be the VRRP MAC. This lets them continue to receive any packets destined for the original MAC address, but it means that any packets they transmit go out the VID MAC address, which is technically wrong. FreeBSD doesn't even allow a single additional MAC address to be programmed: the code that does the SIOCSIFLLADDR handling when the card "init" is called (which incidently reloads the firmware on the Tigon II cards, and sends them into "watchdog timeout, resetting" hell) _ONLY_ permits reprogramming of the main MAC address, and not any of the auxillaries, for cards that support the idea -- or the multicast, for cards that can't support it. So the Linux VRRPd code won't run on FreeBSD (it's a hack), and true VRRP won't run on FreeBSD, since FreeBSD doesn't support the idea of multiple interfaces for a single card (sa_zero, as used in ip_divert, could probably do the trick to provide virtual interfaces for FreeBSD, to do the right thing). -- Terry 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?3B610E69.74C105AB>