VLAN not working?

RouterOS Beginner Basics
1

Ok, putting this under beginner because I never worked with VLAN's on Mikrotik at this level.

Moving a Mikrotik 5009 into the core of my little lab. JUST good enough, and a 10g port that goes into the 10g switch. The others are good enough for an uplink to the office (ether1) and management hardware interfaces. The OS on the machines is using their own separate cards that end up in the mentioned 10g switch using VLAN's.

I so far run that essentially as uncnofigured ethernet switch with the bridge having VLAN interfaces for various VLAN and tagged and untagged traffic going in and out - all goes well, EXCEPT... I now want to isolate ether1. This is part of a security setup - not "security" as breakin, just making sure it is a TAD harder for me to just log into a machine. Also, because I want to use DHCP internally for machine management, and this not use the office ip addresses, I need to separate the ethernet broadcast domain :wink:

The idea is to use VLAN ID 4000 for "office traffic". untagged traffic on ether1 is supposed to get managed to this VLAN id. tagged traffic can be handled normally (filtering is not required). I still want to use ether1 also as trunk so that in case I need to work on some machine,I can use another mikrotik on my desk to give me tags on a port. Small setup, nothing special, just a glorified home lab.

Using WInbox...

I have:

  • Created a VLAN with id 4000 and attached it to the bridge (in the interface list) so it is under the bridge together with some other vlan entries.
  • On the Bridge window in Ports set the PVID on ether 1 to 4000. No ingress filtering. Frane Types; allow all.
  • Same bridge window, VLAN#s, created an entry VLAN ID 4000, for the bridge, untagged: ether 1.

To my understanding the PVID setting on the port handles ingress, adding a 4000 tag header to incoming untagged traffic.
The bridge entry VLAN handles outgoing traffic, in this case making sure VLAN 4000 traffic through ether1 is leaving untagged.

This should make sure all packets in get tagged, all out get untagged (for vlan 4000) and the internal processing works based on that. Good.

It just does not work. I am using MAC address connectivity to the machine, so my winbox is not connected via IP - but I open a nice litle command window on my workstation and run a continuous ping to the router IP Address. If I take the IP Addresss and move it from the bridge to the vlan interface - the router stops responding to the ping and ip does not work. If i move it back from the VLAN interface to the bridge itself, or attach the IP address to ether1, it works.

Did I do anything wrong setting this up?

Here are printouts of the current configuration:

[Administrator@hub-router] /interface/vlan> print detail
Flags: X - disabled, R - running
1 R ;;; Link for ether1 uplink
name="vlan-4000" mtu=1500 l2mtu=1510 mac-address=DC:2C:6E:3E:E3:56 arp=enabled arp-timeout=auto
loop-protect=default loop-protect-status=off loop-protect-send-interval=5s
loop-protect-disable-time=5m vlan-id=4000 interface=bridge use-service-tag=no

[Administrator@hub-router] /interface/bridge/port> print
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HORIZON

INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON

;;; defconf
0 IH ether2 bridge yes 1 0x80 10 10 none
;;; defconf
1 IH ether3 bridge yes 1 0x80 10 10 none
;;; defconf
2 IH ether4 bridge yes 1 0x80 10 10 none
;;; defconf
3 H ether5 bridge yes 1 0x80 10 10 none
;;; defconf
4 H ether6 bridge yes 1 0x80 10 10 none
;;; defconf
5 H ether7 bridge yes 1 0x80 10 10 none
;;; defconf
6 H ether8 bridge yes 1 0x80 10 10 none
;;; Hub: Trunk
7 H sfp-sfpplus1 bridge yes 1 0x80 10 10 none
;;; Uplink
8 H ether1 bridge yes 4000 0x80 10 10 none

[Administrator@hub-router] /interface/bridge/vlan> print detail
Flags: X - disabled, D - dynamic
0 bridge=bridge vlan-ids=4000 tagged="" untagged=ether1 current-tagged="" current-untagged=""

2

On any VLAN question…please start here:
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

3

And you did not even bother to read before posting. SO nice and SO - well - civilized and professional. Just makes me hope one day most humans are replaced by AI - those at least read.

