Advanced 802.1q protocol management for DSA switch

Understand - just untag and PVID are settings provided by swconfig and not

unless I misunderstood the meaning/context of that expression.

There’s no “linkage” that I know of between UCI and the DSA drivers, as there is for those supported by swconfig yet.

2 Likes

a use case basic example for untag 802.1q frames, br-lan enslaving lan0,lan1,lan2

bridge v a dev br-lan self vid 2 untagged pvid
bridge v a dev lan0 vid 2 untagged pvid
bridge v a dev lan1 vid 2 untagged pvid
bridge v a dev lan2 vid 2 untagged pvid
sysctl -w /sys/class/net/br-lan/bridge/vlan_filtering=1

sysctl -w sets the filter in motion and thus to be last or else access to the node could be cut off.

just dropping by to say that if someone finds a reliable way to do VLANs with DSA on OpenWrt,

it would be really nice to write a tutorial in the wiki (or even just here and notify me with @bobafetthotmail so I can integrate it)

1 Like

Turned out that

config switch_vlan
	option device 'switch0'
	option vlan '11'
	option vid '11'
	option ports '0 5t'

is not the same as lan0.11. If I bridge lan0.11 & lan1, then a client connected to lan0 cannot get an IP while lan1 works just fine.

How do I get this behaviour with DSA: untagged packets arrive on lan0 and then get tagged? I just need to isolate the wired ports and I do not use smart switches.

As far I as I understand that is not possible but perhaps there is a misconception comparing swconfig and DSA.

port 5 represents a CPU port (physical lane to the switch chip). If you mean

by that then it is no longer required.


My understanding of how 802.1q tagging works (and I will stand corrected if that is wrong/incomplete)

  • a tagged port is going to output all traffic if part of the VLAN with vlan tag left intact

  • a tagged port will accept all tagged traffic with vlan tags which the port is a member of

  • a tagged port will output traffic matching is PVID without a vlan tag

  • a tagged port will put any incoming untagged traffic into the vlan matching it’s PVID

  • a untagged port will only output traffic of the vlan matching it’s PVID and the traffic will be without a VLAN tag

  • a untagged port will only accept traffic without a vlan tag and will put it into the VLAN matching it’s PVID


In that spirit (meaning an untagged packet on ingress cannot get tagged on egress on the same port) try

  • remove the {downstream iface}.tagged from the network conf

and instead from cli

bridge v a dev br-lan self vid 11 untagged pvid
bridge v a dev lan0 vid 11 untagged pvid
sysctl -w /sys/class/net/br-lan/bridge/vlan_filtering=1

bridge v s will show applied settings

No luck here with 18.06

bridge v a dev br-lan self vid 11 untagged pvid
RTNETLINK answers: Not supported

I think I am missing a kernel module: 8021q ...

Hmm, there is not such package...

it is (should be) compiled in.

CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_VLAN_8021Q=y
CONFIG_NET_ACT_VLAN=m
CONFIG_MACVLAN=m


does it also happen with bridge v a dev lan0 vid 11 untagged pvid ?

bridge v a dev lan0 vid 11 untagged pvid
RTNETLINK answers: Not supported

That commonly indicates some issue with a kernel config. Can you try a reboot and see if it works then?

Rebooted, no luck. I also unloaded br_netfilter that I use, but did not make a difference.

the error means that what iproute2 wants from the kernel is not providing. Something seems amiss.

What is the output of ubus -S call system board

This what I am seeing for target-arm_cortex-a9+vfpv3_musl_eabi in 18.06-SNAPSHOT:

CONFIG_BRIDGE_EBT_VLAN=m
# CONFIG_BRIDGE_VLAN_FILTERING is not set
CONFIG_VLAN_8021Q=y
# CONFIG_NET_ACT_VLAN is not set
CONFIG_MACVLAN=m
{
"kernel":"4.14.130",
"system":"ARMv7 Processor rev 1 (v7l)",
"model":"Turris Omnia",
"board_name":"armada-385-turris-omnia",
"release":
{
"distribution":"OpenWrt",
"version":"18.06-SNAPSHOT",
"revision":"r7803-5e771160b8",
"target":"mvebu\/cortexa9",
"description":"OpenWrt 18.06-SNAPSHOT r7803-5e771160b8"
}
}

Try the release instead of the snapshot, maybe something wrong with the latter.

The buildbots had some trouble around the time the last snapshot is dated.


and despite the odds run swconfig show just to be sure that DSA is really in play

swconfig show
-ash: swconfig: not found

not installed as expected when configured for DSA

I can get the same functionality by creating an interface for each port and AP and add them all to the guest zone, but then I end up with a dozen of IP ranges to manage.
I am gonna try master now: it crashes when using lanX.X notation, but it turned out I do not need that. I will try the bridge commands you provided.