[systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?

[Dusty Mabe]

On 5/12/22 13:36, Dan Streetman wrote:
> On Thu, May 12, 2022 at 11:11 AM Thomas Haller <thaller at redhat.com> wrote:
>>
>> Hi Zbyszek,
>>
>>
>>
>> I must say, I personally don't care too much. NetworkManager is fine
>> either way.
>>
>> There is however the problem about RHEL8/9, which patches this
>> downstream. I don't like that deviation, but I'd also be uncomfortable
>> to push that change for RHEL(10) users.
>>
>> But let me play devil's advocate here...
>>
>>
>> On Mon, 2022-05-09 at 19:27 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>>>
>>> FWIW, I still think it's a better _default_.
>>
>> I don't agree that it's clearly better. Your arguments don't seem
>> strong, arguably, neither are mine. Except, that it's not clear that
>> this solves an actual problem, while it clearly causes problems for
>> some people. Just look at the referened issues from !3374.
>>
>>
>> Either
>>
>>   - a user doesn't care about the MAC address,
> 
> note that it's possible for a user not to care about the *specific*
> mac address, only that they want the mac to remain consistent.
> 
> for example, on my system i have br0 bridge with multiple interfaces
> attached, and my local DHCP server is configured to provide a static
> addr to br0's mac. If I replace an interface card (e.g. change from 1g
> to 10g, or just replace a failing nic) then the br0 mac *does not*
> change, if using systemd's default. If I had br0 inheriting its mac
> from one of the attached interfaces, it would change, and i'd have to
> update my dhcp server config.
> 
> I think the argument really comes down to, should the default be to
> have (without user configuration) a mac that is predictable or a mac
> that is consistent. Your argument is for predictability, which makes
> the field engineer's work deploying systems easier, but if you lose
> consistency then the life of the maintenance engineer gets harder.

Interested discussion. Let's take it a bit further.

On your system how did your DHCP server get configured to provide an
addr to br0's MAC? You had to install the OS, and create br0 first
before you even knew the MAC to tell the network admin what the MAC
was. Now you're golden, the MAC will never change for the lifetime
of that OS install even if someone replaces a NIC, but it wasn't a great
first experience really.

On the other hand, what if you re-provision that server often (new machine-id)
you get a new MAC and you get to dance with your network admin again. OR
what if you have disk failure? You most likely backed up your critical data,
but did you backup your machine-id that hashes your new MAC? Probably not
and even if you did would you want to duplicate that machine-id to the new
install you would do?

Barring other reasons, if we simplify it down to just the consistency argument,
one approach seems better for if you replace NIC cards often and one of them
seems better if you re-install your OS often.

Dusty