Community discussions

 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

AVOIDING VLAN1 ON BRIDGE????

Wed Feb 13, 2019 10:08 pm

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.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 935
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: AVOIDING VLAN1 ON BRIDGE????

Wed Feb 13, 2019 11:06 pm

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?
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Wed Feb 13, 2019 11:59 pm

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:
BR,
Metod
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 935
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 12:31 am

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:

:-)

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.
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 1:03 am

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
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 8:47 am

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.

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".

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.
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).
BR,
Metod
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 2:04 pm

So i gather what I posted is acceptable thus far?
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 935
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 3:00 pm

If untagged frames are allowed across trunk ports, then some VLAN renumbering can happen (usually this is not desirable) when pvid settings on trunk ports are not consistent. One could argue that the bridge's pvid setting defines which is "native" VLAN.

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 stuff and treat all VLANs equally (tagged on the bridges and trunk ports inside LAN perimeter).

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.
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 4:50 pm

So i gather what I posted is acceptable thus far?

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 :lol:
BR,
Metod
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 6:10 pm

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?
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 7:21 pm

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 ;-)
BR,
Metod
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 7:27 pm

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 ;-)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 7:51 pm

I'm not judging you ... just feeling slightly amused ;-)

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 ...
BR,
Metod
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 9:08 pm

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......
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 10:22 pm

... its that your data is on the cloud and if hacked then folks may be able to reach your equipment through the net ...
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.
BR,
Metod
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 935
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: AVOIDING VLAN1 ON BRIDGE????

Thu Feb 14, 2019 11:06 pm

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?
Last edited by pcunite on Sat Feb 16, 2019 10:20 pm, edited 1 time in total.
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 1:37 am

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)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 8:24 am

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).
Last edited by mkx on Fri Feb 15, 2019 9:07 am, edited 2 times in total.
BR,
Metod
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 9:02 am

For MKX there are three ways to filter ingress traffic wrt to vlan tags on the SwOS

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:
BR,
Metod
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 2:55 pm

What I can pass along is failure! :-(
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 :-)

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??)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 935
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 5:18 pm

I'm with @anav regarding ether7 on router. Make it a dedicated access port for management VLAN, the same as is port ether24 on switch.

@mkx,

Would you confirm this update? Is this what it needs to be now?
Verify no tags on ingress, set to 99, on egress, remove tag.
#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 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether7] pvid=99
/interface bridge vlan add bridge=BR1 tagged=BR1,sfp1 untagged=ether7 vlan-ids=99

#Switch:
# Optional: Change ether24 to be an admin Access port so you can configure device directly over BASE_VLAN
/interface bridge port set bridge=BR1 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether24] pvid=99
/interface bridge vlan set bridge=BR1 tagged=BR1,sfp1,sfp2 untagged=ether24 [find vlan-ids=99]
Last edited by pcunite on Sat Feb 16, 2019 10:21 pm, edited 1 time in total.
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 7:19 pm

I'm with @anav regarding ether7 on router. Make it a dedicated access port for management VLAN, the same as is port ether24 on switch.

Would you confirm this update?
It seems fine with me.
BR,
Metod
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 935
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 7:32 pm

It seems fine with me.

Wait, sorry. I've been tired lately. Shouldn't both be set to:
frame-types=admit-only-untagged-and-priority-tagged

They are both Access ports, so you can hook your laptop in direct.
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 8:04 pm

I think yes, would be consistent!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 9:03 pm

@pcunite ... you're not the only one tired, that one slipped my vigilance as well. Since you corrected yourself really quickly, I'm starting to suspect you were just testing my consciousness ...

@anav, your updated VLAN setup for wifi seems right.

Regarding pvid=1: I suggest you to look away from it. May be, if you ignore it long enough, it'll just go away? ;-)

Now seriously: on true trunk ports frame-types should be set to admit-only-vlan-tagged. In this case untagged frames will be dropped on ingress as the first step and there won't be any more to tag with pvid in the second step. So pvid setting is ignored and could be set to just anything. And it doesn't really matter which vendor is on the other end of ethernet cable. On ingress, any untagged frames will be ignored. On egress pvid setting doesn't matter at all, it's the untagged section of /interface bridge vlan which defines it. If there are no VLANs where trunk port was listed as untagged, then MT won't emit single untagged frame on that port. Hence it doesn't matter how other vendors deal with "native" VLANs as MT won't give them a chance to do it.

