Question related to "RouterOS bridge mysteries explained"

@sindy I would like to ask a few questions please,

  1. If I understood correctly, there should be two “entities” capable of switching, the switch chip and the switching functional block in the cpu?

  2. Also when you specify a bridge in the tagged or untagged parameter in /interface bridge vlan does that apply for the router-facing port of the switch or the switch-facing interface of the router, or both?

/interface bridge add name=bridge1
/interface bridge port add bridge=bridge1 interface=ether2
/interface bridge port add bridge=bridge1 interface=ether3
/interface bridge port add bridge=bridge1 interface=ether4
/interface vlan add vlan-id=10 interface=bridge1
  1. And after I issued these command it should look like the image below?(excluding switch chip because I still didn’t understand that yet)
  2. I drew the bridge as another seperate “entity” running inside the switch functional block because I think that the switch functional block is always there and is only used when the bridge is created. Is this correct?
    Bridge Schematics4.png

So if I issue my Router these command

/ip add add interface=ether2 address=192.168.1.254
/interface vlan add vlan-id=10 interface=ether2

Say I have a switch connected to my Router that sends tagged frames with vlan id 10, when my router receives the frames and sends the reply to the switch, does my router tags the frame it about to send to the switch with vlan id 10 or is it the switch’s duty to tag the reply coming from my router?

When port is used as stand-alone, then switch-chip passes frames to CPU (via cpu-facing bridge port) as they are … then CPU does VLAN header manipulations (via VLAN interfaces attached to such stand alone port). So in this case no L2HW offload.

It’s rather similar when bridge is used … and L2HW offload works. CPU still does VLAN tag manipulations for traffic, passing between CPU and cpu-facing bridge port if the later is anything but access port with PVID set …

So in short: offloaded to switch chip is only what’s configured under /interface/bridge (or on devices eligible anything configured under /interface/ethernet/switch).

  1. As @mkx has already kindly explained, the switch chip is integrated into the operation of the software bridge as seamlessly as was possible, so the overall functionality does not depend on whether the switch chip is present or not and whether hardware forwarding is enabled on a particular port or not. If you want to know the fine details, most switch chips that Mikrotik uses support also proprietary tags that indicate the ingress port of frames they forward to the CPU and allow the CPU to specify which egress port to use for frames it sends. So if ether2 is not configured as a member port of any bridge, the frames the CPU wishes to send via ether2 are still forwarded by the switch chip, but bypassing its local forwarding decision it would otherwise make using its MAC address table. The same thing happens if ether2 is a member port of a bridge but hardware forwarding is disabled for it. The switch chip itself is only allowed to forward traffic among all the member ports of the same bridge on which hardware forwarding is active. But even in such case, all what I wrote in my original posting remains valid, because most of it deals with the communication between the “virtual switch” and “virtual router”, i.e. not with the external ports.

  2. referencing the bridge in the untagged or tagged list on a row in /interface bridge vlan only controls the behavior on the router-facing port of the switch.

  3. if you want frames belonging to VLAN 10 to make it tagged to the router, the router-facing port of the switch must be on the tagged list on the row whose vlan-ids includes 10. In the router, you attach an /interface vlan with vlan-id=10 to the switch-facing interface of the router to provide the routing stack with access to untagged frames that belong to VLAN 10.

So assuming that

  • ether1 and the router-facing port of the switch are access ports to VLAN 1,
  • ether5 is an access port to VLAN 10,
  • the router-facing port of the switch is a trunk port of VLAN 10,
  • /interface vlan vlan-ids=10 name=bridge.vlan10 is attached to the switch-facing interface of the router,

the following happens:

  • an untagged frame that arrives to ether1 gets tagged with VID 1 as it enters the virtual switch and untagged again as it egresses towards the router via the router-facing port of the switch;
  • in the router, the untagged frame carrying an IP packet arrives to the switch-facing interface of the router so the IP stack can see it there.
  • an untagged frame that arrives to ether5 gets tagged with VID 10 as it enters the virtual switch and stays tagged as it egresses towards the router via the router-facing port of the switch;
  • in the router, the IP stack ignores the frame on the switch-facing interface of the router because it is tagged, but the /interface vlan with vlan-ids=10 that is attached to the switch-facing interface of the router takes the frame, untags it, and offers the untagged one to the IP stack at its untagged end.
  1. as explained above, on your drawing, the /interface vlan is on a wrong place and with a wrong orientation. There is a plain “wire” between the router-facing port of the switch and the switch-facing interface of the router - all tagging and untagging takes place in the virtual router and in the virtual switch. As explained “even more above”, if something, then a switch chip is a functional block inside the software bridge rather than the other way round, as the hardware switch provides just part of the overall functionality of the bridge.

In this example, the /interface vlan is attached directly to ether2, which therefore must not be a member port of any bridge to avoid unexpected behavior. If the router replies from an IP address 192.168.1.254, which is attached to ether2 itself, it encapsulates the IP packet into an untagged frame that then leaves via ether2 to the external switch. But if e.g. an IP address 192.168.97.5 was attached to the /interface vlan with vlan-id=10 and the router was responding from that address, the /interface vlan would get the IP packet encapsulated in a untagged frame from the IP stack and tag it with VID 10 prior to sending it out via ether2 to the external switch.

In the router, you attach an /interface vlan with vlan-id=10 to the switch-facing interface of the router to provide the routing stack with access to untagged frames that belong to VLAN 10.

