Bug 1472965
| Summary: | Upping an already up bond connection will change the bond MAC | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Francesco Giudici <fgiudici> | ||||||||
| Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 7.4 | CC: | atragler, bgalvani, danken, edwardh, fgiudici, igkioka, lrintel, mburman, rkhan, salmy, snagar, sukulkar, thaller, vbenes, vkavtikw | ||||||||
| Target Milestone: | rc | Keywords: | ZStream | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| 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.
|
Story Points: | --- | ||||||||
| Clone Of: | |||||||||||
| : | 1490741 (view as bug list) | Environment: | |||||||||
| Last Closed: | 2018-04-10 13:27:23 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 1443347, 1444109, 1463218, 1490741 | ||||||||||
| Attachments: |
|
||||||||||
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. 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.
(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? (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. Created attachment 1304473 [details]
[PATCH v2] device: don't set a fake permanent hardware address
(In reply to Beniamino Galvani from comment #6) > Created attachment 1304473 [details] > [PATCH v2] device: don't set a fake permanent hardware address lgtm 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 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 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. Dan/Yaniv, Can you clone this defect for a z stream bug, so that Beniamino can add it in? Thanks! Sushil I have no cloning powers on rhel bugs. I think that a rhel program manager should do that. Thanks Dan.. Anita, can you please clone this bug for inclusion in the z-stream. -Sushil 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 Michael, would you be kind to assist in verification (of the RHV use case)? (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. 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. *** Bug 1488715 has been marked as a duplicate of this bug. *** bond_mac_reconnect_preserve test is running on daily bases. I can also confirm that RHV use cases which were affected by this bug are verified. 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 |
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