VLAN-filtered bridge acting like hub?

I'm running 21.02.5 on a Linksys WRT1200AC.

The test setup:
This is the test setup I'm working with:

The device of interest is openwrt-spare.

On the rpi3 I run: tcpdump -ni eth0 host
On the rpi4 I run: tcpdump -ni eth0 host

Or in other words, each pi will print any traffic it sees that's destined for, or originates from, the other pi.

Default behaviour
In the default configuration with the LAN interface containing devices lan1 - lan4, each pi can download things from the internet, ping the router, and similar, without network traffic being seen by the other pi. They can also send traffic directly to one another.

The problematic configuration
I create a br-trunk interface, assign devices lan1-lan4, then set both pi's to the same VLAN (untagged) -

For the LAN interface I also switch the member device to br-trunk.10 only.

Now, any network activity of either pi (or the router itself using the IP) is broadcast to all devices on the VLAN.

What I'm expecting
I thought that within the VLAN OpenWrt would still switch traffic. Have I configured this correctly?

What I want is to have one of my lanX devices be a VLAN trunk to another device, but OpenWrt is broadcasting VLAN traffic to all ports configured for a given VLAN. Is there another way to do this?

Thank you!

Let’s see the text config

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network

Also, why use 2 openwrt devices? You can achieve this with just one.

root@OpenWrt-spare:~# cat /etc/config/network 

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr ''
        option netmask ''

config globals 'globals'
        option ula_prefix 'fde9:ec85:c2a8::/48'

config device
        option name 'br-lan'
        option type 'bridge'

config interface 'lan'
        option proto 'static'
        option netmask ''
        option ip6assign '60'
        option ipaddr ''
        option device 'br-trunk.10'

config device
        option name 'wan'
        option macaddr '5a:ef:68:0f:29:58'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'

config device
        option type 'bridge'
        option name 'br-trunk'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'
        option ipv6 '0'

config bridge-vlan
        option device 'br-trunk'
        option vlan '10'
        list ports 'lan3:u*'
        list ports 'lan4:u*'

I don't plan to run with two OpenWrt devices, this second one is just running to debug this problem. My primary router has the same issue, but with a much more complicated config.

This is the broken kernel on 22.x mvebu; resolved with 5.15 on master.

I'm not seeing anything immediately wrong with the config itself, but as @anomeome said, there is a bug in the kernel that could be responsible for this.

That said, there is no reason (currently) for using VLANs on this config since both ports are untagged/PVID. If you revert to the standard configuration, does the problem persist?

I switched to 21.02.5 (5.4 kernel) for that very reason. I thought that made me safe from that issue.

The problem goes away if I remove any VLANs and go back to the default of all switch ports listed as devices under the LAN interface. The configuration I want to get to will have 3 VLANs, this is just the simplest config I could make that recreates the problem.


If I'm not mistaken, the bug is fixed in the current master builds... have you tried those?

I haven't. I'll try that next.

Looks like it, just checked the git log and things were not disabled on 21.x. But the DSA support had some issues back in the 21.x time frame.