And to attach a vlan interface to the switch-facing interface of the router is to attach the vlan interface to the bridge right?

/interface vlan add vlan-id=10 name=vlan10 interface=<bridge-name-here>



an untagged frame that arrives to ether1 gets tagged with VID 1 as it enters the virtual switch and untagged again as it egresses towards the router via the router-facing port of the switch

This means that Ether1 and Ether5 has to be a part of a bridge in order to work with vlan?
So assuming Ether1 is a part of a bridge, then when a frame enters Ether1 it gets tagged with vlan id 1, but the router-facing port of the switch is a trunk port with vlan id 10, so why is it able to egress a frame that doesn’t have vlan id 10?

ether1 and the router-facing port of the switch are access ports to VLAN 1



the router-facing port of the switch is a trunk port of VLAN 10

Is it because you said that the router-facing port of the switch is an access port with vlan id 1? So in this case is the router-facing port of the switch a hybrid port?

In this example, the /interface vlan is attached directly to ether2, which therefore must not be a member port of any bridge to avoid unexpected behavior. If the router replies from an IP address 192.168.1.254, which is attached to ether2 itself, it encapsulates the IP packet into an untagged frame that then leaves via ether2 to the external switch. But if e.g. an IP address 192.168.97.5 was attached to the /interface vlan with vlan-id=10 and the router was responding from that address, the /interface vlan would get the IP packet encapsulated in a untagged frame from the IP stack and tag it with VID 10 prior to sending it out via ether2 to the external switch.

So if a ping packet is coming with a destination of 192.168.1.254, I think it will reach the destination and the reply will be sent without any vlan tags
If another ping packet comes with a destination of 192.168.97.5 and encapsulated with vlan header with vlan tag of 10, I think it will also reach the destination and the reply will be sent with a vlan tag of id 10
But if another ping packet comes with a destination of 192.168.1.254 but this time also encapsulated with vlan header with vlan tag of 10, would it still be able to reach the destination? If so, would the reply be sent with vlan tag 10?

@HeptaZ, did you read through excellent Using RouterOS to VLAN your network tutorial?

Because most of discussion in this thread is about VLANs and they are explained pretty well in the tutorial I linked above.

Right.


To be able to work with VLAN - no, to conform to the example - yes. Any L2 interface can physically pass both tagged and untagged frames, the question is the internal configuration - whether an /interface vlan and/or IP configuration are attached to that L2 interface directly or whether the L2 interface is configured as a member port of a virtual switch and what are the VLAN settings relevant for that port in the bridge configuration (intentionally leaving bonding aside). But the rule is - no IP configuration and no VLAN interfaces can be directly attached to an L2 interface that is a member port of a bridge or of a bond.


Different vendors name the port roles with regard to VLANs differently - some use the “hybrid port” name, some don’t. So “access port for VLAN x” means to me that frames that belong to VLAN x are untagged on the wired side of such a port and tagged on the silicon side (i.e. they get tagged on ingress, wire->silicon, and untagged on egress, silicon->wire), whereas “trunk port for VLAN y” means that the frames that belong to VLAN y are tagged both at the wired side and at the silicon side (no tagging or untagging takes place). So indeed, in the example, the router-facing port of the switch is hybrid (access for VLAN 1 and trunk for VLAN 10) - and, if you want to put it that way, so is the switch-facing interface of the router.



OK, so apparently I have oversimplified the previous answer. The router will respond a ping to any of its own addresses, no matter how it came in, provided that the IP stack could see it in an untagged form. So if a packet for 192.168.1.254 arrives encapsulated in a frame tagged with VID 10 through interface X and there is an /interface vlan with vlan-id=10 attached to interface X and there is some IP address attached to that /interface vlan, making it an IP interface of the router, and if the address 192.168.1.254 is attached to any interface of the router (intentionally omitting VRF), the router will receive the packet. However, unless you take quite a lot of configuration effort, which interface the router will use to send the response to that request packet has nothing to do with how exactly that request got in - the routing normally does not even know that the packet it is told to find a route for is a response to some other packet. So the response will take the route that has been statically or dynamically configured towards the source address of the request, because what the responding application has asked the routing to do was “send this packet to this address”. If that route uses an IP address in the same subnet like the 192.168.1.254 as a gateway, the response will be sent from ether2 untagged; if that that route uses an IP address in the same subnet like the 192.168.97.5 as a gateway, the IP stack will use the /interface vlan to which 192.168.97.5 is attached to send the packet, so the frame carrying it will get tagged with VID 10 prior to being sent out via ether2.

I did, but I just wanted to make sure that I didn’t miss anything and in the documentation above, there isn’t really much reasoning as to why you would issue certain commands.

@sindy Thank you for answering! :slight_smile:

  1. referencing the bridge in the untagged or tagged list on a row in /interface bridge vlan only controls the behavior on the router-facing port of the switch.

Hi.
Sorry to revive old post, but isn’t the other claim also true : specfiying bridge itself as tagged parameter in /interface bridge vlan , is ALSO used on a ROUTER (when it is doing inter vlan communication) - like in the pcunite post example (http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1)

or in other words you add bridge itself as a tagged member for traffic which interacts with services provided by the cpu of router (that is, traffic which needs l3 services) - like in a router on a stick setup.

p.s. and am i corrent to say that in the case of switch, adding brdige interface itself as tagged memeber in /interface bridge vlan, is used when you want to access the switch for management (vlan99 interface), and also if the switch itself is doing inter-vlan routing (like l3 switch)

Thanks, in advance

