X-Debbugs-CC: Roman Fiedler <[email protected]>
On Sat, Aug 14, 2021 at 08:18:00PM +0000, Roman Fiedler wrote:
> > iface virtbr0 inet static
> > address 192.168.1.1
> > netmask 255.255.255.0
> > bridge_hw 86:aa:aa:aa:aa:aa
>
> Weird, using the configuration from above will result in:
>
> $ ifup virtbr0
> Cannot find device "virtbr0"
> ifup: failed to bring up virtbr0
It is because the "bridge_ports" directive is missing. From the
manpage bridge-utils-interfaces(5):
bridge_ports interface specification
this option must exist for the scripts to setup the bridge.
Either specify "bridge_ports none" or "bridge_ports enp2s0 enp2s1" (or
whatever your physical interfaces are named).
> I also reactivated "systemd-udevd":
>
> $ systemctl start systemd-udevd-kernel.socket
> $ systemctl start systemd-udevd-control.socket
> $ systemctl start systemd-udevd.service
>
> And then tried to use the link, but I am not sure, if it is active
> without rebooting as "reload" does not seem to be the right command
> for it.
>
> # systemctl reload /lib/systemd/network/80-bridgeutils.link
> Failed to reload lib-systemd-network-80\x2dbridgeutils.link.mount: Unit
> lib-systemd-network-80\x2dbridgeutils.link.mount not found.
Running "systemctl daemon-reload" would have been the correct thing to
do here.
> Without rebooting (which at the moment would be annoying for
> the test machine), the "hw_address" does still not work:
>
> iface virtbr0 inet static
> address 192.168.1.1
> netmask 255.255.255.0
> pre-up brctl addbr virtbr0
> post-down brctl delbr virtbr0
> bridge_hw 86:aa:aa:aa:aa:aa
>
> but now the MAC seems truely random each time the bridge is created:
This is because with systemd-udevd stopped (or told to not touch
bridge devices through 80-bridgeutils.link) the MAC address the kernel
assigns upon device creation (which is randomly generated every time)
remains untouched. systemd-udevd would also assign a random MAC address,
but generates the same one every time (it's random only compared to
the burnt-in MAC address).
Regards.
