Nathan, thanks for the reply, yes I agree the proposed solution would work as long as one does not mind that vlan10 frames leak out of the interface ether1. This is not necessarily a problem but is a bad practice. + I'm sure that spanntree will not work correctly in this case. (but than again it never does
I was aware of the possibility to add vlan interfaces on top od the bridge and frankly this is what I'm using right now except with a slight variation on your proposed solution
It is interesting that the "real" solution would be possible with router of if only one could create a vlan interface by specifying that this particular vlan interface should not be tagged. Then we would proceed as usual by creating per vlan bridges.
code could look like this:
/interface bridge
add name=untagged-bridge disabled=no
add name=vlan10-bridge disabled=no
/interface vlan
add interface=ether3 name=ether3-vl10 vlan-id=10 disabled=no
add interface=ether4 name=ether4-vl10 vlan-id=10 disabled=no
add interface=ether5 name=ether5-vl10 vlan-id=10 disabled=no
add interface=ether3 name=ether3-vl1 vlan-id=1 disabled=no [b]tagged=no[/b]
add interface=ether4 name=ether4-vl1 vlan-id=1 disabled=no [b]tagged=no[/b]
add interface=ether5 name=ether5-vl1 vlan-id=1 disabled=no [b]tagged=no[/b]
/interface bridge port
add bridge=untagged-bridge interface=ether1 disabled=no
add bridge=untagged-bridge interface=ether3-vl1 disabled=no
add bridge=untagged-bridge interface=ether4-vl1 disabled=no
add bridge=untagged-bridge interface=ether5-vl1 disabled=no
add bridge=vlan10-bridge interface=ether2 disabled=no
add bridge=vlan10-bridge interface=ether3-vl10 disabled=no
add bridge=vlan10-bridge interface=ether4-vl10 disabled=no
add bridge=vlan10-bridge interface=ether5-vl10 disabled=no
this could be implemented in routerOS very quickly. the only question would be how would a router realize that the untagged ingres traffic on say ether5 should be destined to ether5-vl1 rather than ether5.
I've seen a number of vendors solving this problem in a different ways. Some better than others. My personal favorite is the introduction of so called native-vlan feature which may lead to other design problems.
ultimately I propose that Mikrotik develpers agree on the following:
1. ethernet is almost everywhere. Mikrotik does not support any of the legacy l2 networks such as FR or ATM or TR or FDDI DPT etc.
2. the only tiny bit of legacy is left in the PPP and its variants: pptp l2tp pppoe.
3. therefore the need for "bridgeing" is almost exclusively related to bridgeing between ethernet networks. current "int bridge" syntax may remain for before mentioned reason, however new syntax is needed for ethernet ports as:
4. ...as soon as people have ethernet interfaces they will want vlans and other ethernet specifics like ether-channel...
5. ...and there are MT products with lots of ethernet ports. most likely Mikrotik will produce products with even more ethernet ports in the future.
therefore it makes sense that "ethernet friendly" commands are introduced. my proposal is that Mikrotik follows analogies from other l3 switching vendors. this would mean the introduction of vlans as separate entities, allocation of vlans to physical and ether-channel interfaces and the intruduction of l3 vlan interfaces.
this would break the existing Mikrotik syntax where every interface can be turrned into l3 interface (by assigning an IP address to it) by introducing an additional layer between physical interfaces and l3 interfaces int the Mikrotik RouterOS code, which would allow for creation of vlans and ether-channel and whatever else is out there....
