netdev - Re: [PATCH] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48ED0FB3.7040600@hp.com>
Date:	Wed, 08 Oct 2008 15:53:23 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	Alex Sidorenko <alexandre.sidorenko@...com>,
	Brian Haley <brian.haley@...com>,
	David Miller <davem@...emloft.net>, fubar@...ux.vnet.ibm.com,
	Simon Horman <horms@...ge.net.au>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	netdev-owner@...r.kernel.org
Subject: Re: [PATCH] bonding: send IPv6 neighbor advertisement on failover

David Stevens wrote:
> Well, I think the reason to send mulitple of them is identical.
> If one is dropped due to network load, it won't happen; sending
> multiple increases the odds of success.
> 
> DAD itself should update caches for neighboring nodes, so I
> guess it makes sense that it isn't sending unsolicited NA's, But
> that makes me think that the DAD retransmit counter is the one
> you want. At least, the part of the DAD retransmit counter that is
> for updating other nodes' caches. :-)

Nope, DAD doesn't trigger a cache update.

> 
> For MLD and IGMP, they were explicit SHOULD's-- I need to have
> a look at ND RFC's to again to see what it says about it.
> 
> I don't think that alone is a reason to block the patch, but I also
> don't think that updating neighbor caches with a new MAC address
> is a unique requirement of bonding.

Well, the mac address is not new since the same address is replicated
across all slaves.  Also, unsolicited NAs are not permitted to change
the neighbor cache entries other then state.  An unsolicited NA will
cause an existing entry to go from REACHABLE to STALE, and nothing else.
So, it use in bonding is really the same as gratuitous ARP.

> Moving an address manually
> ought to be identical in needs and behavior, as well as very-quick
> reboots where the hardware changed. Thus, I don't think the knob
> ought to be specific to bonding. I guess that leads to the suggestion
> that you re-use the DAD counter for that.

Yes, a dad counter could be re-used for this, but in some scenarios
it's overkill.  Frankly, NA itself is an overkill.  There may be
some unintentional consequences to using it that I am looking at now.

> 
> References to MLD now and before are just me looking for an
> analog to what ND should be doing. No new knob is definitely
> required for them, since they already have this support for
> unsolicited reports.
> 

The problem is MLDs are only triggered when you are adding a new IPv6
multicast address.  However, in the bond failover case, we are simply
moving a hardware multicast address from one slave interface to
another while leaving the IPv6 multicast address on the master bond interface.
Thus there is not trigger to fire off an MLD report.

-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