On 8/25/09, Alan Jenkins <sourcejedi.lkml@xxxxxxxxxxxxxx> wrote: > 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. To be more specific, it's fine to set the MAC address; the bug is that the change survives a reboot. > 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
