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: <ZuAcpIqvJYmCTFFK@fedora>
Date: Tue, 10 Sep 2024 10:17:08 +0000
From: Hangbin Liu <liuhangbin@...il.com>
To: netdev@...r.kernel.org
Cc: Jay Vosburgh <j.vosburgh@...il.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	"David S . Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	Simon Horman <horms@...nel.org>, Aaron Conole <aconole@...hat.com>,
	Ilya Maximets <i.maximets@....org>,
	Adrian Moreno <amorenoz@...hat.com>,
	Stanislas Faye <sfaye@...hat.com>
Subject: [Discuss] ARP monitor for OVS bridge over bonding

Hi all,

Recently, our customer got an issue with OVS bridge over bonding. e.g.

  eth0      eth1
   |         |
   -- bond0 --
        |
      br-ex (ovs-vsctl add-port br-ex bond0; ip addr add 192.168.1.1/24 dev br-ex)


Before sending arp message for bond slave detecting, the bond need to check
if the br-ex is in the same data path with bond0 via function
bond_verify_device_path(), which using netdev_for_each_upper_dev_rcu()
to check all upper devices. This works with normal bridge. But with ovs
bridge, the upper device is "ovs-system" instead of br-ex.

After talking with OVS developers. It turned out the real upper OVS topology
is looks like

              --------------------------------
              |                              |
  br-ex  -----+--      ovs-system            |
              |                              |
  br-int -----+--                            |
              |                              |
              |    bond0    eth2   veth42    |
              |      |       |       |       |
              |      |       |       |       |
              -------+-------+-------+--------
                     |       |       |
                  +--+--+  physical  |
                  |     |    link    |
                eth0  eth1          veth43

The br-ex is not upper link of bond0. ovs-system, instead, is the master
of bond0. This make us unable to make sure the br-ex and bond0 is in the
same datapath.

On the other hand, as Adrián Moreno said, the packets generated on br-ex
could be routed anywhere using OpenFlow rules (including eth2 in the
diagram). The same with normal bridge, with tc/netfilter rules, the packets
could also be routed to other interface instead of bond0.

So the rt interface checking in bond_arp_send_all() is not always correct.
Stanislas suggested adding a new parameter like 'arp monitor source interface'
to binding that the user could supply. Then we can do like
	If (rt->dst.dev == arp_src_iface->dev)
		goto found;

What do you think?

Thanks
Hangbin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