[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4a3bfd11-491b-37bc-b843-b438db764aca@blackwall.org>
Date: Tue, 14 Mar 2023 13:51:25 +0200
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Ido Schimmel <idosch@...dia.com>, netdev@...r.kernel.org,
bridge@...ts.linux-foundation.org
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
edumazet@...gle.com, roopa@...dia.com, petrm@...dia.com,
mlxsw@...dia.com
Subject: Re: [PATCH net-next 04/11] rtnetlink: bridge: mcast: Relax group
address validation in common code
On 13/03/2023 16:53, Ido Schimmel wrote:
> In the upcoming VXLAN MDB implementation, the 0.0.0.0 and :: MDB entries
> will act as catchall entries for unregistered IP multicast traffic in a
> similar fashion to the 00:00:00:00:00:00 VXLAN FDB entry that is used to
> transmit BUM traffic.
>
> In deployments where inter-subnet multicast forwarding is used, not all
> the VTEPs in a tenant domain are members in all the broadcast domains.
> It is therefore advantageous to transmit BULL (broadcast, unknown
> unicast and link-local multicast) and unregistered IP multicast traffic
> on different tunnels. If the same tunnel was used, a VTEP only
> interested in IP multicast traffic would also pull all the BULL traffic
> and drop it as it is not a member in the originating broadcast domain
> [1].
>
> Prepare for this change by allowing the 0.0.0.0 group address in the
> common rtnetlink MDB code and forbid it in the bridge driver. A similar
> change is not needed for IPv6 because the common code only validates
> that the group address is not the all-nodes address.
>
> [1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-2.6
>
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
> ---
> net/bridge/br_mdb.c | 6 ++++++
> net/core/rtnetlink.c | 5 +++--
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@...ckwall.org>
Powered by blists - more mailing lists