From: Vivien Didelot <vivien.didelot@gmail.com>
To: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next v4 3/3] net: dsa: enable flooding for bridge ports
Date: Wed, 20 Feb 2019 17:29:43 -0500 [thread overview]
Message-ID: <20190220172943.GD9484@t480s.localdomain> (raw)
In-Reply-To: <E1gwYuS-0001b7-L7@rmk-PC.armlinux.org.uk>
On Wed, 20 Feb 2019 20:56:04 +0000, Russell King <rmk+kernel@armlinux.org.uk> 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 disables flooding of
> multicast and unicast frames for bridged ports. 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 for
> unknown unicast and unknown multicast frames to be flooded to all ports
> on the bridge, 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 whenever a port is added to a bridge, and
> disables the flooding when a port leaves the bridge. This means that
> mv88e6xxx DSA switches now behave as per the bridge(8) man page, and
> IPv6 works flawlessly through such a switch.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
prev parent reply other threads:[~2019-02-20 22:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 20:55 [PATCH net-next v4 0/3] net: dsa: mv88e6xxx: fix IPv6 Russell King - ARM Linux admin
2019-02-20 20:55 ` [PATCH net-next v4 1/3] net: dsa: add support for bridge flags Russell King
2019-02-20 21:46 ` Florian Fainelli
2019-02-20 23:18 ` Florian Fainelli
2019-02-20 23:23 ` Russell King - ARM Linux admin
2019-02-20 20:55 ` [PATCH net-next v4 2/3] net: dsa: mv88e6xxx: " Russell King
2019-02-20 21:51 ` Florian Fainelli
2019-02-20 22:23 ` Vivien Didelot
2019-02-20 20:56 ` [PATCH net-next v4 3/3] net: dsa: enable flooding for bridge ports Russell King
2019-02-20 21:51 ` Florian Fainelli
2019-02-20 22:29 ` Vivien Didelot [this message]
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=20190220172943.GD9484@t480s.localdomain \
--to=vivien.didelot@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=rmk+kernel@armlinux.org.uk \
/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