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...
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.
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 Nnot the VLAN tag itself.
You might try (though it should/might be defaulted already) adding, for each port
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. 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.
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...