The whole OP was aimed to explain that in fact, there is no single “bridge itself”, because the “bridge” term actually represents three distinct functional entities that are tightly linked to each other, and that a clear distinction between these entities in the respective contexts is critical for understanding how it all works together. And that the fact that the settings related to all these entities have been groouped together on a single configuration row is a consequence of an (overly optimistic) assumption that the users do understand the underlying architecture.


From the point of view of required bridge and VLAN settings, there are just two cases: either the routing part of the device needs to access a given VLAN or it doesn’t. What exactly the router does next with the traffic it has received via a particular VLAN doesn’t change anything about how the bridge and VLANs have to be configured.


What has changed since I’ve written the original post of this topic is that RouterOS now automates a lot more tasks than back then, but that does not change the architecture. Back then, if you attached a VLAN “subinterface” to the “switch-facing interface of the router”, you had to also add the “router-facing port of the bridge” to the tagged list on the /interface bridge vlan row for that VLAN; since ROS 7.16 at least, ROS does the second dynamically.

So now, if you need the routing part to access VLAN 234, it is enough to use /interface vlan add interface=bridge vlan-id=234 name=my234vlan and if you use /interface bridge vlan print, you will see something like this:

[me@myTik] > interface/bridge/vlan/print
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
...
;;; added by vlan on bridge
3 D bridge       234  bridge

“What has changed since I’ve written the original post of this topic is that RouterOS now automates a lot more tasks than back then, but that does not change the architecture. Back then, if you attached a VLAN “subinterface” to the “switch-facing interface of the router”, you had to also add the “router-facing port of the bridge” to the tagged list on the /interface bridge vlan row for that VLAN; since ROS 7.16 at least, ROS does the second dynamically.”

ah you mean i dont need this anymore (from OP)
/interface bridge vlan
add bridge=bridge-row-name vlan-ids=10,… tagged=bridge-row-name,…

p.s. i have just realized i made big mistake, by thinking all the time that you were reffering in OP to router and a switch as a seperate mikrotik devices (and not one device with routing and switching parts..) :unamused:
i just got entagled in all of this last few days, i will now go over it again few days until i hopefully understand it

edit: i have just tried your example with vlan234, but /interface/bridge/vlan/print says in vlan-ids column : 1 (vlan1)
but then again i am using gns3 routeros 7.8 maybe it works different..

Thanks for explanations anyway

You have to pay attention to details: as @sindy already wrote: the example works since ROS version 7.16 … 7.8 doesn’t have that feature.

got it finally :slight_smile: just to make some observations of this post,and parallels, to lets say cisco

  1. As soon as you make bridge and enable vlan-filter, router-facing port of the switch has default pvid=1 (ingress behaviour) and is untagged for vlan1 (egress behaviour)

  2. Switch-facing interface of the router, can have its own ip address, by binding an ip address to bridge itself (/ip address/add address=x.x.x.x interface=bridge) and accepts untagged frames (from vlan1 by default), and it can also have vlan-subinterface (just like in cisco) for particular vlan, by defining parent interface as bridge itself(/interface vlan add interface=bridge vlan-id=…), which will receive tagged frames for that vlan.
    I realised this when i was wondering how to make VLAN1 interface - there is no need to - it is there by default, i just need to add ip address to it, by adding address to bridge itself, but…
    3…if i make bridge,enable vlan filter, assign an ip address to bridge (/ip address/add address=1.1.1.1/24 interface=bridge), assign port eth1 to bridge in access mode vlan1. I can ping 1.1.1.1 from eth1. If i add now vlan1 interface explicitly /interface/vlan add interface=bridge name=vl1 vlanid=1, and assign ip address to it (/ip address add address=1.1.1.2/24 interface=vl1), now i can ping 1.1.1.2 , and can not ping 1.1.1.1.
    I would expect to need to make router-facing port of the switch tagged for vlan1, in order to reach vl1 interface, but it works without that, AND works with it also (/interface bridge vlan/add tagged=bridge vlanid=1), so i am not sure about that part.
    And for not being able to ping 1.1.1.1 now, that i realised is because the fact that i created vlan1 last, so its route is first in ip route list - if i remove bridge interface 1.1.1.1, and add it again, then its route will be first in route table, so now i can ping 1.1.1.1 but can not ping 1.1.1.2

The router will respond a ping to any of its own addresses, no matter how it came in, provided that the IP stack could see it in an untagged form. So if a packet for 192.168.1.254 arrives encapsulated in a frame tagged with VID 10 through interface X and there is an /interface vlan with vlan-id=10 attached to interface X and > there is some IP address attached to that /interface vlan> , making it an IP interface of the router, and if the address 192.168.1.254 is attached to any interface of the router (intentionally omitting VRF), the router will receive the packet.

I think this is not corret - router will not accept packet tagged with id10(destined for 192.168.1.254), unless that ip address from above quote is not from the same subnet

mikrotikrouter(has interface ether2 and subinterface ether2.10) ether2 ----f0/0 cisco router (has f0/0.10 subinterface in vlan10 )
ether2 ip = 192.168.1.254
ether2.10 ip =10.10.10.254
f0/0.10 ip =192.168.1.1
When cisco pings 192.168.1.254, tagged frame with id10, comes to ether2, but there is no vlan10 interface on mikrotik with same subnet (192.168.1.0) so the mikrotik router will not accept frame, and ping doesnt work

p.s. tested it all in gns3 with chr routeros 7.8

