From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: netdev@vger.kernel.org, Jiri Pirko <jiri@resnulli.us>,
Ivan Vecera <ivecera@redhat.com>
Cc: Andrew Lunn <andrew@lunn.ch>, Vivien Didelot <vivien.didelot@gmail.com>
Subject: [RFC 0/3] VLANs, DSA switches and multiple bridges
Date: Sun, 22 Dec 2019 19:22:35 +0000 [thread overview]
Message-ID: <20191222192235.GK25745@shell.armlinux.org.uk> (raw)
Hi,
I've been trying to configure DSA for VLANs and not having much success.
The setup is quite simple:
- The main network is untagged
- The wifi network is a vlan tagged with id $VN running over the main
network.
I have an Armada 388 Clearfog with a PCIe wifi card which I'm trying to
setup to provide wifi access to the vlan $VN network, while the switch
is also part of the main network.
However, I'm encountering problems:
1) vlan support in DSA has a different behaviour from the Linux
software bridge implementation.
# bridge vlan
port vlan ids
lan1 1 PVID Egress Untagged
...
shows the default setup - the bridge ports are all configured for
vlan 1, untagged egress, and vlan 1 as the port vid. Issuing:
# ip li set dev br0 type bridge vlan_filtering 1
with no other vlan configuration commands on a Linux software bridge
continues to allow untagged traffic to flow across the bridge.
This difference in behaviour is because the MV88E6xxx VTU is
completely empty - because net/dsa ignores all vlan settings for
a port if br_vlan_enabled(dp->bridge_dev) is false - this reflects
the vlan filtering state of the bridge, not whether the bridge is
vlan aware.
What this means is that attempting to configure the bridge port
vlans before enabling vlan filtering works for Linux software
bridges, but fails for DSA bridges.
2) Assuming the above is sorted, we move on to the next issue, which
is altogether more weird. Let's take a setup where we have a
DSA bridge with lan1..6 in a bridge device, br0, with vlan
filtering enabled. lan1 is the upstream port, lan2 is a downstream
port that also wants to see traffic on vlan id $VN.
Both lan1 and lan2 are configured for that:
# bridge vlan add vid $VN dev lan1
# bridge vlan add vid $VN dev lan2
# ip li set br0 type bridge vlan_filtering 1
Untagged traffic can now pass between all the six lan ports, and
vlan $VN between lan1 and lan2 only. The MV88E6xxx 8021q_mode
debugfs file shows all lan ports are in mode "secure" - this is
important! /sys/class/net/br0/bridge/vlan_filtering contains 1.
tcpdumping from another machine on lan4 shows that no $VN traffic
reaches it. Everything seems to be working correctly...
In order to further bridge vlan $VN traffic to hostapd's wifi
interface, things get a little more complex - we can't add hostapd's
wifi interface to br0 directly, because hostapd will bring up the
wifi interface and leak the main, untagged traffic onto the wifi.
(hostapd does have vlan support, but only as a dynamic per-client
thing, and there's no hooks I can see to allow script-based config
of the network setup before hostapd up's the wifi interface.)
So, what I tried was:
# ip li add link br0 name br0.$VN type vlan id $VN
# bridge vlan add vid $VN dev br0 self
# ip li set dev br0.$VN up
So far so good, we get a vlan interface on top of the bridge, and
tcpdumping it shows we get traffic. The 8021q_mode file has not
changed state. Everything still seems to be correct.
# bridge addbr br1
Still nothing has changed.
# bridge addif br1 br0.$VN
And now the 8021q_mode debugfs file shows that all ports are now in
"disabled" mode, but /sys/class/net/br0/bridge/vlan_filtering still
contains '1'. In other words, br0 still thinks vlan filtering is
enabled, but the hardware has had vlan filtering disabled.
Adding some stack traces to an appropriate point indicates that this
is because __switchdev_handle_port_attr_set() recurses down through
the tree of interfaces, skipping over the vlan interface, applying
br1's configuration to br0's ports.
This surely can not be right - surely
__switchdev_handle_port_attr_set() and similar should stop recursing
down through another master bridge device? There are probably other
network device classes that switchdev shouldn't recurse down too.
I've considered whether switchdev is the right level to do it, and
I think it is - as we want the check/set callbacks to be called for
the top level device even if it is a master bridge device, but we
don't want to recurse through a lower master bridge device.
Some proposed patches are attached.
--
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 reply other threads:[~2019-12-22 19:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-22 19:22 Russell King - ARM Linux admin [this message]
2019-12-22 19:24 ` [RFC 1/3] net: switchdev: do not propagate bridge updates across bridges Russell King
2019-12-24 8:39 ` Ido Schimmel
2019-12-25 7:41 ` Ido Schimmel
2019-12-22 19:24 ` [RFC 2/3] net: dsa: mv88e6xxx: fix duplicate vlan warning Russell King
2019-12-23 17:49 ` Florian Fainelli
2019-12-22 19:24 ` [RFC 3/3] net: dsa: mv88e6xxx: fix vlan setup Russell King
2019-12-23 18:02 ` Florian Fainelli
2019-12-24 8:30 ` Ido Schimmel
2019-12-23 11:16 ` [RFC 0/3] VLANs, DSA switches and multiple bridges Andrew Lunn
2019-12-31 16:10 ` Pali Rohár
2019-12-31 18:06 ` Ido Schimmel
2020-01-01 1:10 ` Pali Rohár
2020-01-01 17:30 ` Russell King - ARM Linux admin
2020-01-01 18:07 ` Pali Rohár
2020-01-01 18:29 ` Russell King - ARM Linux admin
2020-01-02 4:53 ` Florian Fainelli
2020-01-02 15:40 ` Pali Rohár
2020-01-02 12:54 ` Andrew Lunn
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=20191222192235.GK25745@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--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).