Hi Thomas, thank you for your support. I think I found it now. It was a bug in my script which didn't bring up the bridge. I think, that the bridge was on auto-connect in the persistent config, network-manager brought the bridge up. So everthing worked but my settings got lost and I looked for the cloned-mac-address setting via my script after I set it, so I thought everything is fine.
Thank you for your patience! Cheers, Thilo Am Dienstag, den 05.06.2018, 11:24 +0200 schrieb Thilo Cestonaro: > Hi Thomas, > > > Am Dienstag, den 05.06.2018, 09:32 +0200 schrieb Thomas Haller: > > On Wed, 2018-05-30 at 07:16 +0000, [email protected] > > wrote: > > > Hi, > > > > > > I'm configuring a network namespace during bootup to be connected to > > > the real world via a bridge. > > > > > > physical <-> bridge <-> veth_outside <-> veth_inside > > > > > > The bridge and the veth_inside are configured to retrieve IPv4 > > > configuration via DHCP. > > > The problem is, that the bridge gets it's MAC address either from > > > pyhsical or from veth_outside, except that, everthing is working > > > fine. > > > > > > My approach: > > > I create the veth peer via "ip link" then I add the physical and the > > > veth_outside to the bridge profile via > > > "nmcli con add type bridge-slave" ... > > > > > > Then I modify the bridge profile adding the cloned-mac-address, and > > > then I call "nmcli con up" on the bridge profile. > > > In my opinion, this is the order it should be, right? But the bridge > > > still uses either the mac address of the physical adapter or the one > > > of the veth_outside, > > > depening on the sort order. > > > > Hi, > > > > It's not clear what you are doing. > > as far as I know, network manager doesn't support network namespaces, right? > That's why I have a script which is started via systemd to configure a network > namespace at every boot. > This script uses "ip link add" and similiar stuff to configure the network > namespace and the virtual ethernet adapters. > > > > > In general, you create one (or more) connection profiles with the > > settings you want. Profiles are persisted, so you usually create them > > only once, and from then on, you just activate/deactivate it. > > -- contrary to `ip link add`, which is lost after reboot. > > As the network namespace can't be configured via networkmanager, I can't use > any persistent stuff. :( > Please tell me, I'm wrong here :) > > > > > How did you create the profiles in detail? > > At first I created the bridge and added the physical adapter to it via nmtui. > But when the network namespace came in, > I started using nmcli to add the slaves (physical adapter and virtual > adapter) at every boot to the bridge and bring the bridge up. > > > > > Is the right profile active? (nmcli device) > > Yes the right profiles are active as everything works as expected, > except which mac address is used for the bridge. Thats why the bridge gets > different IP addresses from the DHCP > which is disturbing me as the system should be a server with a reserved lease. > > > > > Does the active profile have the right cloned-mac-address setting? > > (nmcli con show $NAME) > > Yes, it shows me this line for the bridge connection: > > 802-3-ethernet.cloned-mac-address: 90:1B:0E:E7:03:A1 > > And the mac address is exactly the one I want the bridge to have but it uses > a different one. > > > > > If that looks alright, it would be good look at the logfile, with > > level=TRACE level enabled. See > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf > > for hints. > > > > Thanks for the hint, I will have a look if this shows any information. > > > > > > best, > > Thomas > > > > > > > I wanted to change the bridge profile on disk, to have it configured > > > before anything happens. > > > My hope was, that it just doesn't work because I'm to late with my > > > network namespace script. > > > > > > Cheers, > > > Thilo > > > > > > > > > > > > > > > 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? > > > > > > > > I don't understand what you are doing. > > > > > > > > In NetworkManager, you commonly configure connection (profiles), > > > > and > > > > then activate them. > > > > > > > > You first set ethernet.cloned-mac-address in the profile, before > > > > activating it. The systemd target does not matter here. > > > > > > > > If you modify a profile that is already active, you need to re- > > > > activate > > > > it for the changes to take effect. This means, call `nmcli > > > > connection > > > > up "$PROFILE"` after modifying a profile. > > > > > > > > > > > > > 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? > > > > > > > > Sure, you can edit profiles on disk. Note that must be followed by > > > > `nmcli connection reload` for the changes to be picked up. And if > > > > the > > > > profile is currently active, you also will need to re-activate the > > > > profile too. > > > > > > > > However, there is little reason to ever edit files on disk. Just > > > > use > > > > > > > > nmcli connection modify "$PROFILE" ethernet.cloned-mac-address > > > > "$VALUE" > > > > > > > > > > > > > > > > best, > > > > Thomas > > > > > > > > > > > > > > > > > > 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, [email protected] > > > > > > > .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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