edit: i have found an answer to my 3rd question: point is, bridge itself (swith facing interface of router) will accept untagged frames, and if you make vlan1 interface with /interface/vlan command, it expects tagged frames with tag=1 (so you need to add /interface/bridge/vlan tagged=bridge vlan-id=1 , but then you cant ping bridge address of 1.1.1.1). The reason i could sometimes ping vlan1 and sometimes bridge, is because pc rememberd mac address of bridge(or vlan1) in its arp table, and was sending icmp request immidiately without an arp reques. also the router itself had populated ip arp table. interesting fact: if pc sends icmp request immidiatley (without arp) to mac dest addres of vlan1 interface, it will come to vlan1 interface and it will respond, even if i removed /interface/bridge/vlan tagged=bridge vlan-ids=1 command (and thus icmp will come untagged to switch facing port of router, and since it is already destined for vlan1 mac address, vlan1 subinterface will receive it).
So forget about this question . Tnx sindy and others for clarifying this topic.

1 Like

This is something I think that ROS should not allow you to do, at least not without a dire warning.

Specifically, ROS should not allow you to:

  1. Create a vlan interface on bridge and have the vlan-id of the vlan interface be the same as the pvid of the bridge.
  2. Set the pvid of the bridge to the same vlan as an existing vlan interface under the bridge.

Allowing both tagged vlan1 and native vlan 1 on the same trunk creates a situation where there are multiple representations (framing) for the same vlan on the trunk link. And that causes problems, and these problems are hard to troubleshoot without wireshark, and not possible to actually tap what's on the "virtual trunk" between the router block and the virtual switch. This is discussed some in the Bridge PVID topic, I am sure other places, but that's the one I found.

Unless you use something like macvlan (similar to a secondary L2 mac address for a ethenet port), all vlans under a parent interface will use the parent's mac address. When ROS vlan-filtering is active, my understanding is that the bridge maintains separate mac address tables for each vlan (Independent VLAN learning (IVL) vs Shared VLAN Learning (SVL)). Because of this, I question your "explanation" of how cached arp was involved.

ROS shouldn't allow adding an ip address from the same subnet to two different interfaces (at least without VRF). Do both interfaces (bridge with pvid=1 with ip address 1.1.1.1/24 and vlan1 with vlan-id=1 with address 1.1.1.2/24) think they are in the same subnet? Did ROS really allow that? Were there connected routes for 1.1.1.0/24 on both bridge and vlan1? I can't think of a good use case for allowing the two interfaces to have ip addresses in the same subnet. Perhaps someone can provide a good use case. I think that ROS should should at least warn the user when they attempt to do this.

Some examples of what ROS as of 7.19.6 allows, that it should not.

  1. Allows creating vlan interface under bridge for same vlan as the bridge's pvid
  2. Allows changing bridges pvid to a vlan that there already exists a vlan interface on the bridge.
[demo@MikroTik] > interface/export 
# 2025-10-11 20:01:08 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > interface p   
ppp-client     ppp-server     pppoe-client     pppoe-server     pptp-client     pptp-server     print   
[demo@MikroTik] > interface pr
Flags: R - RUNNING; S - SLAVE
Columns: NAME, TYPE, ACTUAL-MTU, L2MTU, MAX-L2MTU, MAC-ADDRESS
#    NAME    TYPE      ACTUAL-MTU  L2MTU  MAX-L2MTU  MAC-ADDRESS      
0 R  ether1  ether           1500   1596       2026  DC:2B:AD:4D:EC:F1
1 RS ether2  ether           1500   1596       2026  DC:2B:AD:4D:EC:F2
2  S ether3  ether           1500   1596       2026  DC:2B:AD:4D:EC:F3
3  S ether4  ether           1500   1596       2026  DC:2B:AD:4D:EC:F4
4 RS ether5  ether           1500   1596       2026  DC:2B:AD:4D:EC:F5
5  S sfp1    ether           1500   1596       2026  DC:2B:AD:4D:EC:F6
6 R  br.200  vlan            1500   1592             DC:2B:AD:4D:EC:F2
7 R  br.210  vlan            1500   1592             DC:2B:AD:4D:EC:F2
8 R  bridge  bridge          1500   1596             DC:2B:AD:4D:EC:F2
9 R  lo      loopback       65536                    00:00:00:00:00:00
[demo@MikroTik] > interface bridge/pri
Flags: D - dynamic; X - disabled, R - running 
 0  R name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=DC:2B:AD:4D:EC:F2 protocol-mode=rstp fast-forward=yes 
      igmp-snooping=no auto-mac=no admin-mac=DC:2B:AD:4D:EC:F2 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 
      vlan-filtering=yes ether-type=0x8100 pvid=1 frame-types=admit-all ingress-filtering=yes dhcp-snooping=no port-cost-mode=long mvrp=no 
      max-learned-entries=auto 
[demo@MikroTik] > interface bridge/vlan print 
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge       200  bridge                          
                 210                                  
