[Bridge] 2.6.27: persistent MAC assignment to bridge not working

[Daniel Robbins]

OK, I think I understand:

The MAC of the bridge is what the bridge uses to communicate with
other machines on the LAN, an IP address has been assigned to the
bridge. So the bridge's MAC setting affects the contents of the ARP
replies that are sent out from the Linux host.

When an external machine sends traffic to the Linux host, the MAC of
the bridge (in the external machine's ARP cache) must match one of the
Linux host's slave interfaces, so that the incoming traffic bound for
the Linux host is processed locally and funnels up from layer 2 to
layer 3.

If the bridge were configured with a MAC address that was not also the
MAC of one of the slave interfaces, the layer 2 traffic will remain in
layer 2 and will be forwarded to the other slave interfaces, so that
it can find its final destination, which is presumably not on the
local Linux host.

So having the bridge use a MAC from one of the slave interfaces allows
the bridge to "catch" the traffic that would otherwise be forwarded.

So the important thing from my particular use of bridging is that:

1) My bridge should use a MAC of one of the slave interfaces

2) I should ensure the MAC is "sticky" so that adding/removing
interfaces from the bridge does not cause the MAC to change and thus
invalidate the ARP caches on external machines, resulting in an
intermittent pause in network activity until the external machine's
ARP cache is updated with the new MAC address.

Does this sound right?

-Daniel

On Fri, May 8, 2009 at 9:42 PM, Stephen Hemminger <shemminger at vyatta.com> wrote:
> On Fri, 8 May 2009 19:08:06 -0600
> Daniel Robbins <drobbins at funtoo.org> wrote:
>
>> Your code in 2.6.27 works perfectly.
>>
>> Let me tell you what I was doing wrong, and if you could tell me why
>> it didn't work, I'd really appreciate it :) (Might also be a good
>> addition to the Net:Bridge FAQ):
>>
>> # brctl addbr br0
>> # brctl addif br0 eth0
>> # ifconfig br0 10.0.1.220 netmask 255.255.255.0
>> # brctl addif br0 veth100.0
>> # brctl addif br0 veth102.0
>>
>> Now, the zinger:
>>
>> # ifconfig br0 hw ether "12:34:56:78:90:ab"
>>
>> ^^ By using a unique MAC address, this command totally disables my
>> bridge, and the machine can no longer send or receive data.
>>
>> If I use a MAC that is already in use by my bridge's sub-interfaces,
>> however, (ie. from eth0, veth100.0 or veth102.0) then there's no
>> problem, and everything works, and the MAC address is sticky as it
>> should be.
>>
>> So this was the mistake I was making - I was using a user-generated
>> MAC for my testing rather than choosing a MAC from one of the bridge's
>> interfaces.
>>
>> So, my question is: why doesn't a user-generated MAC work? On the
>> surface, it seems like all devices on the same LAN should have
>> different MAC addresses. Yet, with Linux bridging, it appears that (at
>> least in certain conditions, like if there is an IP assigned to the
>> bridge,) then the bridge *must* share a MAC with one of its
>> sub-interfaces in order to function properly. This is very
>> counter-intuitive and a mystery to me and probably quite a few other
>> bridging newbies (which is why an explanation would make a great
>> addition to the Net:Bridge FAQ :)
>
> The problem is that the bridge only thinks a packet is "local" if
> it arrives with destination hw addr == incoming device address.
>