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: <9575.1180719013@death>
Date:	Fri, 01 Jun 2007 10:30:13 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	"Laurent Chavey" <chavey@...gle.com>
cc:	netdev@...r.kernel.org
Subject: Re: [PATCH]: bonding: Fix 802.3ad no carrier on "no partner found" instance 

Laurent Chavey <chavey@...gle.com> wrote:

>On 5/31/07, Laurent Chavey <chavey@...gle.com> wrote:
>> if a host configured with 802.3ad bond mode is connected to a switch
>> that does not support 802.3ad,  then an aggregator is selected as the
>> active aggregator (first link that has carrier in the slave list).
>> This is perfectly fine, since it lets at least one of the link become active.
>> (this was the behavior prior to 2.6.18)
>>
>> In 2.6.18 and above, a new check for the partner mac address was added
>> before an aggregator's carrier is set on. If a host is  configured as
>> previously
>> described,  then no links will become active.
>>
>> is that the intended behavior ?

	Prior to the change in question, the carrier state of the master
device was always on, regardless of the state of the slaves (so even if
things didn't work, bonding would claim to be up).

	My concern specifically was more with failures in negotiation
with 802.3ad capable peers, not for interoperability with non-802.3ad
devices (since bonding can always be run in a non-802.3ad mode).

	This behavior (don't pass traffic if no 802.3ad setup occurs)
also parallels the behavior of the Cisco switches I use to test bonding
(they will not pass traffic across ports of a lacp channel-group if the
802.3ad negotation does not occur), so it seemed appropriate.

	I'm checking the standard to see what it says, but I'm also
curious if this has some real-world impact, or is just something you
happened across?

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.com
-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