On Sat, Jun 25, 2022 at 08:39:22PM +0000, devel-request@xxxxxxxxxxxxxxxxxxxxxxx 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). +1 (for very large values of 1 :) "MACAddressPolicy=none" was the default, reliable, expected behavior for literally *decades* until it got broken around the time of F32 (systemd 242): https://bugzilla.redhat.com/show_bug.cgi?id=1834537 Unbreaking the behavior (at least for bridge/bond/team interfaces) is welcome -- better late than never! Thanks much, --Gabriel > == 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]]. > > > == Benefit to Fedora == > > Pros: > > - Consistent behavior with RHEL8 and RHEL9. > > - Avoid race of udev and the tool that creates the interface. > > - Bridge and bond interfaces can get the MAC addresses from their first port. > > In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will > get a MAC related to one of its physical NIC devices. In the case of > provisioning > new systems (especially in a large datacenter) information about the server > can be used to configure the network environment (DHCP, Firewall, etc) before > the server is ever even powered on. This does mean that you may have to update > your network environment configuration if you replace a NIC (con), but that you > won't have to update your network environment configuration if you re-install > your server (pro), which is what you'd have to do now with > `MACAddressPolicy=persistent`. > > Cons: > > - Deviate from upstream systemd. > > It is desirable that RHEL and Fedora behaves similar. A possible outcome > could be the current behavior stays and RHEL 10 would change behavior. On the > other hand, different distributions (or even Fedora spins) have different > uses and needs. Deviating might be fine. In the same vein, there is also > a desire to stay close to upstream systemd behavior. But the uses of systemd > project go beyond Fedora/RHEL, so deviating here may also be fine. > > > == Scope == > > * Proposal owners: > The main goal of this request is to generate productive discussion and > find the desired behavior. > The implementation/changes are either way very simple. > > * Other developers: > Other projects that wish a certain MAC address are welcome to > set it for their devices. Including using udev's MACAddressPolicy. > > * Release engineering: > Not needed for this change. > > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > == Upgrade/compatibility impact == > > After the change, the MAC address for the affected device types changes. > > > == How To Test == > > 1) Create a software device two times, for example `ip link add type > bridge`. Note > that the MAC address is either stable or random, depending on the > `MACAddressPolicy=`. > > 2) Note that if the software device has the MAC address set initially, > udev does not > change it (`ip link add address aa:aa:aa:aa:aa:aa type bridge`). That depends on > `/sys/class/net/$dev/addr_assign_type`. > > 3) Create a bridge/bond interface without setting the MAC address. > Note that if `MACAddressPolicy=none`, > the MAC address is random at first. Note that attaching the first port > will update the controller's MAC address. > On the other hand, with `MACAddressPolicy=persistent`, the MAC address > of the controller is fixed > and not inherited from the port. > > 4) Run > > ip monitor link & > while : ; do > ip link del xxx > ip link add name xxx type dummy \ > && ip link set xxx addr aa:00:00:00:00:00 \ > && ip link show xxx | grep -q aa:00:00:00:00:00 \ > || break > done > > to reproduce the race between a simple tool and udev changing the MAC address. > > > == User Experience == > > Bond/bridge devices would again get assigned the MAC address of the > first NIC added to the device. > If we chose to not limit the scope of this change to just > bonds/bridges then all software devices would get randomly assigned > MAC addresses. > > > == Dependencies == > > None. > > > == Contingency Plan == > > If the change is rejected, nothing needs to be done. The change > itself will be simple to implement. > Contingency deadline: beta freeze > Blocks release? No > > > == Documentation == > > TODO. > > == Release Notes == > > -- > Vipul Siddharth > He/His/Him > FPgM team member _______________________________________________ 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
