AVOIDING VLAN1 ON BRIDGE????

RouterOS General
1

According to the bible written by mkx, and I am getting to the point where I agree, I want to try to setup my main lan subnet, being the bridge subnet and of course maintain what used to be my VLAN1 for HOME USERS, and the rest of the vlans for other activities
Architecture RB450Gx4 connectected by eth2 to a dlink managed switch, with one of its ports going to a CAPAC-2, and one of its ports going to an unmanaged zyxel switch which attaches to another CAPAC-1. Ether3 goes to a SwOS managed switch. (eth1 and eth 5 are two separate ISPs)

eth2 requires vlans
40-smart devices upstairs (runs on wifi_)
100 - guest wifi upstairs
50- smart devices downstairs (runs on wifi)
200 -guest wifi downstairs
70-specific PC
80-mediaboxes

eth3 requires vlans
10-videohub
20-NAS
30-voip modem

10-192.168.10.0/24
20- .20.0
30 .30.0
and so on.

My main lan subnet should be 192.168.0.0/24 etc…
The bridge as stated should use a vlan other than1, so I wish to use 11.

Bridge=homebridge
eth2 is a trunk port
eth3 is a trunk port

Capac-1 eth1- is a trunk port (with vlans 50,200 and homelan)
Capac-2 eth1 - is a trunk port. (with vlans 40, 100 and homelan)

SwOS-1 eth1 is trunk port
eth2 - feeds an unmanaged switch for homelan
eth3- 10 video hub
eth4 - 20 - nas
eth5 - 30 - voipmodem
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Settings thus far ROUTER:

/interface bridge
add admin-mac=6 auto-mac=no comment=defconf
ingress-filtering=yes name=HomeBridge protocol-mode=none vlan-filtering=
yes PVID=11 ??

/interface vlan (where and how do I identify vlan11 on this list???)
add interface=HomeBridge name={first vlan} vlan-id=10
add interface=HomeBridge name={secon vlan} vlan-id=20
etc…

/interface bridge port
add bridge=HomeBridge comment=defconf interface=ether2
add bridge=HomeBridge comment=defconf interface=ether3

/interface bridge vlan (Do I need to stick in vlan 11 or is implied untagged vlan11??)
add bridge=HomeBridge tagged=HomeBridge ether2 vlan-ids=
40,50,70,80,100,200
add bridge=HomeBridge tagged=HomeBridge,ether3 vlan-ids=
10,20,30

/interface list member
add interface=HomeBridge list=LAN
add interface={vlan10} list=LAN
add interface={vlan20}=LAN
etc…

/ip address
add address=192.168.0.1/24 interface=HomeBridge network=192.168.0.0

/ip pool
add name=dhcp-HomeLAN ranges=192.168.0.10-192.168.0.200

/ip dhcp-server
add address-pool=dhcp-HomeLAN disabled=no interface=HomeBridge lease-time=1d
name=HoMeLAN

/ip dhcp-server network
add address=192.168.0.0/24 comment=HomeDHCP dns-server=192.168.0.1 gateway=
192.168.0.1
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Capac-1
/interface bridge port
add bridge=upstairsbridge comment=defconf interface=ether1 pvid=11???

/interface bridge vlan (Do I need to stick in vlan 11 or is implied untagged vlan11??)
add bridge=upstairsbridge tagged=ether1 vlan-ids=
50,200

Capac-2
/interface bridge port
add bridge=downstairsbridge comment=defconf interface=ether1 pvid=11??

/interface bridge vlan (Do I need to stick in vlan 11 or is implied untagged vlan11??)
add bridge=downstairsbridge tagged=ether1 vlan-ids=
40,100

SwOS
??? Will wait till I get the above right before tackling the SwOS.

2

Hello, sorry, I’ve been so busy. These questions are important and interesting.

So, you want a pure VLAN configuration, is that it? All networks and VLANs on your MikroTik without the Native VLAN being present?

3

My thoughts … in order @anav applied some colour …

Don’t use pvid on bridge. Rather use vlan interface with appropriate vid set … setup becomes more readable and more uniform … no need to pick out some vlan as being different than the rest.

