All of lore.kernel.org
 help / color / mirror / Atom feed
From: marty <marty@goodoldmarty.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: duplicate MAC addresses
Date: Mon, 24 Aug 2009 20:13:06 +0000	[thread overview]
Message-ID: <4A92F452.50701@goodoldmarty.com> (raw)
In-Reply-To: <4A8B0E98.6030202@goodoldmarty.com>

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

John Stoffel wrote:
>>>>>> "marty" == marty  <marty@goodoldmarty.com> 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).

Marty B.



-- 
An artist who is forced to work a specific schedule, is no longer
an artist; he is just hired help. Inspiration cannot be purchased.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2009-08-24 20:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-18 20:27 duplicate MAC addresses marty
2009-08-18 21:20 ` Greg KH
2009-08-18 21:36 ` Matthew Dharm
2009-08-19  0:26 ` marty
2009-08-19  9:19 ` Alan Jenkins
2009-08-19  9:45 ` Rui Santos
2009-08-19 16:51 ` marty
2009-08-23  0:36 ` marty
2009-08-24 18:56 ` John Stoffel
2009-08-24 20:13 ` marty [this message]
2009-08-25  8:30 ` Alan Jenkins
2009-08-25  8:31 ` Alan Jenkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A92F452.50701@goodoldmarty.com \
    --to=marty@goodoldmarty.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.