[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190219092125.GE10191@otheros>
Date: Tue, 19 Feb 2019 10:21:25 +0100
From: Linus Lüssing <linus.luessing@...3.blue>
To: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc: bridge@...ts.linux-foundation.org, netdev@...r.kernel.org,
roopa@...ulusnetworks.com, f.fainelli@...il.com, idosch@...sch.org
Subject: Re: [Bridge] [RFC v2] net: bridge: don't flood known multicast
traffic when snooping is enabled
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.
Powered by blists - more mailing lists