From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Ido Schimmel <idosch@idosch.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
nikolay@cumulusnetworks.com,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
bridge@lists.linux-foundation.org,
Russell King - ARM Linux admin <linux@armlinux.org.uk>,
"davem@davemloft.net" <davem@davemloft.net>,
Ido Schimmel <idosch@mellanox.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [RFC net-next] net: dsa: add support for MC_DISABLED attribute
Date: Wed, 3 Jul 2019 01:13:08 +0200 [thread overview]
Message-ID: <20190702231308.GA2414@otheros> (raw)
In-Reply-To: <20190702171158.GA7182@splinter>
Hi Ido,
> Do you differentiate between IPv4 and IPv6 in batman-adv?
For most things, yes: The querier state is kept separately for
IPv4 and IPv6. And we do have something like a "router node"
flag to signalize that a node needs all multicast traffic, which
is split into IPv4 and IPv6.
The "MDB" equivalent in batman-adv (multicast entries in our "TT",
translation table) are on MAC address base right now, not on an IP
address base yet, so that sounds similar to what you do in mlxsw?
Regarding querier state, we periodically ask the
bridge via "br_multicast_has_querier_anywhere(dev, ETH_P_IP)"
and "br_multicast_has_querier_anywhere(dev, ETH_P_IPV6)".
(Something more event based with handler functions would probably
be nicer, but this was the easier thing to start with.)
> 1. All the IPv6 MDB entries need to be removed from the device. At least
> in mlxsw, we do not have a way to ignore only IPv6 entries. From the
> device's perspective, an MDB entry is just a multicast DMAC with a
> bitmap of ports packets should be replicated to.
Ah, I see, yes. We had a similar "issue". Initially we just always
added any multicast entry into our translation table offered by
the IP stack or bridge, no matter what a querier state or "router
node" state said. Which would have led to a node receiving two
copies of a multicast packet if it were both a querier or router
and were also having a listener announced via IGMP/MLD.
So there we also just recently changed that, to filter out
IPv6 multicast TT entries if this node were also announcing itself as
an MLD querier or IPv6 router. And same, independently for
IPv4/IGMP.
> 2. We need to split the flood tables used for IPv4 and IPv6 unregistered
> multicast packets. For IPv4, packets should only be flooded to mrouter
> ports whereas for IPv6 packets should be flooded to all the member
> ports.
This one I do not fully understand yet. Why don't you apply the
"flood to all ports" (in the no IGMP querier present case)
for IPv4, too?
Sure, for IPv4 nothing "essential" will break, as IPv4 unicast
does not rely on multicast (contrary to IPv6, due to NDP, as you
mentioned). But still there would be potential multicast packet loss
for a 239.x.x.x listener on the local link, for instance, wouldn't
there?
If I'm not mistaken, we do not apply differing behaviour for IPv4
vs. IPv6 in the bridge either and would flood on all ports for IPv4
with no querier present, too.
Regards, Linus
next prev parent reply other threads:[~2019-07-02 23:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190620235639.24102-1-vivien.didelot@gmail.com>
[not found] ` <5d653a4d-3270-8e53-a5e0-88ea5e7a4d3f@gmail.com>
[not found] ` <20190621172952.GB9284@t480s.localdomain>
[not found] ` <20190623070949.GB13466@splinter>
[not found] ` <20190623072605.2xqb56tjydqz2jkx@shell.armlinux.org.uk>
[not found] ` <20190623074427.GA21875@splinter>
[not found] ` <20190629162945.GB17143@splinter>
2019-06-30 16:56 ` [RFC net-next] net: dsa: add support for MC_DISABLED attribute Linus Lüssing
2019-07-02 14:27 ` Nikolay Aleksandrov
2019-07-02 17:11 ` Ido Schimmel
2019-07-02 23:13 ` Linus Lüssing [this message]
2019-07-07 9:07 ` Ido Schimmel
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=20190702231308.GA2414@otheros \
--to=linus.luessing@c0d3.blue \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@idosch.org \
--cc=idosch@mellanox.com \
--cc=jiri@resnulli.us \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=vivien.didelot@gmail.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