Re: Forced lladdr change with bridge - or not?

Re: Forced lladdr change with bridge - or not?

[bdschuym]

You're right. The Linux bridge does just what the 802.1D standard recommends (http://standards.ieee.org/getieee802/download/802.1D-2004.pdf):
"7.12.5 Unique identification of a bridge
A unique 48-bit Universally Administered MAC Address, termed the Bridge Address, shall be assigned to
each Bridge. The Bridge Address may be the individual MAC Address of a Bridge Port, in which case, use
of the address of the lowest numbered Bridge Port (Port 1) is recommended."

Apparently you can get around this problem, see (I didn't verify):
http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports/

cheers,
Bart

----- Originele e-mail  -----
Van: "Pascal Hambourg" <pascal.mail@plouf.fr.eu.org>
Aan: "Jan Engelhardt" <jengelh@medozas.de>
Cc: "Bart De Schuymer" <bdschuym@pandora.be>, netfilter@vger.kernel.org
Verzonden: Zondag 22 augustus 2010 22:53:04 GMT +01:00 Amsterdam / Berlijn / Bern / Rome / Stockholm / Wenen
Onderwerp: Re: Forced lladdr change with bridge - or not?

Hello,

Jan Engelhardt a écrit :
> On Sunday 2010-08-22 18:55, Bart De Schuymer wrote:
>>> # brctl addbr br0
>>> # brctl addif br0 tap1
>>> # brctl addif br0 tap2
>>> # ip a
>>> 196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>>>    link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
>>> 197: tap2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>>>    link/ether ce:61:28:5a:b7:93 brd ff:ff:ff:ff:ff:ff
>>> 198: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN     link/ether
>>> 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
>>>
>>> Is this behavior normal that the lladdrs of all but the first brport
>>> remain unchanged? If so, what is the purpose of changing the lladdr on the
>>> first brport?
>>>  
>> I don't understand your question,

Me neither : according to your output, the MAC address of neither port
has changed.

> but the Linux bridge code assigns the MAC
>> address of its first-added port to the virtual bridge device.
> 
> 1. Why does it do that,

The bridge interface must have a MAC address, so why not pick up one in
thoses of its ports ?

> 2. Why only the first port?

IME, the bridge picks up the lowest MAC address of its ports.
This has an advantage : the bridge MAC address ends up the same for a
same set of ports regardless of the order in which the ports are added.
But this also has a big disadvantage : the bridge MAC address can change
whenever you add or remove a port, breaking ARP for a while, changing
link-local and stateless autoconfigured IPv6 addresses...

Re: Forced lladdr change with bridge - or not?

[Pascal Hambourg]

bdschuym@telenet.be a écrit :
> You're right. The Linux bridge does just what the 802.1D standard
> recommends
> (http://standards.ieee.org/getieee802/download/802.1D-2004.pdf):
> "7.12.5 Unique identification of a bridge
> A unique 48-bit Universally Administered MAC Address, termed the Bridge
> Address, shall be assigned to each Bridge. The Bridge Address may be
> the individual MAC Address of a Bridge Port, in which case, use of the
> address of the lowest numbered Bridge Port (Port 1) is recommended."

Thanks for the explanation.

> Apparently you can get around this problem, see (I didn't verify):
> http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports/

"if the bridge's MAC address is forced to a specific value, the bridge
"remembers" that and makes the address permanent. But there's a caveat:
the address must belong to one of the devices enslaved to the bridge"

Hmm, I remember I had a similar idea, but it didn't work : the address
was not permanent and could still be replaced if an interface with a
lower MAC address was added. Maybe I didn't do things right, I will try
again, thanks.

I had the idea that maybe it was a kernel change, so looking at the
kernel changelogs, I found this in ChangeLog-2.6.27 :

> commit 92c0574f11598c8036f81e27d2e8bdd6eed7d76d
> Author: Stephen Hemminger <shemminger@vyatta.com>
> Date:   Tue Jun 17 16:10:06 2008 -0700
> 
>     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.

At the time I tried to force a permanent MAC address to the bridge I
used a kernel older than 2.6.27, this explains why it didn't work.

Re: Forced lladdr change with bridge - or not?

[Pascal Hambourg]

Pascal Hambourg a écrit :
> bdschuym@telenet.be a écrit :
> 
>> Apparently you can get around this problem, see (I didn't verify):
>> http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports/
> 
> "if the bridge's MAC address is forced to a specific value, the bridge
> "remembers" that and makes the address permanent. But there's a caveat:
> the address must belong to one of the devices enslaved to the bridge"
> 
> Hmm, I remember I had a similar idea, but it didn't work : the address
> was not permanent and could still be replaced if an interface with a
> lower MAC address was added. Maybe I didn't do things right, I will try
> again, thanks.
> 
> I had the idea that maybe it was a kernel change, so looking at the
> kernel changelogs, I found this in ChangeLog-2.6.27 :
> 
>> commit 92c0574f11598c8036f81e27d2e8bdd6eed7d76d
>> Author: Stephen Hemminger <shemminger@vyatta.com>
>> Date:   Tue Jun 17 16:10:06 2008 -0700
>>
>>     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.
> 
> At the time I tried to force a permanent MAC address to the bridge I
> used a kernel older than 2.6.27, this explains why it didn't work.

I tried again. Indeed it worked with 2.6.27 but not with 2.6.26, as
expected. Contrary to the article, I observed that the statically
assigned MAC address can be arbitrary and does not have to belong to one
of the enslaved devices.

Forced lladdr change with bridge - or not?

[Jan Engelhardt]

Hi,



# tunctl -p -t tap1
Set 'tap1' persistent and owned by uid 0
# tunctl -p -t tap2
Set 'tap2' persistent and owned by uid 0
# ip a
196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
    link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
197: tap2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
    link/ether ce:61:28:5a:b7:93 brd ff:ff:ff:ff:ff:ff
# brctl addbr br0
# brctl addif br0 tap1
# brctl addif br0 tap2
# ip a
196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
    link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
197: tap2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
    link/ether ce:61:28:5a:b7:93 brd ff:ff:ff:ff:ff:ff
198: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
    link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff

Is this behavior normal that the lladdrs of all but the first brport
remain unchanged? If so, what is the purpose of changing the lladdr on 
the first brport?

Re: Forced lladdr change with bridge - or not?

[Bart De Schuymer]

Jan Engelhardt schreef:
> Hi,
>
>
>
> # tunctl -p -t tap1
> Set 'tap1' persistent and owned by uid 0
> # tunctl -p -t tap2
> Set 'tap2' persistent and owned by uid 0
> # ip a
> 196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>     link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
> 197: tap2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>     link/ether ce:61:28:5a:b7:93 brd ff:ff:ff:ff:ff:ff
> # brctl addbr br0
> # brctl addif br0 tap1
> # brctl addif br0 tap2
> # ip a
> 196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>     link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
> 197: tap2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>     link/ether ce:61:28:5a:b7:93 brd ff:ff:ff:ff:ff:ff
> 198: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
>     link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
>
> Is this behavior normal that the lladdrs of all but the first brport
> remain unchanged? If so, what is the purpose of changing the lladdr on 
> the first brport?
>
>   
I don't understand your question, but the Linux bridge code assigns the 
MAC address of its first-added port to the virtual bridge device.

Best regards,
Bart

-- 
Bart De Schuymer
www.artinalgorithms.be

Re: Forced lladdr change with bridge - or not?

[Jan Engelhardt]

On Sunday 2010-08-22 18:55, Bart De Schuymer wrote:
>> # brctl addbr br0
>> # brctl addif br0 tap1
>> # brctl addif br0 tap2
>> # ip a
>> 196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>>    link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
>> 197: tap2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>>    link/ether ce:61:28:5a:b7:93 brd ff:ff:ff:ff:ff:ff
>> 198: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN     link/ether
>> 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
>>
>> Is this behavior normal that the lladdrs of all but the first brport
>> remain unchanged? If so, what is the purpose of changing the lladdr on the
>> first brport?
>>  
> I don't understand your question, but the Linux bridge code assigns the MAC
> address of its first-added port to the virtual bridge device.

1. Why does it do that,
2. Why only the first port?

Re: Forced lladdr change with bridge - or not?

[Pascal Hambourg]

Hello,

Jan Engelhardt a écrit :
> On Sunday 2010-08-22 18:55, Bart De Schuymer wrote:
>>> # brctl addbr br0
>>> # brctl addif br0 tap1
>>> # brctl addif br0 tap2
>>> # ip a
>>> 196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>>>    link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
>>> 197: tap2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>>>    link/ether ce:61:28:5a:b7:93 brd ff:ff:ff:ff:ff:ff
>>> 198: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN     link/ether
>>> 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
>>>
>>> Is this behavior normal that the lladdrs of all but the first brport
>>> remain unchanged? If so, what is the purpose of changing the lladdr on the
>>> first brport?
>>>  
>> I don't understand your question,

Me neither : according to your output, the MAC address of neither port
has changed.

> but the Linux bridge code assigns the MAC
>> address of its first-added port to the virtual bridge device.
> 
> 1. Why does it do that,

The bridge interface must have a MAC address, so why not pick up one in
thoses of its ports ?

> 2. Why only the first port?

IME, the bridge picks up the lowest MAC address of its ports.
This has an advantage : the bridge MAC address ends up the same for a
same set of ports regardless of the order in which the ports are added.
But this also has a big disadvantage : the bridge MAC address can change
whenever you add or remove a port, breaking ARP for a while, changing
link-local and stateless autoconfigured IPv6 addresses...

Re: Forced lladdr change with bridge - or not?

[Jan Engelhardt]

On Sunday 2010-08-22 22:53, Pascal Hambourg wrote:
>>>> # ip a
>>>> 196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>>>>    link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
>>>> 197: tap2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>>>>    link/ether ce:61:28:5a:b7:93 brd ff:ff:ff:ff:ff:ff
>>>> 198: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN     link/ether
>>>> 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff
>>>>
>>>> Is this behavior normal that the lladdrs of all but the first brport
>>>> remain unchanged? If so, what is the purpose of changing the lladdr on the
>>>> first brport?
>>>>  
>>> I don't understand your question,
>
>Me neither : according to your output, the MAC address of neither port
>has changed.

Well.. rerun `ip a` before enslaving tap to br and you see.

>> but the Linux bridge code assigns the MAC
>>> address of its first-added port to the virtual bridge device.
>> 
>> 1. Why does it do that,
>
>The bridge interface must have a MAC address, so why not pick up one in
>thoses of its ports ?

Why not remain with the one it had right after "addbr" creation?

>> 2. Why only the first port?
>
>IME, the bridge picks up the lowest MAC address of its ports.

Seems logical to me at last.

Re: Forced lladdr change with bridge - or not?

[Pascal Hambourg]

Jan Engelhardt a écrit :
> On Sunday 2010-08-22 22:53, Pascal Hambourg wrote:
>>>  
>>>> I don't understand your question,
>> Me neither : according to your output, the MAC address of neither port
>> has changed.
> 
> Well.. rerun `ip a` before enslaving tap to br and you see.

Sorry to insist heavily, but I still don't get your point.
You wrote :

> Is this behavior normal that the lladdrs of all but the first brport
> remain unchanged? If so, what is the purpose of changing the lladdr on the
> first brport?

from which I understand that tap1's MAC address changed when it was
added to the bridge. But comparing tap1's MAC address from your own "ip
a" output before it is added to the bridge :

> 196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>     link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff

and after :

> 196: tap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
>     link/ether 9a:17:c4:65:e9:76 brd ff:ff:ff:ff:ff:ff

it appears to me that it didn't change.

Did I misunderstand something ?

Re: Forced lladdr change with bridge - or not?

[Jan Engelhardt]

On Monday 2010-08-23 10:21, Pascal Hambourg wrote:
>> On Sunday 2010-08-22 22:53, Pascal Hambourg wrote:
>>>>  
>>>>> I don't understand your question,
>>> Me neither : according to your output, the MAC address of neither port
>>> has changed.
>> 
>> Well.. rerun `ip a` before enslaving tap to br and you see.
>
>Sorry to insist heavily, but I still don't get your point.
>
>> Is this behavior normal that the lladdrs of all but the first brport
>> remain unchanged? If so, what is the purpose of changing the lladdr on the
>> first brport?
>
>from which I understand that tap1's MAC address changed when it was
>added to the bridge.

Yes, because br0 apparently had a lower lladdr than tap1.
Let it rest now.