From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27009C43381 for ; Sat, 16 Feb 2019 19:15:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CB3D12192D for ; Sat, 16 Feb 2019 19:15:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=cumulusnetworks.com header.i=@cumulusnetworks.com header.b="YxyRdv+a" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732578AbfBPTP2 (ORCPT ); Sat, 16 Feb 2019 14:15:28 -0500 Received: from mail-wr1-f68.google.com ([209.85.221.68]:34198 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732568AbfBPTP2 (ORCPT ); Sat, 16 Feb 2019 14:15:28 -0500 Received: by mail-wr1-f68.google.com with SMTP id f14so13843447wrg.1 for ; Sat, 16 Feb 2019 11:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=date:in-reply-to:references:mime-version:content-transfer-encoding :subject:to:cc:from:message-id; bh=TE6S8+toKNtH7LIYVtHsL6cKqbmDP6L1Zb4Y1eYAhkI=; b=YxyRdv+ajNJx928r3u99Xcn2AlHvjgtHFPKEjY8hBJFwsVsQncN5HP+HCOSIqxHxWa 5T+pi2cPPFc7gUWHTI1YR/zjOVVMXR8YF1tkyREF7PWF9xIIAND5OR4R7GDh1hw2TzGa h6lFcApVy6s/P/XYWDlT3IME7pcf9xBim+vIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=TE6S8+toKNtH7LIYVtHsL6cKqbmDP6L1Zb4Y1eYAhkI=; b=MULyssMPQ4mfb+EHSZV5UuhtHlZLEWrg+YfauhtLq3diMwJoay11dtzuJs4nqAF55T FfyqiCiCiIs7U/JPIm0abm8CV/8MlOf4KkAlbDNY0t2jhCTZ9b3cY7sTImo3MTw6LFkZ /fLjhdXkNjyMMykmKOuTU32Y1X5a1AcSEtcZX52i2tWWbFZM+7ZDX0QDmgJ3Toj2eSJt TSgkpuZI/TDxlT8+l3Bltg2nuWTQH758bx8ieeQmESU5wVy10r0JFFwI+62XVKd8Rj8Y QAdKjOHLn6Fu+3B7CLTKlBD+aCn36+iBtr/4egJFwrki9b73zgylNQM8Hf21avF6nZaz Q1WQ== X-Gm-Message-State: AHQUAubu8hDVdpX0WNHYstoMctdlY6AaJPpCB8r3HaA3jpwwiVuzR/kV KG9hmiDndhff7EaSUMhOZhQgLHvJY+R1rA== X-Google-Smtp-Source: AHgI3IbZFJ/uJ2oMpVePxntV+NdLHMMc06DKNjckKA8vK9V50KyZMGTI7+1LI8nJDtzYoWZUECyg0A== X-Received: by 2002:adf:ba05:: with SMTP id o5mr10847916wrg.325.1550344526028; Sat, 16 Feb 2019 11:15:26 -0800 (PST) Received: from localhost ([149.62.204.225]) by smtp.gmail.com with ESMTPSA id w23sm9782423wmc.38.2019.02.16.11.15.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Feb 2019 11:15:25 -0800 (PST) Date: Sat, 16 Feb 2019 21:15:21 +0200 In-Reply-To: <20190216184353.GA10888@splinter> References: <20190215130427.29824-1-nikolay@cumulusnetworks.com> <20190215171332.GA1472@otheros> <479a1acf-c7f3-4e6f-4246-e1583e98d356@cumulusnetworks.com> <20190216184353.GA10888@splinter> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled To: Ido Schimmel CC: =?ISO-8859-1?Q?Linus_L=FCssing?= , netdev@vger.kernel.org, roopa@cumulusnetworks.com, wkok@cumulusnetworks.com, anuradhak@cumulusnetworks.com, bridge@lists.linux-foundation.org, davem@davemloft.net, stephen@networkplumber.org From: nikolay@cumulusnetworks.com Message-ID: <0FE44F84-AD68-4FC0-8FEB-D033CF6159D2@cumulusnetworks.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 16 February 2019 20:43:53 EET, Ido Schimmel wrote: >On Sat, Feb 16, 2019 at 10:05:40AM +0200, Nikolay Aleksandrov wrote: >> On 15/02/2019 19:13, Linus L=C3=BCssing wrote: >> > On Fri, Feb 15, 2019 at 03:04:27PM +0200, Nikolay Aleksandrov >wrote: >> >> Every user would expect to have traffic forwarded only to the >configured >> >> mdb destination when snooping is enabled, instead now to get that >one >> >> needs to enable both snooping and querier=2E Enabling querier on all >> >> switches could be problematic and is not a good solution, >> >=20 >> > There is no need to set the querier on all snooping switches=2E >> > br_multicast_querier_exists() checks if a querier exists on the >> > link in general, not if this particular host/bridge is a querier=2E >> >=20 >>=20 >> We need a generic solution for the case of existing mdst and no >querier=2E >> More below=2E >>=20 >> >=20 >> >> for example as summarized by our multicast experts: >> >> "every switch would send an IGMP query >> >=20 >> > What? RFC3810, section 7=2E1 says: >> >=20 >> > "If it is the case, a querier election mechanism (described in >> > section 7=2E6=2E2) is used to elect a single multicast router to be >> > in Querier state=2E [=2E=2E=2E] Nevertheless, it is only the [electe= d] >Querier >> > that sends periodical or triggered query messages on the subnet=2E" >> > >> for any random multicast traffic it >> >> received across the entire domain and it would send it forever as >long as a >> >> host exists wanting that stream even if it has no >downstream/directly >> >> connected receivers" >> >=20 >>=20 >> This was taken out of context and it's my bad, I think everyone is >aware >> of the election process, please nevermind the above statement=2E >>=20 >> [snip]>=20 >> >=20 >> > Have you done some tests with this change yet, Nikolay? >> >=20 >>=20 >> You've raised good questions, IPv6 indeed needs more work - we'll >have to flood >> link-local packets etc=2E but I wanted to have a discussion about no >querier/existing mdst=2E >> To simplify we can modify the patch and have traffic forwarded to the >proper ports when an >> mdst exists and there is no querier for both unsolicited report and >user-added entry=2E >> We can keep the current behaviour for unknown traffic with and >without querier=2E >> This would align it closer to what other vendors currently do as well >IIRC=2E >> What do you think ? > >The no querier condition is not currently reflected via switchdev, so >the behavior you're proposing in your patch is what actually happens in >the data plane=2E > >We already hit the problem Linus mentioned in commit b00589af3b04 >("bridge: disable snooping if there is no querier")=2E Namely, IPv6 ND >broke because a port joined before the bridge was created=2E > >I introduced a workaround in commit 9d45deb04c59 ("mlxsw: spectrum: >Treat IPv6 unregistered multicast as broadcast")=2E I'm interested to >know >what other vendors are doing=2E Can you elaborate? > Exactly like your fix=2E :) Flood it, this patch unfortunately breaks it= =C2=A0 because of mrouters flag, but we can retain the behaviour by forwarding only known mdsts to their ports and flooding unregistered mcast when there is no querier=2E I think that is=20 what others do by default too, actually I think they flood with querier as= well=2E Maybe unknown mcast flooding should be controlled by a flag when a= querier is present because we've had this behaviour for a long time, personally I'd have it o= n by default=2E=20 I am currently away and will be able to prepare a rfc patch after the week= end=2E=20 >We can trap IPv6 ND packets at L2 (we'll eventually need to do for ND >suppression) and let the bridge take care of flooding them correctly=2E >I'm not sure it's good enough=2E