From: Brian Haley <brian.haley@hp.com>
To: David Stevens <dlstevens@us.ibm.com>
Cc: 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,
Vlad Yasevich <vladislav.yasevich@hp.com>
Subject: Re: [RFC] bonding: add better ipv6 failover support
Date: Fri, 26 Sep 2008 15:28:08 -0400 [thread overview]
Message-ID: <48DD37C8.1010205@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.
Ok, I'll try and change this code to spin through all the multicast
addresses on the master and call igmp6_join_group() instead.
> 2) There is already a configurable and code for unsolicited neighbor
> advertisements
> when adding an address-- why not use that? In fact, wouldn't just
> moving the
> failing device's address list to the new device do everything you
> want, since
> adding an address already sends unsolicited neighbor
> advertisements,
> joins the solicited node address, etc.? Or am I missing something?
In this case the address is configured on the bond master, each slave is
just used for transmit/receive. While I could have sent an unsolicited
NA, sending an NS is much easier, especially since it's only notifying
the switch that the address has moved.
> 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).
Like #1, I'll try changing the code.
Thanks for the comments.
-Brian
next prev parent reply other threads:[~2008-09-26 19:28 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 [this message]
2008-09-26 19:55 ` Vlad Yasevich
2008-09-26 19:46 ` Vlad Yasevich
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=48DD37C8.1010205@hp.com \
--to=brian.haley@hp.com \
--cc=alexandre.sidorenko@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 \
--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.