I am using a RB750 GL with ROS 6.43. ether1 is a trunk port with Vlan 1/100/200/300/400/500. ether2 should be a tagged trunk “out” so all the vlans from trunk ether1 are switched to ether2.
ether3-5 are untagged and should not be the focus of the question.
I can ping my mikrotik on IP 192.168.0.190. On ether2 there is another router on a stick attached with IP 192.168.0.229 on vlan1. Its also pingable.
So now if I change vlan mode of ether1 or ether2 to “secure” both pings fail suddenly. Can anybody expain this to me?
ether1 is connected to a HP 1820-24G switch, just for your information.
I think “secure” checks all the vlan tags on ether1 if they exist in the vlan table of the switch. I in my opinion they exist…
Using vlan-id=1 calls for trouble. I never found out for sure if that VLAN is considered untagged or not. I tried something similar and didn’t work. When I chose another VLAN id (e.g. 2), it just started to work.
Another thing: if you’re using vlan-header=add-if-missing, then you probably have to use default-vlan-id setting. Or else switch chip doesn’t know explicitly which VLAN id to add to untagged packets on egress.
Well I have already considered changing my homenet vlan to something else than 1 for all devices. But this is a lot for work to do I would like to find another solution/explanation
Another issue, I have just noticed that my vlan100 is not forwarded to the router on the stick on ether2. There a DHCP client does not get an ip Just vlan1 is working.
The point is that Mikrotik’s software bridge (/ip interface bridge) supports tagless frames internally, which normal switches don’t. So if you forget about the switch chip for a moment, and you imagine what happens when vlan-filtering=yes on a bridge and a tagless ingress frame comes to an ethernet port which is a member port of that bridge. On a “normal” switch, the pvid setting of that port (or its equivalent in the vocabulary of another manufacturer) determines with what VLAN ID the frame will be tagged, and that’s it, no more mysteries.
On Mikrotik, this works too, except if the pvid of the port matches the pvid of the bridge of which the port is a member - in such case, the tagless frame from the wire makes it to the bridge itself tagless; consistently, also a frame which came tagged from outside with a VID matching bridge’s pvid value will get untagged. So if pvid of /interface bridge is set to N, attaching an /interface vlan with vlan-id=N to that bridge won’t work because no frame tagged with VID N will ever arrive to the tagged side of the /interface vlan (which is another “member port” of the bridge).
It is not clear to me how the above works with vlan-filtering=no on the bridge, which is how you currently run it - I know that the /interface bridge port and /interface bridge vlan settings are ignored in such case but whether the pvid value of /interface bridge is ignored as well is not clear to me.
Now as Metod wrote above, vlan-header=add-if-missing should be paired with explicitly setting default-vlan-id to 1, because nobody really knows what the default auto means. Even worse, the current revision of the Switch chip wiki states that the 8327 actually ignores the vlan-header setting and only looks at default-vlan-id for both ingress and egress.
So if you set it that way and keep vlan-filtering=no for the bridge (which you have to do as setting it to yes disables the “hardware acceleration”, i.e. disables frame forwarding by the switch chip itself), there is a good chance that the switch chip will tag tagless ingress frames with VID 1, the bridge won’t touch them, and the /interface vlan vlan-id=1 will receive them. But it is not a sure thing; if it does not work, set the bridge’s pvid value to some VID unused in your network and see whether it helps.
Hm a bridge with disabled VLAN filtering does not have a PVID. Or am I misunderstanding something? You simply cannot set them.
Now I have added a vlan100 interface on my bridge. A dhcp client on this interface does not get an IP address. It should work because VLAN id 100 is attached to switch1cpu in the swich menu. What do you think?
You have to add switch-cpu to the list of ports in switch vla for VLAN id 100 … or else switch chip doesn’t communicate it with bridge. This part is missing from config you posted above.
@Jotne, forget about bridges in this particular case, the OP wants to make VLAN filtering work in hardware, which the 8327 “chip” (actually, a functional block within an SoC) in RB750GL can do (provided that you don’t require any STP flavor to run). So the bridging part is there only to make the local /interface vlan work, the rest is handled by the switch “chip” itself.
if you want to use hw offloading, put every port in coresponding bridge, configure each port in switch chip as secure including switch chip. Every VLAN that needs to reach the router must be configured in switch vlan.
leave one port extra for management until everything works!
B…dy export where the switch ports are identified by id (0 to 5) rather than name.
Never mind - this way you’ve set the switch1-cpu port to behave as an access one for VID 1, i.e. prior to being sent to the CPU, frames tagged with VID1 get untagged. So set default-vlan-id for switch1-cpu to 0 instead of current 1 and you should be good, because frames tagged with VID 1 will stay tagged on the bridge, so the /interface vlan vlan-id=1 will get them the way it can recognize them.
The other posssibility is to keep the switch1-cpu port configuration as-is (with default-vlan-id=1) and re-attach the IP configuration (IP address and DHCP server) from /interface vlan vlan-id=1 (which thus becomes useless) to the /interface bridge itself. That means that internally the VID 1 will exist tagless.
Great it works! Thanks a lot! I struggled a lot with this new vlan/bridge and hardware offloading stuff, it a steep learning curve
Maybe the mikrotik guys should add such a config to the wiki, I think a lot of people are having issues here..
I would like to find another solution/explanation