If you don’t set pvid on bridge, then you set up vlan interface for vid=11 exactly the same way as the rest of vlan interfaces.

If you don’t set pvid on bridge, you set bridge as tagged member of vlan 11, exactly the same way as all other vlans with vlan interface off the bridge.

And exactly the same philosophy goes for cAP …

I’m tempted to reply to @pcunite’s post saying that there is no such thing as native vlan … it’s either vlan or it is not. If vlan is a vlan, it’s carrying vlan tag with numerical VID (no such number like native).
But I won’t reply like this :wink:

4

:slight_smile:

Well, as I work on my Security section, the Native VLAN (the base network without tags aka VLAN 1) is most definitely something you have to be cognizant of when enforcing Trunk behavior (admit only VLAN tagged) and Access ports (admit only untagged) behavior. Otherwise you’ll lose access to your equipment.

You must have a management VLAN present, if you want to configure your switches in this locked down mode. You can no longer use Winbox plugged into a properly configured switch from one of its Access ports. You can only connect over a Trunk port. If that is an up-link port, then you’ll have to go to wherever that is, which in my examples will be the main Router.

I see the appeal of not allowing for the presence of a Native VLAN. What I did was configure a port on the router just for this purpose, to put you in the MGMT_VLAN, so you can hit every switch in the environment. When switches are configured to only accept tagged traffic over their Trunks, the Native VLAN, which is actually taggless on the wire, gets dropped!

It seems we’ve simply replaced the Native VLAN for a MGMT VLAN. Since this must be done on all equipment, we’ve come full circle back to having a base network ip scheme, only now, it has tags.

5

Thanks MKX, this should look better… I will have to adjust the other managed switches that also use default PVID=1, but as you state a simple change to 11 should suffice for the most part.
The whole idea is to get away from unknown or not understood default vlan behaviour on routers, caps, switches etc…

Settings thus far ROUTER:

/interface bridge
add admin-mac=6 auto-mac=no comment=defconf
ingress-filtering=yes name=HomeBridge protocol-mode=none vlan-filtering=
yes

/interface vlan
add interface=HomeBridge name=HomeVLAN vlan-id=11
add interface=HomeBridge name={first vlan} vlan-id=10
add interface=HomeBridge name={secon vlan} vlan-id=20
etc…

/interface bridge port
add bridge=HomeBridge comment=defconf interface=ether2
add bridge=HomeBridge comment=defconf interface=ether3

/interface bridge vlan
add bridge=HomeBridge tagged=HomeBridge,ether2 vlan-ids=
11,40,50,70,80,100,200
add bridge=HomeBridge tagged=HomeBridge,ether3 vlan-ids=
11,10,20,30

/interface list member
add interface=HomeBridge list=LAN
add interface={vlan10} list=LAN
add interface={vlan20}=LAN
add interface={HomeVLAN}=LAN
etc…

/ip address
add address=192.168.0.1/24 interface=HomeVLAN network=192.168.0.0 (and not the bridge anymore)

/ip pool
add name=dhcp-HomeLAN ranges=192.168.0.10-192.168.0.200

/ip dhcp-server
add address-pool=dhcp-HomeLAN disabled=no interface=HomeVLAN lease-time=1d
name=HoMeLAN

/ip dhcp-server network
add address=192.168.0.0/24 comment=HomeDHCP dns-server=192.168.0.1 gateway=
192.168.0.1
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Capac-1
/interface bridge port
add bridge=upstairsbridge comment=defconf interface=ether1

/interface bridge vlan
add bridge=downstairsbridge tagged=ether1 vlan-ids=
11,50,200

Capac-2
/interface bridge port
add bridge=downstairsbridge comment=defconf interface=ether1

/interface bridge vlan
add bridge=downstairsbridge tagged=ether1 vlan-ids=
**11,**40,100

6

That’s not necessarily true. If we stick to ROS landscape, this makes all the difference:

/interface list member
add interface=vlan-MGMT list=MGMT
/tool mac-server
set allowed-interface-list=MGMT
/tool mac-server mac-winbox
set allowed-interface-list=MGMT