Seriously, I have read all that I can read up - problem is that it simply does not seem to work. It may be related to the RouterOS version and be a bug, it may not.

4

Not all relevant config is shown, so we’ll be guessing a bit. But: bridge interface has to be set as tagged member of VLAN 4000 in /interface/bridge/vlan (since you’re using bridge interface as anchor for vlan-4000 interface). Also it’s not entirely clear (missing from posted config) whether you have vlan-filtering=yes set on bridge.

If the above doesn’t fix the problem, post config (execute /export hide-sensitive file=anynameyouwish and copy-paste contents of that text file,nleaving out any remaining sensitive data, such as public IP address, any passwords or PSKs, even device serial number).

5

I said I do not filter. I think I said it, but not in the config. Also the bridge VLAN is set to 4000…

Just aded the whole config as it works.

in winbox Interface list, i see no traffic on the bridge vlan 4000, though.

if I move the IP Address of the router to this (from it being on bridge as in the config) it does not respond.

From that I would deduct that the incoming traffic on ether1 is not getting tagged, so it ends up untageed or tagged 1 in the bridge, so it only reacts there, not on the VLAN interface of the bridge.
vlanconfig.rsc (7.16 KB)

6

If bridge doesn’t have vlan-filtering=yes, then none of vlan-related settings under /interface/bridge apply. Including tagging and untagging on access/hybrid ports with pvid setting. The option is named sligtly awkard, it could say something like “vlan-functons-enabled=yes” … Which means that indeed frames don’t get tagged with PVID on ingress through ether1 (and don’t get untagged on egress, but that’s not the deal breaker right now). Have a look at bridge manual for broader explanation.

The options which enforce/filter frames based on actual settings, are per-port: frame-types and ingress-filtering. Keep in mind that bridge has multiple personalities, one of them is also being a port of brdige … and some settings under /interface/bridge are about that port (and not default for all bridge ports as one might assume). More about different bridge personalities. And you have to add bridge port as member of a VLAN if you want router to interact with that VLAN. In your particular case you have to add bridge port as tagged member of VLAN 4000 (under /interface/bridge/vlan). Ditto for VLAN 42.

BTW, I find your post #3 above a bit rude. The problems you have are pretty beginner level and are addressed (this way or another) in the tutorial recommended to you by @erlinden in post #2. If you have read it (and try to understand it) before posting, you could have said so politely. If you did not read it, then …

7

That is not absolutely optimal. Ouch. I was udner the impression that filtering was that - filtering - and would not override the settings to start with. Like “you set things up, can test them, and at the last step you enable filtering so that stuff that is not matching the setup is filtered out”. Right now, from waht you say, I can not even test this - this is not “slightly badly worded”, it is quite off.

And you are right, it says so i nthe documentation - must have oferlooked it:

The main VLAN setting is vlan-filtering which globally controls vlan-awareness and VLAN tag processing in the bridge. If vlan-filtering=no, bridge ignores VLAN tags, works in a shared-VLAN-learning (SVL) mode and cannot modify VLAN tags of packets. Turning on vlan-filtering enables all bridge VLAN related functionality and independent-VLAN-learning (IVL) mode. Besides joining the ports for Layer2 forwarding, bridge itself is also an interface therefore it has Port VLAN ID (pvid).

Final question to one warning it gives:

Warning: You don’t have to add access ports as untagged ports, they will be added dynamically as untagged port with the VLAN ID that is specified in
PVID, you can specify just the trunk port as tagged port. All ports that have the same PVID set will be added as untagged ports in a single entry.

Does that mean I do not have to specify ether1 as untagged port here for vlan 4000 if the PVID on the bridge port is set to 4000 already? I read it like that (and it would remove a simple redundant step).

8

No, not the way you wrote. Again this has nothing to do with bridge port PVID, it’s about PVID of each individual port.
I.e. you could have ether1 with pvid=4000 and ether2 with pvid=42. In this case, ether1 will be automatically added as untagged port to VLAN 4000 and ether2 will be added as untagged port to VLAN 42. All that while bridge port may have setting pvid=1 (which is, BTW, default setting and the reason for seeing all bridge ports but ether1 being members of VLAN 1 on bridge port listing from your initial post).

