Re: Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?

[Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>]

On Mon, May 09, 2022 at 03:57:21PM +0200, Lennart Poettering wrote:
> On Mo, 09.05.22 11:23, Thomas Haller (thaller@xxxxxxxxxx) wrote:
> 
> > Hi everybody,
> >
> > this email is for discussing MACAddressPolicy=persistent in
> > /data/src/systemd/network/99-default.link
> 
> I think this would be better discussed on a new github issue, as
> suggested here:

I suggested systemd-devel for this… It's not a question of a bug,
but instead whether the default MACAddressPolicy makes sense. So I think
it's better to discuss this on the mailing list.

FWIW, I still think it's a better _default_. The patch that finally
introduced this was my patch [1], so I'm obviously biased… Some more
considerations:

1. this allows bridge devices to be created without attached
interfaces, and have a stable MAC address.

2. the idea that all interfaces are always available and always in the
same order is something that isn't necessarilly true for modern systems
where we want to react to hardware being detected dynamically.
If we wait until late userspace to configure networking, then yeah, all
devices will most likely have been detected by that time. But if we want
to bring networking in the initrd, not all hardware must be detected by
the time we start configuration.

3. one of the reasons to use bridge/bond and similar devices it that
the agreggate device can function when some of the child devices die.
By requiring the presence of one of the devices, we're partially
defeating this.

[1] https://github.com/systemd/systemd/commit/6d36464065

> 1) for bridge/bond interfaces, there is a special meaning of leaving
> the MAC address unassigned. It causes kernel to automatically set the
> MAC address when the first port gets attached. By setting a persistent
> MAC address, that automatism is not longer possible.
>
> The MAC address can matter, for example, if you configure the DHCP
> server to hand out IP addresses based on the MAC address (or based on
> the client-id, which in turn might be based on the MAC address). If you
> boot many machines (e.g. in data center or cloud), you might know the
> MAC address of the machines, and thereby can also determine the
> assigned IP addresses. With MACAddressPolicy=persistent the MAC address
> is not predictable.

This is true. But one can just as well argument that with
MACAddressPolicy=persistent the address is even more predictable. If
you know the machine-id and device name, you can calculate the address
in advance, even before deciding if the device will e.g. have this or
that card attached.

I'm not sure if we expose this conveniently anywhere… Would it help if
we document how to do this calculation with python one-liner or some
helper?

> 2) udev changing the MAC address causes races with naive scripts/tools.
> For example:
>
>   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

Again, this is a question of expecations. With MACAP=p, 'dummy' gets
the same address every time, and maybe there's no reason to set it
manually.

It would be great if we could have 'ip link add' wait for udev to
process the device. Maybe even by default?

We also discussed adding a kernel command-line switch similar to
net.ifnames= to allow this to be configured globally. Would that
help?

The cases where the old behaviour is relied on seems to be cases like
the data center described above. But in that case you're creating
local configuration anyway, so dropping in an override should be
acceptable.

Zbyszek


> https://github.com/systemd/systemd/issues/3374#issuecomment-1031072530
> 
> or here:
> 
> https://github.com/systemd/systemd/issues/3374#issuecomment-601240730