;;; added by pvid
1 D bridge       200                  ether2          
;;; added by pvid
2 D bridge         1                  bridge          
;;; added by pvid
3 D bridge       210                  ether5          
[demo@MikroTik] > # what ROS shouldn't allow
[demo@MikroTik] > interface vlan add interface=bridge vlan-id=1 name=br.1      
[demo@MikroTik] > interface export
# 2025-10-11 20:05:11 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
add interface=bridge name=br.1 vlan-id=1
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > interface print                                              
Flags: R - RUNNING; S - SLAVE
Columns: NAME, TYPE, ACTUAL-MTU, L2MTU, MAX-L2MTU, MAC-ADDRESS
 #    NAME        TYPE      ACTUAL-MTU  L2MTU  MAX-L2MTU  MAC-ADDRESS      
 0 R  ether1      ether           1500   1596       2026  DC:2B:AD:4D:EC:F1
 1 RS ether2      ether           1500   1596       2026  DC:2B:AD:4D:EC:F2
 2  S ether3      ether           1500   1596       2026  DC:2B:AD:4D:EC:F3
 3  S ether4      ether           1500   1596       2026  DC:2B:AD:4D:EC:F4
 4 RS ether5      ether           1500   1596       2026  DC:2B:AD:4D:EC:F5
 5  S sfp1        ether           1500   1596       2026  DC:2B:AD:4D:EC:F6
 6 R  br.200      vlan            1500   1592             DC:2B:AD:4D:EC:F2
 7 R  br.210      vlan            1500   1592             DC:2B:AD:4D:EC:F2
 8 R  bridge      bridge          1500   1596             DC:2B:AD:4D:EC:F2
 9 R  lo          loopback       65536                    00:00:00:00:00:00
10 R  br.1        vlan            1500   1592             DC:2B:AD:4D:EC:F2
[demo@MikroTik] > interface bridge/vlan print                                  
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge         1  bridge                          
                 200                                  
                 210                                  
;;; added by pvid
1 D bridge       200                  ether2          
;;; added by pvid
2 D bridge       210                  ether5          
[demo@MikroTik] > interface bridge print
Flags: D - dynamic; X - disabled, R - running 
 0  R name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=DC:2B:AD:4D:EC:F2 protocol-mode=rstp fast-forward=yes 
      igmp-snooping=no auto-mac=no admin-mac=DC:2B:AD:4D:EC:F2 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 
      vlan-filtering=yes ether-type=0x8100 pvid=1 frame-types=admit-all ingress-filtering=yes dhcp-snooping=no port-cost-mode=long mvrp=no 
      max-learned-entries=auto 
[demo@MikroTik] > interface vlan print
Flags: R - RUNNING
Columns: NAME, MTU, ARP, VLAN-ID, INTERFACE
#   NAME         MTU  ARP      VLAN-ID  INTERFACE
0 R br.200      1500  enabled      200  bridge   
1 R br.210      1500  enabled      210  bridge   
2 R br.1        1500  enabled        1  bridge   
[demo@MikroTik] > interface vlan remove br.1      
[demo@MikroTik] > interface vlan print            
Flags: R - RUNNING
Columns: NAME, MTU, ARP, VLAN-ID, INTERFACE
#   NAME     MTU  ARP      VLAN-ID  INTERFACE
0 R br.200  1500  enabled      200  bridge   
1 R br.210  1500  enabled      210  bridge   
[demo@MikroTik] > # now change pvid of bridge from 1 to 199
[demo@MikroTik] > interface bridge set bridge pvid=199 
[demo@MikroTik] > interface bridge print                   
Flags: D - dynamic; X - disabled, R - running 
 0  R name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=DC:2B:AD:4D:EC:F2 protocol-mode=rstp fast-forward=yes 
      igmp-snooping=no auto-mac=no admin-mac=DC:2B:AD:4D:EC:F2 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 
      vlan-filtering=yes ether-type=0x8100 pvid=199 frame-types=admit-all ingress-filtering=yes dhcp-snooping=no port-cost-mode=long mvrp=no 
      max-learned-entries=auto 
[demo@MikroTik] > # ROS shouldn't let us create a vlan interface on bridge with the same vlan-id as the bridge pvid          
[demo@MikroTik] > interface export
# 2025-10-11 20:13:36 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no name=bridge pvid=199 vlan-filtering=yes
/interface vlan
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > interface vlan add interface=bridge name=br.199 vlan-id=199 comment="Should not be allowed when bridge pvid=199"
[demo@MikroTik] > interface export                                                                                                
# 2025-10-11 20:15:39 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no name=bridge pvid=199 vlan-filtering=yes
/interface vlan
add comment="Should not be allowed when bridge pvid=199" interface=bridge name=br.199 vlan-id=199
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > interface vlan print
Flags: R - RUNNING
Columns: NAME, MTU, ARP, VLAN-ID, INTERFACE
#   NAME     MTU  ARP      VLAN-ID  INTERFACE
;;; Should not be allowed when bridge pvid=199
0 R br.199  1500  enabled      199  bridge   
1 R br.200  1500  enabled      200  bridge   
2 R br.210  1500  enabled      210  bridge   
[demo@MikroTik] > interface bridge vlan print
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge  199-200   bridge                          
            210                                       
;;; added by pvid
1 D bridge  200                       ether2          
;;; added by pvid
2 D bridge  210                       ether5          
[demo@MikroTik] > interface vlan remove br.199
[demo@MikroTik] > interface bridge vlan print 
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge       200  bridge                          
                 210                                  
