netdev - Re: Bonding and Neighbour Discovery on IPv6-only devices

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:	Wed, 24 Sep 2008 13:29:48 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Vlad Yasevich <vladislav.yasevich@...com>
cc:	Alex Sidorenko <alexandre.sidorenko@...com>,
	Jeff Garzik <jeff@...zik.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Bonding and Neighbour Discovery on IPv6-only devices

Vlad Yasevich <vladislav.yasevich@...com> wrote:
[...]
>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.

	This behavior is by design.  Previously, it worked the other way
(every slave did IPv6 addrconf stuff, etc), but that confused the
switches because they'd snoop the addrconf traffic whenever a backup
slave came up, and update the switch forwarding table.

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

	Yes, there needs to be an ipv6 equivalent of the gratuitous ARP
and IGMP rejoin that's done for ipv4.  I haven't figured out how to
accomplish that yet; suggestions are welcome.

	-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