Re: howto define which slave provides the mac addr for the bridge



Hi Thomas,

I tried your solution but without any success.
I set the 802-3-ethernet.cloned-mac-address of the connection "Bridge br1" (which is the active-connection of 
device br1) to the mac address of the physical
network adapter. 

It is set after systemd network-pre.target and NetworkManager.service, but before network.target.
I add the slaves to the bridge-connection and then I modify the connection to include the 
802-3-ethernet.cloned-mac-address property.
After that I bring the connection up.

Is that the correct order / moment during boot-up? Or shouldn't that be a problem, anyway?
Do you have other ideas what I can try? Can I set the cloned-mac-address property permanent in a 
/etc/sysconfig/network-script/ifcfg-XXXX file?

Cheers,
Thilo


Am Mittwoch, den 23.05.2018, 15:23 +0200 schrieb Thomas Haller:
On Wed, 2018-05-23 at 15:08 +0200, Thomas Haller wrote:
On Wed, 2018-05-23 at 07:16 +0000, thilo cestonaro ts fujitsu com
wrote:
Hi!

I want to connect a real ethernet adapter and a virtual ethernet
adapter to a
bridge. The bridge itself is configured to ask a dhcp for an ip
address.

The problem is, that I can't tell the bridge to always use the mac
address of
the real ethernet adapter. Rather than it is more or less luck
which
one's mac
address the bridge uses. Mostly the address of the virtual adapter
which is not
hardcoded and will be generated at every boot (which is ok, I don't
want to
hardcode this).

Is it possible to define which slave provides the mac addr for the
bridge?
The first slave which is enslaved? The last slave?
Or can I set a property in the slaves or bridges settings?
Do I need to retrieve the mac addr of the real adapter and assign
it
via a
script to the bridge?


Hi,


Which version of NetworkManager is this?

I think if you configure connection.autoconnect-slaves=yes on the
master, activating the master will re-activate the slaves in a
defined
order. With this, the slaves probably should be all
connection.autoconnect=no.

Then, you may also configure connection.autoconnect-priority on the
slaves, to ensure that the order is as you wish.

That should work, but I don't think we test this sufficiently. Hope
it's not broken :)

Hi,

Beniamino just informed me, that this might not work.

For bond and team devices, kernel chooses as MAC address the MAC
address of the slave that connects first (unless explicitly
configured).

For bridge devices, apparently kernel chooses the MAC address of the
slaves, by sorting the MAC addresses like numbers. This means, if you
first activate a slave with numerically higher MAC address, then a
second slave with a lower MAC address, the MAC address of the bridge
master changes. The order in which slaves are enslaved does not matter.

As workaround:

- ensure that the slave's MAC addresses are in a way, that kernel will
pic the right one. Possibly configuring ethernet.cloned-mac-adddress on
the slaves.

- just explicitly configure a MAC address on the bridge master, with
ethernet.cloned-mac-address.


best,
Thomas

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]