Shouldn't ONLY the sfp1 port in your diagram be purple in color? Apart from the WAN port that is yellow, shouldn't the remaining ports have no color?
Based on the legend, the purple port stands for a trunk port on the router; so it doesn't seem to make sense to have so many trunk ports on the router.

It is rather normal for a router to mostly have trunk ports.
Can be one, can be many.

Keep in mind that there is also a switch that connects via sfp1/2 to the router, please refer to the origin above. If the connection is via fiber from a switch, then it only makes sense to connect the other end to the fiber port on the router, and not on an ethernet port although one could do that (and pcunite does state connecting to ether ports as well) but then it defeats the purpose of connections via fiber. Why drive on 1st gear when you can switch to 5th gear?

I don't deny that there can be more than one trunk port, but if this article is meant for newbies and amateurs, it is unnecessarily confusing. For this reason alone, the other purple colored boxes should be uncoloured, and changes made accordingly to the router.rsc file.
The purpose of this entire post is to help newbies understand and how to perform various real-world configurations, that is the basic premise.

If one looks at the router.rsc file, it does say that the tagged ports can also be ether2-7, and therefore coloring them purple is in-line with the way the diagram is colored. I don't deny that. All I am saying is make it simple...plug a fiber port to a fiber port. Avoid saying it's OK to plug to a fiber port at one end and to an ethernet copper port at the other, in which case one is teaching the wrong thing to newbies.
pcunite also says the post is also meant for network admins, I am sure this fiber to copper connection would look silly to them.
More importantly, keep in mind that lots of us MT newcomers will be referring to the post as well, some would also be new to networking.

You are a forum guru, so it is easy for you. But the MikroTik journey for beginners is very very frustrating, I can attest to that, so why add more confusion? Remember the KISS principle?
If the intent of this posting is to help newbies, then the purpose is defeated by this unnecessary coloring, this is my opinion.

In any case, thank you for having taken the effort and time to reply.

I understand what you're aiming for but it's not that uncommon.
I have a router with a CSS610 switch connected via SFP+ at home and still most of my router ports are trunk ports (only 1 access port, the 2.5Gb one for direct connection to my PC in my office and ofcourse the ISP uplink).

I am not the author of the original posts but the way I see it his aim was mostly to provide clarity on how to use VLANs in a ROS environment.
This is not about why use VLAN, when to use trunk ports, when to use access ports, ...
Anyone able to grasp those VLAN related concepts, should be (I hope) smart enough to figure out when to use access ports and when to use trunk ports. This guide then gives you the handles how to implement it using ROS.

As far as being a guru, I'm far from. Don't let post count mislead you.
Still learning new things ... but I have been an absolute beginner too. I also started from zero with ROS and yes, the learning curve is steep.
But put in the time, experiment, start over and learn doing so.
Again, I do understand your position but I believe you're misunderstanding (a bit) the real aim of this thread.

Concur Holvoe........
The post made is nonsensical, based on the experience on this forum I have seen all manner of setups and none of the threads examples seem out of place compared to that of which one is exposed to here. The intent of the article is to help users navigate through implementing vlans via vlan-filtering=yes, and the examples are 'fictionary and any resemblance to actual configs is not intentional, nor were any bunny rabbits harmed during the process. The post misses the mark by a continental mile.

Hi, need some help on these scripts. When I factory default the router, it has a default configuration already with bridge etc which conflicts with the script. I see the system "Start with a reset (/system reset-configuration)" note, but that doesn't allow me to connect via winbox to then import the script. I'm sure I'm doing something lame since no one else seems to have encounter this issue.

... but that doesn't allow me to connect via winbox to then import the script. I'm sure I'm doing something lame since no one else seems to have encounter this issue.

