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

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

[Daniel Robbins]

Hi All,

I am trying to figure out how to get a persistent, non-changing MAC
address assigned to a bridge. It looks like there is new functionality
in 2.6.27 to allow this to happen, specifically, in:

void br_stp_recalculate_bridge_id(struct net_bridge *br)
[...]
       /* user has chosen a value so keep it */
        if (br->flags & BR_SET_MAC_ADDR)
                return;

and in..

static int br_set_mac_address(struct net_device *dev, void *p)
[...]
        br->flags |= BR_SET_MAC_ADDR;

However, I cannot get this functionality to work as it appears it
should. If I manually set a bridge's MAC address to an arbitrary
value, as follows:

# ifconfig br0 hw ether "xx:xx:xx:xx:xx:xx"

Then, subsequent calls such as the following seem to still change the
bridge's MAC address:

# brctl addif br0 veth100.0
# brctl delif br0 veth100.0

Am I doing something wrong? What is the proper way to take advantage
of the new code in 2.6.27?

The only mechanism that I have found that appears to achieve my
desired result is application of Deitmar Maurer's 2.6.24 patch which,
after being applied, seems to disable the dynamic nature of the
bridge's MAC, so that br0 persistently uses the MAC of the first
interface that was added to the bridge. Here is this patch that seems
to be working for me:

--- linux-2.6.24-openvz.org/net/bridge/br_stp_if.c.org  2008-06-11
09:15:16.000000000 +0200
+++ linux-2.6.24-openvz.org/net/bridge/br_stp_if.c      2008-06-11
09:44:53.000000000 +0200
@@ -217,10 +217,7 @@
       struct net_bridge_port *p;

       list_for_each_entry(p, &br->port_list, list) {
-               if (addr == br_mac_zero ||
-                   memcmp(p->dev->dev_addr, addr, ETH_ALEN) < 0)
-                       addr = p->dev->dev_addr;
-
+               addr = p->dev->dev_addr;
       }

       if (compare_ether_addr(br->bridge_id.addr, addr))
--------------------------

However, when I look at the 2.6.27 source code, it seems like this
patch should no longer be needed and an "ifconfig br0 hw ether
"xx:xx:xx:xx:xx:xx" should be sufficient. Am I doing something wrong?

Thanks for your time,

Daniel Robbins

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

[Stephen Hemminger]

On Fri, 8 May 2009 15:31:43 -0600
Daniel Robbins <drobbins@funtoo.org> wrote:

> Hi All,
> 
> I am trying to figure out how to get a persistent, non-changing MAC
> address assigned to a bridge. It looks like there is new functionality
> in 2.6.27 to allow this to happen, specifically, in:
> 
> void br_stp_recalculate_bridge_id(struct net_bridge *br)
> [...]
>        /* user has chosen a value so keep it */
>         if (br->flags & BR_SET_MAC_ADDR)
>                 return;
> 
> and in..
> 
> static int br_set_mac_address(struct net_device *dev, void *p)
> [...]
>         br->flags |= BR_SET_MAC_ADDR;
> 
> However, I cannot get this functionality to work as it appears it
> should. If I manually set a bridge's MAC address to an arbitrary
> value, as follows:
> 
> # ifconfig br0 hw ether "xx:xx:xx:xx:xx:xx"
> 
> Then, subsequent calls such as the following seem to still change the
> bridge's MAC address:
> 
> # brctl addif br0 veth100.0
> # brctl delif br0 veth100.0
> 
> Am I doing something wrong? What is the proper way to take advantage
> of the new code in 2.6.27?
> 
> The only mechanism that I have found that appears to achieve my
> desired result is application of Deitmar Maurer's 2.6.24 patch which,
> after being applied, seems to disable the dynamic nature of the
> bridge's MAC, so that br0 persistently uses the MAC of the first
> interface that was added to the bridge. Here is this patch that seems
> to be working for me:
> 
> --- linux-2.6.24-openvz.org/net/bridge/br_stp_if.c.org  2008-06-11
> 09:15:16.000000000 +0200
> +++ linux-2.6.24-openvz.org/net/bridge/br_stp_if.c      2008-06-11
> 09:44:53.000000000 +0200
> @@ -217,10 +217,7 @@
>        struct net_bridge_port *p;
> 
>        list_for_each_entry(p, &br->port_list, list) {
> -               if (addr == br_mac_zero ||
> -                   memcmp(p->dev->dev_addr, addr, ETH_ALEN) < 0)
> -                       addr = p->dev->dev_addr;
> -
> +               addr = p->dev->dev_addr;
>        }
> 
>        if (compare_ether_addr(br->bridge_id.addr, addr))
> --------------------------
> 
> However, when I look at the 2.6.27 source code, it seems like this
> patch should no longer be needed and an "ifconfig br0 hw ether
> "xx:xx:xx:xx:xx:xx" should be sufficient. Am I doing something wrong?
> 
> Thanks for your time,
> 
> Daniel Robbins

