Using RouterOS to VLAN your network

RouterOS Useful user articles
321

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 ?

322

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.

323

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.

bridge-vlan-frame-types.png
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.

324

@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…

325

That screenshot is from my main router, and it has been like that since ages and all VLANs work without issue :slight_smile:. 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.


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.

326

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.

327

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.

328

Adding a “thanks” for this post + thread. I’m still fiddling with it to work with my network and I have locked myself out a few times but this is by far the best collection of examples and configs to use and route VLANs in any normal scenario I have yet found. Coming from a cisco/arista background I found the idea of doing most of the stuff you would usually do with L3 routing by switching L2 VLANs through a bridge completely weird however .. I think I’m almost there.

329

One question - in the first (and some other) examples, on the router, the WAN ethernet port is not in the bridge. Is there a reason for this? My mental model of MikroTik says that switching ports over the bridge at L2 is the way to go for speed and the ability to offload to the switch chip. So if you put the WAN interface into the bridge also, with I think the same firewall rules, would it not be faster?

The way it’s configured in the examples is it not the case that all packets between the bridged VLANs and the WAN have to be handled by the CPU at L3 where if that port (or VLAN if you want to make the WAN a VLAN) were in the bridge, the packets would be switched faster.

What did I miss?

330

Read the following @sindy post RouterOS bridge mysteries explained and skim the thread. Then if you still have questions, open a new topic with your specific questions.

331

When a device is acting as a router, the WAN interface ( typically an ethernet port) normally has nothing to do with the LAN bridge.
( only the router itself is getting an IP address via this port )
( the subnets either get their ip address from the bridge, or via vlans, or possibly partly bridge for some and on etherports directly for others)

When a device is acting as a switch, the TRUNK interface ( normally an etherport ) from the upstream device must be part of the bridge.
(the device gets its Ip address from the management vlan defined on the switch)

332

Adding WAN as VLAN on bridge would NOT make it switched*. It still go through the CPU regardless. Now you may want to put a WAN in bridge for other reasons. But it wouldn’t make it “faster”. In fact, it add very, very marginal extra hop (inside kernel) to/from bridge to WAN port, instead going of direct CPU to/from WAN port (then to bridge to LAN port).

_* Unless you have high-end CCR/CRS, if so see: https://help.mikrotik.com/docs/spaces/ROS/pages/62390319/L3+Hardware+Offloading_

As noted, above @sindy’s “Bridge Mysteries” post goes in way more depth.

333

Soon to be a Netflix Series… The Mystery of Sindy’s Bridge :wink:

334

Hi,

also in regard to the recent questions, if also need some further clarification.

In router.rsc it is written

# Purple Trunk. These need IP Services (L3), so add Bridge as member
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=10
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=20
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=30
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=99

In AccessPoint.rsc on the other hand

# Purple Trunk. L2 switching only, Bridge not needed as tagged member (except BASE_VLAN)
add bridge=BR1 tagged=ether1     vlan-ids=10
add bridge=BR1 tagged=ether1     vlan-ids=20
add bridge=BR1 tagged=ether1     vlan-ids=30
add bridge=BR1 tagged=BR1,ether1 vlan-ids=99

First question:

Could I simplify both as

add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=10,30,30,99

and

add bridge=BR1 tagged=ether1     vlan-ids=10,20,30
add bridge=BR1 tagged=BR1,ether1 vlan-ids=99

Second question:

Why should I not include the BR1 for all VLANs in AccessPoint?

For the router it says “These need IP Services (L3)”… Why does it need them, and why should the AP not need them.

Third question:

What behaviour is to be expected, if I had configured the router the same way as the AP? (BR1 only included for VLAN 99)

335

To the first question:
Depends, on the surface yes. If one has multiple ports, all the same and tagged and all going to the same VLAN-ID, they can be combined on the router or Switch.

Discussion: If there are any differences between any of the VLAN-IDS, like one has an implicit ( set on bridge port ) or explicit ( set on bridge port and properly (best practice opinion) access port entered on bridge vlan ( and also then clear to the reader), THEN that vlan-id has to be removed from the grouping approach. Also,obviously the same applies to an vlan-id involved in the access part of hybrid ports.

To the second question: Yes
Already answered above, there is a difference in the ports and thus 99 is separated out, as you have done.

Only paid to answer two questions at a time. Try the third question on your device and report back the results…