Transition from VLAN-less config to “locked” VLAN config can be smooth … just add and remove appropriate interfaces to the used interface list at the right moments (and use “safe mode” :wink: ).
Or, if one doesn’t want to introduce separate management VLAN, only /interface list member add interface=vlan-MGMT list=LAN (MAC connects are allowed from LAN interfaces by default).

With configuration above Winbox MAC connection is possible from whichever access port of MGMT VLAN anywhere in LAN. No need for “native VLAN”.


Not really. If untagged frames are allowed across trunk ports, some VLAN renumbering can happen (usually this is not desirable) when pvid settings on trunk ports are not consistent.
One could argue that bridge’s pvid setting defines which is “native” VLAN (diferent trunk ports on the same device can have different pvids set). This definition has some merit as that particular VLAN has some special treatment inside particular piece of equipment. Things, however, get less obvious (one could miss bridge pvid setting and assume it’s actually untagged as all the rest of config doesn’t differ between untagged and pvid set). In addition to that, every piece of equipment can have bridge set to different pvid, hence concept of “native” VLAN becomes local to particular device … which hurts consistency of settings over all LAN infrastructure devices.
Further more, some setups will be flawed in a sense that there will be more than one bridge defined. And each bridge inside same device can have different pvid set.

You’re saying we’ve replaced “native” VLAN with MGMT VLAN … if I judge from @anav’s case, then “native” VLAN will be used just for anything (@anav used it for normal LAN) … so basically whatever user decides not to migrate to proper VLAN due to various reasons (the strongest being laziness).

At the end of the day, having some “native” VLAN doesn’t solve or help with anything, it just complicates things because “native” VLAN should be conceptually considered as any other VLAN, it’s just VID which is not well defined (and thus moot), handling inside different pieces of equipment is different than for properly configured VLANs … and can bring problems if LAN is multi-vendor (and vendors might handle “native” VLAN differently).

BTW, we started a discussion somewhere whether bridge port with pvid set should be tagged or untagged member of bridge something-like-a-switch. I don’t remember if we came to definitive answer. Which doesn’t really matter if we skip all of this “native” VLAN nonsense^H^H^H^H^H^H^H^Hstuff and treat all VLANs equally (tagged on the bridges and trunk ports inside LAN perimeter).

7

So i gather what I posted is acceptable thus far?

8

Yeah, I’m thinking the Bridge’s pvid parameter (the bridge itself, not the ports) is how MikroTik defines the “untagged” (Native VLAN) behavior. Currently, this is defaulted to 1. So, if you set every switch (which we are supposed to only use one now) to a pvid of 15, then 15 is your Native VLAN. However, this means taggess traffic on egress I think to follow spec. Allowing untagged traffic across your trunks might get you into trouble someday. So, Access ports should always drop ingress tags, and Trunks should never allow untagged, if we want to be proper about things.

To those reading. The Native VLAN is what came before VLAN. Its a way to explain what we used to do, and what happens now when everything gets a tag after ingress. You can try and mixed the two behaviors, but you’ll be better off not to!

In any event, I agree that Native is not something I think should exist in a VLAN environment. Based on this, I think I should update my examples to point this out. Maybe even remove it all together. I was wanting to ease people into VLAN. But it seems all or nothing, to be proper.

9

Huh … seems like I’ll have to come to Nova Scotia and perform site survey of your challet (judging by your LAN setup it must be something like Fortress of Louisburg) to verify your VLAN setup :laughing:

10

hahah no, but is there another way to ensure

guest wifi - is not connected to my home lan
videohub which talks to a netgear server is not connected to my home lan
mediaboxes from china AND appletv which stream crap to my TV are not connected to my home lan.
NAS boxes which store information are not connected to my home lan or internet (except for my pc).
voip modem attached to a company is not connected to my home lan
smart devices attached to a company cloud which are connected to doorbell/camera or door status are not connected to my home LAN
smart devices thermostats attached to a company cloud are not attached to my home lan
one pc on my system that had a bad experience with potential compromise is no longer attached to my home LAN
I do have a dmz (fancy name for simply another LAN) subnet off the bridge for a device that is monitored externally by two companies…