It was fixed by:

Author: Stephen Hemminger <shemminger@vyatta.com>  2008-06-17 16:10:06
Committer: David S. Miller <davem@davemloft.net>  2008-06-17 16:10:06
Parent: 0b040829952d84bf2a62526f0e24b624e0699447 (net: remove CVS keywords)
Branches: master, remotes/origin/master
Follows: v2.6.26-rc6
Precedes: v2.6.27-rc1

    bridge: make bridge address settings sticky
    
    Normally, the bridge just chooses the smallest mac address as the
    bridge id and mac address of bridge device. But if the administrator
    has explictly set the interface address then don't change it.
    
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

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

[Daniel Robbins]

This commit is in my 2.6.27-based kernel. It does not appear to be
working. Can you show me what steps I should take to confirm that this
sticky code is functioning properly, ie commands and expected results?

Thanks.

-Daniel

On Fri, May 8, 2009 at 4:54 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Fri, 8 May 2009 15:31:43 -0600
> Daniel Robbins <drobbins@funtoo.org> wrote:
>
>> Hi All,
>>
>> I am trying to figure out how to get a persistent, non-changing MAC
>> address assigned to a bridge. It looks like there is new functionality
>> in 2.6.27 to allow this to happen, specifically, in:
>>
>> void br_stp_recalculate_bridge_id(struct net_bridge *br)
>> [...]
>>        /* user has chosen a value so keep it */
>>         if (br->flags & BR_SET_MAC_ADDR)
>>                 return;
>>
>> and in..
>>
>> static int br_set_mac_address(struct net_device *dev, void *p)
>> [...]
>>         br->flags |= BR_SET_MAC_ADDR;
>>
>> However, I cannot get this functionality to work as it appears it
>> should. If I manually set a bridge's MAC address to an arbitrary
>> value, as follows:
>>
>> # ifconfig br0 hw ether "xx:xx:xx:xx:xx:xx"
>>
>> Then, subsequent calls such as the following seem to still change the
>> bridge's MAC address:
>>
>> # brctl addif br0 veth100.0
>> # brctl delif br0 veth100.0
>>
>> Am I doing something wrong? What is the proper way to take advantage
>> of the new code in 2.6.27?
>>
>> The only mechanism that I have found that appears to achieve my
>> desired result is application of Deitmar Maurer's 2.6.24 patch which,
>> after being applied, seems to disable the dynamic nature of the
>> bridge's MAC, so that br0 persistently uses the MAC of the first
>> interface that was added to the bridge. Here is this patch that seems
>> to be working for me:
>>
>> --- linux-2.6.24-openvz.org/net/bridge/br_stp_if.c.org  2008-06-11
>> 09:15:16.000000000 +0200
>> +++ linux-2.6.24-openvz.org/net/bridge/br_stp_if.c      2008-06-11
>> 09:44:53.000000000 +0200
>> @@ -217,10 +217,7 @@
>>        struct net_bridge_port *p;
>>
>>        list_for_each_entry(p, &br->port_list, list) {
>> -               if (addr == br_mac_zero ||
>> -                   memcmp(p->dev->dev_addr, addr, ETH_ALEN) < 0)
>> -                       addr = p->dev->dev_addr;
>> -
>> +               addr = p->dev->dev_addr;
>>        }
>>
>>        if (compare_ether_addr(br->bridge_id.addr, addr))
>> --------------------------
>>
>> However, when I look at the 2.6.27 source code, it seems like this
>> patch should no longer be needed and an "ifconfig br0 hw ether
>> "xx:xx:xx:xx:xx:xx" should be sufficient. Am I doing something wrong?
>>
>> Thanks for your time,
>>
>> Daniel Robbins
>
> It was fixed by:
>
> Author: Stephen Hemminger <shemminger@vyatta.com>  2008-06-17 16:10:06
> Committer: David S. Miller <davem@davemloft.net>  2008-06-17 16:10:06
> Parent: 0b040829952d84bf2a62526f0e24b624e0699447 (net: remove CVS keywords)
> Branches: master, remotes/origin/master
> Follows: v2.6.26-rc6
> Precedes: v2.6.27-rc1
>
>    bridge: make bridge address settings sticky
>
>    Normally, the bridge just chooses the smallest mac address as the
>    bridge id and mac address of bridge device. But if the administrator
>    has explictly set the interface address then don't change it.
>
>    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
>
>

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

[Stephen Hemminger]

On Fri, 8 May 2009 17:20:08 -0600
Daniel Robbins <drobbins@funtoo.org> wrote:

