Package: systemd Version: 241-7~deb10u4 Severity: normal File: /lib/systemd/systemd-networkd Tags: upstream fixed-upstream Forwarded: https://github.com/systemd/systemd/issues/12558 User: [email protected] Usertags: buster-backport Control: fixed -1 242-1
Hi systemd maintainers, I'd like you to include a one-line fix for a niche problem in the next stable update of systemd. When systemd-networkd is used to create a bridge interface, systemd-networkd assigns a random mac address to the interface and overrides the kernel choice. The kernel would choose the minimal mac of the participating interfaces and that's usually what one wants. A random mac address is not stable and it can cause collisions. The issue only happens when creating the bridge using systemd-networkd. When creating a bridge using "ip link add bridge0 type bridge", the kernel policy is applied. The issue can be worked around by explicitly configuring the MACAddress in a .network configuration file when it is known in advance. This method is not applicable to cloud and embedded deployments where the same rootfs is reused for multiple nodes. The upstream solution, quite simply, is to never generate a mac address for bridge interfaces unless explicitly requested. This is implemented in https://github.com/systemd/systemd/commit/deb2cfa4c6885d448eb1f17e5ef1b139106b7e86. The commit applies easily to the version in buster and solves the problem. Current master releases have further refactored the code, so it looks different there. This issue very much affects a non-default configuration and thus affects few users. This also limits the scope of possible regressions. Backporting it locally mostly is a feasible option except for the fact that systemd is updated quite often in stable and we already are at the fourth update. The request thus is to include the fix with the next update to avoid the need for further backports by endusers. In case this bug is still present after bullseye is released, it should be closed immediately with no further action. Thank you for considering Helmut
