Re: [PATCH net v3 0/5] bonding: 3ad: fix carrier state with no valid slaves

[Jay Vosburgh <jv@jvosburgh.net>]

Jakub Kicinski <kuba@kernel.org> wrote:

>On Thu, 9 Apr 2026 13:49:06 +0200 Louis Scalbert wrote:
>> > Signalling link up too early can cause issues for some protocols that
>> > may change behavior in the absence of PDUs from a link partner.  
>> 
>> I agree with your point. I have observed issues with
>> keepalived VRRP when it is configured on top of a bonding interface.
>> 
>> When the bond reports carrier as up while no slave is actually able to
>> receive traffic (due to the partner not being ready, as indicated by the
>> absence of LACP negotiation), the VRRP process interprets the interface
>> as operational. At the same time, the absence of received VRRP
>> advertisements is interpreted as if it were the only router on the
>> segment. As a result, it transitions to the MASTER state.
>> 
>> In reality, another VRRP router may already be MASTER and actively
>> sending advertisements, but those packets are not received due to the
>> bonding state. This leads to a split-brain condition with multiple
>> masters on the network.
>> 
>> Such a situation breaks the assumptions of
>> VRRP, where a single MASTER is expected to handle traffic,
>> and can result in traffic inconsistency or loss when upper-layer
>> processes rely on this behavior.
>
>It's been like this for what, 15 years?
>We have to draw the line between fix and improvement somewhere.
>In Linux we generally draw the line at regressions+crashes/security
>bugs. If a use case never worked correctly it's not getting fixed.
>It's getting enabled.
>
>That said, if Jay wants it as a fix I'm not going to argue.

	My apologies for not responding sooner, I was under the weather
for a few days and am just now catching up.

	My general position is that, first, the current bonding behavior
is compliant to the standard, which gives latitude in how individual
ports (those not partnered with a LACP peer) are managed.  The stated
Cisco, et al, behavior of denying use of such ports is also compliant.
One thing we cannot do is run such ports together as a logical link
aggregation, for both standards compliance reasons and well as the
practical issues of creating topology loops or duplicate frames.

	Second, the minutiae of the standard is not the real issue at
hand, which is that bonding's behavior of enabling an un-partnered port
and setting the bond to carrier up based on carrier state does cause
communications issues with peers that behave differently and deny use of
un-partnered ports.

	As such, in principle I'm not opposed to an option that would
essentially tell bonding to only use LACP-partnered ports for the active
aggregator.  I'll have some time over the weekend to review the patch
set in detail and respond to the specifics.

	-J

---
	-Jay Vosburgh, jv@jvosburgh.net