Maybe you are just using the "wrong" method?
Winbox can connect to IP (that don't exist after a reset) or to MAC (that does exist after a reset).
If in Winbox the device is detected, it will have a MAC and and IP of 0.0.0.0.
Make sure to click on the MAC, and that the upper box gets populated with it before clicking on connect.
Whenever possible, connection by IP Is to be preferred, but after a reset you can only use the MAC.

... but that doesn't allow me to connect via winbox to then import the script. I'm sure I'm doing something lame since no one else seems to have encounter this issue.

Maybe you are just using the "wrong" method?
Winbox can connect to IP (that don't exist after a reset) or to MAC (that does exist after a reset).
If in Winbox the device is detected, it will have a MAC and and IP of 0.0.0.0.
Make sure to click on the MAC, and that the upper box gets populated with it before clicking on connect.
Whenever possible, connection by IP Is to be preferred, but after a reset you can only use the MAC.

It doesn't show up. I'm plugged into port 8 of the rb5009. The larger question is should I accept the default config or not?

Well, nothing prevents you from accepting the default configuration and later remove/delete it manually.
But it is strange that Winbox doesn't see the router, you should try with another PC and on all other ethernet ports (except ether1)

This guide is great
Does all the scripts work on RO7?

As far as I understand, the router is mostly trunks as in big networks, many switches are connected up to the router

Switch with a separate router (RoaS)

---snip---

Router Configuration at a glance:


---snip---

Firstly, I am only a recent MikroTik user, so I am still building my inventory of MT knowledge.
Kindly bear with my limited knowledge, but I have a question.

Shouldn't ONLY the sfp1 port in your diagram be purple in color? Apart from the WAN port that is yellow, shouldn't the remaining ports have no color?
Based on the legend, the purple port stands for a trunk port on the router; so it doesn't seem to make sense to have so many trunk ports on the router.

Its an example only. Your assumption is as equally questionable as I have seen routers with all trunk ports, going to APs, switches etc. More than likely, would agree that a mix is more likely or not all ports are used.
In any case its just an example not to be taken at face value.

This guide is great
Does all the scripts work on RO7?

As far as I understand, the router is mostly trunks as in big networks, many switches are connected up to the router

Yes the scripts work fine on RoS7. The only deviation comes when you start using capsman but thats another topic ( datapath is used to assign vlans or something like that)

Hi,
I would like to solve the connection of the hAP ax3 router and the cAP ax access point with VLAN and CAPsMAN under ROS7 based on the description.
Unfortunately, there are problems with it.
I would use the Router-Switch-AP (all in one) configuration on the router, while the AccessPoint config on the access point. Of course, I modified it and set up CAPsMAN, but it doesn't want to connect.

Is there a solution for this?

Thank you for your help

Hello @pcunite,

While searching for material to learn about VLAN, I found your magnificent post. Since networking is not a discipline I master at all, I took the liberty of translating it into Spanish as faithfully as possible to the original to facilitate its understanding and use your guide as study and experimentation material. I hope it will be useful to other spanish speakers and that I have not transgressed the purpose of this material or any other rule.

If any spanish speaker decides to make a comment, please do so in english as the common language of the forum. I have seen other sites that seem like the Tower of Babel.

Thank you very much in advance

Hi,
I would like to solve the connection of the hAP ax3 router and the cAP ax access point with VLAN and CAPsMAN under ROS7 based on the description.
Unfortunately, there are problems with it.
I would use the Router-Switch-AP (all in one) configuration on the router, while the AccessPoint config on the access point. Of course, I modified it and set up CAPsMAN, but it doesn't want to connect.

Is there a solution for this?

Thank you for your help

This help article does not address capsman, suggest you visit the wireless forum and peruse any topics with vlans.

This help article does not address capsman, suggest you visit the wireless forum and peruse any topics with vlans.

Thank you for your advice.

Hello @pcunite,

While searching for material to learn about VLAN, I found your magnificent post. Since networking is not a discipline I master at all, I took the liberty of translating it into Spanish as faithfully as possible to the original to facilitate its understanding and use your guide as study and experimentation material. I hope it will be useful to other Spanish speakers and that I have not transgressed the purpose of this material or any other rule.

Excellent. Thank you. Hope that helps the Spanish community.

After reading WHOLE thread, i must say original posts and few other posts, really concisely explained the matter - other posts only made me more confused : D
I have few observations (which i would like to know if true) and questions:

1. hardware offloading does the original post logic and setup, depends if mikrotik device is using hardware offloading or not ? Because that matter is still not clear to me.
If hardware offloading makes, lets say, communication between two VLANs done in switch chip, without the use of CPU , or if i didnt get that right - communication between two VLANs is done in switch chip which is INSIDE the CPU block, then
do we still need to make bridge itself as a tagged member of VLAN, in order to have intraVLAN communication (between VLANs) ?
Because the whole point of adding bridge itself as tagged member is to send tagged frames to cpu , if i am not wrong.
I don't want to make topic more complicated with hardware stuff, but only interested does it changes some of the logics and configurations of original post .

4. ip address of the bridge when do you want to add ip address to the bridge itself - ip address add interface=bridge address=x.x.x.x?
is it for example when you have bridge pvid=1 and you want l3 access to cpu, from port (member of the bridge) in vlan1 ? (for managing device, or routing outside of vlan1)
OR, is it used as in cisco world where bridge interface is used to send packets outside of the bridge ?

5. firewall logic and lastly just one question about firewall logic, using pcunite example :

0.add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"
1.add chain=forward action=accept connection-state=new in-interface=RED_VLAN comment="Allow RED_VLAN to access the Internet AND other VLANs"
2.add chain=forward action=drop comment="Drop"
now if add a line for RED_VLAN to access only internet :
add chain=forward action=accept connection-state=new in-interface=RED_VLAN out-interface=wan

i tested this in gns3, and it doesnt change anything - still get access to internet AND other vlans, regardless if i put this rule before 1.line or after 1.line

how to explain that firewall logic? if there are two same rules, with one being restricted , it will ignore it and use less restricted rule ?

tnx

For the first question reading here --> https://help.mikrotik.com/docs/spaces/R ... NFiltering
"Currently, CRS3xx, CRS5xx series switches, CCR2116, CCR2216 routers and RTL8367, 88E6393X, 88E6191X, 88E6190, MT7621, MT7531, EN7562CT switch chips (since RouterOS v7) are capable of using bridge VLAN filtering and hardware offloading at the same time, other devices will not be able to use the benefits of a built-in switch chip when bridge VLAN filtering is enabled. Other devices should be configured according to the method described in the Basic VLAN switching guide. If an improper configuration method is used, your device can cause throughput issues in your network."

For the second question:
Never IMHO, once you go vlans, the bridge should not normally be involved in DHCP again. However MT is extremely flexible and there may be some niche configs that require this.
Note that the bridge vlan-id default is 1, it works in the background and normally should not be considered as management vlan or used for any data, just leave it alone!!

For the third question
First of all I disagree with PC Unites approach. I personally do not permit or use open ended firewall rules. I prefer to have a clear source and clear destination for all my rules, even If I have to make additional rules. In this regard less inferences need be made.
Secondly, its a misnomer almost to put in connection-state=new, the reason being is that only the first packet of the connection is new, subsequent packets it established related etc......
Thus for each session, the rule is only new for the first packet and subsquent packets dont hit the rule. No one uses connection-state=new.
I have seen that used in some mangle rules, where it may be useful to pinpoint traffic being mangled.

The rules set assuming for a router should read
{ default rules to keep }
add chain=forward action=fasttrack connection-state=established,related
add chain=forward action=accept connection-state=established,related,untracked
add chain=forward action=drop connection-state=invalid.
( admin rules )
add chain=forward action=accept chain=forward comment="internet access" in-interface-list=LAN out-interface-list=WAN
add chain=forward action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat disabled=yes { enable if required or remove }
******* --> Add any other allow rules here <-- ************
add chain=forward action=drop comment="Drop all else"

With that in mind lets look:
0.add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"
1.add chain=forward action=accept connection-state=new in-interface=RED_VLAN comment="Allow RED_VLAN to access the Internet AND other VLANs"
2.add chain=forward action=drop comment="Drop"
now if add a line for RED_VLAN to access only internet :
add chain=forward action=accept connection-state=new in-interface=RED_VLAN out-interface=wan

Focussing on rule 1
It says --> Allow the Red VLAN (assuming its base/trusted/management) to anywhere ( thus to other vlans, and to WAN, perhaps to wireguard vpn if it was available )

The second rule say, drop everything else........... So no other traffic not permitted above this rule will not traverse the router etc.

If you add the third rule explicitly allowing the red vlan out the WAN, it will NEVER have any effect.
a. in case A you stick this rule after the drop rule, ITS TOO LATE, you have already dropped everything,
b. in case B you stick it before the drop rule, its redundant! You already let VLAN red anywhere so its gone out the internet and the rule will never be hit.

Typically we assign all the vlans as members of the LAN interface list.
in cases lets say we have 8 vlans that need to go out internet and 1 vlan that does not
we can make the standard rule look like
add chain=forward action=accept comment="internet access" in-interface-list=LAN out-interface-list=WAN src-address=!192.168.9.0/24

Or you could have a interface LAN list that simply doesnt include that VLAN and the standard rule works.
Or you could make a separate interface LAN list called With-Internet
add chain=forward action=accept comment="internet access" in-interface-list=With-Internet out-interface-list=WAN

There are so many ways to accomplish the same thing so its part knowing the rules and tools and part imagination.

I have few observations (which i would like to know if true) and questions:

>> hardware offloading?
As anav pointed out, it depends on the hardware.

>> when would you assign an ip address to the bridge itself?
When using VLANs, you would not do this. The Bridge is just a mechanism to manage your VLANs which are the only thing that really needs to be exposed.

>> firewall logic?
FW logic is personal. I only show examples. All my rules are drop by default. So, unless you open up something, prior to the drop rule, it will get dropped. Rules are processed in order, and thus anything placed after a DROP rule will never fire (unless jumping). I used connection state new to fire the red vlan rule and thus stop further processing. But there are other ways to go about this.

Hi, pcunite

Thank you for the vlan guide!

Thanks for this topic guys, helped me to understand MikroTik better. But I have a little question.

For me Ethernet2 is a trunk port (admit only vlan tagged) carrying about 4 vlans(one is the mangement ). I tagged the bridge on each vlan table and the ethernet2 also. At this moment normally my L3 would work if I will allow it throught my firewall but for the moment I don't want L3, I just want it to have the set-up prepared for this. My bridge has no ip adresses and I have an "offbridge" port for disastrous confings so I can go back to fix my mistakes.

As @pcunite and @anav in other topic specifies, if my bridge has pvid=1, you guys say my trunk port has to be on pvid=1 also. Is it not more secure to use a different PVID on the trunk ? like something that is not even used ? I have zero to none experiente but is it not more susceptible to attacks, because they can exploit that pvid=1 that is most used ? Will the L3 not work if the Bridge has different pvid than the TrunkPort ?

Thanks for this topic guys, helped me to understand MikroTik better. But I have a little question.

For me Ethernet2 is a trunk port (admit only vlan tagged) carrying about 4 vlans(one is the mangement ). I tagged the bridge on each vlan table and the ethernet2 also. At this moment normally my L3 would work if I will allow it throught my firewall but for the moment I don't want L3, I just want it to have the set-up prepared for this. My bridge has no ip adresses and I have an "offbridge" port for disastrous confings so I can go back to fix my mistakes.

As @pcunite and @anav in other topic specifies, if my bridge has pvid=1, you guys say my trunk port has to be on pvid=1 also. Is it not more secure to use a different PVID on the trunk ? like something that is not even used ? I have zero to none experiente but is it not more susceptible to attacks, because they can exploit that pvid=1 that is most used ? Will the L3 not work if the Bridge has different pvid than the TrunkPort ?

Good question, I look at it this way, if you read Sindys article, and its quicksand, there are multiple components to consider CPU, PORT, SWITCH and he will use terms like switch facing side, CPU facing side etc......until one is in a complete pretzel. The point I am trying to make is that internalyl there is probably an important reason to keep the default pvid as 1, as some sort of glue between these components. This is no different from other consumer switches. All their ports come default untagged on ether1 and members of vlan1. ONLY when the pvid is changed due to it being an access port or hybrid port, is vlan1 untagged removed. It stays as untagged as default on all Tagged ports.
All to say, it sits in the background and is best left alone.
For practical purpose, aka security as you stated, is why its important on the MT device to set on its trunk ports the following:
add ingress-filtering=yes frame-types=admit-only-tagged frames. In other words, no untagged traffic will even leak into the MT be it vlan1 or vlan100 on these ports.
Thats the why I look at it. Sorry couldnt give you a more definitive answer.

I think the goal is not to have any unwanted VLAN ID appearing in the /interface bridge vlan table. Ingress filtering should be turned on for all ports, including "bridge", then you can keep 1 as the PVID of "bridge" but here you should also set frame-types to admit-only-vlan-tagged.


Then for any other trunk port, you can keep PVID = 1 but always set frame-types to admit-only-vlan-tagged for them too (like with "bridge").

That should eliminate the dynamic entry for VLAN ID 1 in the /interface bridge vlan. And because of ingress-filtering=yes everywhere, if a VLAN ID does not appear in the /interface bridge vlan table then you can be sure that frame with that VLAN ID will never be accepted, which means there is no more risk of VLAN ID 1 being used.

Other access or hybrid ports should not have PVID = 1 set at all.

@anav I tought about that also, but I still don't get clear information if it really has to stay on PVID=1, I really tried to find out, and also nobody seems to modify that so I started to think it is like something "holy" that you never touch, haha.

@CGGXANNX I wanted to do that, but I had some doubts. You mentioned it about that dynamic entry in the /interface bridge vlan, that is exactly what I want to acomplish, to get rid of that because it sits always on pvid1 in the untagged group. My trunk port of course has only "vlan tagged" but still, I don't like the bridge staying like that in that table.

Last 6 hours I used the bridge with a pvid=900 but still on "admit all" and the trunk port with a pvid=902 and I had zero problems, doesn't seem that it breaks something or slowing down. But your sugestion sounds good, I will try it, hopefully "admiting only vlan tags" on the bridge, won't interfere with "admiting untagged and priority tagged" on my other ports and other vlans.

Thanks !

EDIT : it works, I don't see the dynamic entry anymore. I guess if i only admit vlan tagged on both trunk port and bridge, and any of my other ethernet ports have other pvids than "1", then the bridge and trunk port pvid doesn't matter that much. I mean in a security perspective, that's how I see it, all is blocked as you said so yea...

Though, what if i put 1000 pvid for these two instead of 1 ? Probably useless...

That screenshot is from my main router, and it has been like that since ages and all VLANs work without issue . For this tab, "bridge" acts as a port (like etherX, where you have the same tab with the same options) and setting Frame Types here only affect the "bridge" port, which is the switch CPU port. As you can see in your /interface bridge vlan table, currently you should only have that "bridge" port appearing in the "tagged" attributes of the VLANs, which mean "admit-only-vlan-tagged" is the perfect setting for the "bridge" port.

Though, what if i put 1000 pvid for these two instead of 1 ? Probably useless...

You can put any number between 1..4094 there, it will not make any difference because the number is ignored for admit-only-vlan-tagged. Which means leave it to be 1 is fine too.

Yes, is tagged on all interfaces that have a VLAN-ID. Nothing dynamic anymore, I will let it on PVID=1, all seems ok, and it should be. Thank you ! You really enlightened me on this matter.

CGG is bang on, it looks like that the BRIDGE itself, should not really have any selections for ingress filtering for frame types or PVID for that matter for vlan-filtering=yes and leaving PVID=1.
As I stated I use frame-types admit only vlan tagged specifically to stop any traffic entering the router from untagged vlan1s as they are prevalent on many switches.

For the case of vlan-filtering=off. Well guess what NO vlan filtering applies so we dont care about frame types, ingress filtering or pvid anyway.

The whole selection seems in the end meaningless and should be best left to /interface bridge ports when using vlans to be granular.