Advanced 802.1q protocol management for DSA switch

But why do you need VID3 in this case, as it is untagged it will only be valid inside the switch itself. I agree that you found differences between swconfig and DSA, I simply do not yet understand why these actually should matter? If you could state a use case in which the hidden VID3 is important I would love to hear it.

I did not initiate the thread to get into a discussion of "do you really need this feature? (aka state your use case)". But rather to figure of how to get it working.

Anyway,

For one

http://www.microhowto.info/tutorials/802.1q.html

It is considered good practice to move traffic off the default VLAN where possible, in order to minimise the extent to which an unconfigured switch port would give access to the network.

This does not mean that a network which uses the default VLAN is necessarily insecure, and vacating it may not be feasible since some devices have functions that are hardwired to a VID of 1. However, if you have the opportunity to use a different VLAN then that is usually preferable.

And another reason is VLAN filtering which provides for less cluttered topology

Lastly - there is quite a number of users with such scenario (specific VID with untag state) for whatever their (different) use case is, if you were reckoning me being the sole one.


Hope that otherwise we could stay on topic and not debating whether mine or someone else's use case justifies this thread topic in the first place.

discovery from https://lore.kernel.org/patchwork/patch/575746/

seems like bridge vlan add vid [X] dev lan[N] untagged pvid is the way to go.

[X] = VID
[N] = lan port

Just I do not see that UCI is able to parse it somehow from a config file, or rephrasing - how that would translate into a config setting being parsed by UCI.


also raising the question about setting a PVID with UCI for DSA as it used to be possible with swconfig?

How to express non-swconfig configuration is not an agreed-upon thing, or perhaps even discussed yet.

If you're going to work with DSA at this time and want anything but default config, you will need to configure it with sh scripts, not with UCI, as far as I know.

You might want to add ip-bridge to your builds.

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"
}
}