> This commit is in my 2.6.27-based kernel. It does not appear to be
> working. Can you show me what steps I should take to confirm that this
> sticky code is functioning properly, ie commands and expected results?
> 
> Thanks.
> 
> -Daniel
> 
> On Fri, May 8, 2009 at 4:54 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> > On Fri, 8 May 2009 15:31:43 -0600
> > Daniel Robbins <drobbins@funtoo.org> wrote:
> >
> >> Hi All,
> >>
> >> I am trying to figure out how to get a persistent, non-changing MAC
> >> address assigned to a bridge. It looks like there is new functionality
> >> in 2.6.27 to allow this to happen, specifically, in:
> >>
> >> void br_stp_recalculate_bridge_id(struct net_bridge *br)
> >> [...]
> >>        /* user has chosen a value so keep it */
> >>         if (br->flags & BR_SET_MAC_ADDR)
> >>                 return;
> >>
> >> and in..
> >>
> >> static int br_set_mac_address(struct net_device *dev, void *p)
> >> [...]
> >>         br->flags |= BR_SET_MAC_ADDR;
> >>
> >> However, I cannot get this functionality to work as it appears it
> >> should. If I manually set a bridge's MAC address to an arbitrary
> >> value, as follows:
> >>
> >> # ifconfig br0 hw ether "xx:xx:xx:xx:xx:xx"
> >>
> >> Then, subsequent calls such as the following seem to still change the
> >> bridge's MAC address:
> >>
> >> # brctl addif br0 veth100.0
> >> # brctl delif br0 veth100.0
> >>
> >> Am I doing something wrong? What is the proper way to take advantage
> >> of the new code in 2.6.27?
> >>
> >> The only mechanism that I have found that appears to achieve my
> >> desired result is application of Deitmar Maurer's 2.6.24 patch which,
> >> after being applied, seems to disable the dynamic nature of the
> >> bridge's MAC, so that br0 persistently uses the MAC of the first
> >> interface that was added to the bridge. Here is this patch that seems
> >> to be working for me:
> >>
> >> --- linux-2.6.24-openvz.org/net/bridge/br_stp_if.c.org  2008-06-11
> >> 09:15:16.000000000 +0200
> >> +++ linux-2.6.24-openvz.org/net/bridge/br_stp_if.c      2008-06-11
> >> 09:44:53.000000000 +0200
> >> @@ -217,10 +217,7 @@
> >>        struct net_bridge_port *p;
> >>
> >>        list_for_each_entry(p, &br->port_list, list) {
> >> -               if (addr == br_mac_zero ||
> >> -                   memcmp(p->dev->dev_addr, addr, ETH_ALEN) < 0)
> >> -                       addr = p->dev->dev_addr;
> >> -
> >> +               addr = p->dev->dev_addr;
> >>        }
> >>
> >>        if (compare_ether_addr(br->bridge_id.addr, addr))
> >> --------------------------
> >>
> >> However, when I look at the 2.6.27 source code, it seems like this
> >> patch should no longer be needed and an "ifconfig br0 hw ether
> >> "xx:xx:xx:xx:xx:xx" should be sufficient. Am I doing something wrong?
> >>
> >> Thanks for your time,
> >>
> >> Daniel Robbins
> >
> > It was fixed by:
> >
> > Author: Stephen Hemminger <shemminger@vyatta.com>  2008-06-17 16:10:06
> > Committer: David S. Miller <davem@davemloft.net>  2008-06-17 16:10:06
> > Parent: 0b040829952d84bf2a62526f0e24b624e0699447 (net: remove CVS keywords)
> > Branches: master, remotes/origin/master
> > Follows: v2.6.26-rc6
> > Precedes: v2.6.27-rc1
> >
> >    bridge: make bridge address settings sticky
> >
> >    Normally, the bridge just chooses the smallest mac address as the
> >    bridge id and mac address of bridge device. But if the administrator
> >    has explictly set the interface address then don't change it.
> >
> >    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >    Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >

# brctl addbr brex0
# modprobe dummy

# ip li set dev brex0 addr 0c:01:02:03:04:05
# ip li show dev brex0
22: brex0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
    link/ether 0c:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
# brctl addif brex0 dummy0
# ip li show dev brex0
22: brex0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
    link/ether 0c:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff

-- 

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

[Daniel Robbins]

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 :)

Best Regards,

Daniel Robbins

