On 6/27/22 22:35, Neal Gompa wrote:
> On Sat, Jun 25, 2022 at 3:06 PM Vipul Siddharth
> <siddharthvip...@gmail.com> 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: <thal...@redhat.com>
>> * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
>> * Email: <dm...@redhat.com>
>>
>>
>> == 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
