The only mistake I can spot is that under /interface bridge port, you haven't set the pvid for the access ports ether4 and ether5.

So you have to add the pvid parameter to these lines in accord with the rules under /interface bridge vlan:

/interface bridge port
set [find interface=ether4] pvid=100
set [find interface=ether5] pvid=200

The point is that /interface bridge vlan only defines filtering, but the pvid which has to be untagged on egress and tagged to on ingress must be configured under /interface bridge port.

If tagged packets do not pass between ether2 and ether3 with this configuration, I believe the issue is not the Mikrotik configuration but something else.

Not sure I understand your last sentence. I am trying have VLAN 100 and 200 present (egress?) on ether2 to and 3 to pass tagged to a downstream switch. The Tags simply aren't there. I can confirm this with a test downstream switch and a Netool.io scan device. When I use your option 1 from the first link that defines a bridge for each VLAN it works correctly and the tags pass.

Also - I assume this does not use any of the HW offload and is lower performance? Is the switch/vlan a better place to try and do this?

/interface ethernet switch port
set [find name=ether2] default-vlan-id=1 vlan-mode=secure
set [find name=ether3] default-vlan-id=1 vlan-mode=secure
set [find name=ether4] default-vlan-id=100 vlan-mode=secure
set [find name=ether5] default-vlan-id=200 vlan-mode=secure

/interface ethernet switch vlan
add ports=ether2,ether3,ether4,ether5,switch1-cpu switch=switch1 vlan-id=100
add ports=ether2,ether3,ether4,ether5,switch1-cpu switch=switch1 vlan-id=200

Not sure I understand your last sentence. I am trying have VLAN 100 and 200 present (egress?) on ether2 to and 3 to pass tagged to a downstream switch. The Tags simply aren't there. I can confirm this with a test downstream switch and a Netool.io scan device. When I use your option 1 from the first link that defines a bridge for each VLAN it works correctly and the tags pass.

So what you say is that if you ping from the local IP address 192.168.100.1 assigned to interface=vlan100 to some other address in Vlan 100, i.e. in the 192.168.100.0/24 subnet, you can see the arp requests for that other address coming from 192.168.100.1 as tagless on ether2 and/or ether3 when you use the "one bridge all vlans" configuration, but you can see them tagged when using the "one bridge per vlan" configuration?

That is very strange to put it softly. I admit I haven't tested that on 6.42.3 but I did on previous "current" versions and it works properly there.

Also - I assume this does not use any of the HW offload and is lower performance? Is the switch/vlan a better place to try and do this?

Well, that's a topic where I miss some bits. In general on devices with 8337/8237/8227 switch chips, switching vlan-filtering to yes on bridges disables the hw-offload (forwarding of frames by the switch chip itself). The reason is that all the tagging and untagging has to be done in software because these switch chips are not sophisticated enough to distinguish STP frames from other tagless frames and treat them differently. So yes, with vlan-filtering=yes on a bridge, even when a frame is forwarded between two Ethernet interfaces of the same switch chip, it goes via the CPU, so the total bridging throughput is limited. In this mode, the frames are left unchanged on the switch, except that a proprietary tag is added to indicate the port ID on ingress to inform the CPU about the ingress port, and the CPU uses the same proprietary tag to address the egress port when sending the frames out.

When you disable vlan-filtering, set protocol=none and hw-offload=yes for that bridge alone, you can configure the switch chip to do tagging/untagging and vlan filtering on the member ports of that bridge, but I'm not sure how exactly the frame exchange with the CPU looks like in that case. Nevertheless, if you make the CPU port of the switch chip a member of all VLANs you want to create /interface vlan for and keep the /interface bridge port configuration unchanged as if the switch chip was not doing any filtering, the switch chip forwards frames directly between the ports and does the vlan filtering.

So the switch chip configuration would look something like

Code: Select all

/interface ethernet switch port
set [find name=ether2] default-vlan-id=1 vlan-mode=secure
set [find name=ether3] default-vlan-id=1 vlan-mode=secure
set [find name=ether4] default-vlan-id=100 vlan-mode=secure
set [find name=ether5] default-vlan-id=200 vlan-mode=secure

/interface ethernet switch vlan
add ports=ether2,ether3,ether4,ether5,switch1-cpu switch=switch1 vlan-id=100
add ports=ether2,ether3,ether4,ether5,switch1-cpu switch=switch1 vlan-id=200

On my-bridge, you must set hw-offload to yes and vlan-filtering to no to make this work; the /interface bridge ports configuration must remain unchanged, the /interface bridge vlan configuration may be kept unchanged but its items related to bridges with vlan-filtering=no are ignored.

One remark here, you've mentioned 3011 but your configuration export reveals you actually use a 2011, where the second switch chip (ether6-ether10) is an 8227, and that one doesn't support hybrid ports so the configuration for /interface ethernet switch port looks slightly different depending on whether you want the port to be a trunk one or an access one. Another difference is that the 8227 does not support independent learning of vlans (so if the same MAC address is accessible via different ports for different VLANs, the chip won't cope with it).

do it the old way...
RB3011 connections
ether1 - WAN
ether2 - Trunk 1 (V100, V200, V300)
ether3 - Trunk 2 (V100, V200, V300)
ether4 - access port vlan 100
ether5 - access port vlan 200


1. make a bridge. br1
2. add ether2 and 3 to the bridge.

3 make vlan 100 and 200 as port to the bridge. vlan100_br1 and vlan200_br1
4 make a bridge br_vlan100 and a br_vlan200

add vlan100_br1 to br_vlan100 and vlan200_br1 to br_vlan200

add ether4 to br_vlan100 and ether5 to br_vlan200