Hi, no one? ...
Can someone at least tell me that the way it is done isn't wrong and should work, please? Or have I misunderstood something absolutley wrong? Cheers, Thilo Am Mittwoch, den 30.05.2018, 09:16 +0200 schrieb Thilo Cestonaro: > 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. > > 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] > > > > > 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