;;; added by pvid
1 D bridge       200                  ether2          
;;; added by pvid
2 D bridge       210                  ether5          
;;; added by pvid
3 D bridge       199                  bridge          
[demo@MikroTik] > interface bridge port print
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, FAST-LEAVE, BPDU-GUARD, EDGE, POINT-TO-POINT, PVID, FRAME-TYPES
#    INTERFACE  BRIDGE  HW   HORIZON  TRUSTED  FAST-LEAVE  BPDU-GUARD  EDGE  POINT-TO-POINT  PVID  FRAME-TYPES
;;; defconf
0  H ether2     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
1 IH ether3     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
2 IH ether4     bridge  yes  none     no       no          no          auto  auto             199  admit-all  
;;; defconf
3  H ether5     bridge  yes  none     no       no          no          auto  auto             210  admit-all  
;;; defconf
4 I  sfp1       bridge  yes  none     no       no          no          auto  auto               1  admit-all  
[demo@MikroTik] > interface bridge print
Flags: D - dynamic; X - disabled, R - running 
 0  R name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=DC:2B:AD:4D:EC:F2 protocol-mode=rstp fast-forward=yes 
      igmp-snooping=no auto-mac=no admin-mac=DC:2B:AD:4D:EC:F2 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 
      vlan-filtering=yes ether-type=0x8100 pvid=199 frame-types=admit-all ingress-filtering=yes dhcp-snooping=no port-cost-mode=long mvrp=no 
      max-learned-entries=auto 
[demo@MikroTik] > # change bridge pvid back to default 1
[demo@MikroTik] > interface/bridge/set bridge pvid=1
[demo@MikroTik] > interface bridge print                
Flags: D - dynamic; X - disabled, R - running 
 0  R name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=DC:2B:AD:4D:EC:F2 protocol-mode=rstp fast-forward=yes 
      igmp-snooping=no auto-mac=no admin-mac=DC:2B:AD:4D:EC:F2 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 
      vlan-filtering=yes ether-type=0x8100 pvid=1 frame-types=admit-all ingress-filtering=yes dhcp-snooping=no port-cost-mode=long mvrp=no 
      max-learned-entries=auto 
[demo@MikroTik] > interface export
# 2025-10-11 20:22:57 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > # now that bridge pvid is not 199, we should be able to create vlan interface with vlan-id=119 (and we can)
[demo@MikroTik] > interface vlan add interface=bridge vlan-id=199 name=br.199
[demo@MikroTik] > interface export                                                                                           
# 2025-10-11 20:41:48 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=br.199 vlan-id=199
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > # but now we shouldn't be able to change the bridge pvid to 199 (but we can)
[demo@MikroTik] > interface/bridge/pr
Flags: D - dynamic; X - disabled, R - running 
 0  R name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=DC:2B:AD:4D:EC:F2 protocol-mode=rstp fast-forward=yes 
      igmp-snooping=no auto-mac=no admin-mac=DC:2B:AD:4D:EC:F2 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 
      vlan-filtering=yes ether-type=0x8100 pvid=1 frame-types=admit-all ingress-filtering=yes dhcp-snooping=no port-cost-mode=long mvrp=no 
      max-learned-entries=auto 
[demo@MikroTik] > interface/bridge/vlan print 
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge  199-200   bridge                          
            210                                       
;;; added by pvid
1 D bridge  200                       ether2          
;;; added by pvid
2 D bridge  210                       ether5          
;;; added by pvid
3 D bridge  1                         bridge          
[demo@MikroTik] > interface/bridge/port print     
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, FAST-LEAVE, BPDU-GUARD, EDGE, POINT-TO-POINT, PVID, FRAME-TYPES
#    INTERFACE  BRIDGE  HW   HORIZON  TRUSTED  FAST-LEAVE  BPDU-GUARD  EDGE  POINT-TO-POINT  PVID  FRAME-TYPES
;;; defconf
0  H ether2     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
1 IH ether3     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
2 IH ether4     bridge  yes  none     no       no          no          auto  auto             199  admit-all  
;;; defconf
3  H ether5     bridge  yes  none     no       no          no          auto  auto             210  admit-all  
;;; defconf
4 I  sfp1       bridge  yes  none     no       no          no          auto  auto               1  admit-all  
[demo@MikroTik] > interface/bridge/set bridge pvid=199 comment="We should not be allowed to set pvid to 199 when there is a vlan interface for 199"
[demo@MikroTik] > interface/export
# 2025-10-11 20:45:03 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no comment="We should not be allowed to set pvid to 199 when there is a vlan interface for 199" name=bridge pvid=\
    199 vlan-filtering=yes
/interface vlan
add interface=bridge name=br.199 vlan-id=199
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > interface/bridge/port print                                                                                                      
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, FAST-LEAVE, BPDU-GUARD, EDGE, POINT-TO-POINT, PVID, FRAME-TYPES
#    INTERFACE  BRIDGE  HW   HORIZON  TRUSTED  FAST-LEAVE  BPDU-GUARD  EDGE  POINT-TO-POINT  PVID  FRAME-TYPES
;;; defconf
0  H ether2     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
1 IH ether3     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
2 IH ether4     bridge  yes  none     no       no          no          auto  auto             199  admit-all  
;;; defconf
3  H ether5     bridge  yes  none     no       no          no          auto  auto             210  admit-all  
;;; defconf
4 I  sfp1       bridge  yes  none     no       no          no          auto  auto               1  admit-all  
[demo@MikroTik] > interface/bridge/vlan print                                                                                                      
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge  199-200   bridge                          
            210                                       
