Re: [RFC 0/3] VLANs, DSA switches and multiple bridges

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

Hi Pali,

I've just tried this setup here:

# ip ad add 192.168.4.1/24 dev lan1
# ip li set dev lan1 up
# ip li add li lan1 name lan1.128 type vlan id 128
# ip ad add 192.168.5.1/24 dev lan1.128
# ip li set dev lan1.128 up

without lan1 being part of at Linux software bridge.  lan2..6 are
part of a software bridge that has vlan filtering disabled.

On the other end of lan1, I have another machine setup with addresses
192.168.4.2/24 on the raw network interface and 192.168.5.2/24 on vlan
128 - and it works perfectly, without issue.

This is my 5.4.0 kernel, which has a lot of patches on top of 5.4.0,
including the patch set that started this thread. The hardware is a
SolidRun Clearfog (MV88E6176 DSA switch with mvneta host ethernet).

I think the most important thing to do if you're suffering problems
like this is to monitor and analyse packets being received from the
DSA switch on the host interface:

# tcpdump -enXXi $host_dsa_interface

Here's an example ping packet received over the vlan with the above
configuration, captured from the host DSA interface (ether mac
addresses obfuscated):

        0x0000:  DDDD DDDD DDDD SSSS SSSS SSSS dada 0000  .PC.....[h:.....
                                               ^^^^^^^^^
        0x0010:  c020 0000 8100 0080 0800 4500 0054 ec40  ..........E..T.@
                 ^^^^^^^^^ ^^^^^^^^^ ^^^^
        0x0020:  4000 4001 c314 c0a8 0502 c0a8 0501 0800  @.@.............
        0x0030:  8784 0c85 0001 32c8 0c5e 0000 0000 59fc  ......2..^....Y.
        0x0040:  0c00 0000 0000 1011 1213 1415 1617 1819  ................
        0x0050:  1a1b 1c1d 1e1f 2021 2223 2425 2627 2829  .......!"#$%&'()
        0x0060:  2a2b 2c2d 2e2f 3031 3233 3435 3637       *+,-./01234567

dada 0000 c020 0000	- EDSA tag
8100 0080		- VLAN ethertype, vlan id
0800			- IPv4 ethertype, and what follows is the ipv4
			  packet.

That way it would be possible to know whether the DSA switch is
forwarding the packets, and in what manner it's forwarding them.

Another tool that I've found useful is Vivien's debugfs patch,
which seems to be way superior for understanding the Marvell DSA
switch state than any other tool out there. It's my understanding
that DaveM doesn't want that in the mainline kernel, but it's
really useful for understanding what's going on. It was key to me
discovering why vlan stuff wasn't working for me.

-- 
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