But in order to have nice and tidy exports, pvid when unused should be set to pvid=1 ... as default values are not presented in export...
BR,
Metod
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 935
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 10:11 pm

1) True trunk ports frame-types should be set to admit-only-vlan-tagged. 2) On ingress, untagged frames will be dropped. So, pvid setting is ignored and could be set to anything. 3) On egress, pvid setting doesn't matter at all, it's the untagged section of /interface bridge vlan which defines it. If there are no VLANs where trunk port was listed as untagged, then MT won't emit a single untagged frame on that port.

Wow ... I think I'm getting it. However, conceptually speaking, most people don't know how MikroTik does it under covers. So, to the humble newcomer, am I not being just to show that pvid=1 is for Trunks, and pvid=XYZ is for Access ports? I'm afraid I have tasted the sweet savory pvid parameter and now I'm too uncomfortable to let my security blanket go!
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Fri Feb 15, 2019 11:15 pm

... most people don't know how MikroTik does it under covers. So, to the humble newcomer, am I not being just to show that pvid=1 is for Trunks, and pvid=XYZ is for Access ports?

As you said most users won't care about particularities. It seems that every vendor interprets pvid=1 in some other weird way. It's hard to educate users about them properly, so IMHO it's best to stay away from it ... and include a short statement about the reason. Any "user-friendly" explanation (or recipe or simplification) will back-fire at some inappropriate moment sooner or later.

After all, every piece of software has a data field which doesn't apply in all cases. A good (G)UI will hide that setting when not applicable. ROS CLI doesn't but then every advanced ROS user expects UI won't hide anything.
BR,
Metod
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 935
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: AVOIDING VLAN1 ON BRIDGE????

Sun Feb 17, 2019 12:17 am

@mkx,
Here is what I hope to be the final version of the Router.rsc file. Everything look okay? I'll update all other examples to follow suit, taking out pvid=1. I want to focus on the Security section now. Might take a month or more.

# Web: https://forum.mikrotik.com/viewtopic.php?t=143620
Last edited by pcunite on Tue Feb 19, 2019 1:28 am, edited 1 time in total.
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Sun Feb 17, 2019 4:22 am

Looks good from my quick inspection.....
Although earlier I said you could combine all your 10,20,30 rules for each bridge vlan rules for a trunk,
I am more apt not to argue the point as its cleaner in the long run to showing keeping the vlan-IDs separate per rule.
Personally I would still do it, but for most setups with any bit of complexity it would get folks into trouble fast.

I do have a question for both of you.
My dlink has 3 types of vlans, Trunk Access and Hybrid.
The Hybrid is the strange one here you have to identify the
native vlan ID (the access part)
Other allowed VLANs. (the trunk part).

So basically the idea that all packets ingress that port if tagged should be part of the other allowed vlans or if untagged, they
are allowed to ingress and then are tagged with the entry you have put in native vlan.

Is there anything equivalent on the MT, and if not, why not?
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Sun Feb 17, 2019 10:52 am

@pcunite: it seems fine. The only thing I'd change, but it's not related to VLANs but rather basic firewall: I'd allow ICMP in chain=input also from WAN ... dropping it doesn't really add to firewall security but allowing it might save some trouble (such as path MTU discovery).

@anav: in D-link nomenclature hybrid is the type called "trunk with native VLAN" by @pcunite et al. The one I hate so much that I made @pcunite to remove from his configuration examples ;-)
The only difference is that D-link seems to insist on pvid being set so no frames pass untagged interior of the switch (while with ROS untagged can pass interior causing all kinds of conceptual problems).

