Jay Vosburgh <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
