As of several years back, this was a limitation of the non-VLAN aware Linux kernel bridging. I haven’t tracked the issue since then in Linux, so I have no idea if any proposed solutions made it back into mainline kernels.
However, MikroTik COULD (and I encourage MikroTik to do it!) fix this problem.
Here’s an example Cisco IOS switch configuration:
interface FastEthernet0/1
description VLAN Trunk with native (untagged) VLAN
switchport trunk native vlan 100
switchport trunk allowed vlan 100,101
switchport mode trunk
!
interface FastEthernet0/2
description Access port (no tagging) on VLAN 100
switchport access vlan 100
!
interface FastEthernet0/3
description Access port (no tagging) on VLAN 101
switchport access vlan 101
!
It is CURRENTLY IMPOSSIBLE* to do this on a MikroTik switch.
Sure, I can make a trunk port and bridge one of the tagged VLANs:
...CURRENTLY NO WAY to somehow split out untagged packets from ether1...
/interface vlan add disabled=no vlan-id=101 interface=ether1 name=ether1_vlan101
/interface bridge add name=vlan100_bridge
...CURRENTLY NO WAY to bridge vlan100_bridge to interface ether1 UNTAGGED...
/interface bridge port add interface=ether2 bridge=vlan100_bridge
/interface bridge add name=vlan101_bridge
/interface bridge port add interface=ether1_vlan101 bridge=vlan101_bridge
/interface bridge port add interface=ether3 bridge=vlan101_bridge
A quick search turns up some proposed solutions to the 2009 Linux kernel state of affairs including:
http://www.mail-archive.com/bridge@lists.osdl.org/msg01440.html
As I mentioned above, I don’t know the current VLAN-awareness state of the Linux kernel.
However, MikroTik, even using the above proposed patches from 2009 could use that as a starting place to implement the ability to cleanly separate out untagged traffic from a physical interface that also has several tagged VLANs (a mixed trunk or a trunk with an untagged “native” vlan).
One proposed idea for implementing the CLI in RouterOS would be to treat VLAN 0 as a special placeholder for untagged packets (even though I think the 802.1q spec actually allows for packets with a VLAN tag header in VLAN 0 with special treatment):
/interface vlan add disabled=no vlan-id=101 interface=ether1 name=ether1_vlan101
/interface vlan add disabled=no vlan-id=0 interface=ether1 name=ether1_untagged
/interface bridge add name=vlan100_bridge
/interface bridge port add interface=ether1_untagged bridge=vlan100_bridge
/interface bridge port add interface=ether2 bridge=vlan100_bridge
/interface bridge add name=vlan101_bridge
/interface bridge port add interface=ether1_vlan101 bridge=vlan101_bridge
/interface bridge port add interface=ether3 bridge=vlan101_bridge
See that? One would essentially abuse the /interface vlan CLI command such that if vlan-id=0 were specified, it would indicate that all untagged packets received on that interface would belong to the named pseudo-vlan interface (and likewise packets outgoing from that pseudo-vlan interface would be untagged on transmission out the physical interface).
I’m sure there are many other ways to implement a user interface to such.
No matter which UI is used, PLEASE, MikroTik, PLEASE add the ability to separate out untagged traffic on a mixed trunk/trunk-with-native-VLAN!
This feature has been requested MANY times.
Thanks,
Aaron out.
P.S. Here’s another thread about this issue in which potential kernel patches were talked about: http://forum.mikrotik.com/t/vlan-truck-bridging-untagged-packets/31611/1