9

What the warning states is that for interfaces that are access ports, untagged, and when so identified in /interface bridge port settings by pvid, then one does not have to add the corresponing untagged entry for that interface in /interface bridge vlan settings. They are applied on the fly by the router. BUT!!!

However, I always do manually because I like to compare both sets of settings to ensure I havent missed anything in the logic. Further, if you dont manually untagg them they dont show up the export of the config. Thus unable to see if the admins intent is matched by the config as 1/2 the equation is missing and I would rather not assume any facts.

10

@anav
What about this other appriach. PID in the interface is NEVER used, a script can be used to check that this is the case. INSTEAD the routing table ALONE is used. One place to rule them all - with the hope that long term maybe the PID setting in the interface is allowed to be turned off. The way I remember it, the routing in hardware etc. integration is quite new - so that PID may predate the relevance of hardware routing and the unification here, and having it all in one, not two, places sound not too bad either. Anything wrong with this approach?

Another final question - how does WinBox play into all this and integrate with VLAN / Bridge? I do not talk of Winbox over IP - here the integration is obvious. I mean Winbox over Ethernet. May I assume that:

  • The packets sent from a windows machine are used, so there is no priority tagging or vlan configurable in winbox?
  • As packets are filtered on EGRESS only by default, that means Winbox packets would still reach the bridge and be processed, regardless of bridge VLAN settings BUT… the answer would be handled how? Is there any documentation on that? if I set up a VLAN as untagged on a port, and that VLAN is not matched by a VLAN on the bridge (because it is purely a port passthrough), then may I assume that WinBox also would not work? Or does the bridge see the Ethernet packets and send back packets to the same VLAN?
    This is one area I have not found ANY documentation on. The closest I could get was Tools/RoMON. It states there ni the manual that RoMon works totally independent on separately assigned MAC’s and acts as a forwarding network. And works over hops. Which would mean that RoMon could be used to access a switch that otherwise is blocked via vlan etc.
    But what without? How does the vlan / bridge functionality interact with Mikrotik over Ethernet?
11

Hi Nect.

Sorry not qualified to answer that question, not a script guru and I have never seen a config done like so. Unable to comment.

Winbox works via neighours discovery so if all your smart devices have an IP from the trusted subnet and that subnet is so identified in neighbours discovery ( and tools winbox mac-server) then you should have connectivity.

12

General remark: when L2 (including VLANs) is properly configured (and all necessary functionality enabled), then winbox (over MAC) works as expected - over VLAN interfaces etc. Essentially, winbox over MAC is no exception when it comes to L2 configuration (the only special thing is that it does not rely on proper L3 config, i.e. IP addresses et. al.). It’s quite easy to verify that that is so by limiting MAC access (under /tool/mac-server) to only certain interfaces. And yes, winbox over MAC works in the way that return packets are sent out via ingress interface …

@NetTecture: you mentioned this is a lab setup. So I suggest you to tear it apart and start from scratch (empty config), having vlan-filtering enabled right from beginning … alternatively you can try to make your current setup working, it’s not too complex. I suggest you to take out of bridge one ethernet port and set it up with dedicated IP subnet. This way you’ll have another access route in case you get the bridge setup wrong (it’s only too easy to lock oneself out and then without alternative access the only solution is to reset config and restart from scratch). Another feature, that might come handy, is safe mode … which will revert configuration to the one before enabling it if administrative connectivity gets lost. Mind that small number of actions are supposed to break adminsitrative access, in which case on must not enable safe mode.

13

Re Setup:

Have to try that out then. Given that the PVID analog is automatically generated as you say - it should be enough to assign the VLAN ID and set a port to tagged, no need to go into the Interface. As I said - smells like legacy creep, the PVID entry predating the full bridge filter functionality.

Re WinBox:

Actually WinBox does NOT work via IP discovery - it also can work via Ethernet :wink: It can also show you boxes with no or no valid IP - if it can reach it via Ethernet.

