netdev - Re: [Issue] Bonding can't show correct speed if lower interface is bond 802.3ad

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: <84548.1683570736@vermin>
Date: Mon, 08 May 2023 11:32:16 -0700
From: Jay Vosburgh <jay.vosburgh@...onical.com>
To: Hangbin Liu <liuhangbin@...il.com>
cc: netdev@...r.kernel.org
Subject: Re: [Issue] Bonding can't show correct speed if lower interface is bond 802.3ad

Hangbin Liu <liuhangbin@...il.com> wrote:

>On Fri, Apr 28, 2023 at 09:06:40AM -0700, Jay Vosburgh wrote:
>> Hangbin Liu <liuhangbin@...il.com> wrote:
>> 
>> >A user reported a bonding issue that if we put an active-back bond on top of a
>> >802.3ad bond interface. When the 802.3ad bond's speed/duplex changed
>> >dynamically. The upper bonding interface's speed/duplex can't be changed at
>> >the same time.
>> >
>> >This seems not easy to fix since we update the speed/duplex only
>> >when there is a failover(except 802.3ad mode) or slave netdev change.
>> >But the lower bonding interface doesn't trigger netdev change when the speed
>> >changed as ethtool get bonding speed via bond_ethtool_get_link_ksettings(),
>> >which not affect bonding interface itself.
>> 
>> 	Well, this gets back into the intermittent discussion on whether
>> or not being able to nest bonds is useful or not, and thus whether it
>> should be allowed or not.  It's at best a niche use case (I don't recall
>> the example configurations ever being anything other than 802.3ad under
>> active-backup), and was broken for a number of years without much
>> uproar.
>> 
>> 	In this particular case, nesting two LACP (802.3ad) bonds inside
>> an active-backup bond provides no functional benefit as far as I'm aware
>> (maybe gratuitous ARP?), as 802.3ad mode will correctly handle switching
>> between multiple aggregators.  The "ad_select" option provides a few
>> choices on the criteria for choosing the active aggregator.
>> 
>> 	Is there a reason the user in your case doesn't use 802.3ad mode
>> directly?
>
>Hi Jay,
>
>I just back from holiday and re-read you reply. The user doesn't add 2 LACP
>bonds inside an active-backup bond. He add 1 LACP bond and 1 normal NIC in to
>an active-backup bond. This seems reasonable. e.g. The LACP bond in a switch
>and the normal NIC in another switch.
>
>What do you think?

	That case should work fine without the active-backup.  LACP has
a concept of an "individual" port, which (in this context) would be the
"normal NIC," presuming that that means its link peer isn't running
LACP.

	If all of the ports (N that are LACP to a single switch, plus 1
that's the non-LACP "normal NIC") were attached to a single bond, it
would create one aggregator with the LACP enabled ports, and then a
separate aggregator for the indvidual port that's not.  The aggregator
selection logic prefers the LACP enabled aggregator over the individual
port aggregator.  The precise criteria is in the commentary within
ad_agg_selection_test().

	-J

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