From: Brian Haley <brian.haley@hp.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: Vlad Yasevich <vladislav.yasevich@hp.com>,
David Miller <davem@davemloft.net>,
Simon Horman <horms@verge.net.au>,
Alex Sidorenko <alexandre.sidorenko@hp.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH] bonding: send IPv6 neighbor advertisement on failover
Date: Wed, 08 Oct 2008 15:05:44 -0400 [thread overview]
Message-ID: <48ED0488.7080502@hp.com> (raw)
In-Reply-To: <17192.1223490884@death.nxdomain.ibm.com>
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).
My testing has shown that it doesn't matter which address I send the NA
for, I can ping both the link-local and global without dropping a packet
simultaneously. I'm using a Procurve 5400 series switch for what it's
worth that has IPv6 support, not sure if something not as recent would
behave any different.
-Brian
next prev parent reply other threads:[~2008-10-08 19:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-08 1:13 [PATCH] bonding: send IPv6 neighbor advertisement on failover Brian Haley
2008-10-08 7:26 ` Simon Horman
2008-10-08 17:40 ` David Stevens
2008-10-08 18:08 ` Vlad Yasevich
2008-10-08 18:19 ` David Stevens
2008-10-08 19:01 ` Brian Haley
2008-10-08 22:22 ` Sridhar Samudrala
2008-10-09 2:08 ` Brian Haley
2008-10-08 19:12 ` Vlad Yasevich
2008-10-08 19:41 ` David Stevens
2008-10-08 19:53 ` Vlad Yasevich
2008-10-08 18:15 ` Vlad Yasevich
2008-10-08 18:34 ` Jay Vosburgh
2008-10-08 19:05 ` Brian Haley [this message]
2008-10-08 19:07 ` Vlad Yasevich
2008-10-08 19:36 ` Jay Vosburgh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48ED0488.7080502@hp.com \
--to=brian.haley@hp.com \
--cc=alexandre.sidorenko@hp.com \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=horms@verge.net.au \
--cc=netdev@vger.kernel.org \
--cc=vladislav.yasevich@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.