From: Hangbin Liu <liuhangbin@gmail.com>
To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Cc: "Linus Lüssing" <linus.luessing@c0d3.blue>,
netdev@vger.kernel.org, roopa@cumulusnetworks.com,
bridge@lists.linux-foundation.org, davem@davemloft.net,
yinxu@redhat.com,
"Sebastian Gottschall" <s.gottschall@newmedia-net.de>
Subject: Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
Date: Fri, 22 Feb 2019 15:57:05 +0800 [thread overview]
Message-ID: <20190222075705.GN10051@dhcp-12-139.nay.redhat.com> (raw)
In-Reply-To: <9db055dd-6486-1d6e-7dce-edc511650af9@cumulusnetworks.com>
Hi Nikolay,
On Thu, Feb 21, 2019 at 03:20:14PM +0200, Nikolay Aleksandrov wrote:
> >
> > Yes, I agree. But this "regression" could be fixed by setting up correct
> > switch configuration. See more explains below.
> >
>
> That is irrelevant, if the setup once worked we should not break it unless
> it's in RFC requirement violation and RFC 4541 is only suggestive, not required.
Thanks for your reply. I just noticed the RFC4541 category is informational.
> > "because this would cause the Queries to be seen as coming from a newly
> > elected Querier" means other address could be elected as a Querier but
> > "0.0.0.0" should not.
> >
>
> But this change hasn't been incorporated, has it ? A 0.0.0.0 address currently
> will always win the election and silence all of the rest. Current bridge state
> is simply broken for some cases because of that.
Yes. I agree. I realized linus also said
"""
However, one of the two options seems to be necessary. Either
reverting the patch for the IGMP part, too. Or Ignoring 0.0.0.0
sources for querier eletcion and presence detection.
"""
>
> Removing 0.0.0.0 from the election will effectively disable snooping even if there's
> a configured bridge unless it has an address. You can see that this will end up in
> people having suddenly their multicast flooded with current setups, right ?
Yes
> Any big behaviour change like that should be optional, but I don't think we need
> another option as this is not so big of a deal because we're not breaking any
> required behaviour.
Just a little curious, RFC 3376 said the General Queries are sent from multicast
routers. I think a router *should* has a IP address, isn't it?
RFC 4541 also suggested:
If the switch is not the Querier, it should use the 'all-zeros' IP
Source Address in these proxy queries (even though some hosts may
elect to not process queries with a 0.0.0.0 IP Source Address).
When such proxy queries are received, they must not be included in
the Querier election process.
And what I got is most vendors apply this suggestion.
> In case you decide to follow the option path, please use the new boolopt api to avoid
> adding new fields to the bridge, this should be an on/off thing. I still vote for a
> revert though.
For consistency with other vendors and rfc, I would prefer to remove zero address election.
For compatibility with previous users, I'm also OK to revert it.
Regards
Hangbin
next prev parent reply other threads:[~2019-02-22 7:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-27 0:50 [net:master 17/19] net//bridge/br_multicast.c:1432:32: error: 'union <anonymous>' has no member named 'ip6'; did you mean 'ip4'? kbuild test robot
2018-10-27 7:10 ` Nikolay Aleksandrov
2018-10-27 9:07 ` [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries Nikolay Aleksandrov
2018-10-28 15:20 ` [Bridge] " Stephen Hemminger
2018-10-28 16:09 ` Nikolay Aleksandrov
2018-10-29 1:33 ` Hangbin Liu
2018-12-13 16:10 ` [Bridge] " Linus Lüssing
2018-12-14 2:32 ` Ying Xu
2018-12-17 13:15 ` [Bridge] " Linus Lüssing
2019-02-21 8:01 ` Hangbin Liu
2019-02-21 13:20 ` Nikolay Aleksandrov
2019-02-22 7:57 ` Hangbin Liu [this message]
2019-02-22 11:16 ` Nikolay Aleksandrov
2019-02-22 12:49 ` Hangbin Liu
2018-10-29 2:18 ` David Miller
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=20190222075705.GN10051@dhcp-12-139.nay.redhat.com \
--to=liuhangbin@gmail.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linus.luessing@c0d3.blue \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=roopa@cumulusnetworks.com \
--cc=s.gottschall@newmedia-net.de \
--cc=yinxu@redhat.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 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).