Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.

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.