RB4011iGS+ 802.1Q VLANs

Hi All,

I’m aware that the Realtek RTL8367 switch chip in the RB4011iGS+ is a little limited, however I have the following scenario:

ether2: Tagged 10,20,30 and Untagged 1
ether3: Tagged 10,20,30 and Untagged 1

Inter-VLAN routing is to be performed on the RB4011iGS+ itself, however there is also likely to be traffic between devices on ether2, ether3 within the same VLANs and I’d prefer to avoid switching that traffic via the CPU if possible.

I see under /interface ethernet switch vlan, I can assign ports to VLANs, but it’s not clear as to whether this is happening within the switch and if indeed these VLANs would be 802.1Q Tagged or not given that we don’t have the /interface ethernet switch [ ingress-vlan-translation | egress-vlan-tag ] options that we have on other devices.

What would the most effective way be to configure VLANs on the RB4011iGS+ such that traffic within the same VLAN does not traverse the CPU (assuming the same switch chip at least) and also transport the VLANs back to the CPU for inter-VLAN routing?

Thanks,
Jonathan

This device is expressly created for the purpose of using the CPU and vlans. You should configure it that way.

I have yet to see a reasonable explanation as to why they chose to downgrade the switch chips in favor of going with the CPU approach. Is the design that much different that it doesn’t need hardware offload or VLAN switching versus CPU?

Atheros switch chips support an additional header in traffic between the CPU and switch chip, together with Linux driver support this allows logical etherX interfaces to be multiplexed over the single communication channel to physical ethernet interfaces using port-based VLANs - this is completely hidden by the user interface, and can co-exist with 802.1Q VLANs.

Realtek and Mediatek switch chips do not have this functionality, so internally I expect Mikrotik are using 802.1Q VLANs to multiplex traffic from the CPU to physical ethernet interfaces. It would be possible to make a subset of VLAN IDs available to users, but Mikrotik have chosen not to do so. Another approach would be to do away with the logical etherX interfaces and always have to configure the switch chip - this is what you see if you install OpenWRT on supported Mikrotik hardware, for example, but would be a radical shift to the interface design Mikrotik have always used.

As to why they have changed to these switch chips, it could be for a number of reasons.

This is not entirely clear from the documentation, however after configuring it this way, the performance is pretty impressive. I can live with that as I have saved a lot of pain with the “/interface ethernet switch” configuration for VLANs that I’m used to on the CRS.