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 CFC72C43381 for ; Sat, 16 Feb 2019 19:27:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8C054222E0 for ; Sat, 16 Feb 2019 19:27:35 +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="Q8+j6d2Z" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732734AbfBPT1e (ORCPT ); Sat, 16 Feb 2019 14:27:34 -0500 Received: from mail-wm1-f54.google.com ([209.85.128.54]:35014 "EHLO mail-wm1-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728542AbfBPT1d (ORCPT ); Sat, 16 Feb 2019 14:27:33 -0500 Received: by mail-wm1-f54.google.com with SMTP id t200so12948353wmt.0 for ; Sat, 16 Feb 2019 11:27:31 -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=VFWWHOXJNYmVrfGB6C/hxXl37j2MMeoUpcMpaKc6pE0=; b=Q8+j6d2ZkW830rYb1vJvk1y3wmRFaSirDcxETGbhpItbO5qKm3GUhGCUWTPvrHxyYh TH08hywhGQIxtbz55FgITShifllXFAhmyngm6yvqbIJ8G2pnwFKfAc39UBwaWSCyMfW/ D7oAsmFVt77HURbK9Xmba9sKHVl2DVP895y3U= 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=VFWWHOXJNYmVrfGB6C/hxXl37j2MMeoUpcMpaKc6pE0=; b=KM1eUW3Gc8DUrGxmhjSsivlHb1WAKGbHOCCb17EqBh2T1IOjPMDf3XwNCz3Lkh+hzN 4Hkjv+CGckkiudlGZTqsh1uU6R6/g4BIlS6I+4IxIOiQrLKoGYpPOVWQ6o70L3Q62i1e 61SVqi5h23OeZRPf7ui0P9jKdickwEafIsKgX3UfN1JjVo+zh8dzcB5zX14Dtza+Qcbk Mp8AXeDwLAg52d+JgQjNNjEKvjLLNPQzKvuX7leNpo0q4NBZNNPK/X6AcJM83KfKvinD UHM4S4UPo3lQemUei32+bvJU0wizUNLzgvkKKZioKveCZbqrY0waCNUuqtIGmutBUwhM ++JQ== X-Gm-Message-State: AHQUAuZ10N8NMdQGk56OU86LSR6cvsr6/nbWDCINcAGoxmGcqs8ubsuj b53y3aLu7azeJnxAyz7wBgLlsvky7lGOoQ== X-Google-Smtp-Source: AHgI3Iaw2L2pBof9bufMKFAQAZIMWVZt+RabROmhGQv1i2rfIFSGRtynkqkZHtjCpKk+12E1dgD3yw== X-Received: by 2002:a7b:c396:: with SMTP id s22mr11426685wmj.100.1550345250673; Sat, 16 Feb 2019 11:27:30 -0800 (PST) Received: from localhost ([149.62.204.225]) by smtp.gmail.com with ESMTPSA id o12sm4356851wrx.53.2019.02.16.11.27.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Feb 2019 11:27:30 -0800 (PST) Date: Sat, 16 Feb 2019 21:27:26 +0200 In-Reply-To: <0FE44F84-AD68-4FC0-8FEB-D033CF6159D2@cumulusnetworks.com> References: <20190215130427.29824-1-nikolay@cumulusnetworks.com> <20190215171332.GA1472@otheros> <479a1acf-c7f3-4e6f-4246-e1583e98d356@cumulusnetworks.com> <20190216184353.GA10888@splinter> <0FE44F84-AD68-4FC0-8FEB-D033CF6159D2@cumulusnetworks.com> 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: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 16 February 2019 21:15:21 EET, nikolay@cumulusnetworks=2Ecom wrote: >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 [elect= ed] >>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 on >by default=2E=20 Ugh, mispoke please read the above statement to be only about no querier= =2E=20 I meant flooding v6 link-local always=2E=20 >I am currently away and will be able to prepare a rfc patch after the >weekend=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 --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E