[RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Luiz Angelo Daros de Luca]

Hello,

I had the same feeling since I saw this patch. I would really like
something that could transparently allow me to bridge
either DSA ports, standard ethernet ports or even have a syntax that
would be compatible with swconfig (where dsa is not available).

It is a good opportunity to rebuild current network configuration from
scratch. Today, OpenWrt config does not make clear
how this two are connected:

config switch
       option name 'switch0'
       option reset '1'
       option enable_vlan '1'

config interface 'lan'
       option type 'bridge'
       option ifname 'eth0.1'
       option proto 'static'
       option ipaddr '192.168.1.1'
       option netmask '255.255.255.0'

And we still have wireless:

config wifi-iface 'wifinet0'
       option device 'radio0'
       option mode 'ap'
       option network 'lan' #shouldn't it be "interface"?

It's confusing for someone just arriving that switch0 will use eth0
and switch0 vlan 1 will be mapped to eth0.1. And, after bringing up
the interface, we have a br-lan, not mentioned anywhere.
Both L2 and L3 configurations are mixed, with part of it being even in
a separated configuration file (wireless).

The same feeling is still with this DSA proposal. The syntax "lan2.t
lan2 lan3 lan5" is unstructured and it does not help too.
The use of "switch0" for cpu interface is good and I think it should
even be used for swconfig (simply rename eth0 to switch0 by default
and it will improve usability).
Trying to reuse the current swconfig syntax might be a curse that will
haunt us. We could have simply 2 sections: bridge (L2) and interface
(L3). My proposal:

config bridge br-lan <- the real bridge device name
  option type "auto" # use the best way to merge every ports
  # swconfig
  list port switch0 at 1.1 # switch0, port 1, vlan 1, untagged
  list port switch0 at 2.1 # switch0, port 2, vlan 1, untagged
  list port switch0 at 3.1t # switch0, port 3, vlan 1, tagged
  list port switch0 at 4.2t # switch0, port 4, vlan 2, tagged
  list port switch0 at 4 # switch0, port 4, no vlan filtering (trunk mode)
  # DSA
  list port lan1     # lan1, no vlan filtering (trunk mode)
  list port lan2.1  # lan2 port, vlan 1, untagged
  list port lan3.1t # lan3 port, vlan 1, tagged
  list port lan3.2t # lan3 port, vlan 2, tagged
  # Other interfaces
  list port eth0 # eth0 port, no vlan filtering (trunk mode)
  list port eth0.2t # eth0 port, vlan 2, tagged
  list port wlan0 # it could also be specified in wifi-iface

# for swconfig, where wan would be what eth0.2 is today (simply renamed).
# it might keep the current misunderstanding that eth0.2 is not wan
port but a two-port bridge
# between CPU and wan ports
bridge wan
  list port switch0 at 0 # swith0, port 0, no vlan filtering

# for DSA or swconfig
interface wan
  ifname wan
  proto dhcp

interface lan
  ifname lanbridge0 #<- the real bridge device name
  proto static
  ...



config wifi-iface 'wifinet'
   option bridge lanbridge0
   ...

I don't have a working DSA system to test on but according to
https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html,
it looks like DSA could allow two different ports to use the same vlan
but belong to different bridges. swconfig does not allow that setup
when you use two bridges. But, it could join them using software
bridges. There are obviously incompatible arrangements but the system
could detect them if the configured setup is not possible and avoid to
load them (or load whatever is possible). The bridge device might be
a DSA switch, a software bridge, or simply the CPU port (maybe even
using openvswitch when available?).

My proposal might have tons of uncovered cases (PPPoE, vlan, tunnel)
but it looks easier than current swconfig and dsa proposed
configuration.
The main points are to split L2 and L3 confs, split port list into
individual options and let the system decide the best way to implement
the proposed setup.

Regards,
---
     Luiz Angelo Daros de Luca
            luizluca at gmail.com