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

[Jay Vosburgh <jay.vosburgh@canonical.com>]

Jonathan Toppins <jtoppins@redhat.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@canonical.com