I am still struggling to get my head around this VLAN thing, I understand the concept, etc but struggling to fully understand the way of implementation in Mikrotik.
But with recent changes in ROS 6.41 onward, I am lost again, will someone be so kind and explain explain in a similar, easy to follow / understand way how to achieve this configuration in the new “Bridge Only” config of Mikrotik in order to benefit from the hardware offloading, routing between VLAN’s on the same box, etc?
As usually with this highly popular topic, I’m guessing based on the experience gathered up to now.
The new implementation moves part of switch chip configuration from the switch menu to the bridge menu.
The switch chips remain the same so it is still true that most of them have physical Ethernet ports and a single port towards the CPU.
Until you start thinking about VLANs, the only change which really matters is that you have to make each ethernet port a member of a bridge individually, while before you could use the so-called “master port”.
When you start thinking about VLANs but not about vlan-filtering, it is still quite easy:
before, the idea was that you make one bridge for all the Ethernet interfaces where a given VLAN should appear tagged, and another bridge for all the Ethernet interfaces where the VLAN should be untagged. The joining interface between the two bridges was “/interface vlan” which was using the “tagged” bridge as its (bearer) “interface” and itself was a member port of the “untagged” bridge, to which you could add also e.g. WLAN interfaces.
“Hardware acceleration” was done by choosing one of the Ethernet ports as a “master port” which was made a member of the bridge, and choosing several others as its “slave ports”. Between all the slave ports and the master, everything was forwarded by the switch chip.
after, you can still use the method of handling tagged and untagged ports described above, but it is better to use only a single bridge for all VLANs. When adding an Ethernet port to that bridge, you set its “pvid” parameter to the VLAN ID for which it should behave as “access port”, i.e. frames with this VLAN ID will be untagged at egress, and frames without a VLAN tag will be tagged with this VLAN ID at ingress; the frames bearing tags with other VLAN IDs will remain tagged at both ingress and egress through that port. So instead of bridging all the untagged Ethernet ports together using the dedicated bridge at the untagged side of the “/interface vlan”, you tag the previously tagless ingress frames in the switch chip as they come in through the Ethernet port, and untag them as they pass from the tagged side to the untagged side of the “/interface vlan”.
For the WLAN interfaces, you can set the VLAN ID and set them to use the common “tagged” bridge as well, both if set up directly or using cAPsMAN.
What is not so obvious is that this “tagged” bridge itself also constitutes an interface which can be given an IP configuration_, and therefore it also has a “pvid” parameter. It then works much the same like an “/interface vlan” would. So if you use 3 different VLANs on a bridge, you may create only two “/interface vlan”, the third VLAN ID may be configured directly at the “/interface bridge” (as “pvid”) instead. No tagless frames can exist in this bridge._
**WARNING:**The information above was based on the description of pvid parameter on the Mikrotik wiki: “Port VLAN ID (pvid) specifies which VLAN the untagged ingress traffic is assigned to. It applies e.g. to frames sent from bridge IP and destined to a bridge port.”. However, the reality is different. At least on hardware models using the AR8227 switch chip, the bridge interface ignores the pvid parameter and sends its packets to the switch chip tagless. So should e.g. VLAN 1 be supported on a trunk port of the switch chip, it is not enough to set pvid=1 in the bridge configuration, and it would be necessary to configure an /interface vlan with vlan-id=1 on that bridge.
On the other hand, this approach permits to configure hybrid ports with hardware acceleration even on AR8227, provided that the same VLAN will be tagless on all of them and that there is no need to have this VLAN tagged on other ports. The key is to use VLAN ID 0 for this tagless VLAN in switch chip configuration. Access ports to other VLANs must not be listed as VLAN 0 member ports.
Frames between member Ethernet ports of that single “tagged” bridge are forwarded by the switch chip without passing forth and back to the CPU, which is the substance of the “hardware acceleration”. It works until you decide to use bridge filtering or some other L2 processing which requires CPU interaction. And it seems to work only on a single bridge like this. You may add several bridges with similar configuration but only one of them will be hardware accelerated even though all of them would be configured to be.
You can still use the switch chip’s own VLAN handling (which differ notably between switch chip types!) using the switch menu (/interface ethernet switch). The possibilities of various switch chips are described quite clearly on the Mikrotik Wiki.
The rodeo begins when you want to use vlan-filtering at bridge configuration level. On almost all hardware platforms switching it on means that you lose the hardware acceleration because the vlan-filtering is (so far?) done by the CPU, but you cannot avoid it e.g. if you want to use MSTP.
For vlan-filtering, it is necessary to define the rules for the filtering using “/interface bridge vlan” rule list. The rules here provide, for each group of vlans (item “vlan-ids”) and each bridge (item “bridge”), a list of ports on which the group of VLANs should be permitted as tagged and another list for untagged member ports of that VLAN group (items “tagged” and “untagged”). But beware - the bridge itself must be listed as its own tagged member interface, otherwise the path between the switch chip and the CPU will be closed for that VLAN group once you permit vlan-filtering on the bridge. So the Ethernet members of the VLAN would remain isolated from the CPU-side members - local interfaces (the /interface bridge itself, all the /interface vlan using it, and all the WLAN interfaces using it). I hope the need to do this confusing setting is only temporary.
Another source confusion is that some rows in this table are generated dynamically, much like in the “/interface bridge port” table:
there, you have to set Ethernet interfaces as bridge member ports manually, using “/interface bridge port add”, while /interface vlan and /interface wireless become member interfaces “dynamically” - actually because their own configuration indicates the bridge they should become members of.
here, all elements whose configuration includes a VLAN ID (/interface vlan, /interface wireless) dynamically pop up in the “/interface bridge vlan” table on a line with that single VLAN ID on the “vlan-ids” list. I’m not sure whether this is the case also for Ethernet interfaces (which also have a pvid parameter), but in 6.41, it was not possible to add a manually created line to the table when the dynamically created one was present.
I’d appreciate a feedback - of course at first place on anything which is not true in my desciption, but also on anything which is missing or incomprehensible.
I am a software guy. Let me explain how I see it, even after 6.41:
Switch is to pilot the hardware switch. This is your best bet to control/achieve top notch performance.
Bridge was (initially) pure software to realize non homogenous switches (L2 link between wifi, ethernet, vpn, …).
They both have exact same goals but achieve differently: once with some switch fabric, once with CPU power.
Now Mikrotik attempts to merge/reunify them and will attempt to figure out for you based on hardware capabilities were it can achieve some hw optimizations.
Switch menu will eventually disappear but it is likely it will take many iterations before it is complete.
Meanwhile and despite the confusion, Mikrotik is nice enough to leave the switch menu available.
So now to summarize:
If you care for maximum performance, are fully wired, then continue using switch features for your vlan + vlan filtering.
If you look for maximum flexibility to build non homogenous L2 then use bridge.
If you care for both and your applications permits it, then you should probably look for L3 routing anyway.
If you really need L2 with top performance, upgrade your hardware for beefy CPU (eg: CCU or x86), none have switch fabric built-in anyway
My recommendation (untested but seems logical given the above):
As of 6.41.2, continue doing vlan + vlan filtering at the switch level for ethernet, then use no filtering at the bridge level if you can for those ports as they will have been already filtered by switch fabric.
If you have to filter at the bridge port, then doing in both switch+bridge might remove some traffic and help the CPU. This may no longer hold once they continue imlementing hw optimizations.
Suggestion for Mikrotik:
Whatever switch features you pilot from bridge, should go as a dynamic entry in switch.
Maybe I’m a bit ignorant… I work with Cisco and Juniper all day, and they make this stuff really easy.
You either have a tagged vlan or you don’t. You just push those around to whatever port you want them to go, and they go there. There’s a little bit more to it than that in areas, but basically that’s all it is.
I would really like to see this idea of a “native” vlan in MikroTik, because it’s an easy concept to grasp, especially on a trunk link between devices (ISL as it’s called). Or to an edge port for a device that wants tagged traffic.
I never wanted to know if the CPU has to “deal with it” or not, although I suppose on smaller not so integrated devices it’s a pretty important thing to know.
Sindy or netflow (or anyone) - is this explanation valid for both SwOS and RouterOS? I really need to dig deeper into vlan config and trunk ports in MikroTik despite my incredulity at the complexity of it. Hopefully it will make more sense once I practice at it.
You are right, hence the current move to bridge with automatic optimizations.
From a conceptual prospective understanding bridge feature is enough and you may skip the switch feature completely.
It’s almost like this but not exactly. The general principle with switches is that nothing like VLANs actually exists physically (that’s why they are called “virtual”), it is all about the frame VLAN tags and filtering incoming and outgoing frames up to these tags. So if you say that a switch port is a member of a VLAN, it actually means that frames tagged with that VLAN ID are allowed to pass through it (bi-directionally).
On top of that, you can tell each port how to handle ingress (received from the wire) frames with no VLAN tag at all, but normally the only choices are “tag it with ID xxx” and “drop it”. So on any switch with an elementary self-respect, you cannot meet frames without VLAN tag inside.
The rest, including the vernacular, is manufacturer dependent. You can have permit lists (no VLANs except the listed ones permitted on the port) or deny lists (all VLANs except the listed ones permitted on the port), you can have the “access ports” (with just a single VLAN permitted which is tagged on ingress and untagged on egress), “trunk ports” (where all permitted VLANs must be tagged), and “hybrid” ports which behave as “trunk” for N VLANs and “access” for one additional one; Cisco calls the same thing a “native VLAN” of a trunk port. There are switches where the tag handling in egress and ingress direction is configured separately, i.e. if you configure tagging of tagless ingress frames with VLAN ID x, it may not automatically mean that frames with this VLAN ID will be untagged on egress.
I would really like to see this idea of a “native” vlan in MikroTik, because it’s an easy concept to grasp, especially on a trunk link between devices (ISL as it’s called). Or to an edge port for a device that wants tagged traffic.
But you do have it on Mikrotik (at least in the 6.41+ concept), except that the “native VLAN” is called “pvid” here. When you tell the bridge that a given port has “pvid=5”, it means that ingress tagless packets will be tagged with VLAN ID 5 and egress packets tagged with VLAN ID 5 will be untagged.
What you do not have in Mikrotik unless you permit vlan-filtering in bridge configuration or do some middle level wizardry on switch configuration (and I deeply trust you should not do both unless you are really sure what you do) is filtering of VLANs on ports. So if some neighbouring equipment decides to broadcast frames in a VLAN you are not interested in, the Mikrotik switch would broadcast them to all its ports.
I never wanted to know if the CPU has to “deal with it” or not, although I suppose on smaller not so integrated devices it’s a pretty important thing to know.
The thing here is the speed and how activation of some functionalities affects it. The switch is a hardware device whose throughput should basically be sufficient to forward everything it receives, unless e.g. incoming data from two ports should be forwarded through a single egress port. The bridge (in Mikrotik or linux sense) is a software which implements the same algorithms like a switch does in hardware. However, whereas on a PC it is theoretically possible to have a similar throughput if the bus is fast enough that several Ethernet cards can send and receive simultaneously without competing for the bandwidth, smaller Mikrotik hardware has two bottlenecks here - one is the CPU power itself and the one is the fact that the CPU is connected to just one of the ports of the switch chip whose bandwidth is not the sum of bandwidths of its Ethernet ports.
So you can pamper your ignorance about what is done by a switch and what is done by the CPU until you find out that you get a 80 Mbit/s throughput between two gigabit ports.
A bright example is MSTP. The purpose of STP is to prevent loops in complex L2 network topologies, as the founding fathers of L2 networking forgot to include a TTL field to the frames so if a loop topology incidentally occurs, broadcast frames circulate through that loop forever, until they eventually occupy the whole available bandwidth of the slowest member link of the loop.
So the STP monitors the topology and if a loop occurs, it cuts it at an optimal place by disabling a port at one end of the link closing the loop. But not only that the port must be disabled for any traffic except STP’s control one; with MSTP, which controls several independent spanning trees (instances) with individual topologies, it may be necessary to disable a port only for member VLANs of one spanning tree instance but not for others. And unless the switch chip supports this simultaneously with the ability to deliver STP control frames to the CPU together with an information from which port they come, this must be done by the CPU and therefore at bridge level. So instead of forwarding frames between ports of the switch chips, they must all be delivered to the CPU for handling.
What you do not have in Mikrotik unless you permit vlan-filtering in bridge configuration or do some middle level wizardry on switch configuration (and I deeply trust you should not do both unless you are really sure what you do) is filtering of VLANs on ports. So if some neighbouring equipment decides to broadcast frames in a VLAN you are not interested in, the Mikrotik switch would broadcast them to all its ports.
I probably did not get your point right.
If broadcasting was bypassing filtering by VLAN ports we can call it a major flaw and we will have to drop Mikrotik equipments for any L2 traffic using vlan.
Could you show any evidence of that ? Any configuration issue on your side maybe ?
What I am saying is not specific to broadcast frames, I have used them just as an illustration to avoid additional details regarding handling of unicast frames.
So what I am saying is that without configuring the VLAN filtering rules under “/interface bridge vlan” and then activating them using “/interface bridge set vlan-filtering=yes” for a bridge, or without setting VLAN ID filters in the “/switch” configuration tree: if a frame tagged with any VLAN ID arrives through a member port of that bridge, it is forwarded to one or all member ports of that bridge according to the forwarding database (MAC table), of course still tagged with the same VLAN ID. So unicast frames towards MAC addresses the bridge has never seen before, as well as broadcast/multicast frames, are forked to all member ports of that bridge. And that this behaviour does not depend on whether an “/interface vlan vlan-id=X” is created on the bridge.
Or, in much simpler words, that the bridge is transparent for all VLANs unless you activate filtering by VLAN ID one way or the other.
What I am not saying is that broadcast frames would bypass VLAN filtering if it is activated.
Ok, I am further behind than I thought and you clever guys are talking way above my head at the moment.
To give you some background, I have been in IT Industry for 25 years now, but the last 18 years of that has been in management managing IT Operations for multi national corporations, which also means I had to sit in meetings all day and have lost all the how to of the nuts & bolts, etc a long time ago
I came onto a perfect opportunity to practice this VLAN thing to help me understand it better, I learn better with practical experience. But need yous clever people’s assistance, if I may.
Herewith the scenario:
At home I have a RB2011UiAS-2HnD, with ROS 6.41.2. All interfaces are in a bridge, including WLAN interface with a /24 subnet. Have a 1Gb down and 100Mb up fibre link, extremely happy with this little router but always felt the wireless response can be bit better.
So being bored today, I connected my laptop via WiFi, did not open any applications and started sniffing my home network to see what happens to/from my laptop and analyzed the frames/packets with Wireshark.
From all the packets sniffed, ± 40% of these were UDP broadcasts on port 54915 I received from 2 pc’s, (2 of my boys pc’s) which are connected via Ethernet cable on the Gb ports of RB2011. Some further research revealed that these might be possible from Logitech ARX Control software, so I was thinking, I have about 15 wireless devices on this router, every wireless device will also receive these packets and at 40% of traffic, surely it will affect the WiFi.
Now what I want to do is, place these 2 buggers in a VLAN on their own IP subnet, but do not want to lose the hardware offloading ability as that seems to happen when I create a 2nd bridge, the hardware offloading disables, is that by design?
This way they can broadcast each other broken and it will not affect the WiFi as much. PS. I will also instruct them to correct their settings which will be the best as it will not make use of any router resources then, but I first want to use this opportunity to practice the VLAN thing.
I tried following the previous posts in this topic, I reviewed 3 different VLAN configs on the Mikrotik Wiki, tried a bit but cant get what I want.
So if you can please explain to me like I am a six year old how to achieve this, it will be much appreciated.
As always, thanking you in advance, if you need more info, please shout
Obviously yes, the switch chip can not handle two independent groups of ports using separate forwarding tables. So any port which needs individual treatment has to be handled by the CPU where each bridge has its independent forwarding tables.
So if you can please explain to me like I am a six year old how to achieve this, it will be much appreciated.
You say that you have all ports in the same bridge, including WLAN. Does that “all” include the WAN port? Or, from another perspective, is the box configured as a router at all?
I think the answer to all questions we may have is the output of “/export hide-sensitive” after systematically replacing each public IP eventually present with a distinctive token if you don’t want to reveal them. So let’s start from this.
Correct (at least as in terms that it matches my initial explanation), except that by setting “vlan-filtering=yes”, you break the hardware offloading. And if you do not set vlan-filtering to yes, you don’t need all the settings under “/interface bridge vlan”.
Next, don’t forget that you need the complete DHCP server settings for both VLANs/subnets (/ip pool, /ip dhcp-server network, /ip dhcp-server itself).
If your juniors’ PCs flood the network only with broadasts, it is enough to give them their own subnet as you’ve suggested. If you suspect that there may be something worse than a broken Logitech driver, you may want to set firewall rules between this “quarantine LAN” and the basic one.
I still hope it is a temporary state at least for some of the switch chips for which it is currently true but I have no qualified reasons for that See the reference in my first post in this topic.
