On 8/24/09, marty <marty@xxxxxxxxxxxxxxxx> wrote: > John Stoffel wrote: >>>>>>> "marty" == marty <marty@xxxxxxxxxxxxxxxx> writes: >> >> marty> Greg KH wrote: >>>>> On Tue, Aug 18, 2009 at 04:27:04PM -0400, marty wrote: >>>>>>> I got trouble... >>>>>>> (duplicate MAC addresses) >>>>> That's a bug in your hardware, have you asked your manufacturer to >>>>> resolve this for you? That violates the ethernet spec... >> >> marty> I have resolved that problem as of today. I found this was >> marty> caused by the software I had been using. If a hardware issue >> marty> remains, it is moot. >> >> marty> The bonding driver/utilities normally sets the bond address to >> marty> the MAC of the first NIC. But it also set the MAC of the slave >> marty> (eth3) to the MAC of the first NIC. This persists through >> marty> reboots so that is how my MACs got duplicated. >> >> marty> Resetting the MAC corrected those problems and everything works >> marty> fine now. >> >> Doesn't this point to a udev rules problem? What should happen if >> there are conflicting devices which both satisfy a condition, but >> where only one device is allowed to match? >> >> Now I realize that with MAC addresses you're actually allowed to have >> multiple NICs on a host all with the SAME Mac addr, but only if >> they're on different segments. Older Sun boxes all used to have a >> single MAC address across all ports. This usually isn't a problem >> since the ethernet spec says that MAC addresses are local to the >> segment, and with switches and bridges, the segment is is limited. >> >> Fails when you have bonding drivers and other HA tricks which I'm not >> up on though. >> >> John >> >> >> > > OOPS... Duplicate MACS won't work on a single box. On a network, yes. > Duplicate MACS mess everything up, because the lower networking layers do > not > use IP addresses. They depend on the MAC to route the traffic. > > I thought this was a udev problem. Greg KH suggested a hardware problem, but > I fixed it by removing the bonding driver from my config. Took a lot of > debug. > I am using shorewall to configure iptables, which has another means to > handle > multiple ISP's using packet marking. Works and as far as I can see no > issues. > > I was able to make the bonding driver work, but only if I manually corrected > the > borked MAC beforehand. My changes didn't survive reboot. Something is broken > in > that driver. I haven't looked as yet but I'm sure someone will discover it. > > There was a issue with udev, however not a rule; the LFS bootscripts I use > were guilty. --retry-failed is in invalid option on udev-1.46. Caused a big > delay for some reason. I commented it out and it boots fast now. > > BTW, this is a handy thing we can do on linux. > ip link set eth0 address 01:02:03:04:05:06 > That will set a MAC address and survives reboot (on my system anyway). That's a bug, and it's what causes you grief when you reboot with a bonding configuration. I'm pretty sure it's fixable. Your DNS was down or something when I elaborated on this earlier <http://thread.gmane.org/gmane.linux.hotplug.devel/14491>. You wouldn't know from these crippled web interfaces, but I addressed the message to the r8169 maintainer. No reply yet though. Regards Alan -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