On Fri, May 8, 2009 at 5:27 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Fri, 8 May 2009 17:20:08 -0600
> Daniel Robbins <drobbins@funtoo.org> wrote:
>
>> This commit is in my 2.6.27-based kernel. It does not appear to be
>> working. Can you show me what steps I should take to confirm that this
>> sticky code is functioning properly, ie commands and expected results?
>>
>> Thanks.
>>
>> -Daniel
>>
>> On Fri, May 8, 2009 at 4:54 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
>> > On Fri, 8 May 2009 15:31:43 -0600
>> > Daniel Robbins <drobbins@funtoo.org> wrote:
>> >
>> >> Hi All,
>> >>
>> >> I am trying to figure out how to get a persistent, non-changing MAC
>> >> address assigned to a bridge. It looks like there is new functionality
>> >> in 2.6.27 to allow this to happen, specifically, in:
>> >>
>> >> void br_stp_recalculate_bridge_id(struct net_bridge *br)
>> >> [...]
>> >>        /* user has chosen a value so keep it */
>> >>         if (br->flags & BR_SET_MAC_ADDR)
>> >>                 return;
>> >>
>> >> and in..
>> >>
>> >> static int br_set_mac_address(struct net_device *dev, void *p)
>> >> [...]
>> >>         br->flags |= BR_SET_MAC_ADDR;
>> >>
>> >> However, I cannot get this functionality to work as it appears it
>> >> should. If I manually set a bridge's MAC address to an arbitrary
>> >> value, as follows:
>> >>
>> >> # ifconfig br0 hw ether "xx:xx:xx:xx:xx:xx"
>> >>
>> >> Then, subsequent calls such as the following seem to still change the
>> >> bridge's MAC address:
>> >>
>> >> # brctl addif br0 veth100.0
>> >> # brctl delif br0 veth100.0
>> >>
>> >> Am I doing something wrong? What is the proper way to take advantage
>> >> of the new code in 2.6.27?
>> >>
>> >> The only mechanism that I have found that appears to achieve my
>> >> desired result is application of Deitmar Maurer's 2.6.24 patch which,
>> >> after being applied, seems to disable the dynamic nature of the
>> >> bridge's MAC, so that br0 persistently uses the MAC of the first
>> >> interface that was added to the bridge. Here is this patch that seems
>> >> to be working for me:
>> >>
>> >> --- linux-2.6.24-openvz.org/net/bridge/br_stp_if.c.org  2008-06-11
>> >> 09:15:16.000000000 +0200
>> >> +++ linux-2.6.24-openvz.org/net/bridge/br_stp_if.c      2008-06-11
>> >> 09:44:53.000000000 +0200
>> >> @@ -217,10 +217,7 @@
>> >>        struct net_bridge_port *p;
>> >>
>> >>        list_for_each_entry(p, &br->port_list, list) {
>> >> -               if (addr == br_mac_zero ||
>> >> -                   memcmp(p->dev->dev_addr, addr, ETH_ALEN) < 0)
>> >> -                       addr = p->dev->dev_addr;
>> >> -
>> >> +               addr = p->dev->dev_addr;
>> >>        }
>> >>
>> >>        if (compare_ether_addr(br->bridge_id.addr, addr))
>> >> --------------------------
>> >>
>> >> However, when I look at the 2.6.27 source code, it seems like this
>> >> patch should no longer be needed and an "ifconfig br0 hw ether
>> >> "xx:xx:xx:xx:xx:xx" should be sufficient. Am I doing something wrong?
>> >>
>> >> Thanks for your time,
>> >>
>> >> Daniel Robbins
>> >
>> > It was fixed by:
>> >
>> > Author: Stephen Hemminger <shemminger@vyatta.com>  2008-06-17 16:10:06
>> > Committer: David S. Miller <davem@davemloft.net>  2008-06-17 16:10:06
>> > Parent: 0b040829952d84bf2a62526f0e24b624e0699447 (net: remove CVS keywords)
>> > Branches: master, remotes/origin/master
>> > Follows: v2.6.26-rc6
>> > Precedes: v2.6.27-rc1
>> >
>> >    bridge: make bridge address settings sticky
>> >
>> >    Normally, the bridge just chooses the smallest mac address as the
>> >    bridge id and mac address of bridge device. But if the administrator
>> >    has explictly set the interface address then don't change it.
>> >
>> >    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>> >    Signed-off-by: David S. Miller <davem@davemloft.net>
>> >
>> >
>
> # brctl addbr brex0
> # modprobe dummy
>
> # ip li set dev brex0 addr 0c:01:02:03:04:05
> # ip li show dev brex0
> 22: brex0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>    link/ether 0c:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
> # brctl addif brex0 dummy0
> # ip li show dev brex0
> 22: brex0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
>    link/ether 0c:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
>
> --
>

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

[Stephen Hemminger]

On Fri, 8 May 2009 19:08:06 -0600
Daniel Robbins <drobbins@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.

Re: [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@vyatta.com> wrote:
> On Fri, 8 May 2009 19:08:06 -0600
> Daniel Robbins <drobbins@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.
>