And at some point they introducd ROMON which is an ethernet based relay network that is self-organizing and can forward winbox and works by assigning additional mac addresses on interfaces, totally separate from routing :wink: Obviously with separate password (for the forwarding) and allow/deny list for interfaces.

If you open Winbox- you see top right a “connect using ROMON” button :wink:

This allows you to NOT have a management layer and still access all Mikrotik. it also makes sure you can bypass whatever crap you set up on the VLAN filtering side as it is using separate MAC addresses.

It is NOT a mangagement layer as it is a Mikrotik only setup - my management layer has a lot of other stuff in it, from BMC’s (computer management boards) to tape libraries :wink:

But this is a definite last resort connectivity layer - I like it :wink: Exactly what is needed when you work on the higher level stuff and set things up.

14

@mkx:

First, it is a lab setup I am just setting up - no need to tear anything apart :wink: Servers are ready to start but not part of that new setup yet :wink:

" I suggest you to take out of bridge one ethernet port and set it up with dedicated IP subnet." is what I originally had. Funny enough I was adviced to NOT do that as it means that any bridging between them (which may be handy on occasion, mostly when I move a server to the office for configuration) means CPU level switching. I get that as idea - so I moved it all into the bridge.

Re L2 - I was not even aware - though I use Mikrotik for about a decade - that the MAC Server menu exists. I literally had no idea how to limit Winbox Ethernet level. That explains it - WInbox works on the MAC interface as defined there (which obviously should NOT be a bridge when using VLAN style filtering for risk)

Also note that “when L2 (including VLANs) is properly configured (and all necessary functionality enabled), then winbox (over MAC) works as expected” is quite contrary to my question whether it still works when i.e. a VLAN issue blocks that… but ok, I can just allow Winbox on all physical interfaces, good enough… AND…

I enabled ROMON on the whole setup - that allows me a backdoor that cannot easily be misconfigured. This solves the other issue - without a seprate VLAN - of being able to see the whole set of installed versions and winbox into every system to update it :wink: I have a 1-1-1 setup now (home router, lab router, lab switch) that likely will turn into a 1-1-2 or 1-1-3, depending what else i need - so the ability to winbox easily into everything every half year makes a lot of benefit, ROMON handles that nicely. And I asked on a number of places how to handle that and noone even mentioned ROMON. Ah, hidden gem.

Thanks for all the help, guys :wink:

15

True you can connect by IP via Winbox, but mac via discovery is fantastic on a local network. The IP method is essential for remote connections via VPN. All good!

16

Btw., you guys overlooked one element in the VLAN that I finally found - and now it works.

I totally forgot to bind bridge as a tagged port for all the VLAN’s - so the CPU never saw traffic :wink: And you do not add the VLAN’s under bridge to the switch - only the bridge, hardware. Winbox has some issues here, offering you way too many interface (and interface lists actually). Once I did that, things worked :wink:

So, finally it works - ah, so nice. This definitely has too much docu :wink:

Now I just need to decide whether to even use the RB5009 for routing or just forward the ethernet level. Because the 10g switch happens to be a CRS317-1G-16S+ and - that has hardware routing. And multiple 10g ports directly connecting to virtualization machines so possibly some cross traffic between the VLAN’s of different projects. AAH. I stick with the 5009 for now - making this a pure “FOR NOW” router.

17

Tagging of bridge was clearly outlined in the article you purported to have read. The switch only needs the managment/trusted vlan tagged to the bridge, logically all the other vlans are simply flowing through the switch from ether1 (lets say trunk in) and out the various ports as assigned. Literacy is not our issue.

ROUTER:

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

SWITCH
add bridge=BR1 tagged=sfp1,sfp2 vlan-ids=10
add bridge=BR1 tagged=sfp1,sfp2 vlan-ids=20
add bridge=BR1 tagged=sfp1,sfp2 vlan-ids=30
add bridge=BR1 tagged=BR1,sfp1,sfp2 vlan-ids=99

Understanding how the bridge vlan operates.........

18

Didn’t I write that in my post #4 above? And the fact that you only configure things under bridge and not switch … is pretty obvious from the tutorial mentioned by @erlinden (which you dismissed in a rather rude way).