RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1472965 - Upping an already up bond connection will change the bond MAC
Summary: Upping an already up bond connection will change the bond MAC
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
: 1488715 (view as bug list)
Depends On:
Blocks: 1443347 1444109 1463218 1490741
TreeView+ depends on / blocked
 
Reported: 2017-07-19 17:10 UTC by Francesco Giudici
Modified: 2021-06-10 12:38 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, the NetworkManager service set by default the MAC address of a master device (bond, bridge, team) to a random value generated by the kernel. As a consequence, the MAC address of the device changed every time the device was activated. The bug has been fixed and now NetworkManager no longer changes the MAC address of a master device by default. Instead, the interface inherits the Mac address from one of its slaves.
Clone Of:
: 1490741 (view as bug list)
Environment:
Last Closed: 2018-04-10 13:27:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
NM trace log (1.16 MB, text/plain)
2017-07-19 17:10 UTC, Francesco Giudici 		no flags Details
[PATCH] device: bond: don't set the permanent hardware address (8.39 KB, patch)
2017-07-21 12:21 UTC, Beniamino Galvani 		no flags Details | Diff
[PATCH v2] device: don't set a fake permanent hardware address (8.12 KB, patch)
2017-07-25 21:20 UTC, Beniamino Galvani 		no flags Details | Diff
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0778 0 None None None 2018-04-10 13:28:55 UTC

Description Francesco Giudici 2017-07-19 17:10:19 UTC 
Created attachment 1301245 [details]
NM trace log

Description of problem:
When configuring a bond and enslaving an interface in it, the master interface is created correctly and the MAC is taken from the enslaved device.
If the bond connection is upped again, the MAC address is changed to the fake, temporary one the bond had during the creation (before changing it to the enslaved one).

Version-Release number of selected component (if applicable):
nm-1-8 (RHEL-7.4)

How reproducible:
create a bond slave connection on an existing interface
create a bond (master) connection
#check the MAC --> all ok
nmcli conn up BOND_MASTER_IFACE
#check the MAC --> reverted to the fake one (enslaved iface too)


--
attached NM log: trace level log starts just before adding the bond2 connection and then upping it (marked inline where the verbose logging starts: seems good to start looking from there).

--
this bug affects RHEV
Comment 2 Beniamino Galvani 2017-07-21 12:04:39 UTC 
NM now sets the hw-addr from the ethernet.cloned-mac-address property
when the bond is activated; the property default value is 'preserve'
upstream and 'permanent' on RHEL (cfr. bug 1413312).

When the bond is activated the first time on RHEL, NM notices that the
current MAC is already the permanent one (*), and does not set
it. Later, an interface is enslaved to the bond and the kernel assigns
the slave MAC to the bond (because the bond MAC had not been
explicitly changed).

When the connection is re-activated, NM tries again to set the
permanent address and notices that the current address is
different. So, this time it actually sets the MAC. From this point,
the kernel will never changed the MAC upon interface enslavement
because it was explicitly set by the user.

A solution to this would be to ignore for bonds the cloned-mac-address
property when it's set to 'permanent' because it doesn't make much
sense to enforce a permanent address that's actually random. We could
also do the same for other software devices, but it's only for bonds
that setting the pseudo-permanent MAC has negative effects.

(*) a bond doesn't really have a permanent MAC, we consider the first
random MAC assigned by kernel as the permanent one.
Comment 3 Beniamino Galvani 2017-07-21 12:21:10 UTC 
Created attachment 1302340 [details]
[PATCH] device: bond: don't set the permanent hardware address

A possible fix.

