On Sat, Jun 25, 2022 at 3:06 PM Vipul Siddharth <siddharthvipul1@xxxxxxxxx> wrote: > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > > == Summary == > > The `systemd-udev` package installs > `"/usr/lib/systemd/network/99-default.link"`, > which sets `Link.MACAddressPolicy=persistent`. This proposal is to > change it to set `Link.MACAddressPolicy=none` to stop changing the MAC address. > This is particularly important for bridge and bond devices. > > This change can either only apply to bridge/bond devices, or to > various software devices. That is to be discussed. > > == Owner == > > * Name: [[User:thaller|Thomas Haller]] (NetworkManager) > * Email: <thaller@xxxxxxxxxx> > * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS) > * Email: <dmabe@xxxxxxxxxx> > > > == Detailed Description == > > On Fedora, udev by default changes the MAC address of a wide range of > software devices. > This was introduced by systemd 242 in early 2019 (Fedora 31), when > `MACAddressPolicy=` was > extended to affect more types of devices. > > With `MACAddressPolicy=persistent` udev's aim is to provide a stable > MAC address, otherwise > the kernel will assign a random one. However, that can cause problems: > > Firstly, software devices are always created by some tool that has > plans for the device. The tool may not > expect that udev is going to change the MAC address and races against > that. The best solution > for the tool is to set the MAC address when creating an interface. > This will prevent > udev from changing the MAC address according to the MACAddressPolicy. > Otherwise, the tool should wait for udev to initialize the device to > avoid the race. In theory, a > tool is always advised to wait for udev to initialize the device. > However, if it were not for MACAddressPolicy, > in common scenarios udev doesn't do anything relevant for software > devices to make that necessary. > > Secondly, for interface types bridge and bond, an unset MAC address > has a special meaning > to the kernel and the MAC address of the first port is used. If udev > changes the MAC > address, that no longer works. > Now the generated MAC address is not directly discoverable as it is > based on `/etc/machine-id` > ([https://www.man7.org/linux/man-pages/man5/machine-id.5.html > machine-id(5)]), among > other data. Even if there were a tool to easily calculate the MAC > address, it could be cumbersome > to use it without logging into the machine first. The MAC address can > directly affect the > assigned IP address, for example when using DHCP. When booting a new > virtual machine, the user might > know the MAC address of the (virtual) "physical" interfaces. When > bonding/bridging those > interfaces, the bond/bridge would get one of the well known MAC > addresses. `MACAddressPolicy=persistent` > interferes with that. > > The goal of persistent policy is to provide a stable MAC address. Note > that if the > tool or user who created the interface would want a certain MAC address, they > have all the means to set it already. That applies regardless whether > the tool is > iproute2, NetworkManager, systemd-networkd. Neither NetworkManager nor > systemd-networkd > rely on udev's MACAddressPolicy for setting the MAC address. This > behavior is mostly > useful for plain `ip link add`, but it's unclear which real world user > wants this behavior. > > Of course, the user is welcome to configure the MAC address in any way > they want. Including, > dropping a link file that sets `MACAddressPolicy=persistent`. The > problem is once udev sets a MAC address, > it cannot be unset. Which makes this problematic to do by default. > > While Fedora inherited this behavior from upstream systemd, RHEL-9 > does not follow this behavior > ([https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c8953519504bf2e694bfbc2b02a456c1056f252e/0028-udev-net-setup-link-change-the-default-MACAddressPol.patch#L43 > centos9], > [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For > RHEL-8, this doesn't > apply because the systemd there is too old to change the MAC address > of most software devices. > > This could be either implemented by patching > `/usr/lib/systemd/network/99-default.link` > to have a different policy, or by dropping a link file with higher > priority. In the latter > case, that override could be shipped either by udev or even by NetworkManager. > > Another option is to change the scope of this proposal to only change to > `MACAddressPolicy=none` for the device types where this causes the most issues > (bridge/bond/team). > > > == Feedback == > > This was also discussed on upstream systemd mailing list > [https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html > here]. > The upstream systemd maintainers' opinion is that the current udev > behavior is desirable, but accepts that distributions (or network > stacks such as NetworkManager) may choose to change the default > depending on their needs > ([https://lists.freedesktop.org/archives/systemd-devel/2022-May/047943.html > reference]). > The goal here is to find out what the Fedora community thinks is the > most appropriate default. > > The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 > [rh#1921094]]. > > I'd be interested in seeing the justification for the revert in RHEL 9. From my perspective, it doesn't make sense to disable this because it makes bonds/teams/etc. device dependent. This can be particularly bad if you've got a bond and then you swap out the hardware over time. The MAC address would change on the bond, which could break any layer 2 rules in place on the network. The RHEL 9 bug seems to be private, though. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