;;; added by pvid
1 D bridge  200                       ether2          
;;; added by pvid
2 D bridge  210                       ether5          
[demo@MikroTik] > # change bridge pvid back to 1
[demo@MikroTik] > interface/bridge/set bridge pvid=1 comment="bridge has default pvid=1, don't create vlan interface for vlan-id=1" 
[demo@MikroTik] > interface export
# 2025-10-11 20:49:31 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no comment="bridge has default pvid=1, don't create vlan interface for vlan-id=1" name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=br.199 vlan-id=199
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > interface vlan print
Flags: R - RUNNING
Columns: NAME, MTU, ARP, VLAN-ID, INTERFACE
#   NAME     MTU  ARP      VLAN-ID  INTERFACE
0 R br.199  1500  enabled      199  bridge   
1 R br.200  1500  enabled      200  bridge   
2 R br.210  1500  enabled      210  bridge   
[demo@MikroTik] > interface bridge print
Flags: D - dynamic; X - disabled, R - running 
 0  R ;;; bridge has default pvid=1, don't create vlan interface for vlan-id=1
      name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=DC:2B:AD:4D:EC:F2 protocol-mode=rstp fast-forward=yes 
      igmp-snooping=no auto-mac=no admin-mac=DC:2B:AD:4D:EC:F2 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 
      vlan-filtering=yes ether-type=0x8100 pvid=1 frame-types=admit-all ingress-filtering=yes dhcp-snooping=no port-cost-mode=long mvrp=no 
      max-learned-entries=auto 
[demo@MikroTik] > interface bridge vlan print
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge  199-200   bridge                          
            210                                       
;;; added by pvid
1 D bridge  200                       ether2          
;;; added by pvid
2 D bridge  210                       ether5          
;;; added by pvid
3 D bridge  1                         bridge          
[demo@MikroTik] > interface bridge port print
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, FAST-LEAVE, BPDU-GUARD, EDGE, POINT-TO-POINT, PVID, FRAME-TYPES
#    INTERFACE  BRIDGE  HW   HORIZON  TRUSTED  FAST-LEAVE  BPDU-GUARD  EDGE  POINT-TO-POINT  PVID  FRAME-TYPES
;;; defconf
0  H ether2     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
1 IH ether3     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
2 IH ether4     bridge  yes  none     no       no          no          auto  auto             199  admit-all  
;;; defconf
3  H ether5     bridge  yes  none     no       no          no          auto  auto             210  admit-all  
;;; defconf
4 I  sfp1       bridge  yes  none     no       no          no          auto  auto               1  admit-all  
[demo@MikroTik] > 

There could be certain ui improvements, but it’s sort of the default stance in both the Linux and consequently Mikrotik networking that certain inconsistent configurations result in shooting oneself in the foot. And it’s not ultimately straightforward to catch these cases: e.g. what you say about a vlan interface matching pvid - this only applies if admit-only-vlan-tagged is not the current configuration.

When you have these complex rules, it’s not easy to handle these situations without enforcing a strict process for the user and/or linking settings in unintuitive ways.

As to not allowing the same subnet on different interfaces: this is a very common configuration. It can be debated how “proper” it is, but it’s certainly widespread, and deprecating it is not really possible, at least without mass revolt.

1 Like

I well understand backward compatibility concerns. But what is wrong with at least a warning (similar to what C compliers do when the compiler has to make assumptions about what the user meant).

It is true that if you set frame-types=admit-only-vlan-tagged on the bridge (which applies to the router facing port of the virtual switch), and if the /interface/bridge/vlan has the bridge included in the tagged port list (which it will by default in 7.16+) that the traffic will work when the vlan interface is used.

But it rules out using the bridge itself for any traffic (which will make @anav happy). But it also is another way to shoot yourself in the foot, especially for people just learning how vlans work in MikroTik/linux that may be working from a connection to the bridge interface. Which does add more fuel to the "take a port out of the bridge that you can work from" camp.

About the quickest way to lock yourself out when in defconf is to use the command

/interface/bridge set bridge comment="Don't do this from defconf" frame-types=admit-only-vlan-tagged vlan-filtering=yes

The bridge interface of the router is going to send and receive only untagged traffic. But any traffic sent by the router's bridge interface will not make it to the virtual switch (because untagged traffic will be blocked at ingress to the virtual swtich. When using 7.16+, it does appear that the bridge port connected to the "router block" will be set to send vlan 1 traffic tagged as soon as you create a vlan interface for vlan-id 1. Even thought the pvid is really set to 1, the virtual switch will never receive the untagged traffic from the bridge interface. So what changing the bridge frame-types=admit-only-vlan-tagged does is to effectivley disable communication with the base bridge interface.

Here's confirmation that @lurker888's assertion that as long as frame-types=admit-only-vlan-tagged is set, then bridge pvid and vlan with same vlan-id can co-exist is true.

[demo@MikroTik] > interface export
# 2025-10-12 01:46:00 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no comment="bridge has default pvid=1, don't create vlan interface for vlan-id=1" frame-types=\
    admit-only-vlan-tagged name=bridge vlan-filtering=yes
/interface vlan
add interface=bridge name=br.199 vlan-id=199
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > interface vlan print
Flags: R - RUNNING
Columns: NAME, MTU, ARP, VLAN-ID, INTERFACE
#   NAME     MTU  ARP      VLAN-ID  INTERFACE
0 R br.199  1500  enabled      199  bridge   
1 R br.200  1500  enabled      200  bridge   
2 R br.210  1500  enabled      210  bridge   
[demo@MikroTik] > interface bridge vlan print
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge  199-200   bridge                          
            210                                       
