Bug 1899745

Beniamino, we discussed this in the past when you were helping me with the NetworkManager-OVS bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1853750#c3

Any ideas on fixing this in NM to use the bridge cloned mac?

Hi, which (In reply to Dan Winship from comment #0)
> Bug 1852106 fixed MAC address cloning + DHCP on OVS bridge interfaces, but
> in a way that ends up causing spurious errors in the OVS logs:
> 
>   2020-11-17T12:20:50.895Z|00033|bridge|ERR|interface br-ex: ignoring mac in
> Interface record (use Bridge record to set local port's mac)
> 
> OVS wants us to set the MAC on the Bridge record, but NOT on the Interface
> record for the local port; NM is now setting it on both.

Usually, if you set the cloned-mac-address in a OVS bridge or
interface connection, NM sets an hwaddr value in the matching ovsdb
table (Bridge or Interface).

However, if an OVS interface is local (i.e. it has the same name as
the bridge) OVS considers it special and wants the address configured
on the Bridge table, otherwise it complains with the errors you see in
logs.

Therefore, NM treats the cloned-mac-address specially for local
interfaces. When the property is set only on the interface or only on
the bridge, NM sets the mac in the Bridge table. If it's set in both
connections, NM sets each MAC in the matching table (Bridge and
Interface).

>   $ nmcli c add type ovs-bridge conn.interface br-ex con-name br-ex
> 802-3-ethernet.cloned-mac-address 12:34:56:78:9a:bc
>   $ nmcli c add type ovs-port conn.interface enp0s31f6 master br-ex con-name
> ovs-port-phys0
>   $ nmcli c add type ovs-port conn.interface br-ex master br-ex con-name
> ovs-port-br-ex
>   $ nmcli c add type 802-3-ethernet conn.interface enp0s31f6 master
> ovs-port-phys0 con-name ovs-if-phys0
>   $ nmcli c up ovs-if-phys0
>   $ nmcli c add type ovs-interface slave-type ovs-port conn.interface br-ex
> master ovs-port-br-ex con-name ovs-if-br-ex
> 802-3-ethernet.cloned-mac-address 12:34:56:78:9a:bc

Here NM sets the bridge MAC in the Bridge table and the interface MAC
in the Interface table, leading to errors in OVS logs.

But NM could be smarter and notice that the MAC addresses in the two
connections are the same, and could deduce that the user just wants to
set that address in the Bridge table. I will post a patch for that.

If the two addresses are different, it's not clear what the user wants
and probably it's fine to keep the current behavior.

> If you remove the "802-3-ethernet.cloned-mac-address 12:34:56:78:9a:bc" from
> the last line you won't get the errors in the OVS logs but apparently you no
> longer get the right MAC address in DHCP requests either.

Yes, that's because of the race condition of bug 1852106. Even if NM
tells OVS to create the interface with a given hardware address, OVS
first creates the kernel link and only later updates its address. The
fix for 1852106 was to also change the MAC of the interface via
netlink before starting IP configuration. However this works only when
the cloned address is set on the ovs-interface connection.

> (The bug is just that we get spurious errors, but those errors have already
> caused a bunch of confusion, where something is not working and then as soon
> as people see those error messages they assume that's what's wrong and stop
> investigating further.)

Did you try setting the cloned-mac-address only on the OVS interface?
That should avoid the error in logs and also the race condition,
assuming that you have NM >= 1.22.8-6.

Hi Dan,

Any feedback base on the comment of Beniamino above?

Thank you!

I'm not looking at this issue currently and I forget what Tim and I had decided about where the problem was.

(Tim, if you don't think this bz is useful any more feel free to close it.)

I'll try it out on OCP and see what I find.

I was able to test this out on a libvirt deployment. I tried:

while ./configure-ovs.sh OpenShiftSDN && sleep 5 && ./configure-ovs.sh OVNKubernetes && ip a show br-ex | grep 192.168.126.11 && ovs-vsctl list bridge br-ex |grep hwaddr=\"52:54:00:7E:3B:1F\"; do echo "good"; done

Ran that tons of times, never had a failure.

I then tried on reboot a handful of times, since that is where I have seen this race condition in the past. Seemed fine. I think we can go ahead and remove the cloned mac on the bridge, in at least 4.8, and probably close this bug as fixed.

The version of NM I was testing with was:
[root@test1-rgxt8-master-0 ~]# rpm -qa | grep Network
NetworkManager-ovs-1.26.0-13.1.rhaos4.7.el8.x86_64
NetworkManager-1.26.0-13.1.rhaos4.7.el8.x86_64
NetworkManager-cloud-setup-1.26.0-13.1.rhaos4.7.el8.x86_64
NetworkManager-team-1.26.0-13.1.rhaos4.7.el8.x86_64
NetworkManager-libnm-1.26.0-13.1.rhaos4.7.el8.x86_64
NetworkManager-tui-1.26.0-13.1.rhaos4.7.el8.x86_64

That helps a lot. Thank you.

Thanks Tim.

The customer is using OpenShiftSDN, not OVNKubernetes, so I filed it against NetworkManager for now: https://bugzilla.redhat.com/show_bug.cgi?id=1952229

Hi David,

Above bug comment shows issue been fixed. Any other issue should this bug be tracking?

Thank you!

Hi Gris,

Not that I know of.

*** This bug has been marked as a duplicate of bug 1952229 ***