Re: [PATCH net-next 0/3] VLANs, DSA switches and multiple bridges

[Florian Fainelli <f.fainelli@gmail.com>]

On 2/18/20 3:45 AM, Russell King - ARM Linux admin wrote:
> Hi,
> 
> 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.

FWIW, because VLAN filtering is global with b53 switches, we do actually
program every port with a valid VLAN entry into VID 0 which ensures that
standalone (non-bridged) ports, with, or without VLAN interfaces on top
(e.g.: sw0p0.N) continue to work as soon as another port gets enslaved
into a bridge that does request vlan_filtering.

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


-- 
Florian