Bug 1488715

As far as I see, nothing indicates that the NetworkManager connection for the team interface specifies an explict MAC address.


For team, there are two ways. Either set "hwaddr" in the team JSON config: 

  nmcli connection modify "$TEAM0" team.config '{"hwaddr": "02:01:02:03:04:05", "runner": {"name": "activebackup"}}'

Or better: set ethernet.cloned-mac-address to a fixed address:

  nmcli connection modify "$TEAM0" ethernet.cloned-mac-address 02:01:02:03:04:05




Why do you expect the MAC address of the software device to be stable, if you don't configure it?



Using a dispatcher script seems a bad workaround, compared to explicitly configuring it in the connection. Is there some reason that doesn't work?

Hello Thomas,

Thanks for the input and the workaround where we can add the hardware address to the team configuration which will give fix the problem.


So the query here is :-

- Is it expected to add the hardware address to team configuration file to get a fixed team mac addressing? and if so then what should be mac address provided at the time of a new team configuration?

Once the team is created and system assigned some random mac address we can pick that and modify the connection but what if we want to add it at the time of team connection creation?

- Please correct me here as I am still learning, is it an enhancement compare to bonding where teaming picks any random mac address than the one from any slave whereas in bonding, systems picks mac address from any of the slave and assign it to bond interface & keeps it same across the reboots.

So I am finding it a bit difficult to understand the use-case of this feature with teaming as it will be difficult to modify the every new team connection with the mac address generated by system.



Coming to the queries:-

Why do you expect the MAC address of the software device to be stable, if you don't configure it?

- Our most of the customers are familiar with bonding where the behaviour is, as soon as we create a new bond interface,  it picks the mac address of any slave or primary slave and keep it same across the reboots. Where we need not to add a hardware address explicitly to the configuration file until we want to have failover-mac. 


So would like to know more on the new feature.


As well, would like to know if there is any feature with teaming which allows us to fallback to similar behaviour as of bonding if not then can this be considered as a feature enhancement? Please share your thoughts on this.

Hi Venkatesh,

when not explictily configured in the JSON or in the connection, the
team gets the MAC address of the first interface that gets
enslaved. The order in which NM enslaves interfaces is stable across
reboots and this should guarantee a stable MAC address for the team
interface.

However, there is currently a bug in NetworkManager-1.8.0-9 that makes
the MAC change when the connection is reactivated manually. See:

 https://bugzilla.redhat.com/show_bug.cgi?id=1472965

for more details. We plan to fix it in the 7.4.2 z-stream update; I
can provide a scratch build with the fix if your want to try it
earlier.

Also, consider that when doing:

 for x in 1 2 3 4 5; do nmcli conn down team0; sleep 5 ; nmcli conn up team0; ip l l team0; done | grep link/ether

the team connection is reactivated, but its slaves remain disconnected
(unless the connection has autoconnect-slaves=yes). When the team
interface has no slaves, it can't inherit a MAC and thus its MAC is
random until the first slave comes up. Probably you should do
something like:

 for x in 1 2 3 4 5; do nmcli conn down team0; sleep 5 ; nmcli conn up $slave_connection; ip l l team0; done | grep link/ether

because activating a slave also activates its master. Or, as
an alternative, configure the team to autoconnect the slaves:

 nmcli conection modify team0 connection.autoconnect-slaves 1

Hello,

Thanks for the information and sorry for the late reply.

I have asked customer to upgrade the NetworkManager and share the result.

I will update the BZ as soon as I hear back from CU.

Thanks again for this.