I'll make a step sideways now: sometimes hybrid (trunk with native) is a necessity, but only when such port is facing other network or a particular device requiring such setup. In my case, my ISP is delivering internet (PPPoE) untagged and IPTV tagged. Hence I have to configure port as hybrid (trunk with native). But as that port has pvid set, PPPoE frames inside my LAN infrastructure are normal tagged frames. Similarly I'm running a couple of device-facing ports as hybrid because those are ports connected to IPTV STBs which require IPTV streams delivered tagged and internet untagged.
And D-link with hybrid ports behaves the same. BTW, on my D-link it is not possible to remove VLAN with VID=1 even if no port (either tagged or untagged) is member. So I have to look away whenever I configure that part of my switch and pretend it doesn't exist :wink:
BR,
Metod
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Sun Feb 17, 2019 4:23 pm

You nailed it well, so in some cases with other vendors switch, I may have to turn the other cheek on pvid=1 existence, but as you stated earlier, as long as on the RB ingress filtering=yes and I have frames set accordingly, will be sufficient to remove any uncertainty about what goes where!!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 935
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: AVOIDING VLAN1 ON BRIDGE????

Sun Feb 17, 2019 4:23 pm

@pcunite:
The only thing I'd change ... I'd allow ICMP in chain=input also from WAN

I'll make a step sideways now: sometimes hybrid (trunk with native) is a necessity, but only when such port is facing other network or a particular device requiring such setup.

Right, I always allow for ICMP. That will be covered under the Security section. For now, I'm trying to use as few lines as possible, just to show what must be done regarding allowing VLAN to work.

Hybrid Ports
Regarding Hybrid ports, I did not plan to cover that unless I had to. Maybe a small note in the Security section might be wise, since it can exists. I did not take the time to research it, since I wanted to avoid it. However, I would like to hear more about why, because of upstream equipment out of your control? I understand that. But I don't agree that we simply allow it.

Risk:
It is an Access port, it is a Trunk port. Ingress can have tags or not, Egress can have tags or ... not? The egress behavior I'm unsure about. However, they must be treated like Trunk ports in that they need physical security. But let me go over what I see as the real risk. I think the following is true, but need to verify:

1) Incoming packets that are not tagged, you choose to tag them so that they get the VLAN you desire. Egress packets have the tag removed. 2) Incoming packets with a Tag, choose for you the VLAN they want to be in. But can you control what happens if they choose a tag you don't want? Can you drop it? Can you say, "only allow Tags 10 & 20?" If not, that's a big security breach.

In a correct VLAN infrastructure, only Access ports allow packets into your network (taggless). Then you tag them and put them into Trunks. You are in control the whole way. Why would you allow incoming packets to pick the VLAN they want to be apart of? Well, you shouldn't.

So, if you must use Hybrid, you need something in the middle. You have a Rogue VLAN (like a switch) and it must not access your Real VLAN. Is this done with hardware or can there be a software configuration to do this?
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Sun Feb 17, 2019 4:32 pm

I do not think there is added risk as long as you are aware of what the port is doing and that up the food chain the RB is set appropriately.
I do not think I would use this setup for any ports on an RB or capac etc................ but for a managed switch down the line it may have to happen.
Here is the only situation I can think of with limited experience.

RB---------->Managed Switch---------------->Unmanaged Switch--------------->CapAC

In my scenario the Unmanaged switch is also connected to many PCs or devices with no tagging.
PVID=1 used to cover this off and the port between the MS and US was a trunk port and I knew for certain that the UM would still pass the tagged packets back and forth between the capac with no detrimental effect on both untagged pc or tagged wifi traffic.

However now that I am running pvid11 for homelan things are different.
For the Port between the MS and US I intend to use Hybrid, with the native VLAN set to 11 and tagged for the two tagged vlans I am using for smart devices and guest wifi.
In addition, I have homelan WIFI on the capAC, but I am using the capac to mark the packets but I still should add 11 to the list of tagged vlans*****.

