Vlad Yasevich <vladislav.yasevich@hp.com> wrote:

quoted text
>Jay Vosburgh wrote:
>> Vlad Yasevich <vladislav.yasevich@hp.com> wrote:
>> 
>>>> +
>>>> +	list_for_each_entry(bond, &bond_dev_list, bond_list) {
>>>> +		if (bond->dev == event_dev) {
>>>> +			switch (event) {
>>>> +			case NETDEV_UP:
>>>> +				ipv6_addr_copy(&bond->master_ipv6, &ifa->addr);
>>>> +				return NOTIFY_OK;
>>> I think you want to store the first address configured on the device (most
>>> likely link-local), and not overwrite it every time  a new address is
>>> configured.  Since new addresses can be configured rather often (think
>>> temporary, new RAs, etc) we really want the most stable address we can have.
>>> Also, since ND is a link protocol, link-local is sufficient.
>> 
>> 	That depends upon how the IPv6 unsolicited NAs are handled by
>> the switch.  For IPv4, we issue a gratuitous ARP for one of the IP
>> addresses on the interface to update the switch's MAC table; for this
>> case, it doesn't matter which IP address is used.
>> 
>> 	If IPv6-smart switches snoop the same way, then it again doesn't
>> matter which IPv6 address is used; this is just to update the MAC table.
>> I'll agree that it's logically sensible to use a link-local, though.
>> If, on the other hand, IPv6 needs an update for each configured address,
>> then storing just one IPv6 address is insufficient (as we'd need an NA
>> for each address).
>> 
>
>Yes, but the unsolicited NA for the global address just looks rather strange
>when the link local one is provide.  Also, with temporaries that can come and
>go, it's better to use a stable address.

	As I said, I'll agree that it's logically sensible to use a
link-local address.  This appears to be just cosmetic, though, and
(apparently, from what Brian Haley says) doesn't affect the switch
response to the update.  But, wait, there's more...

quoted text
>We are simply using it to refresh the MAC tables and for a while I thought it
>would be sufficient to do just one ARP or ND, but then I realized that in an
>environment where 2 systems are connected back-to-back, you would potentially
>need to do both.  Need to play with this config...

	Yah, I've been thinking about that in the background, too,
specifically for cases with devices that cannot change their MAC address
(bonding fail_over_mac enabled); in those cases, the MAC changes during
a failover, so the gratuitous update is particularly important.  The
fail_over_mac is used for Infiniband (fixed MAC) and a few ethernet
multiport devices that are confused by having more than one of their
ports set to the same MAC.

	If those devices (when run back to back without a switch) need a
gratutious for each address, they'll need it for IPv4 and IPv6, I
suspect.  I've not heard of any problems of this sort with Infiniband,
but I'm not sure how common back to back is with Infiniband (not very, I
suspect).

	I think the non-fail_over_mac back to back connect case is ok,
at least for linux, because ARP already connects the MAC address to the
bonding device, not the underlying slave.

	As you say, something to play with (but not today, alas, as my
office space is being remodeled).

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html