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.
>
> >
> > Signed-off-by: Russell King <rmk+ker...@armlinux.org.uk>
> > ---
> > 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
--
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
