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: <48DA71A8.5050900@hp.com>
Date:	Wed, 24 Sep 2008 12:58:16 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Alex Sidorenko <alexandre.sidorenko@...com>
Cc:	Jeff Garzik <jeff@...zik.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Bonding and Neighbour Discovery on IPv6-only devices

Alex Sidorenko wrote:
> On September 15, 2008 02:00:15 pm Jeff Garzik wrote:
>> On Mon, Sep 15, 2008 at 01:35:16PM -0400, Alex Sidorenko wrote:
>>> Hello,
>>>
>>> I suspect that there are some problems while switching slaves manually on
>>> IPv6-only bonds. I have tested that this does not work on 2.6.18 kernel
>>> (RHEL5). I looked at recent sources (2.6.26) and even though there were
>>> multiple changes in bonding code, I still don't see how this could work.
>>>
>>> Testing setup
>>> -------------
>>>
>>> Two ethernets enslaved (eth2 and eh3), active-backup bond has IPv6-only
>>> address (no IPv4)
>>>
>>> Everything works fine, but if we switch the slave doing
>>>
>>> # ifenslave -c bond0 eth3
>>>
>>> the incoming ping6 to this host stops for up to several minutes (waiting
>>> until the switch updates its caches).
>> We _just_ put in an IPv6 fix, FWIW...
>>
> 
> Hi Jeff,
> 
> do you mean the patch for ALB/TLB bonds? I looked at it but I still don't 
> understand how this helps for active-backup case.

It doesn't.  What appears to happen in the active-backup case the MLD reports
are not generated on all of the slave devices, just the active one.  Thus the
switch knows only about the active device.

When you force the failover, no reports happen because the device believes that
the MLD group was already reported.  Thus there needs to be some trigger after
the failover to tell the switch that the mac address and multicast group have
moved to a different port.

-vlad
--
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