I disagree, I find it very confusing to have set PVID on the bridge ports and then not put the associated untagged entries on the bridge vlan.
When reading a config its dirt easy visually to see what a person has done.
Its so difficult to have to double check a config when not seeing the config, especially when they use hybrid ports.
This is highlighted to me time and time again when I am looking at a config in winbox,
For example if a port is not at the moment dynamically untagged by the router there is no indication that it is an untagged port.
If I have physically untagged it, it is always there to confirm, whether the port vlan is being used or not.
I think it suffices to say that the Router automatically assigns untagged ports in the bridge vlan settings and its up to the user to decide if not or to insert them in the bridge vlan configuration.
So far I have not seen any input to change my mind.
You shouldnāt use this āuntaggedā setting as a sort of documentation for how things are set up. You can always add a comment to the bridge vlan (ex. āpvid ether1-ether23ā) if you are concerned about documentation purposes as a reminder for yourself. At least then if you forget to change the comment it wonāt cause a problem.
It is normal with most switches to simply have to change the PVID for the port and that takes care of both egress and ingress. That is the case with MikroTik too, except if you also use the āuntaggedā then you have to change it in two places. If you have some network person who is used to working with HPE or Cisco or other major vendor switches they will likely change the PVID only and not realize that they have potentially created a problem. If they do create a problem, they will likely blame MikroTik for their non standard configuration to have to set the untagged VLAN in two places which nobody else requires.
Iām kinda in the middle. I think for examples, it looks good which is why I kept it included. However, out in the field, when Iām making changes, I find it error prone to make edits on live systems. So, I prefer the automatic egress behavior for Access ports in a production environments. To your point, I see why it is helpful debugging posted configurations in these forums.
Hi mud, you do make some points there in terms of cross vendors but let me point you to the jestream switches I use from TPLINK.
I set the PVID in one section and in another I set both Tagged and Untagged ports. I have to set untagged ports. Therefore it is MORE NORMAL for me to do it on the MT.
Other switches i have used such as Netgear, one also has to note which are tagged and untagged, no shortcuts.
I think its fine to state the facts and let the user decide which way they want to go.
I like the idea of using vlans to partition and isolate network traffic using ROUTEROS. Youāre contribution to this article is much appreciated @PCUNITE, MKX, SINDY. I also hope you generate enough traction for this to make it into the Wiki. Thank you ahead of time. Could you kindly show me how to modify the router and switchOS config in order to distribute the vlan information to several APās using CAPsMan? Assuming you have already tried it. If you havenāt it all good. Iām kind of embarrassed for saying this, so Iāll just be straight upā¦ No offense ANAV, and with all due respect, please kindly refrain from lecturing me as to why it wonāt be possible. A simple no will suffice. Yes and NO are both answers to me.
Regards T Navarrete (tmoneymikrotik)
Mikrotik SOHO Devices: purchased 1 day ago.
1 x Non Wireless - POE Router (RouterOS)
1 x Poe Switch (SwitchOS)
2 x CAPs AC (RouterOS)
Not sure it belongs here (as youāve properly stated, this topic should actually be a wiki article). However:
There is no equivalent of Ciscoās VTP on Mikrotik, so you cannot dynamically distribute VLAN configuration across wired network from a single device. But if you are interested solely in cAPs, you can keep the bridges on them VLAN-agnostic (vlan-filtering=no), which means that they will forward both tagless and tagged frames among ports without tagging/untagging them and use a single forwarding table, and you can use caps-man datapath settings to let the individual wireless interfaces tag/untag the traffic as forwarding it to/from the local bridge if you use local-forwarding=yes. With local-forwarding=no, all the client traffic between the CAPsMAN device an the cAPs runs encapsulated into transport frames and virtual wireless interfaces are created on the CAPsMAN machine, so use of VLANs may not be necessary at all in this case.
PCUNITEs article addresses vlans and the various equipment combinations. It does not address the use of capsman.
Whether or not he includes capsman in this article or creates one separate for capsman or NOT at all is up to him.
My advice is the same for all cases, if its 1-3 units, i dont see the value in attempting capsman right away due to the added layer of complexity and overhead. I still think its best to setup the vlans and understand the standard bridge vlan filtering setup for both wired and wireless first. Then one can tackle the capsman with a solid background in how wireless works and vlans work. Just adviceā¦ Finally, if you want assistance start a new thread and I am sure the plethora of experienced capsman users will help you defing the config you desire.
As sindy suggested, for any CAPs you are using, I would generally recommend not using bridge VLAN filtering on the CAP itself. Use it on the routers and the switches, but not the CAP. The issue is that bridge VLAN filtering artificially limits what you can do with the CAP. For instance, normally you can do per client VLAN assignments for individual clients if you wish, but as soon as you enable bridge VLAN filtering on the CAP itself, that feature becomes, if not impossible, much more difficult to accomplish.
Hi Mudharm, I use capac and bridge vlan filtering with great success (and no capsman). I use a vlan per SSID to separate users.
What am I missing here??
You are talking about per-SSID VLANs - those work fine with bridge VLAN filtering. Iām talking about per-user VLANs with a single SSID - that does not work so well with bridge VLAN filtering. There are workarounds you could potentially use, but I find it easier to just not use bridge VLAN filtering on a CAP in the first place.
It isnāt only with CAPsMAN - you can also assign VLANs to different clients on a single SSID without CAPsMAN using an access list that assigns the VLAN tag based on the MAC, or with RADIUS assigning per-user VLANs outside of CAPsMAN. The issue is that in either of those cases, the bridge VLAN filtering function is going to be blissfully unaware of what VLAN tags are being assigned to users based on either their MAC (in the ACL) or some RADIUS attribute, and are not going to allow those to pass to the switch by default as a result. But, if you do not enable bridge VLAN filtering on the CAP, all VLANs are passed, so this issue will not occur in the first place.
Title:
Using RouterOS to VLAN your network the new way with RouterOS 6.41+
This to make i clear what type of VLAN implementation you are using in this guid.
In Router-Switch-AP (all in one) you do use VLAN 99 as BASE/Native VLAN.
That is OK for learning, but my experience tells me that most starts off with VLAN 1 only and then later add one or more VLAN.
This will then make VLAN 1 as BASE/Native VLAN for the most of the people with small home router.
Negative as a homeowner, donāt agree and it leads to nothing but problems.
keeping it default mirrors all other vendor managed switches which use vlan1 as a background default vlan, not the management vlan
You do get a lollipop for making a suggestion, but the flavour is moldy warts, a Hogwarts Candy
I totally agree with you. This was just from what I do see from real life situation. Most starts off with a basic router with all in VLAN 1, then add more VLANs as needed. In a good deign, management VLAN should be it own VLAN not one that are used for normal traffic.
Hi, Iām trying to use the RoaS approach and Iāve got most of it behaving as I want (I think). However, I canāt seem to be able to ping the switchās IP address after assigning a management VLAN to the switch itself. Hereās my config:
My desktop is plugged into ether1 (untagged VID 399) with IP set to 192.168.3.2/28. The switch has IP set to 192.168.3.1/28 on MGMT_VLAN interface, which has a VID of 399. Neither device can ping the other. What am I doing wrong here?
