Date: Wed, 3 Mar 2004 10:44:11 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Cole <cole@opteqint.net> Cc: net@freebsd.org Subject: Re: freevrrpd (was: My planned work on networking stack) Message-ID: <20040303184409.GA1466@Odin.AC.HMC.Edu> In-Reply-To: <007e01c40142$fe89a780$4206000a@stalker> References: <09be01c4011f$83228cb0$02c0a8c0@gnbuero.qhintra.net> <20040303131512.GC35449@shellma.zin.lublin.pl> <1294253421.1078330774@andromede.faubourg.reaumur.net> <007e01c40142$fe89a780$4206000a@stalker>
next in thread | previous in thread | raw e-mail | index | archive | help
--sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 03, 2004 at 07:14:31PM +0200, Cole wrote: >=20 > The problem with freevrrp on vlan is that the ether MAC address gets > changed on the vlan device which is then different to the parent > device that the vlan was attached to. Since the vlan then has a > different ether MAC to the parent device, i dont think the parent > device is passing the packets back to the vlan device. > > What i tried to implement was a patch to the vlan device to update the > parent device's ether MAC address. I dont do this kind of programming > so i really dont have much skill with device drivers, i asked a few > devs that worked on the vlan device, and i either got no reply, and > the ones that did reply, only did so once and no further. You can't just change the parent, you will also have to change the MAC of any other vlans of the parent. This requires scanning the interface list for vlans and checking if they are children of the parent interface. This is non-trivial, but doable. If a patch that did this were written and met style(9), I'd probably be willing it commit it. It won't help people who want to abuse vlans to let a server do fail over for multiple machines on different subnets though. The real solution is to modify the Ethernet code to allow processing of select, non-multicast MACs up the the point where they are sent to the vlan which can decide which MACs it's actually going to pay attention to. This means you have to do some filtering in software (probably all filtering on many (most?, all?) nics). I think this could be done by reordering parts of ether_demux and modifying the way packets which don't match our "primary" address are handled. This looks do-able, but care are would have to be taken to ensure things were done correctly and that performance for the other 99.999+% of the world wasn't measurably harmed. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFARid3XY6L6fI4GtQRAqKBAKC+ClweVeyNM8aNSOrLGKztSuv5KgCeJg+i qBnNP+q0OKakkAVnMdyfvgE= =Gng9 -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040303184409.GA1466>