Alternatively, we could add a new configuration snippet to change the ethernet.cloned-mac-address default value to 'preserve' for bonds.
Comment 4 Edward Haas 2017-07-23 12:46:25 UTC 
(In reply to Beniamino Galvani from comment #2)
> 
> A solution to this would be to ignore for bonds the cloned-mac-address
> property when it's set to 'permanent' because it doesn't make much
> sense to enforce a permanent address that's actually random. We could

I'm not clear if this also means that customizing the mac address is no longer possible. If the user wants to enforce a customer mac address that is not one of its slaves, will he be able to do it?
Comment 5 Beniamino Galvani 2017-07-24 07:36:25 UTC 
(In reply to Edward Haas from comment #4)
> (In reply to Beniamino Galvani from comment #2)
> > 
> > A solution to this would be to ignore for bonds the cloned-mac-address
> > property when it's set to 'permanent' because it doesn't make much
> > sense to enforce a permanent address that's actually random. We could
> 
> I'm not clear if this also means that customizing the mac address is no
> longer possible.

Customizing the mac is still possible by setting a mac in the ethernet.cloned-mac-address property. The patch only changes the meaning of the 'permanent' special value for bonds.

> If the user wants to enforce a customer mac address that is
> not one of its slaves, will he be able to do it?

Yes.
Comment 6 Beniamino Galvani 2017-07-25 21:20:28 UTC 
Created attachment 1304473 [details]
[PATCH v2] device: don't set a fake permanent hardware address
Comment 7 Thomas Haller 2017-07-26 06:47:13 UTC 
(In reply to Beniamino Galvani from comment #6)
> Created attachment 1304473 [details]
> [PATCH v2] device: don't set a fake permanent hardware address

lgtm
Comment 8 Beniamino Galvani 2017-07-26 12:13:22 UTC 
Applied to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2f4dfd0f2e8f85dd86f5abfbeaafd7cb04655525

and nm-1-8:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-8&id=c8d0a0fcf7b8368b9fbe19f4fb2327349dcc5eba
Comment 13 sushil kulkarni 2017-08-09 16:01:21 UTC 
Hi Dan,

Could you please add a note in here to support addition of this to the Z stream? PM can review and approve this bug..

Thanks!
Sushil
Comment 14 Dan Kenigsberg 2017-08-09 17:13:41 UTC 
In RHV hypervisors, we would like to let users configure a bonding device via cockpit, and have this bonding have a stable MAC address (and hence a stable dhcp-provided IP address) when the bonding device is acquired by RHV.

RHV-3 users had this ability, but since we moved to cockpit and NM in RHV-4, current users cannot - with this bug as the current blocker. Please backport to 7.4.z, so we can enable this feature in RHV-4.1.5.
Comment 15 sushil kulkarni 2017-08-31 19:29:13 UTC 
Dan/Yaniv,

Can you clone this defect for a z stream bug, so that Beniamino can add it in?

Thanks!
Sushil
Comment 16 Dan Kenigsberg 2017-08-31 19:57:31 UTC 
I have no cloning powers on rhel bugs. I think that a rhel program manager should do that.
Comment 17 sushil kulkarni 2017-08-31 20:09:15 UTC 
Thanks Dan.. Anita, can you please clone this bug for inclusion in the z-stream.

-Sushil
Comment 18 Anita Tragler 2017-09-01 14:37:56 UTC 
Z-stream ack needs to come from RHEL PM not Network subsystem PM as I understand

once RHEL 7.4.z + has been provided the Program manager (Teodor) will need to clone BZ and set flags for z-stream
Comment 24 Dan Kenigsberg 2017-09-26 18:11:02 UTC 
Michael, would you be kind to assist in verification (of the RHV use case)?
Comment 25 Michael Burman 2017-09-27 05:11:57 UTC 
(In reply to Dan Kenigsberg from comment #24)
> Michael, would you be kind to assist in verification (of the RHV use case)?

Hi Dan, 
See comment10#, i have verified RHV use case(made sure it fixes our issue) and i will do it again when we will have a formal builds with:
1) NetwrokManger available with this fix. The QA currently still using NetworkManager-1.8.0-9.el7.x86_64

2) RHV-H build with this NetworkManager

Once we will get the builds, i will run my tests again to make sure we covered.
Comment 26 Dan Kenigsberg 2017-09-27 09:56:27 UTC 
sorry, Burman, wrong bug. I intended to ask your help with the 7.4.z clone bug 1490741 and the NetworkManager-1.8.0-10.el7_4 in it.
Comment 27 Beniamino Galvani 2017-10-06 13:35:02 UTC 
*** Bug 1488715 has been marked as a duplicate of this bug. ***
Comment 28 Vladimir Benes 2017-12-05 09:11:36 UTC 
bond_mac_reconnect_preserve test is running on daily bases.
Comment 29 Michael Burman 2017-12-05 11:37:50 UTC 
I can also confirm that RHV use cases which were affected by this bug are verified.
Comment 32 errata-xmlrpc 2018-04-10 13:27:23 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0778
Note You need to log in before you can comment on or make changes to this bug.