-
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.
-
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.
-
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.
- 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.