Hmmm I wonder if I should separate my Switch console from the mediaboxes above for another vlan???
I still have not installed my smart speaker yet
I am deathly afraid to try out my echo pucks as who wants a live microphone in ones house…

I could go on… LOL.
What magic pill do you have (morpheus) that will allow me a simpler setup?

11

There’s no such thing as magic pill for @anav. My approach is to identify devices that have to talk to each other … or they have to talk to one or two srrvers but I don’t care if they talk to each other or not … that bunch forms one VLAN. So far I have 5 in my home … but I totally lack home automation so I’m something like 20 VLANs behind you :wink:

12

I am not so trusting as you are… and you thought you were the paranoid one LOL.
For example I do not want mediaboxes on the same network as the camera in my shower ( a slight exaggeration LOL).
I do not want my voip provider with access to my magic box (voip modem) nor the voip modem vendor itself to have access to my vidcam hub packet flow.
Or have access to my door status (locked or unlocked) or associated live video feed.
My switch was a $xxx dollar investment, I dont want a box for whatever reason hacked to be able to access my switch and EFF IT UP.

I think you get my drift!!!
(privacy of information, protection of hardware etc etc)

What are you … the carbon police, ticketing me for excessive vlan use :wink:

13

I’m not judging you … just feeling slightly amused :wink:

As I told you, I’m lagging behind with home automation. VoIP terminates on DSL modem, from there it’s POTS (no need for VLAN there but I need dedicated twisted pair+PoE) … when it dies, it won’t be replaced at all. Doorbell is analogue (but pimped-up version … uses UTP cables) … when that one dies (it’s started to go south already) I’ll replace it with an IP system, which will get its own VLAN for sure.

I’m not sure where to put light bulbs … do RGB ones deserve separate VLAN from dimmable ones and the plain white ones their own VLAN? Or should I group them to VLANs according to rooms? Do I put switches to separate VLAN so if they get hacked light bulbs won’t switch on and off as some Nigerian guy sees fit?

Sorry, couldn’t help myself …

14

LMAO, it depends, do you think the employees at Phillip care a twat about your honeywell thermostat?
Its not the companies themselves that concern me, (besides the disgruntled employee syndrome) its that your data is on the cloud and if hacked then folks may be able to reach your equipment through the net and with that reach and access, they are apt to branch out… If on a VLAN there is no branching to be done, to any other devices or clouds of information… Yes I want to stop cloud hopping LOL…

15

You’re making a very important point here. And it’s not only control over your gadgets, equaly important is your data stored on various clouds. Both personal integrity and historical data are in danger if anything happens to those clouds … and things will happen, it’s only the matter of time.

16

I have two possible updates for the VLAN tutorial. Modifying the first RoaS example, I’ve converted it to a pure VLAN implementation, also setting up maximum VLAN security options. The firewall is left open to the LAN side (or rather the VLAN). Locked it down as you please.

Thoughts?

17

Nice work!!
This line for the router....

Optional: Change ether7 to be an admin Access port so you can configure device directly over BASE_VLAN

/interface bridge port set bridge=BR1 frame-types=admit-all ingress-filtering=yes [find interface=ether7] pvid=99

Frame-type should be admit only untagged? Your PC should not have any vlan tags emanating from it...........

For MKX there are three ways to filter ingress traffic wrt to vlan tags on the SwOS
a. allow any vlan that is on the bridge to be ingressed on a port, (obviously can be stopped by allow frame rule type)
b allow only vlans that are identified for that port onto the port.
c. allow vlan tagged traffic even if not a vlan tag on the bridge but treat it like an untagged packet.

What is the way to invoke the latter two rules??

In SwoS
VLAN Receive = admit frame type rule.

VLAN MODE INGRESS
optional - handle vlan packets with tag not on the on the vlan table bridge like untagged packets.
enabled- only allow vlan packets with tags on the vlan table packets without any vlan id are treated like default vlanID.
strict - same as enabled but only allow vlan packets with tags specified for the port not the overall vlan table (more restrictive)

18

I’m with @anav regarding ether7 on router … I’d make it dedicated access port for management VLAN, the same as is port ether24 on switch. This might be a matter of security (it is connected to physical security of these two devices, so my argument might be moot), but management VLAN frames will leak untagged through this port …