;;; added by pvid
1 D bridge  200                       ether2          
;;; added by pvid
2 D bridge  210                       ether5          
[demo@MikroTik] > interface bridge port print
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, FAST-LEAVE, BPDU-GUARD, EDGE, POINT-TO-POINT, PVID, FRAME-TYPES
#    INTERFACE  BRIDGE  HW   HORIZON  TRUSTED  FAST-LEAVE  BPDU-GUARD  EDGE  POINT-TO-POINT  PVID  FRAME-TYPES
;;; defconf
0  H ether2     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
1 IH ether3     bridge  yes  none     no       no          no          auto  auto             200  admit-all  
;;; defconf
2 IH ether4     bridge  yes  none     no       no          no          auto  auto             199  admit-all  
;;; defconf
3  H ether5     bridge  yes  none     no       no          no          auto  auto             210  admit-all  
;;; defconf
4 I  sfp1       bridge  yes  none     no       no          no          auto  auto               1  admit-all  
[demo@MikroTik] > # working from br.210, frame-types set to admit-only-vlan-tagged, now change bridge pvid to 210.  Hopefully it will still work
[demo@MikroTik] > interface/bridge/set bridge pvid=210 comment="because frame-types set to admit-only-vlan-tagged, br.210 and bridge pvid 210 can co-exist"
[demo@MikroTik] > interface vlan print                                                                                                                     
Flags: R - RUNNING
Columns: NAME, MTU, ARP, VLAN-ID, INTERFACE
#   NAME     MTU  ARP      VLAN-ID  INTERFACE
0 R br.199  1500  enabled      199  bridge   
1 R br.200  1500  enabled      200  bridge   
2 R br.210  1500  enabled      210  bridge   
[demo@MikroTik] > interface bridge vlan print                                                                                                              
Flags: D - DYNAMIC
Columns: BRIDGE, VLAN-IDS, CURRENT-TAGGED, CURRENT-UNTAGGED
#   BRIDGE  VLAN-IDS  CURRENT-TAGGED  CURRENT-UNTAGGED
;;; added by vlan on bridge
0 D bridge  199-200   bridge                          
            210                                       
;;; added by pvid
1 D bridge  200                       ether2          
;;; added by pvid
2 D bridge  210                       ether5          
[demo@MikroTik] > interface bridge print
Flags: D - dynamic; X - disabled, R - running 
 0  R ;;; because frame-types set to admit-only-vlan-tagged, br.210 and bridge pvid 210 can co-exist
      name="bridge" mtu=auto actual-mtu=1500 l2mtu=1596 arp=enabled arp-timeout=auto mac-address=DC:2B:AD:4D:EC:F2 protocol-mode=rstp fast-forward=yes 
      igmp-snooping=no auto-mac=no admin-mac=DC:2B:AD:4D:EC:F2 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 
      vlan-filtering=yes ether-type=0x8100 pvid=210 frame-types=admit-only-vlan-tagged ingress-filtering=yes dhcp-snooping=no port-cost-mode=long mvrp=no 
      max-learned-entries=auto 
[demo@MikroTik] > # eventhough we changed the pvid of the router facing bridge port of the virtual switch to 210,                                          
[demo@MikroTik] > # the bridge is still in the tagged list for vlan 210.  So we still have communication.                                                  
[demo@MikroTik] > # but the router's bridge interface is now disconnected from the vitual switch, because the bridge interface is using untagged traffic
[demo@MikroTik] > interface export
# 2025-10-12 01:54:13 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no comment="because frame-types set to admit-only-vlan-tagged, br.210 and bridge pvid 210 can co-exist" \
    frame-types=admit-only-vlan-tagged name=bridge pvid=210 vlan-filtering=yes
/interface vlan
add interface=bridge name=br.199 vlan-id=199
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
[demo@MikroTik] > interface list member add interface=br.199 list=LAN
[demo@MikroTik] > interface export                                   
# 2025-10-12 01:56:07 by RouterOS 7.19.6
# software id = ****-****
#
# model = RB760iGS
# serial number = ************
/interface bridge
add admin-mac=DC:2B:AD:4D:EC:F2 auto-mac=no comment="because frame-types set to admit-only-vlan-tagged, br.210 and bridge pvid 210 can co-exist" \
    frame-types=admit-only-vlan-tagged name=bridge pvid=210 vlan-filtering=yes
/interface vlan
add interface=bridge name=br.199 vlan-id=199
add interface=bridge name=br.200 vlan-id=200
add interface=bridge name=br.210 vlan-id=210
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=200
add bridge=bridge comment=defconf interface=ether3 pvid=200
add bridge=bridge comment=defconf interface=ether4 pvid=199
add bridge=bridge comment=defconf interface=ether5 pvid=210
add bridge=bridge comment=defconf interface=sfp1
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=br.200 list=LAN
add interface=br.210 list=LAN
add interface=br.199 list=LAN
[demo@MikroTik] > 

My comment was not meant as some all-encompassing reveal.

I just tried to point out that much of the configuration is beyond simple analysis. (That’s exactly why wizardy and heavily limited router platforms are so popular.)

I have lately seen a lot of useful warning messages appear, and even though my comment was somewhat contrarian, I’m not against further progress.

What I tried to focus on is the fact that many features are fundamentally resistant to such: for example many people come to this forum with fundamentally broken firewall rules, and the iptables system is more akin to a programming language (okay, it isn’t Turing complete) than a simple rule-based policy system (that other vendors are happy to give you - even if they ultimately rely on the same kernel subsystem) and basically making any sort of observation on the behavior of a set of rules is a very huge task, and basically veers into the territory of correctness proofs.

1 Like