netdev - [PATCH net-next v1 0/1] bonding: Adding limited support for ARP monitoring with ovs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250411174906.21022-1-wilder@us.ibm.com>
Date: Fri, 11 Apr 2025 10:48:14 -0700
From: David J Wilder <wilder@...ibm.com>
To: netdev@...r.kernel.org
Cc: jv@...sburgh.net, wilder@...ibm.com, pradeeps@...ux.vnet.ibm.com,
        pradeep@...ibm.com
Subject: [PATCH net-next v1 0/1] bonding: Adding limited support for ARP monitoring with ovs

Configurations with the bonding driver and openvswitch are unable to use the
bond's "ARP Monitor" feature. If an ovs bridge sits above the bonding driver
use of ARP Monitoring results in the bond flapping between slaves.
bond_verify_device_path() gathers all vlan tags between the bond and the
interface the arp is to be routed by walking the list of adjacent net_device's.
When OVS is in the stack, this process breaks since ports on OVS bridge are not
linked as they are with other configurations.

This patch adds limited support for the ARP Monitoring feature when OVS is
configured above the bond. When no vlan tags are configured or when the tag
is added between the bond interface and the OVS bridge arp monitoring will
function correctly. The use of tags between the OVS bridge and the routed
interfaces are not supported.

For example:
bond0 -> bond0.100 -> ovs-br -> ovs-port (x.x.x.x) is supported.
bond0 -> ovs-br -> ovs-port -> ovs-port.100 (x.x.x.x) is not supported.

We recognize that some other advance network configurations (with-out
OVS) may encounter the same issue. This is not an attempt to provide a
generic solution, it will provide a solution for known use cases with OVS
and the bonding driver as used by OpenShift with OVN-Kubernetes.

OVS bonding with BFD was evaluated as a possible solution. There are some 
limitations to adopting it.

In our environment the hypervisor manages SR-IOV interfaces. OVS bonding
requires that all slave interfaces have promiscuous mode enabled. However, for
promiscuous mode to function the hypervisor must also enable promiscuous mode
on the VF. Unfortunately, the hypervisor allows only a single VF per PF to have
promiscuous mode enabled.

This is a real customer problem, and they have expressed a strong desire to
continue to use the bonding driver to maintain backward compatibility with
their existing setup.