Bug 1740557
Summary: | MAC address issue with an OvS bridge | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Denis Ollier <dollierp> | |
Component: | NetworkManager | Assignee: | sushil kulkarni <sukulkar> | |
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | |
Severity: | medium | Docs Contact: | ||
Priority: | high | |||
Version: | 7.7 | CC: | alkaplan, atragler, bgalvani, danken, dcritch, fdeutsch, fgiudici, ibezukh, jreznik, lmiksik, lrintel, michael.hanulec, pasik, rkhan, sukulkar, thaller, vbenes | |
Target Milestone: | rc | Keywords: | Reopened, ZStream | |
Target Release: | 7.6 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | NetworkManager-1.18.4-3.el7 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1791672 1791674 (view as bug list) | Environment: | ||
Last Closed: | 2020-03-31 20:07:59 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: | 1791672, 1791674 |
Description
Denis Ollier
2019-08-13 09:11:32 UTC
could you provide level=TRACE logs of NetworkManager (or just the entire boot process, no need to pre-filter the available information). See https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 for hints about logging. See also the comment about journald's rate-limiting, and please disable that first before gathering logs. Thank you!! I tried to gather more logs it last week but I couldn't reproduce this bug on my env anymore. Closing this ticket for now. I will reopen it with more logs if the issue comes back. Hi, I could reproduce the issue again today. Please find attached the systemd journal with NetworkManager full logs. Version of components used: NetworkManager-1.18.0-5.el7_7.1.x86_64 NetworkManager-ovs-1.18.0-5.el7_7.1.x86_64 openvswitch-2.9.0-117.el7fdp.x86_64 Thanks. See also bug 1763734. Appears broken in our openshift 3.11 + rhel7v6 environment too Please fix > # make bridge > nmcli conn add type ovs-bridge conn.interface brcnv > nmcli conn add type ovs-port conn.interface port0 master brcnv > nmcli conn add type ovs-port conn.interface brcnv-port master brcnv > nmcli conn add type ovs-interface conn.id brcnv-iface conn.interface brcnv master brcnv-port ipv4.method auto 802-3-ethernet.cloned-mac-address $mac connection.autoconnect no Changing the MAC address is not implemented at the moment. This is the upstream merge request to add it: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/321 Note that since the OVS interface has the same name of the OVS bridge, it is considered by ovs as the local interface and so it inherits the MAC from the bridge. Thus, if the MR is merged as is, it will be necessary to set the cloned-mac-address on the ovs-bridge connection, not on the ovs-interface. > - 1st reboot => wrong lease with MAC address 4e:b7:2e:a8:9d:4d > - 2nd reboot => good lease > - 3rd reboot => wrong lease with MAC address 36:ff:da:be:e0:4b Are you saying that sometimes the MAC address of the ovs-interface is the expected one? If so, do you have logs for that boot? (In reply to Beniamino Galvani from comment #9) > Are you saying that sometimes the MAC address of the ovs-interface is the > expected one? If so, do you have logs for that boot? It seems so: - Wrong lease: NetworkManager[2219]: <debug> [1571910231.7349] device[0x55bff90390d0] (brcnv): hw-addr: hardware address now BE:DB:42:18:2C:47 NetworkManager[2219]: <debug> [1571910231.7349] device[0x55bff90390d0] (brcnv): hw-addr: update initial MAC address BE:DB:42:18:2C:47 NetworkManager[2219]: <debug> [1571910231.7462] device[0x55bff90390d0] (brcnv): hw-addr: unable to read permanent MAC address (use current: BE:DB:42:18:2C:47) NetworkManager[2219]: <debug> [1571910231.7973] device[0x55bff90390d0] (brcnv): hw-addr: hardware address now 00:10:9B:35:88:B0 - Good lease: NetworkManager[2528]: <debug> [1571998564.2603] device[0x555c732717b0] (brcnv): hw-addr: hardware address now 00:10:9B:35:88:B0 NetworkManager[2528]: <debug> [1571998564.2603] device[0x555c732717b0] (brcnv): hw-addr: update initial MAC address 00:10:9B:35:88:B0 NetworkManager[2528]: <debug> [1571998564.2663] device[0x555c732717b0] (brcnv): hw-addr: unable to read permanent MAC address (use current: 00:10:9B:35:88:B0) See full logs in attached file for wrong and good leases. Great, thanks Ben! Denis, the repo has been updated. Hi, NM does not have any special handling of cloned macs, it just sets the cloned-mac from the ovs-bridge connection into the Bridge table of ovs, and the cloned-mac from the ovs-interface connection into the Interface ovs table. Since the ovs-bridge and the ovs-interface have the same name, ovs treats the ovs-interface as the 'local interface' and as such, it inherits the MAC from the bridge. See the 'ovs-vswitchd.conf.db' man page for more details on how mac addresses are assigned by ovs. In other words, you should set the cloned mac address on the bridge itself: nmcli conn add type ovs-bridge conn.interface brcnv 802-3-ethernet.cloned-mac-address $mac and it will be inherited by the ovs-interface. Asking blocker flag for reasons stated in comment 34. two tests added: 1. bridge and iface named the same and cloned mac assigned to bridge 2. bridge and iface named differently and cloned mac assigned to iface Restoring needinfo? deleted by mistake in comment 44. Hi Anita, Can you please provide z stream+ for this? Thanks! Sushil Hi Alona, this is the official 7.6.z build that includes the fix: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1059407 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-2020:1162 |