On Sat, Jun 25, 2022 at 3:06 PM Vipul Siddharth
<siddharthvipul1(a)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: <thaller(a)redhat.com>
> * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
> * Email: <dmabe(a)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/c8953519504bf...
> 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.
>
>