netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Cc: bridge@lists.linux-foundation.org, netdev@vger.kernel.org,
	roopa@cumulusnetworks.com, f.fainelli@gmail.com,
	idosch@idosch.org
Subject: Re: [Bridge] [RFC v2] net: bridge: don't flood known multicast traffic when snooping is enabled
Date: Tue, 19 Feb 2019 10:21:25 +0100	[thread overview]
Message-ID: <20190219092125.GE10191@otheros> (raw)
In-Reply-To: <20190219085716.GD10191@otheros>

On Tue, Feb 19, 2019 at 09:57:16AM +0100, Linus Lüssing wrote:
> On Mon, Feb 18, 2019 at 02:21:07PM +0200, Nikolay Aleksandrov wrote:
> > This is v2 of the RFC patch which aims to forward packets to known
> > mdsts' ports only (the no querier case). After v1 I've kept
> > the previous behaviour when it comes to unregistered traffic or when
> > a querier is present. All of this is of course only with snooping
> > enabled. So with this patch the following changes should occur:
> >  - No querier: forward known mdst traffic to its registered ports,
> >                no change about unknown mcast (flood)
> >  - Querier present: no change
> > 
> > The reason to do this is simple - we want to respect the user's mdb
> > configuration in both cases, that is if the user adds static mdb entries
> > manually then we should use that information about forwarding traffic.
> > 
> > What do you think ?
> > 
> > * Notes
> > Traffic that is currently marked as mrouters_only:
> >  - IPv4: non-local mcast traffic, igmp reports
> >  - IPv6: non-all-nodes-dst mcast traffic, mldv1 reports
> > 
> > Simple use case:
> >  $ echo 1 > /sys/class/net/bridge/bridge/multicast_snooping
> >  $ bridge mdb add dev bridge port swp1 grp 239.0.0.1
> >  - without a querier currently traffic for 239.0.0.1 will still be flooded,
> >    with this change it will be forwarded only to swp1
> 
> There is still the issue with unsolicited reports adding mdst
> entries here, too. Leading to unwanted packet loss and connectivity issues.

Or in other words, an unsolicited report will turn a previously
unregistered multicast group into a registered one. However in the
absence of a querier the knowledge about this newly registered multicast group
will be incomplete. And therefore still needs to be flooded to avoid packet
loss.

  reply	other threads:[~2019-02-19  9:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15 13:04 [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled Nikolay Aleksandrov
2019-02-15 13:09 ` Nikolay Aleksandrov
2019-02-15 13:53 ` Ido Schimmel
2019-02-15 17:13 ` Linus Lüssing
2019-02-16  8:05   ` Nikolay Aleksandrov
2019-02-16  8:35     ` Nikolay Aleksandrov
2019-02-16 20:04       ` Linus Lüssing
2019-02-16 18:43     ` Ido Schimmel
2019-02-16 19:15       ` nikolay
2019-02-16 19:27         ` nikolay
2019-02-16 20:37           ` Linus Lüssing
2019-02-17  3:05 ` Florian Fainelli
2019-02-17 10:58   ` Nikolay Aleksandrov
2019-02-18 12:21 ` [RFC v2] " Nikolay Aleksandrov
2019-02-19  8:53   ` Ido Schimmel
2019-02-19  8:57   ` Linus Lüssing
2019-02-19  9:21     ` Linus Lüssing [this message]
2019-02-19 13:31       ` [Bridge] " Nikolay Aleksandrov
2019-02-19 15:42         ` Linus Lüssing
2019-02-19 17:26           ` Nikolay Aleksandrov

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=20190219092125.GE10191@otheros \
    --to=linus.luessing@c0d3.blue \
    --cc=bridge@lists.linux-foundation.org \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=roopa@cumulusnetworks.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).