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=-8.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,USER_AGENT_NEOMUTT 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 59013C43381 for ; Sun, 17 Feb 2019 21:58:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1BCEB217F9 for ; Sun, 17 Feb 2019 21:58:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="VYUNe7p0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726845AbfBQV6g (ORCPT ); Sun, 17 Feb 2019 16:58:36 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:43246 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbfBQV6f (ORCPT ); Sun, 17 Feb 2019 16:58:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0o/fGHKy9yr7L54SEKPoAfIKRoFfpEgf2EgwMi1fDwU=; b=VYUNe7p0wghB+2ecL64dr7hq6 hiYboW6LQx+7q6E0d7QQmEy05rwqaHlhT6G2emO1027humdg4+8u8f4bAmDEY1JWga/4VLSHhJpJh T9fRJEYq+7CGms1LH8wxZ6l64lP565UXPgJ6jeBr2uCLA/4h9bFuWv/e+HbNia8kCIn53gxj/tp/z pCGg4cWLZcBg0sLdh7RCklC8+Z2lDKOScFKXo6t2XiTmX6kLHXXE7nYbIQn//+lbNDqeR/6QlR5mC EdJCPIUPSDEdhfanxTmook7ElcZBY4Tq0eRVWEdk9RBZPkB490S2++RnfhPd0j6v383xCxUaSbXlx xNcP5dmUw==; Received: from shell.armlinux.org.uk ([2001:4d48:ad52:3201:5054:ff:fe00:4ec]:54552) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gvUSE-0002rK-67; Sun, 17 Feb 2019 21:58:30 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.89) (envelope-from ) id 1gvUSB-0006bx-Ml; Sun, 17 Feb 2019 21:58:27 +0000 Date: Sun, 17 Feb 2019 21:58:27 +0000 From: Russell King - ARM Linux admin To: Florian Fainelli Cc: Andrew Lunn , Vivien Didelot , "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding Message-ID: <20190217215827.2iavpy4xyh3viqup@shell.armlinux.org.uk> References: <20190217142414.cjtmpi5y2l5rtdlb@shell.armlinux.org.uk> <20190217142716.gsrq5k2gnw3hsnhu@shell.armlinux.org.uk> <20190217163434.xo3ojbny4dnfqqwq@shell.armlinux.org.uk> <1a956aeb-f195-90ca-a5a5-fabac450feac@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a956aeb-f195-90ca-a5a5-fabac450feac@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Feb 17, 2019 at 01:45:24PM -0800, Florian Fainelli wrote: > > > On 2/17/2019 8:34 AM, Russell King - ARM Linux admin wrote: > > On Sun, Feb 17, 2019 at 02:27:16PM +0000, Russell King - ARM Linux admin wrote: > >> On Sun, Feb 17, 2019 at 02:25:17PM +0000, Russell King wrote: > >>> Switches work by learning the MAC address for each attached station by > >>> monitoring traffic from each station. When a station sends a packet, > >>> the switch records which port the MAC address is connected to. > >>> > >>> With IPv4 networking, before communication commences with a neighbour, > >>> an ARP packet is broadcasted to all stations asking for the MAC address > >>> corresponding with the IPv4. The desired station responds with an ARP > >>> reply, and the ARP reply causes the switch to learn which port the > >>> station is connected to. > >>> > >>> With IPv6 networking, the situation is rather different. Rather than > >>> broadcasting ARP packets, a "neighbour solicitation" is multicasted > >>> rather than broadcasted. This multicast needs to reach the intended > >>> station in order for the neighbour to be discovered. > >>> > >>> Once a neighbour has been discovered, and entered into the sending > >>> stations neighbour cache, communication can restart at a point later > >>> without sending a new neighbour solicitation, even if the entry in > >>> the neighbour cache is marked as stale. This can be after the MAC > >>> address has expired from the forwarding cache of the DSA switch - > >>> when that occurs, there is a long pause in communication. > >>> > >>> Our DSA implementation for mv88e6xxx switches has defaulted to having > >>> multicast and unicast flooding disabled. As per the above description, > >>> this is fine for IPv4 networking, since the broadcasted ARP queries > >>> will be sent to and received by all stations on the same network. > >>> However, this breaks IPv6 very badly - blocking neighbour solicitations > >>> and later causing connections to stall. > >>> > >>> The defaults that the Linux bridge code expect from bridges are that > >>> unknown unicast frames and unknown multicast frames are flooded to > >>> all stations, which is at odds to the defaults adopted by our DSA > >>> implementation for mv88e6xxx switches. > >>> > >>> This commit enables by default flooding of both unknown unicast and > >>> unknown multicast frames. This means that mv88e6xxx DSA switches now > >>> behave as per the bridge(8) man page, and IPv6 works flawlessly through > >>> such a switch. > >> > >> Note that there is the open question whether this affects the case where > >> each port is used as a separate network interface: that case has not yet > >> been tested. > > > > I've checked with a mv88e6131 on the clearfog gt8k board. lan1 > > connected to my lan with plenty of traffic on, and configured as > > part of a bridge. lan2 connected to the zii board, but not part > > of the bridge. Monitoring lan2 from the zii board shows no traffic > > that was received from lan1. > > > > So it looks fine. > > With the current state whereby we do not have the necessary hooks to > perform filtering on non-bridged/standalone ports, this is entirely fine > indeed. > > In the future this is part of something I want to address because it is > IMHO highly undesirable to have non-bridged ports be flooded with > unknown multicast or unknown unicast for that matter because that makes > them deviate from a standard NIC interface. Unknown unicast is not > necessarily a low hanging fruit, but still, if we have switches capable > of filtering, we might as well make use of that. Of course, one > difficulty is that we must not break running tcpdump on those DSA slave > network interfaces. Sorry, I think you have the wrong end of the stick. For a non-bridged port, I am seeing _no_ traffic apart from that explicitly sent out through that port. In other words, there are _no_ flooded frames coming out of the non-bridged port. This patch appears to have no material effect on non-bridged ports. > > > > >> > >>> > >>> Signed-off-by: Russell King > >>> --- > >>> drivers/net/dsa/mv88e6xxx/chip.c | 9 +++++---- > >>> 1 file changed, 5 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c > >>> index b75a865a293d..eb5e3d88374f 100644 > >>> --- a/drivers/net/dsa/mv88e6xxx/chip.c > >>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c > >>> @@ -2144,13 +2144,14 @@ static int mv88e6xxx_setup_message_port(struct mv88e6xxx_chip *chip, int port) > >>> static int mv88e6xxx_setup_egress_floods(struct mv88e6xxx_chip *chip, int port) > >>> { > >>> struct dsa_switch *ds = chip->ds; > >>> - bool flood; > >>> > >>> - /* Upstream ports flood frames with unknown unicast or multicast DA */ > >>> - flood = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port); > >>> + /* Linux bridges are expected to flood unknown multicast and > >>> + * unicast frames to all ports - as per the defaults specified > >>> + * in the iproute2 bridge(8) man page. Not doing this causes > >>> + * stalls and failures with IPv6 over Marvell bridges. */ > >>> if (chip->info->ops->port_set_egress_floods) > >>> return chip->info->ops->port_set_egress_floods(chip, port, > >>> - flood, flood); > >>> + true, true); > >>> > >>> return 0; > >>> } > >>> -- > >>> 2.7.4 > >>> > >>> > >> > >> -- > >> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > >> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > >> According to speedtest.net: 11.9Mbps down 500kbps up > > > > -- > Florian > -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up