X-Debbugs-CC: Roman Fiedler <roman.fied...@unparalleled.eu>

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.

Reply via email to