All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Haley <brian.haley@hp.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: David Stevens <dlstevens@us.ibm.com>,
	Alex Sidorenko <alexandre.sidorenko@hp.com>,
	David Miller <davem@davemloft.net>,
	Simon Horman <horms@verge.net.au>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	netdev-owner@vger.kernel.org,
	YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Subject: Re: [PATCH v2] bonding: send IPv6 neighbor advertisement on failover
Date: Fri, 10 Oct 2008 12:04:15 -0400	[thread overview]
Message-ID: <48EF7CFF.4050405@hp.com> (raw)
In-Reply-To: <29444.1223654036@death.nxdomain.ibm.com>

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

If a node has an IPv6 neighbor entry and receives an unsolicited NA it 
will change it's state to stale, forcing a re-lookup on the next 
transmit.  An un-solicited NA will change the state to reachable.

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

Right, and since a bond failover event should be rare, I think sending 
the NA immediately is OK.  All those random delays are meant to cover 
the case, for example, when a router sends an advertisement with a new 
prefix - you don't want everyone that receives it to do DAD immediately 
since it could overwhelm the network.

-Brian

  reply	other threads:[~2008-10-10 16:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-10  0:52 [PATCH v2] bonding: send IPv6 neighbor advertisement on failover Brian Haley
2008-10-10  2:23 ` David Stevens
2008-10-10 14:34   ` Brian Haley
2008-10-10 15:03     ` David Stevens
2008-10-10 15:53       ` Jay Vosburgh
2008-10-10 16:04         ` Brian Haley [this message]
2008-10-10 16:29           ` Vlad Yasevich
2008-10-10 16:56             ` Sridhar Samudrala
2008-10-10 17:15               ` Vlad Yasevich
2008-10-10 15:27 ` Vlad Yasevich
2008-10-27 20:07 ` Brian Haley
2008-10-28  0:24   ` 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=48EF7CFF.4050405@hp.com \
    --to=brian.haley@hp.com \
    --cc=alexandre.sidorenko@hp.com \
    --cc=davem@davemloft.net \
    --cc=dlstevens@us.ibm.com \
    --cc=fubar@us.ibm.com \
    --cc=horms@verge.net.au \
    --cc=netdev-owner@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.org \
    /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.