Bug 2096413
| Summary: | br-ex not created due to default bond interface having a different mac address than expected | ||||||
|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | tonyg | ||||
| Component: | Networking | Assignee: | Jaime Caamaño Ruiz <jcaamano> | ||||
| Networking sub component: | ovn-kubernetes | QA Contact: | Ross Brattain <rbrattai> | ||||
| Status: | CLOSED ERRATA | Docs Contact: | |||||
| Severity: | high | ||||||
| Priority: | urgent | CC: | ffernand, jcaamano, josearod, manrodri, opayne, pblanc, raperez, rbrattai, trozet, yprokule | ||||
| Version: | 4.10 | Keywords: | FastFix | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 4.12.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
* Previously, `ovn-kubernetes` did not configure the correct mac address of bond interfaces in `br-ex` bridge. As a result, a node that uses bonding for the primary Kubernetes interface fails to join the cluster. With this update, `ovn-kubernetes` configures the correct mac address of bond interfaces in `br-ex` bridge, and nodes that use bonding for the primary Kubernetes interface successfully join the cluster. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2096413[*BZ2096413*]
|
Story Points: | --- | ||||
| Clone Of: | |||||||
| : | 2098626 (view as bug list) | Environment: | |||||
| Last Closed: | 2022-08-10 11:17:47 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: | 2103080 | ||||||
| Attachments: |
|
||||||
|
Description
tonyg
2022-06-13 18:42:09 UTC
Looking into ovs-configuration_172.22.1.252.log configure-ovs initially configures the network correctly. Then there is a reboot. On reboot, configure-ovs tries to remove the configuration that it has previously done to build it and apply it again, as expected. For that, it removes the profiles it previously created from the filesystem, does a `nmcli connection reload` and waits for the device that it previously managed (in this case bond0) to be activated with whatever pre-existing network configuration was on the node, before proceeding. At this stage, bond0 device never gets its IP configuration after 60 secs, and remains in state "connecting (getting IP configuration)" The profiles activating bond0 and its slaves are the expected ones and the same ones that did configure the network correctly before configure-ovs did anything: Jun 13 17:00:32 localhost configure-ovs.sh[7624]: bond0:bond:connecting (getting IP configuration):none:none:/org/freedesktop/NetworkManager/Devices/20:bond0:75ac1a13-dbce-36e4-8ecb-c6ed6fce5322:/org/freedesktop/NetworkManager/ActiveConnection/20 Jun 13 17:00:32 localhost configure-ovs.sh[7624]: ens1f0:ethernet:connected:limited:limited:/org/freedesktop/NetworkManager/Devices/11:ens1f0:22f4a3bf-b99a-38ae-91a8-17796391e6aa:/org/freedesktop/NetworkManager/ActiveConnection/22 Jun 13 17:00:32 localhost configure-ovs.sh[7624]: ens1f1:ethernet:connected:limited:limited:/org/freedesktop/NetworkManager/Devices/12:ens1f1:1ffa4bbd-a16e-3ee8-8cde-582cd94ea8be:/org/freedesktop/NetworkManager/ActiveConnection/21 Somehow, dhcp does not resolve for bond0 and this is the last log from NM in that regard: Jun 13 16:59:25 localhost NetworkManager[4726]: <info> [1655139565.9936] dhcp4 (bond0): activation: beginning transaction (no timeout) I do notice that the mac address of bond0 changed during this process, from b8:83:03:91:c5:c8 when it worked, to b8:83:03:91:c5:c9 when it didn't. I guess these mac addresses correspond to the slave nics. In any case, configure-ovs is behaving as expected. @tonyg - is there any static assignment on the dhcp server done by mac? If so, does consider both slave nic mac addresses as any of them could be assigned to the bond? Or should bond0 profile be configured with `cloned-mac-address=b8:83:03:91:c5:c8`? - otherwise, can you provide both dhcp server logs, and NM debug logs? Jaime,
Thank you for the information, to answer your question yes we have static assignment for each MAC, and we did not consider having both mac addresses in the DHCP configuration. We are using dnsmasq and this was the setup for a cluster:
dhcp-host=b8:83:03:91:c5:f8,192.168.12.11,master-0.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:92:c0:40,192.168.12.12,master-1.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:91:c5:34,192.168.12.13,master-2.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:8e:1e:10,192.168.12.20,worker-0.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:91:c5:20,192.168.12.21,worker-1.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:8e:0e:dc,192.168.12.22,worker-2.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:92:c0:48,192.168.12.23,worker-3.cluster1.dfwt5g.lab
I made a test in another cluster, and confirmed you findings. So then I updated the DHCP config to include both MAC addresses :
dhcp-host=b8:83:03:91:c5:f8,b8:83:03:91:c5:f9,192.168.12.11,master-0.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:92:c0:40,b8:83:03:92:c0:41,192.168.12.12,master-1.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:91:c5:34,b8:83:03:91:c5:35,192.168.12.13,master-2.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:8e:1e:10,b8:83:03:8e:1e:11,192.168.12.20,worker-0.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:91:c5:20,b8:83:03:91:c5:21,192.168.12.21,worker-1.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:8e:0e:dc,b8:83:03:8e:0e:dd,192.168.12.22,worker-2.cluster1.dfwt5g.lab
dhcp-host=b8:83:03:92:c0:48,b8:83:03:92:c0:49,192.168.12.23,worker-3.cluster1.dfwt5g.lab
Then I rebooted the nodes, they are accessible after the reboot, baremetal IP assigned, but we observed that the bond0 has the MAC of the second slave interface and br-ex the MAC of the first slave interface. Is this expected? Do you see any problem with that?
[kni.dfwt5g.lab ~]$ for x in {0..3} ; do echo "===== worker-$x =====" ; ssh core@master-$x "ip a s bond0" 2>/dev/null ; done
===== worker-0 =====
15: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:91:c5:f9 brd ff:ff:ff:ff:ff:ff
===== worker-1 =====
15: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:92:c0:41 brd ff:ff:ff:ff:ff:ff
===== worker-2 =====
15: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:91:c5:35 brd ff:ff:ff:ff:ff:ff
===== worker-3 =====
[kni.dfwt5g.lab ~]$ for x in {0..3} ; do echo "===== worker-$x =====" ; ssh core@master-$x "ip a s br-ex" 2>/dev/null ; done
===== worker-0 =====
19: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:91:c5:f8 brd ff:ff:ff:ff:ff:ff
inet 192.168.12.11/24 brd 192.168.12.255 scope global dynamic noprefixroute br-ex
valid_lft 3911sec preferred_lft 3911sec
inet6 fe80::ba83:3ff:fe91:c5f8/64 scope link noprefixroute
valid_lft forever preferred_lft forever
===== worker-1 =====
19: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:92:c0:40 brd ff:ff:ff:ff:ff:ff
inet 192.168.12.12/24 brd 192.168.12.255 scope global dynamic noprefixroute br-ex
valid_lft 7130sec preferred_lft 7130sec
inet6 fe80::ba83:3ff:fe92:c040/64 scope link noprefixroute
valid_lft forever preferred_lft forever
===== worker-2 =====
19: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:91:c5:34 brd ff:ff:ff:ff:ff:ff
inet 192.168.12.13/24 brd 192.168.12.255 scope global dynamic noprefixroute br-ex
valid_lft 7190sec preferred_lft 7190sec
inet 192.168.12.16/32 scope global br-ex
valid_lft forever preferred_lft forever
inet6 fe80::ba83:3ff:fe91:c534/64 scope link noprefixroute
valid_lft forever preferred_lft forever
===== worker-3 =====
I'm running a full deployment again with this setup in case you want us to attach logs.
I redeployed the cluster using OCP 4.10.17, and I see it's not all the nodes that happens the behavior above, (also my echo command above was not showing the right server names, apologies about that), the deployment was completed successfully, only workers get rebooted after applying the PAO profile, we can see mostly the master nodes differ from MAC between bond0 and br-ex, workers most of them match the same MAC except one worker (worker-2)
[kni.dfwt5g.lab ~]$ for x in {0..2} ; do echo "===== master-$x =====" ; ssh core@master-$x "ip a s br-ex | grep -B1 ether ; ip a s bond0" 2>/dev/null ; done
===== master-0 =====
19: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:91:c5:f8 brd ff:ff:ff:ff:ff:ff
15: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:91:c5:f9 brd ff:ff:ff:ff:ff:ff
===== master-1 =====
19: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:92:c0:40 brd ff:ff:ff:ff:ff:ff
15: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:92:c0:41 brd ff:ff:ff:ff:ff:ff
===== master-2 =====
19: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:91:c5:34 brd ff:ff:ff:ff:ff:ff
15: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:91:c5:35 brd ff:ff:ff:ff:ff:ff
[kni.dfwt5g.lab ~]$ for x in {0..3} ; do echo "===== worker-$x =====" ; ssh core@worker-$x "ip a s br-ex | grep -B1 ether ; ip a s bond0" 2>/dev/null ; done
===== worker-0 =====
27: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:8e:1e:11 brd ff:ff:ff:ff:ff:ff
25: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:8e:1e:11 brd ff:ff:ff:ff:ff:ff
===== worker-1 =====
27: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:91:c5:21 brd ff:ff:ff:ff:ff:ff
25: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:91:c5:21 brd ff:ff:ff:ff:ff:ff
===== worker-2 =====
27: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:8e:0e:dd brd ff:ff:ff:ff:ff:ff
25: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:8e:0e:dc brd ff:ff:ff:ff:ff:ff
===== worker-3 =====
27: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether b8:83:03:92:c0:49 brd ff:ff:ff:ff:ff:ff
25: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue master ovs-system state UP group default qlen 1000
link/ether b8:83:03:92:c0:49 brd ff:ff:ff:ff:ff:ff
I'm redeploying using 4.10.18 to see if the results are consistent.
FYI, both bond0 slaves and bond0 use autoconnect-priority=99
*** Bug 2092129 has been marked as a duplicate of this bug. ***
Tested with fail_over_mac=1 on libvirt IPI
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[2100]: ++ nmcli --get-values bond.options conn show a661c652-5ada-3efd-9deb-f73f9d08a896
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[1965]: + bond_opts=mode=active-backup,fail_over_mac=1,miimon=100
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[1965]: + '[' -n mode=active-backup,fail_over_mac=1,miimon=100 ']'
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[1965]: + extra_phys_args+=(bond.options "${bond_opts}")
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[1965]: + MODE_REGEX='(^|,)mode=active-backup(,|$)'
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[1965]: + MAC_REGEX='(^|,)fail_over_mac=(1|active|2|follow)(,|$)'
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[1965]: + [[ mode=active-backup,fail_over_mac=1,miimon=100 =~ (^|,)mode=active-backup(,|$) ]]
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[1965]: + [[ mode=active-backup,fail_over_mac=1,miimon=100 =~ (^|,)fail_over_mac=(1|active|2|follow)(,|$) ]]
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[1965]: + clone_mac=0
Jun 27 14:20:00 master-0-0.qe.lab.redhat.com configure-ovs.sh[1965]: + '[' '!' 0 = 0 ']'
MAC changes after disconnecting primary slave link.
3: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc fq_codel master bond0 state DOWN mode DEFAULT group default qlen 1000\ link/ether 52:54:00:b8:80:b8 brd ff:ff:ff:ff:ff:ff
4: enp6s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000\ link/ether 52:54:00:f9:a6:75 brd ff:ff:ff:ff:ff:ff
11: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP mode DEFAULT group default qlen 1000\ link/ether 52:54:00:f9:a6:75 brd ff:ff:ff:ff:ff:ff
12: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether 52:54:00:b8:80:b8 brd ff:ff:ff:ff:ff:ff
RHEL 8 vSphere DHCP fail_over_mac=0 slaves have the same MAC. bond0 MAC does not change after disconnecting primary slave 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens192: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN mode DEFAULT group default qlen 1000\ link/ether 00:50:56:ac:c4:28 brd ff:ff:ff:ff:ff:ff 3: ens224: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000\ link/ether 00:50:56:ac:c4:28 brd ff:ff:ff:ff:ff:ff permaddr 00:50:56:ac:4f:59 4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\ link/ether b2:e5:ad:9f:40:23 brd ff:ff:ff:ff:ff:ff 5: genev_sys_6081: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65000 qdisc noqueue master ovs-system state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether 72:b2:77:c5:fa:30 brd ff:ff:ff:ff:ff:ff 6: ovn-k8s-mp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether 5e:76:3e:aa:50:98 brd ff:ff:ff:ff:ff:ff 7: br-int: <BROADCAST,MULTICAST> mtu 1400 qdisc noop state DOWN mode DEFAULT group default qlen 1000\ link/ether 72:11:f6:47:1c:20 brd ff:ff:ff:ff:ff:ff 10: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP mode DEFAULT group default qlen 1000\ link/ether 00:50:56:ac:c4:28 brd ff:ff:ff:ff:ff:ff 11: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether 00:50:56:ac:c4:28 brd ff:ff:ff:ff:ff:ff RHCOS UPI vSphere static-ip fail_over_mac=0 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens192: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN mode DEFAULT group default qlen 1000\ link/ether 00:50:56:ac:04:8f brd ff:ff:ff:ff:ff:ff 3: ens224: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000\ link/ether 00:50:56:ac:04:8f brd ff:ff:ff:ff:ff:ff permaddr 00:50:56:ac:41:cd 4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\ link/ether 7e:e6:ed:fa:10:5c brd ff:ff:ff:ff:ff:ff 5: genev_sys_6081: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65000 qdisc noqueue master ovs-system state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether ee:11:ba:56:ca:40 brd ff:ff:ff:ff:ff:ff 6: ovn-k8s-mp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether f6:a2:c2:c4:fb:f4 brd ff:ff:ff:ff:ff:ff 7: br-int: <BROADCAST,MULTICAST> mtu 1400 qdisc noop state DOWN mode DEFAULT group default qlen 1000\ link/ether 86:2f:27:81:0f:20 brd ff:ff:ff:ff:ff:ff 10: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP mode DEFAULT group default qlen 1000\ link/ether 00:50:56:ac:04:8f brd ff:ff:ff:ff:ff:ff 11: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether 00:50:56:ac:04:8f brd ff:ff:ff:ff:ff:ff [ RHCOS libvirt IPI DHCP fail_over_mac=0 bond0,br-ex works after primary slave is disconnected. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 3: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc fq_codel master bond0 state DOWN mode DEFAULT group default qlen 1000\ link/ether 52:54:00:9b:66:d0 brd ff:ff:ff:ff:ff:ff 4: enp6s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000\ link/ether 52:54:00:9b:66:d0 brd ff:ff:ff:ff:ff:ff permaddr 52:54:00:59:28:45 5: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\ link/ether f6:a3:26:98:3d:e6 brd ff:ff:ff:ff:ff:ff 6: genev_sys_6081: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65000 qdisc noqueue master ovs-system state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether ca:fe:4b:2a:a5:78 brd ff:ff:ff:ff:ff:ff 7: ovn-k8s-mp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether 16:cc:80:a7:b4:6d brd ff:ff:ff:ff:ff:ff 8: br-int: <BROADCAST,MULTICAST> mtu 1400 qdisc noop state DOWN mode DEFAULT group default qlen 1000\ link/ether da:59:37:b1:5c:af brd ff:ff:ff:ff:ff:ff 11: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP mode DEFAULT group default qlen 1000\ link/ether 52:54:00:9b:66:d0 brd ff:ff:ff:ff:ff:ff 12: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/ether 52:54:00:9b:66:d0 brd ff:ff:ff:ff:ff:ff 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 (Important: OpenShift Container Platform 4.11.0 bug fix and security update), 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/RHSA-2022:5069 |