netdev - Re: [question] bonding: should assert dormant for active protocols like LACP?

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4196.1652824157@famine>
Date:   Tue, 17 May 2022 14:49:17 -0700
From:   Jay Vosburgh <jay.vosburgh@...onical.com>
To:     Jonathan Toppins <jtoppins@...hat.com>
cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Veaceslav Falico <vfalico@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [question] bonding: should assert dormant for active protocols like LACP?

Jonathan Toppins <jtoppins@...hat.com> wrote:

>So running the following script:
>
>--%<-----
> ip link add name link-bond0 type veth peer name link-end0
> ip link add bond0 type bond mode 4 miimon 100
> ip link set link-bond0 master bond0 down
> ip netns add n1
> ip link set link-end0 netns n1 up
> ip link set bond0 up
> cat /sys/class/net/bond0/bonding/ad_partner_mac
> cat /sys/class/net/bond0/operstate
>--%<-----
>
>The bond reports its operstate to be "up" even though the bond will never
>be able to establish an LACP partner. Should bonding for active protocols,
>LACP, assert dormant[0] until the protocol has established and frames
>actually are passed?
>
>Having a predictable operstate where up actually means frames will attempt
>to be delivered would make management applications, f.e. Network Manager,
>easier to write. I have developers asking me what detailed states for LACP
>should they be looking for to determine when an LACP bond is "up". This
>seems like an incorrect implementation of operstate and RFC2863 3.1.12.
>
>Does anyone see why this would be a bad idea?

	The catch with LACP is that it has a fallback, in that ports
that don't complete LACP negotiation go to "Solitary" state (I believe
this was called "Individual" in older versions of the 802.1AX / 802.3ad
standard; bonding calls this "is_individual" internally).

	If there is no suitable partnered port, then a Solitary port is
made active.  This permits connectivity if one end is set for LACP but
the other end is not (e.g., PXE boot to a switch port set for LACP).
For reference, I'm looking at 6.3.5 and 6.3.6 of IEEE 802.1AX-2020.

	So, how should operstate be set if "has LACP partner" isn't
really the test for whether or not the interface is (to use RCC 2863
language) "in a condition to pass packets"?  In your example above, I
believe the bond should be able to pass packets just fine, the packets
just won't go anywhere after they leave the bond.

	-J

>-Jon
>
>[0] Documentation/networking/operstates.rst
>

---
	-Jay Vosburgh, jay.vosburgh@...onical.com