Merge branch 'VLANs-DSA-switches-and-multiple-bridges'
Russell King says:
====================
VLANs, DSA switches and multiple bridges
This is a repost of the previously posted RFC back in December, which
did not get fully reviewed. I've dropped the RFC tag this time as no
one really found anything too problematical in the RFC posting.
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.
v2: dropped patch 3, since that has an outstanding issue, and my
question on it has not been answered. Otherwise, these are the
same patches. Maybe we can move forward with just these two?
v3: include DSA ports in patch 2
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Showing
Please register or sign in to comment