Latest revision as of 13:13, 20 April 2023

MAC Address Policy none

Summary

The systemd-udev package installs "/usr/lib/systemd/network/99-default.link", which sets Link.MACAddressPolicy=persistent for all software NIC devices. This proposal is to add to the policy so that we use Link.MACAddressPolicy=none for bond/bridge/team devices.

Owner

Name: Thomas Haller (NetworkManager), Dusty Mabe (Fedora CoreOS)
Email: <thaller@redhat.com>, <dmabe@redhat.com>

Current status

Targeted release: Fedora Linux 38
Last updated: 2023-04-20
Devel list thread
FESCo issue: #2824
Tracker bug: #2107754
Release notes tracker: #859

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.

For interface types bridge/bond/team, 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 (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.

While Fedora inherited this behavior from upstream systemd, RHEL-9 does not follow this behavior (centos9, 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.

The proposal here is to 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 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 (reference). The goal here is to find out what the Fedora community thinks is the most appropriate default.

The RHEL-9 bug is rh#1921094.

A Fedora bug after the change: #2188280

Benefit to Fedora

Pros:

- Consistent behavior with RHEL8 and RHEL9 for bond/bridge/team devices.

- 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 simple to implement.

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 MACAddressPolicy for bond/bridge/team device types will be set to none.

How To Test

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.

User Experience

Bond/bridge/team devices would again get assigned the MAC address of the first NIC added to the device.

Dependencies

None.

Contingency Plan

Contingency mechanism: (What to do? Who will do it?)

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

@@ Line 5: / Line 5: @@
 = MAC Address Policy none <!-- The name of your change proposal --> =
-{{Change_Proposal_Banner}}
 == Summary ==
 <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
-systemd-udev package installs `"/usr/lib/systemd/network/99-default.link"`,
+The `systemd-udev` package installs `"/usr/lib/systemd/network/99-default.link"`, which sets
-which sets `Link.MACAddressPolicy=persistent`. This proposal is to change
+`Link.MACAddressPolicy=persistent` for all software NIC devices. This proposal is to add to
-that and set `Link.MACAddressPolicy=none` to stop changing the MAC address.
+the policy so that we use `Link.MACAddressPolicy=none` for bond/bridge/team devices.
 == Owner ==
@@ Line 20: / Line 19: @@
 -->
 <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
-* Name: [[User:thaller|Thomas Haller]]
+* Name: [[User:thaller|Thomas Haller]] (NetworkManager), [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
-* Email: <thaller@redhat.com>
+* Email: <thaller@redhat.com>, <dmabe@redhat.com>
-* Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
-* Email: <dmabe@redhat.com>
 <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
 * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
 -->
 == Current status ==
-[[Category:ChangePageIncomplete]]
+[[Category:ChangeAcceptedF38]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
@@ Line 41: / Line 36: @@
 [[Category:SystemWideChange]]
-* Targeted release: [[Releases/37 | Fedora Linux 37 ]]
+* Targeted release: [[Releases/38 | Fedora Linux 38 ]]
 * Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
 <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
@@ Line 49: / Line 44: @@
 ON_QA -> change is fully code complete
 -->
-* FESCo issue: <will be assigned by the Wrangler>
+* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FZGH473ZUGPXK2E3GOEQ5TBLJ62FYJBC/ Devel list thread]
-* Tracker bug: <will be assigned by the Wrangler>
+* FESCo issue: [https://pagure.io/fesco/issue/2824 #2824]
-* Release notes tracker: <will be assigned by the Wrangler>
+* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2107754 #2107754]
+* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/859 #859]
 == Detailed Description ==
@@ Line 60: / Line 56: @@
 extended to affect more types of devices.
-Udev's aim here is to provide a stable MAC address, otherwise kernel will assign a random one.
+With `MACAddressPolicy=persistent` udev's aim is to provide a stable MAC address, otherwise
-However, that can cause problems:
+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
+For interface types bridge/bond/team, an unset MAC address has a special meaning
-to kernel and the MAC address of the first port is used. If udev changes the MAC
+to the kernel and the MAC address of the first port is used. If udev changes the MAC
 address, that no longer works.
-The generated MAC address is not directly discoverable as it is based on `/etc/machine-id`
+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/briding those
+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]). RHEL-8's systemd is too old to
+[https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For RHEL-8, this doesn't
-change the MAC address of most software devices.
+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`
+The proposal here is to change to `MACAddressPolicy=none` for the device types where this causes
-to have a different policy, or by dropping a link file with higher priority. In the latter
+the most issues (bridge/bond/team).
-case, that override could be shipped either by udev or even by NetworkManager.
-The override could also limit `MACAddressPolicy=none` to certain device types only,
-like bridge, bond and team interfaces.
@@ Line 109: / Line 83: @@
 <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
-This was also discussed on upstream systemd mailing list [https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html [here]].
+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.
+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]].
+The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094].
+A Fedora bug after the change: [https://bugzilla.redhat.com/show_bug.cgi?id=2188280 #2188280]
 == Benefit to Fedora ==
@@ Line 145: / Line 124: @@
 Pros:
-- Consistent behavior with RHEL8 and RHEL9.
+- Consistent behavior with RHEL8 and RHEL9 for bond/bridge/team devices.
 - Bridge and bond interfaces can get the MAC addresses from their first port.
-- Avoid race of udev and the tool that creates the interface.
+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:
@@ Line 155: / Line 141: @@
 - Deviate from upstream systemd.
-It is desirable that RHEL and Fedora behaves similar. A possibly outcome
+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 vain, there is also
+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.
@@ Line 167: / Line 154: @@
 <!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
-The main goal of this request is discussion and find the desired behavior.
+The main goal of this request is to generate productive discussion and find the desired behavior.
-The implementation/changes are either way very simple.
+The implementation/changes are simple to implement.
 * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
@@ Line 194: / Line 181: @@
 <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
-After the change, the MAC address for the affected device types changes.
+After the change, the MACAddressPolicy for bond/bridge/team device
+types will be set to none.
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
@@ Line 216: / Line 204: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-) Create a software device two times, for example `ip link add type bridge`. Note
+Create a bridge/bond interface without setting the MAC address. Note that if `MACAddressPolicy=none`,
-that the MAC address is either stable or random, depending on the `MACAddressPolicy=`.
-) 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`.
-) 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.
-) 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 ==
@@ Line 254: / Line 221: @@
 -->
-The MAC address of software devices would again be random.
+Bond/bridge/team devices would again get assigned the MAC address of the first NIC added to the device.
 == Dependencies ==

Search

Changes/MAC Address Policy none: Difference between revisions