On 6/27/22 22:35, Neal Gompa wrote: > 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. Hmm. To me this feel more in line with a user's expectation. Let's draw a parallel here to a single NIC (no bond) situation. Here are the two cases: - single NIC - reinstalling your OS you don't need to update any external network env/config - the NIC fails - replace the NIC - update your external network env/configuration with the new MAC - dual NIC (bond) - with MACAddressPolicy=persistent - reinstall OS you need to update external network env/config - a single NIC fails - replace the NIC - No need to update your external network env/config - no new MAC - with MACAddressPolicy=none - reinstall OS you DON'T need to update external network env/config - a single NIC fails - replace the NIC - update your external network env/configuration with the new MAC To me the proposal to use MACAddressPolicy=none for bond/bridge/team gets us way more inline with what users expect, which is that if they have to replace a NIC they have to update something. I don't think users expect that if they re-install their OS they'll need to update their network env/config. I also suspect that an OS re-install is much much more common than a NIC failure replacement. > > The RHEL 9 bug seems to be private, though. > > _______________________________________________ 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