For all three types of traffic, PCs off the un-managed switch tagged with 11 on ingress, removed on egress, the two tagged wifi vlans and the third tagged homewifi packets, it should work.
THe only question I have is will I be able to include vlan11 on the tagged portion if also set in the pvid??
(***** my concern is that the MS might strip the vlan11 off the traffic heading to the capacs???? I have some doubt that the MS has connection tracking like Mikrotik products ??????
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Sun Feb 17, 2019 8:49 pm

I don't think that running hybrid port on your own LAN perimeter poses a security risk.

Example: ether1 is used as hybrid port with untagged (tagged to VID=13 on ingress due to pvid setting) and VID=3999 tagged frames.
/interface bridge port
add bridge=bridge interface=ether1 ingress-filtering=yes pvid=13
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 vlan-ids=3999
add bridge=bridge tagged=bridge untagged=ether1 vlan-ids=13

So the untagged will get tagged to VID=13 on ingress and VID=13 will get untagged on egress. Frames with VID=3999 will be admitted on ingress and transmitted tagged on egress. The rest of VLANs will not leak on egress (port is not member of other VLANs) and unconfigured VLANs will be dropped on ingress due to setting vlan-filtering=yes. Which means that one still has control over which VLANs can enter LAN perimeter through hybrid ports.

Security-wise things are not simple though. If some VLAN is only switched (e.g. there are other ports members of VLAN VID=3999), then firewall won't protect those devices. OTOH, if one trusts that particular external LAN for some reason (e.g. it's part of ISP's service network and one can assume they are doing their job protecting it), one can keep LAN infrastructure devices unconfigured on that VLAN (meaning bridge should not be a tagged member of that VLAN in my config snippet above) and only expose those devices that really need it (e.g. STBs).

But all of this stuff is subject to security of a network, not much to do with VLANs.

@anav: as you can see in above config, having hybrid ports doesn't necessarily mean you're back to pvid=1 ...
BR,
Metod
 
mkx
Forum Guru
Forum Guru
Posts: 1958
Joined: Thu Mar 03, 2016 10:23 pm

Re: AVOIDING VLAN1 ON BRIDGE????

Sun Feb 17, 2019 8:58 pm


(***** my concern is that the MS might strip the vlan11 off the traffic heading to the capacs???? I have some doubt that the MS has connection tracking like Mikrotik products ??????
If configuration of MS' port connecting it to US is configured as trunk port, it'll pass all VLAN tags. US won't do anything to VLAN tags, the worst thing that US might do is to clip frames if their size is too big for the switch.

The real problem is that you have normal devices connected to that US. Which means you have to make the above mentioned port on MS hybrid ... and you can't use same VID for both tagged (for cAP) and untagged (for normal devices). I'd go for a MS there, I don't think saving CAD 100 is worth the trouble.
BR,
Metod
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Sun Feb 17, 2019 10:47 pm

You forgot I was a cheap bastad. Hmmm, It all worked fine through the managed switch when all home traffic was on vlan1 LOL.
But I get your point, I am kinda stuck then............. But wait, I do have another 260GS somewhere in the house. I was so frustrated with the damn things initially I tossed it somewhere.
I could use it to connect the MT to the 260GS then one line to the UM and another line to the CapAC. Thanks!!!!
I also have two hexes, one is a backkup to the RB450Gx4 but the other could act like a managed switch as well...........
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
anav
Forum Guru
Forum Guru
Topic Author
Posts: 2454
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: AVOIDING VLAN1 ON BRIDGE????

Mon Mar 11, 2019 2:41 pm

My router is not cooperating LOL.
It is misbehaving!!!

I have vlan11 all set to replace vlan1 (which is basically my 192.168.0.0 subnet which is attached to the homebridge).
a. vlan11 entered as an vlan interface and related to (under the) homebridge.
b. /interface bridge vlan rules now include 11
add bridge=homebridge tagged=homebridge,eth2 vlan-ids=30,45,100,200, 36, 55
add bridge=homebridge tagged=homebridge,eth3 vlan-ds=77,40, 66
add bridge=homebridge tagged=homebridge,eth2,eth3 vlan-id=11

I have vlan11 entered in as a LAN interface member so that it is included in any firewall rules that apply
Technically I should only have to do two actions now to switch from homelansubnet attached to homebridge (using pvid=1) to
homevlan11 using homelansubnet, with the bridge no no longer attached to a subnet.

a. change ip address interface from homebridge to homevlan11
b. change dhcp-server interface from hombridge to homevlan11

However, no matter how I try to accomplish this the router barfs. I do one first then the other.
I try to undo vlan filtering and then carry out these actions...
Each time I get kicked off the router (and saved by safe mode).

What am I missing????
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)

Who is online

Users browsing this forum: Google [Bot] and 7 guests