netdev - Re: sky2 bonding problem, 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]

Date:	Fri, 16 Feb 2007 10:15:59 +0100
From:	Holger Eitzenberger <holger@...eitzenberger.de>
To:	Jay Vosburgh <fubar@...ibm.com>
Cc:	shemminger@...ux-foundation.org,
	sk-drivers@...ts.linux-foundation.org, netdev@...r.kernel.org
Subject: Re: sky2 bonding problem, 802.3ad

Jay Vosburgh <fubar@...ibm.com> writes:

> 	The log you included (with debug turned on) indicates that
> bonding is at least attempting to send LACPDUs, but there are no log
> entries for having received any LACPDUs.

Yes, the log clearly shows that the LACPDUs are sent, at least bonding
thinks so.  I just checked for received mcast packages on the switch:
yes, they come in frequently on all four ports.  Though I can't check or
Slow_Protocols_Multicast address specifically.

> 	If the switch is configured, you may want to also check to see
> if it has counters for LACPDUs sent and received.  If the switch is not
> sending and receiving LACPDUs on the appropriate ports, then it's more
> likely to be a communications problem somewhere (vs. an 802.3ad
> negotiation problem).

I did not find a dedicated stat for received LACPDUs.

I tried some settings on the switch webinterface.  Interesting: if I
toggle the 'Admin Flow Control' from either 'enabled' to
'autonegotiation' I immediately receive the switch LACPCUs, see:

 bonding: ad_tx_machine() 1210: Sent LACPDU on port 1
 bonding: bond_3ad_rx_indication() 2175: Received LACPDU on port 1
 bonding: ad_rx_machine() 1123: Rx Machine: Port=1, Last State=6, Curr
   State=6

If I then disable the bond (rmmod inclusive) and then enable the bond
again there are no received LACPDUs from the switch.  Mmmpff...

> 	For the version of bonding in your dmesg log, the IFF_NOARP is
> expected; 802.3ad will select one aggregator as the active one, the
> other aggregators will be marked inactive, and that sets IFF_NOARP.
> Since no LACPDUs have been exchanged, bonding is leaving each interface
> as a separate aggregator.  Versions of bonding later than February 2006
> (your proc-bond0-ok for example) don't set the IFF_NOARP on inactive
> slaves (a new mechanism is used that doesn't mess with the flags).

Yes, I already saw in the code that IFF_NOARP was expected.

Any ideas?

  /holger
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html