@sindy I would like to ask a few questions please,
If I understood correctly, there should be two “entities” capable of switching, the switch chip and the switching functional block in the cpu?
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
And after I issued these command it should look like the image below?(excluding switch chip because I still didn’t understand that yet)
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?
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).
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 vlanonly 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.
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?
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?
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.
referencing the bridge in the untagged or tagged list on a row in /interface bridge vlanonly 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)
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..)
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..
got it finally just to make some observations of this post,and parallels, to lets say cisco
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)
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.
