Advanced 802.1q protocol management for DSA switch

One of the challenges of use of DSA is that swconfig and the associated UCI is not architected for DSA, but for the switch chips that OpenWrt typically uses.

DSA typically needs to be configured with ip tools directly, assuming that the DSA driver in question can even handle VLANs. qca8k, for example, at least a couple months ago, even in Linux 5.x, can't.

2 Likes

Do you know how to do this for a Turris Omnia?

If you “believe the hype”, ip bridge should magically be understood by the driver. At least as I understand it, you should be able to address each of the switch ports directly, setting up VLAN tagging on each through ethN.1234 notation.

In my (limited, as the device itself is obsolete) experience with a DSA capable driver on a tl-wr941nd v2 (100 MBit/s Marvell 88E6060, which might -or might not- be similar to more modern DSA drivers), you do end up with lan1-4 && wan interfaces (ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan"), which can be tagged or bridged as needed - all the magic of configuring the switch fabric accordingly happens behind the curtain (by the DSA module).

ought to share input from the Turris Omnia developer team

The true is that swconfig is no longer available so switch sections in /etc/config/network are obsolete and they no longer work. On the other hand there is no feature lost. VLANs work and are even easier to configure than before.

The difference between swconfig and DSA is that in case of swconfig you have to configure both sides. You have to configure switch using swconfig including port to CPU and you have to configure CPU interface to switch. This is no longer required. DSA manages switch for you. You now have lan interfaces “exported” to CPU and you can bridge them to create separate lan. Tagging is as easy as tagging CPU port. In Luci you just name port lan0.1 and given interface will be tagged 1. You no longer have to manage and tag CPU<->switch ports. Also note that no traffic is forwarded to CPU unless you assign address to bridge. Setting protocol none allows you to create vlan that does not go to CPU at all. If you want to have some port dedicated to specific interface then it is as easy as using that lan interface as any other ethernet interface.

1 Like

it seems that UCI is capable of providing only 2 port states:

  • lanN.VID = VLAN enabled with tag state, or
  • lanN = VLAN disabled with untag state

but missing (which was possible with swconfig)

  • VLAN enabled with untag state

Been trying to find an OpenWRT script that translates swconfig reliably for UCI DSA but did not succeed, only came across this

We are still missing a script to convert a swconfig configuration to a bridge configuration for DSA.

1 Like

Should be able to bridge, for example, a VLAN-tagged sub-interface of the CPU to an untagged port interface.

that does not achieve setting a specific VID with untag state, e.g. with swconfig

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option ports '5t 2'
	option vid '3'

You get port 2 with VID 3 in untag state (neglect 5t since that being a CPU port and not applicable with DSA)

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