AR934X on MikroTik hEX lite - Software Bridge

Hello there.

I'm having large problems setting up a software bridge with the AR934X switch on a MikroTik device. In particular, I'm using the openwrt-image from ***. I'd like to pass all frames to the operating system and handle them there. As a first step, I created 4 VLANs, set each LAN-Port to untagged & the CPU-Port to tagged on each VLAN ID. In addition, I created an interface, added all 4 VLAN interfaces (eth1.2 to eth1.5) and enabled "bridge interfaces". However, nothing really works as inteded...

The pic shows the configuration in more detail. My /etc/config/network file: https://nopaste.xyz/?d880bb9f0ad17d83#eUdmQX4FMIo44r/x7QJl4j1e/yuAfIzBnqUGQ7JkXuY=

Here is the problem: On the software-side, things work as intended. The VLAN interfaces receive the packets, and they are switched correctly to the correct outgoing interface. I checked that with tcpdump. However, the devices that are connected to these ports don't receive these packets consistently. It's like only one of the output ports works at a time, and the working one changes randomly as I send pings through them, without changing any configuration...

My guess is that the operating system is supposed to send an untagged frame via eth1.X, which should be tagged with X by a random part in the system before it is sent to the switch via eth1, which should correctly distribute it (untagged) to the correct physical port. What did I do wrong? I'm testing random configurations for more than a week now...

The worst part is that I seem to remember that it worked when I first tested it, but I can't seem to recover that configuration now.

Thank you in advance!

On a phone screen here, but the two things I’d try are:

  • Change option vlan = option vid for sanity (since all your numbers are small)
  • Add PVID to each port, even if not required (I don’t recall if you specify by reference to the vlan option or to the VLAN tag itself.)

At least as I understand how swconfig and UCI interact, the PVID confused me immensely when I worked through it the first time.

Hi, thanks for the suggestions. I basically streamlined everything in the file, it now looks like this:

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdd4:09e6:220d::/48'

config interface 'lan'
	option type 'bridge'
	option proto 'none'
	option auto '1'
	option force_link '1'
	option ifname 'eth1.2 eth1.3 eth1.4 eth1.5'

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

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0t 1'
	option vid '1'

config interface 'Management'
	option proto 'static'
	option ifname 'eth0'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option gateway '192.168.1.2'
	option dns '8.8.8.8'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option vid '2'
	option ports '0t 2'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '3'
	option ports '0t 3'

config switch_vlan
	option device 'switch0'
	option vlan '4'
	option vid '4'
	option ports '0t 4'

I restarted the network, but the problem remains. :confused:

OK, back on the big screen. When I look at my switch config here, I have each port with option pvid N where N is the same as that in option vlan N not the VLAN tag itself.

You might try (though it should/might be defaulted already) adding, for each port

config switch_port
        option device 'switch0'
        option port '3'
        option pvid '3'

just to make sure.

Hi again,

I did not really know that separate switch_port blocks existed. Now I basically added these four blocks to my config file:

config switch_port
        option device 'switch0'
        option port '1'
        option pvid '1'

config switch_port
        option device 'switch0'
        option port '2'
        option pvid '2'

config switch_port
        option device 'switch0'
        option port '3'
        option pvid '3'

config switch_port
        option device 'switch0'
        option port '4'
        option pvid '4'

Restarted the network... and nothing changed. The packets (ARP replies in my case) are still sent out of the virtual interfaces and never received by the device behind the port.

Maybe I should add that switching via hardware works perfectly, if I add all ports to the same VLAN. However, I need them to be handed to the Operating System... I believe that this can't be such a serious problem, if it was a bug, I can't possibly be the first one to discover such a basic thing. On the other hand, there is not so much room for error within that little of configuration...

I've got an update. The above problem could not be solved, but I rather found a workaround. I think what happens here is that some mappings (ARP?) are messed up due to multiple entries in both the bridge-interface and the virtual eth1.X interfaces.

I have now setup one interface for each of the 4 VLANs in the system, and each interface only contains that one eth1.X virtual interface that it's created for. Anyway, I enabled the software bridge for this single-port interface. I tested pinging around with the -I parameter to specify exactly what outgoing interface is being used. If I use eth1.X as outbound interface (as intended, if I understand the system correctly), the messages are correctly received on the other and and answered (with an ARP reply), but this answer is never accepted by the OpenWRT box. If I use the bridge-interface instead (that should only contain that one eth1.X interface anyway), messages are both received and sent correctly on both ends. (In fact, ARP requests are never event sent out in that scenario because both SSH and the web GUI are already open for quite some time.)

My plan is now to create another bridge that bridges the automatically-created bridge-interfaces... if you understand what I mean. :slight_smile: Anyway, if anyone has another guess on why only one of my virtual eth1.X interfaces works at a time, or if you need a more specific example... just come back here. :confused:

Edit: Back to business, it does not work as I described. Only pinging via explicit interfaces produces packets, but the regular bridge functionality is still broken. The command ping -I my-bridge 1.1.1.1 does produce valid packets that can be received on all interfaces. If I attempt to use the bridge as a bridge (independently of whether it's a regular linux with brctl or an OpenFlow bridge with ovs-vsctl), I can observe all frames that should be there with tcpdump on that bridge's interface, but only one of my connected devices actually receives the packets...