From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding
Date: Sun, 17 Feb 2019 22:19:27 +0000 [thread overview]
Message-ID: <20190217221927.5efgzd5buy6e4sg3@shell.armlinux.org.uk> (raw)
In-Reply-To: <39dbb59c-0c67-95f8-6703-d3e628d8c50e@gmail.com>
On Sun, Feb 17, 2019 at 02:03:40PM -0800, Florian Fainelli wrote:
>
>
> On 2/17/2019 1:58 PM, Russell King - ARM Linux admin wrote:
> > 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.
>
> Presumably because that non-bridged port and the CPU port are part of
> the same domain with only those 2 ports and that is what we want.
>
> Now what happens if say you have a station that sends multicast traffic
> through that port to e.g.: 226.94.1.1, I bet that port happily sends
> that multicast traffic to the CPU port with no filtering what so ever
> and this ends-up being dropped in the network stack because there is a
> socket look up failure there. IMHO unless you have a receiver/server on
> that network interface on the DSA network interface and a matching
> socket you should not be receiving that multicast traffic and the switch
> should be filtering it. Since the network stack will call into
> ndo_set_rx_mode() for those cases, we really just need to make that
> multicast traffic known, instead of unknown to the switch.
If the port is not bridged, then it's operating as network interface,
and traffic to/from that port needs to be routed to the CPU port so
that it appears as it would do from a real network interface.
Doing anything else makes breaks the idea that you can use a set
of DSA ports as individual interfaces and run anything but IPv4
non-multicast over them.
--
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
next prev parent reply other threads:[~2019-02-17 22:19 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-17 14:24 [PATCH net-next 0/3] net: dsa: mv88e6xxx: fix IPv6 Russell King - ARM Linux admin
2019-02-17 14:25 ` [PATCH net-next 1/3] net: dsa: add support for bridge flags Russell King
2019-02-17 21:37 ` Florian Fainelli
2019-02-17 22:04 ` Russell King - ARM Linux admin
2019-02-17 22:07 ` Florian Fainelli
2019-02-18 0:50 ` Russell King - ARM Linux admin
2019-02-18 11:23 ` Russell King - ARM Linux admin
2019-02-19 15:42 ` Vivien Didelot
2019-02-17 14:25 ` [PATCH net-next 2/3] net: dsa: mv88e6xxx: " Russell King
2019-02-17 21:38 ` Florian Fainelli
2019-02-17 14:25 ` [PATCH net-next 3/3] net: dsa: mv88e6xxx: defautl to multicast and unicast flooding Russell King
2019-02-17 14:27 ` Russell King - ARM Linux admin
2019-02-17 16:34 ` Russell King - ARM Linux admin
2019-02-17 21:45 ` Florian Fainelli
2019-02-17 21:58 ` Russell King - ARM Linux admin
2019-02-17 22:03 ` Florian Fainelli
2019-02-17 22:19 ` Russell King - ARM Linux admin [this message]
2019-02-17 22:30 ` Florian Fainelli
2019-02-17 16:31 ` [PATCH net-next v2 0/3] net: dsa: mv88e6xxx: fix IPv6 Russell King - ARM Linux admin
2019-02-17 16:32 ` [PATCH net-next v2 1/3] net: dsa: add support for bridge flags Russell King
2019-02-17 16:32 ` [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: " Russell King
2019-02-19 16:16 ` Vivien Didelot
2019-02-19 16:24 ` Russell King - ARM Linux admin
2019-02-19 17:00 ` Vivien Didelot
2019-02-19 17:14 ` Russell King - ARM Linux admin
2019-02-19 17:38 ` Vivien Didelot
2019-02-19 17:44 ` Florian Fainelli
2019-02-19 18:20 ` Vivien Didelot
2019-02-19 18:08 ` Russell King - ARM Linux admin
2019-02-19 19:04 ` Vivien Didelot
2019-02-19 19:10 ` Russell King - ARM Linux admin
2019-02-19 19:37 ` Florian Fainelli
2019-02-19 19:56 ` Vivien Didelot
2019-02-19 22:52 ` Russell King - ARM Linux admin
2019-02-19 17:00 ` Russell King - ARM Linux admin
2019-02-19 17:23 ` Vivien Didelot
2019-02-19 17:27 ` Russell King - ARM Linux admin
2019-02-19 23:34 ` Russell King - ARM Linux admin
2019-02-19 23:53 ` Florian Fainelli
2019-02-20 0:07 ` Russell King - ARM Linux admin
2019-02-17 16:32 ` [PATCH net-next v2 3/3] net: dsa: mv88e6xxx: default to multicast and unicast flooding Russell King
2019-02-18 12:53 ` Russell King - ARM Linux admin
2019-02-19 16:05 ` Vivien Didelot
2019-02-19 16:18 ` Russell King - ARM Linux admin
2019-02-18 11:34 ` [PATCH net-next v2 0/3] net: dsa: mv88e6xxx: fix IPv6 Russell King - ARM Linux admin
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=20190217221927.5efgzd5buy6e4sg3@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=netdev@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).