netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Brian Haley <brian.haley@hp.com>
Cc: David Stevens <dlstevens@us.ibm.com>,
	Alex Sidorenko <alexandre.sidorenko@hp.com>,
	fubar@linux.vnet.ibm.com, Jeff Garzik <jeff@garzik.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	netdev-owner@vger.kernel.org
Subject: Re: [RFC] bonding: add better ipv6 failover support
Date: Fri, 26 Sep 2008 15:46:37 -0400	[thread overview]
Message-ID: <48DD3C1D.3020403@hp.com> (raw)
In-Reply-To: <OFE12AA65F.345E597C-ON882574D0.00637542-882574D0.00679AFC@us.ibm.com>

David Stevens wrote:
> 1) You're calling mld_send_report() directly, which will send the MLD
>         report synchronously. It should use the randomized timer (see 
> igmp6_join_group).
>         A mass failover (e.g., a power event in a cluster) would blast all 
> of these at once,
>         which is why the randomized timer is required for gratuitous 
> reports. This
>         should use a randomized timer, like mld_ifc_start_timer(), but 
> joining the
>         group all by itself will do that.

To add to what David said, looks like mld_send_report will always send a
Version 2 report.  This should honor correctly V1 or v2 configuration.

However, to address the random delay, this would have to be static delay
of at most 1 sec.  Otherwise any NUD probes would be lost.


> 3) MLD has a lot of state and it's all associated with the device. 
> Changing the sending device out from under it seems risky to me. I don't know enough 
> about bonding, but I think you really just want all the group 
> memberships and MLD state to be with the master device and the master should just 
> go through the multicast list for the master and join those groups on 
> the new slave. The MLD code will already resolve the filters 
> appropriately for joins and filters already done directly on the new slave that 
> way.  Actually, I thought that's what Jay's prior patch was all 
> about, and those joins should trigger MLD reports where needed, so I'm 
> definitely confused on what the problem with multicasts is beyond the 
> solicited-node addresses (which just needs to mimic the address add code, or use 
> it directly).

Yes, I think this needs a little more thought.  The multicast addresses are
already on the master and also on the active slave.  However, at failover time,
I think those memberships needs to be removed from the old slave, and added
to the new slave.  Alex mentioned that there were some refcounts that didn't
allow for this to happen, but I don't see any.

The trouble I see is that the MLD/IGMPv6 is only sent when an IPv6 multicast
address is added.  In the failover scenario, since IPv6 address is joined on
the bond, we only move the link multicast address from one interface to
another.  This doesn't normally trigger and new report, but this is just what
we want.

Additionally, I think the code should be using an unsolicited NA instead of the
NS, since we do really want to trigger a rediscovery the address and
the associated MAC to make sure that all forwarding state is updated on link.

-vlad

      parent reply	other threads:[~2008-09-26 19:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-15 17:35 Bonding and Neighbour Discovery on IPv6-only devices Alex Sidorenko
2008-09-15 18:00 ` Jeff Garzik
2008-09-15 18:16   ` Jay Vosburgh
2008-09-15 18:16   ` Alex Sidorenko
2008-09-24 16:58     ` Vlad Yasevich
2008-09-24 20:29       ` Jay Vosburgh
2008-09-24 21:07         ` Brian Haley
2008-09-25  2:46         ` [RFC] bonding: add better ipv6 failover support Brian Haley
2008-09-25 15:07           ` Jay Vosburgh
2008-09-25 15:42             ` Brian Haley
2008-10-01  5:53               ` Simon Horman
2008-10-01 13:24                 ` Brian Haley
2008-10-01 13:36                   ` David Miller
2008-09-26 18:51           ` David Stevens
2008-09-26 19:09             ` Jay Vosburgh
2008-09-26 19:28             ` Brian Haley
2008-09-26 19:55               ` Vlad Yasevich
2008-09-26 19:46             ` Vlad Yasevich [this message]

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=48DD3C1D.3020403@hp.com \
    --to=vladislav.yasevich@hp.com \
    --cc=alexandre.sidorenko@hp.com \
    --cc=brian.haley@hp.com \
    --cc=dlstevens@us.ibm.com \
    --cc=fubar@linux.vnet.ibm.com \
    --cc=jeff@garzik.org \
    --cc=netdev-owner@vger.kernel.org \
    --cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).