Bug 2055273

Summary: ovs bridge port ip lose after use ovs-vsctl set hwaddr
Product: Red Hat Enterprise Linux Fast Datapath Reporter: mhou <mhou>
Component: openvswitch2.15Assignee: Timothy Redaelli <tredaelli>
Status: CLOSED NOTABUG QA Contact: mhou <mhou>
Severity: medium Docs Contact:
Priority: unspecified    
Version: FDP 22.ACC: ctrautma, fleitner, jhsiao, mhou, ralongi, tredaelli
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-04 01:08:39 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:

Description mhou 2022-02-16 14:52:41 UTC
Description of problem:
create a ovs bridge and use IP command to configure an IP address for this bridge port. After changing hwaddr, the IP of the bridge port is lost.

Version-Release number of selected component (if applicable):
kernel version: 4.18.0-363.rt7.148.el8.x86_64

openvswitch version:
openvswitch2.15-2.15.0-57.el8fdp.x86_64
openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch
openvswitch2.15-test-2.15.0-57.el8fdp.noarch

How reproducible: 100%


Steps to Reproduce:
1. create a ovs bridge port
# systemctl start openvswitch
# ovs-vsctl --may-exist add-br ovsbr1 -- set bridge ovsbr1 datapath_type=netdev
2. configure a ip address to this port.
# nmcli dev set ovsbr1 managed no
# ip link set ovsbr1 up
# ip addr add 10.0.100.1/24 dev ovsbr1
3. change the hwaddr on this port
# ovs-vsctl set Bridge ovsbr1 other-config:hwaddr=90:e2:ba:cb:ab:28

Actual results:
Befor configure hwaddr check the ovsbr1 ip address as below:
67: ovsbr1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 82:6d:f0:a2:a4:4f brd ff:ff:ff:ff:ff:ff
    inet 10.0.100.1/24 scope global ovsbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::806d:f0ff:fea2:a44f/64 scope link 
       valid_lft forever preferred_lft forever

after configuring hwaddr and using ip command check the interface. The IP address was lost. 
67: ovsbr1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 90:e2:ba:cb:ab:28 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::92e2:baff:fecb:ab28/64 scope link 
       valid_lft forever preferred_lft forever

Expected results:
The IP command should exist on the test port.

Additional info:
I also try to use stock kernel(4.18.0-364.el8.x86_64), after setting hwaddr, the ip still exists on the test port.

Comment 1 Flavio Leitner 2023-06-14 19:23:14 UTC
Hi Timothy, can you please check if 2.17 or 3.1 needs a fix?

Comment 2 mhou 2023-06-15 02:52:01 UTC
run same test on 5.14.0-318.el9.x86_64 + openvswitch3.1-3.1.0-24.el9fdp.x86_64 and didn't hit this issue.



[root@hp-dl388g10-03 ovs_bond_function]# ovs-vsctl --may-exist add-br ovsbr1 -- set bridge ovsbr1 datapath_type=netdev
[root@hp-dl388g10-03 ovs_bond_function]# nmcli dev set ovsbr1 managed no
[root@hp-dl388g10-03 ovs_bond_function]# ip link set ovsbr1 up
[root@hp-dl388g10-03 ovs_bond_function]# ip addr add 10.0.100.1/24 dev ovsbr1
[root@hp-dl388g10-03 ovs_bond_function]# ip addr show ovsbr1
2802: ovsbr1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether aa:b3:0a:1b:39:4f brd ff:ff:ff:ff:ff:ff
    inet 10.0.100.1/24 scope global ovsbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::a8b3:aff:fe1b:394f/64 scope link 
       valid_lft forever preferred_lft forever
[root@hp-dl388g10-03 ovs_bond_function]# ovs-vsctl set Bridge ovsbr1 other-config:hwaddr=90:e2:ba:cb:ab:28
[root@hp-dl388g10-03 ovs_bond_function]# ip addr show ovsbr1
2802: ovsbr1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 90:e2:ba:cb:ab:28 brd ff:ff:ff:ff:ff:ff
    inet 10.0.100.1/24 scope global ovsbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::92e2:baff:fecb:ab28/64 scope link tentative 
       valid_lft forever preferred_lft forever

Comment 3 Timothy Redaelli 2023-07-03 16:32:21 UTC
I tested with openvswitch2.17-2.17.0-52.el9fdp.x86_64 and I have the problem (if I use netdev datapath, with kernel DP it works correctly)

Comment 4 Timothy Redaelli 2023-07-03 17:05:22 UTC
I enabled debug logs of NetworkManager and it seems the problem is of Network Manager itself...
If I stop NetworkManager before doing this test, the test pass without any problem (also with 2.17) and in logs I see:

Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3746] device[41cb56a2348c9b03] (ovsbr1): hw-addr: hardware address now 90:E2:BA:CB:AB:28
Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3747] device[41cb56a2348c9b03] (ovsbr1): hw-addr: update initial MAC address 90:E2:BA:CB:AB:28
Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3747] manager: (ovsbr1): assume: don't assume because not managed
Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3747] platform: (ovsbr1) address: deleting IPv4 address 10.0.100.1/24,  dev ovsbr1
Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3748] platform: (ovsbr1) signal: address 4 removed: 10.0.100.1/24 brd 0.0.0.0 lft forever pref forever lifetime 4-0[4294967295,4294967295] dev 25 flags permanent src kernel
Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3748] platform: (ovsbr1) signal: route   4 removed: type unicast 10.0.100.0/24 dev 25 metric 0 mss 0 rt-src rt-kernel scope link pref-src 10.0.100.1
Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3749] platform: (ovsbr1) signal: route   4 removed: type local table 255 10.0.100.1/32 dev 25 metric 0 mss 0 rt-src rt-kernel scope host pref-src 10.0.100.1
Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3750] platform: (ovsbr1) ip6-route: delete type unicast fe80::/64 dev 25 metric 256 mss 0 rt-src rt-kernel
Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3751] platform: (ovsbr1) signal: route   6 removed: type unicast fe80::/64 dev 25 metric 256 mss 0 rt-src rt-kernel
Jul 03 12:54:00 NetworkManager[52889]: <debug> [1688403240.3752] manager: (ovsbr1): assume: don't assume because not managed
Jul 03 12:54:01 NetworkManager[52889]: <debug> [1688403241.9795] platform: (ovsbr1) signal: address 6   added: fe80::92e2:baff:fecb:ab28/64 lft forever pref forever lifetime 5-0[4294967295,4294967295] dev 25 flags permanent src kernel
Jul 03 12:54:01 NetworkManager[52889]: <debug> [1688403241.9796] platform: (ovsbr1) signal: route   6   added: type local table 255 fe80::92e2:baff:fecb:ab28/128 dev 25 metric 0 mss 0 rt-src rt-kernel
Jul 03 12:54:01 NetworkManager[52889]: <debug> [1688403241.9798] manager: (ovsbr1): assume: don't assume because not managed

Comment 5 mhou 2023-07-04 01:08:39 UTC
Hello Timothy

Since this issue introduce by NetworkManager, I will close this bug.