For switch config: if device is a dedicated to switching duties, it only needs L3 for management. So no need for switch bridge to be part of any other VLAN than VID=99 (including IP config). Hence I’d change the following setup commands:

--- switch.rsc.orig     2019-02-15 07:09:30.629600535 +0100
+++ switch.rsc  2019-02-15 07:13:42.917011404 +0100
@@ -87,11 +87,11 @@
 # egress behavior
 /interface bridge vlan
 
-# Because our Trunk ports need IP Services (L3), also add the Bridge as a member
-# Purple Trunk, allow all VLANs egress
-set bridge=BR1 tagged=BR1,sfp1,sfp2 [find vlan-ids=10]
-set bridge=BR1 tagged=BR1,sfp1,sfp2 [find vlan-ids=20]
-set bridge=BR1 tagged=BR1,sfp1,sfp2 [find vlan-ids=30]
+# This device is dedicated to L2 switching for most VLANs so Bridge doesnt have to
+# be member of those VLANs.
+set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=10]
+set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=20]
+set bridge=BR1 tagged=sfp1,sfp2 [find vlan-ids=30]

It also shows in code (I haven’t checked the text) that bridge doesn’t have to expose certain VLANs if corresponding vlan interface is not created.


I would avoid setting pvid on trunk ports (both code samples feature pvid=1 on trunk port definitions). I know it’s default so it is already implicitly set to that value (and I hate it :wink:). However, if we’re trying to get away from “native” VLAN concept, pvid shouldn’t be (explicitly) set on trunk ports … if only to educate readers that we really don’t care about untagged frames on those ports (which is emphasised by setting frame-types=admit-only-vlan-tagged further down in the setup code).

19

I’m sorry but I don’t have any idea about how SwOS behaves … I don’t have any SwOS devices. So I can only guess.

And I guess that SwOS somehow follows the same principles as did the old (switch chip) way of configuring VLANs. There we had vlan-mode setting with the following possibilities:

  • disabled - disables checking against the VLAN Table completely for ingress traffic. No traffic is dropped when set on ingress port.
  • fallback - checks tagged traffic against the VLAN Table for ingress traffic, forwards all untagged traffic. If ingress traffic is tagged and egress port is not found in the VLAN table for the appropriate VLAN ID, then traffic is dropped. If a VLAN ID is not found in the VLAN Table, then traffic is forwarded. Used to allow known VLANs only in specific ports.
  • check - checks tagged traffic against the VLAN Table for ingress traffic, drops all untagged traffic. If ingress traffic is tagged and egress port is not found in the VLAN table for the appropriate VLAN ID, then traffic is dropped.
  • secure - checks tagged traffic against the VLAN Table for ingress traffic, drops all untagged traffic. Both ingress and egress port must be found in the VLAN Table for the appropriate VLAN ID, otherwise traffic is dropped.

According to descriptions, i’d guess that “strict” in SwOS is same as “secure” in ROS, “enabled” is same as “check”, “optional” is same as “fallback” and the missing option (possibly it’s not there because it might be implicit setting only available when VLAN is disabled on SwOS) is same as “disabled”.

BTW, I was never sure about the difference between “check” and “secure” … I guess it actually affects ingress filtering (seems that egress behaviour is the same).
Actually description is moot in several places … it is describing ingress behaviour but is referring to egress VLAN table. I like to simplify things and I imagine that port doesn’t care about other ports egress filters. It either accepts frame according to own ingress filter rules or not. If frame gets accepted, it’s up to switch chip / bridge to transport it to appropriate ports (either all of them if egress port is not known for destination MAC address or single port if ARP table has this information) and then it’s up to each target port’s egress filter table whether to push it out of port or not.

If we fast-forward to ROS >=6.42, then I’d say the mapping is the following:

/interface bridge port settings:

  • vlan-mode=disabled → frame-types=admit-all ingress-filtering=no
  • vlan-mode=fallback → I don’t know if there’s a combination with same effect in new ROS.
    I’d say that frame-types=admit-all ingress-filtering=yes might define same behaviour. But it’s the following sentence in description that really bothers me: “If a VLAN ID is not found in the VLAN Table, then traffic is forwarded.”. It implies that ingress-filtering is actually not performed after all.
  • vlan-mode=check → frame-types=admit-only-vlan-tagged ingress-filtering=no
  • vlan-mode=secure → frame-types=admit-only-vlan-tagged ingress-filtering=yes

Things are not a simple as they might seem from the list above as also egress settings (/interface ethernet switch vlan settings mapped to /interface bridge vlan) come into play.

So I guess you’ll have to think about it and show us some expertise :wink:

20

What I can pass along is failure! :frowning:
I tried to setup my vlan11
The biggest hurdle is that the bridgevlan rules would not let me add vlan11 to both rules so perhaps my rule structure is wrong and before I get to the specific rules will quick chat about process.

  1. changed IP address for my homelan from interface homebridge to vlan11
  2. changed DHCP SERVER for my homelan from interface homebridge to vlan11
    Keeping it real simple :slight_smile:

To reiterate bridge and port structure…
bridge is named homebridge pvid defaults to 1, ingress filtering=yes
ether2 is trunk port pvid defaults to 1, ingress filtering=yes
ether3 is trunk port pvid defaults to 1, ingress filtering=yes

/ip bridge vlan
add bridge=homebridge tagged=homebridge,eth2 vlan-ids=30,40,45,100,200,666 (tried to add 11)
add bridge=homebridge tagged=homebridge,eth3 vlan-ids=33,77,99 (tried to add 11)

I tried to add vlan-id 11 to both rules and my router Refused, the audacity, the unmitigated gall, to allow me to place 11 on both, as if, I dont know what I am doing LOL
In retrospect what a turkey move!!

the right setup is as follows, off to see if it works…
add bridge=homebridge tagged=homebridge,eth2 vlan-ids=30,40,45,100,200,666
add bridge=homebridge tagged=homebridge,eth3 vlan-ids=33,77,99
add bridge=homebridge tagged=homebridge,eth2,eth3 vlan-id=11

That seemed to work just fine this time… Now the issue is I have three managed switches in the mix and two CapACs, that are using pvid=1 for homelan traffic.
This is going to get tricky but for my dlink and netgear, I am assuming i will have to assign all non trunk ports as access ports vice hybrid or any other name and assign a pvid of 11.
Is that about right?? (and of course add 11 as a tagged port on the trunk ports). If I dont many other brands will assign pvid=1 to untagged ports which we dont want.

@mkx for my capACs… easy enough to add vlan11 to the capac bridge. My issue is how to allow homelan traffic. Before it kind of automagically was using the default pvid of the bridge (1).
How I think I have to be creative for my wifi homelan connection part.

current
/interface bridge vlan
add bridge=capbridge tagged=eth1, untagged=wifi-guest(vWLAN) vlan-id=100
add bridge=capbridge tagged=eth1,untagged=smartdeviceswifi(2.4ghz_wlan) vlan-id=30
{assuming}
add bridge=capbridge tagged=eth1, untagged=homewifi(5ghz_wlan) vlan-id=11 ??

and change my bridgeport setting for homewifi from pvid=1, to pvid=11
(To be clear my bridge port setup as each wlan or vwlan is being assigned a PVID as per the new setup method, vice the pvid the old way in the wireless setup.)

@mkx @pcunite, I am already appreciating the new method for ease of changes and consistency.
One nagging question (pun intended) is what happens with pvid=1.
The reason I ask is because,
pvid=1 still exists as
the router bridge by default is assigned pvid=1 (but is no longer tied to my homelan which was shifted to vlan11)
the capac bridge by default is assigned pvid=1
my SwOS switch still has pvid=1 on the trunk ports
my dlink switch still has vlan-id=1 on trunk ports and unused ports
my netgear switch still has vlan-id=1 on trunk ports and unused ports.

I guess my question is what is the impact of this.
a. do I still neeed vlan1 to talk to these devices?
b. is there a security issue in that all devices are accessible via vlan1
c. should I apply ingress filtering (only allow vlan tagged packets at trunk ports thus stopping untagged packets??)