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

[Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx>]

On Thu, 12 May 2022 14:36:44 -0400
Dan Streetman <ddstreet@xxxxxxxx> wrote:

> On Thu, May 12, 2022 at 2:27 PM Dan Streetman <ddstreet@xxxxxxxx> wrote:
> >
> > On Thu, May 12, 2022 at 1:50 PM Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote:  
> > >
> > >
> > >
> > > On 5/12/22 13:36, Dan Streetman wrote:  
> > > > On Thu, May 12, 2022 at 11:11 AM Thomas Haller <thaller@xxxxxxxxxx> 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.  
> >
> > No, but the alternative is for me to manually find the mac address
> > labels on my nics and use those to pre-configure my DHCP server. I
> > understand for large deployments those are typically provided in a
> > spreadsheet, but that isn't the case for me, and my approach (i.e.
> > simply check the mac once the system is installed) was *much* easier
> > and more reliable.
> >
> > And this doesn't even get into the nuances of figuring out *which* nic
> > mac the bridge/bond will get, which won't be obvious to everyone. Note
> > that the answer here *is not* that the bridge gets the mac of the
> > 'first' interface added to it; the bridge gets the mac of the *lowest*
> > mac that is currently attached to it. And yes, this does mean that if
> > you use this behavior (of a bridge getting its mac from the attached
> > interfaces), the bridge's mac *can change while it is up and running
> > with an address*. Try it out yourself ;-)  
> 
> And to clarify - bond interfaces do 'keep' the mac of the 'first'
> interface added - technically, the bond sets all interfaces added
> later to have the same mac. So this is even less 'predictable' than a
> bridge, where you can predict which of the 2 or more macs are
> 'lowest', a bond mac would just be whatever the 'first' added
> interface is.

I remember that behavior was documented in one of the 802 standards
related to spanning tree.  The bridge advertises based on its MAC
address.