From: Brian Haley <brian.haley@hp.com>
To: David Stevens <dlstevens@us.ibm.com>
Cc: Alex Sidorenko <alexandre.sidorenko@hp.com>,
David Miller <davem@davemloft.net>,
fubar@linux.vnet.ibm.com, Simon Horman <horms@verge.net.au>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
netdev-owner@vger.kernel.org,
Vladislav Yasevich <vladislav.yasevich@hp.com>
Subject: Re: [PATCH] bonding: send IPv6 neighbor advertisement on failover
Date: Wed, 08 Oct 2008 15:01:58 -0400 [thread overview]
Message-ID: <48ED03A6.2060705@hp.com> (raw)
In-Reply-To: <OF3F6EE419.BE384A50-ON882574DC.0063AD5A-882574DC.0064A148@us.ibm.com>
David Stevens wrote:
> Well, actually, it looks like I'm suggesting you to re-use something that
> doesn't
> exist. :-)
>
> MLD (and IGMP) has such a thing where unsolicited advertisements are sent
> multiple times, with delays in between, to account for lossy networks
> possibly
> dropping the first one. There are configurable counts associated with
> probes
> and retransmit intervals for solicits, but I don't see the equivalent yet
> for
> unsolicited NA's.
I don't see an equivalent either, since the only unsolicited NA the
kernel sends is for DAD, which uses dad_transmits.
I left the MLD changes out of this patch so I could work on it
separately, when I get to it I'll make sure to look at the issues you
raised in your other email so it follows the RFC, or at least the Linux
behavior.
> So, instead, what I suggest is that you add (or find!) THAT knob, instead
> of a
> bonding-specific one. Because adding an address that wasn't there before
> has identical issues with unsolicited NA's as bonding has with activating
> a
> new address. The default should probably be 1, but if you ever need to
> send multiple unsolicited NA's for bonding, you probably also need it for
> adding a normal address on the same network. dad_transmits is similar,
> but not really the same thing.
The problem is that dad_transmits can be set to zero, although not
recommended, so if we used that value then bonding failover would be
just as broken. I think having this new tunable stay in the bonding
code is useful since that's the code that's actually doing the transmit.
-Brian
next prev parent reply other threads:[~2008-10-08 19:02 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 [this message]
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
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=48ED03A6.2060705@hp.com \
--to=brian.haley@hp.com \
--cc=alexandre.sidorenko@hp.com \
--cc=davem@davemloft.net \
--cc=dlstevens@us.ibm.com \
--cc=fubar@linux.vnet.ibm.com \
--cc=horms@verge.net.au \
--cc=netdev-owner@vger.kernel.org \
--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.