netdev - Re: [PATCH v2] bonding: send IPv6 neighbor advertisement on failover

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: <29444.1223654036@death.nxdomain.ibm.com>
Date:	Fri, 10 Oct 2008 08:53:56 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	David Stevens <dlstevens@...ibm.com>
cc:	Brian Haley <brian.haley@...com>,
	Alex Sidorenko <alexandre.sidorenko@...com>,
	David Miller <davem@...emloft.net>,
	Simon Horman <horms@...ge.net.au>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	netdev-owner@...r.kernel.org,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH v2] bonding: send IPv6 neighbor advertisement on failover

David Stevens <dlstevens@...ibm.com> wrote:

>Brian Haley <brian.haley@...com> wrote on 10/10/2008 07:34:58 AM:
>
>> I don't really want to since this is bonding-specific behavior, and 
>> we're not performing DAD for the address.  This is just another sysfs 
>> entry: /sys/class/net/bond*/bonding/num_unsol_na, not a sysctl.
>
>        I think they really are the same case, and doing DAD
>would solve the problem just as well. But I can hold my nose a
>little bit and live with it. :-) Getting the problem solved is
>more important than the details.

	If I'm reading things correctly, DAD sends neighbor
solicitations, and we're sending neighbor advertisements, and not
running the DAD logic.

	As a semi-related question, what does IPv6 do if it receives a
gratutitous NA, and finds a duplicate?

	I agree that doing DAD would update the switches, peers, etc,
but, if I'm reading the IPv6 code correctly, the delay between probes is
one second (nd_tbl.retrans_time), and it looks like there's an initial
delay of up to 1 second as well (in addrconf_dad_kick, the
rtr_solicit_delay).  For failover purposes, we want to issue the
gratuitous ARP or NA packets immediately with a minimal delay between
probes.

	Is my understanding of the DAD behavior correct?

	-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