New setup - does it look correct?

Hello all! New around here and have some questions about getting a new setup deployed.

Background:
Moving away from a UniFi setup that I’m not happy with. Currently in the PoC phase to prove to my customer (aka wife and kids) that this will be a more stable setup.

I think my network is pretty simple. It will include a single router/firewall (hEX), a single 5 port POE switch (RB260GSP) running 3x cAP XL ac and 1x wAP ac, and a single non-managed switch. I have fiber coming into the firewall (that needs a VLAN tag of 201). I will be running 4x VLANs. Only one VLAN (LAN - 10) will have both wired and wireless devices. Every other VLAN only has wireless devices. Here is crude diagram:

My questions:

  1. Does my config work for what I need to do on the router side? I know I still need switch and AP configs, but this is first.
  2. I don’t understand the VLAN security part, mostly the frame-types. Can someone explain this one to me?
  3. Is the WAN setup correctly? From what I understood I needed to create a VLAN on that interface and then tag it. But is that it?
  4. Anything else I look like I am missing?

I really appreciate any help!
hex-config.rsc (5.97 KB)

At quick glance, it looks like @pcunite’s guide VLAN guide example… http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

Some comments:

  • you block all inter-VLAN traffic - this may be what you want – but generally something like the main LAN may need to access the other VLANs (but perhaps not the other way around)

  • you have an IOT VLAN… this sounds like a good idea, and works fine depending on what the “IOT device”. But putting things like speakers and TVs into an “IOT” VLAN may not be ideal… since apps that control them sometimes expect them to be on same LAN as the smartphone/desktop to manage them. And since you’re blocking any VLAN from talking to any other VLAN, even unicast control from LAN be broken.

  • firewall doesn’t allow ping/icmp - this will break PMTUD from working, which, essentially, can occasionally cause slow connection and random issues with specific sites.

  • you don’t have a fasttrack rule for established, related connection that may reduce CPU load

  • the bridge vlan table does not include the bridge (BR0) as a tagged port, this is need for IP routing to work:

/interface bridge vlan
add bridge=BR0 tagged=> BR0> ,ether5 vlan-ids=20
add bridge=BR0 tagged=> BR0> ,ether5 vlan-ids=30
add bridge=BR0 tagged=> BR0> ,ether5 vlan-ids=40
add bridge=BR0 tagged=BR0,ether5 vlan-ids=10

  • Re frame-types… Basically for trunks use “allow-only-vlan-tagged…”, which mean the bridge port’s pvid= is NOT untagged. While “admit-only-untagged-and-priority-tagged” is an “access port” and means the pvid= is ALWAYS untagged & it is automatically added to /interface/bridge/vlan table as an untagged= port (why the above config does NOT list any untagged= lines – since there dynamically added by used a pvid= on the /interface/bridge/port.. The only nuance here is the above – basically your bridge needs to be a tagged= port in all the /interface/bridge/vlan entries.

Haha, yes it is pulled heavily from there with modifications.

Some comments:

  • you block > all > inter-VLAN traffic - this may be what you want – but generally something like the main LAN may need to access the other VLANs (but perhaps not the other way around)

That is correct. I don’t need any access to the other VLANs currently.

  • you have an IOT VLAN… this sounds like a good idea, and works fine depending on what the “IOT device”. But putting things like speakers and TVs into an “IOT” VLAN may not be ideal… since apps that control them sometimes expect them to be on same LAN as the smartphone/desktop to manage them. And since you’re blocking any VLAN from talking to any other VLAN, even unicast control from LAN be broken.

I actually let the Roku’s and stuff on the normal LAN for this reason. I consider IOT stuff like the doorbells, cameras, garage opener and stuff like that.

  • firewall doesn’t allow ping/icmp - this will break PMTUD from working, which, essentially, can occasionally cause slow connection and random issues with specific sites.

Oh good catch, I will add that.

  • you don’t have a fasttrack rule for established, related connection that may reduce CPU load

I will look into fasttrack. Thank you!

  • the bridge vlan table does not include the bridge (BR0) as a tagged port, this is need for IP routing to work:

/interface bridge vlan
add bridge=BR0 tagged=> BR0> ,ether5 vlan-ids=20
add bridge=BR0 tagged=> BR0> ,ether5 vlan-ids=30
add bridge=BR0 tagged=> BR0> ,ether5 vlan-ids=40
add bridge=BR0 tagged=BR0,ether5 vlan-ids=10

Ah thank you, I will add that!

  • Re frame-types… Basically for trunks use “allow-only-vlan-tagged…”, which mean the bridge port’s pvid= is NOT untagged. While “admit-only-untagged-and-priority-tagged” is an “access port” and means the pvid= is ALWAYS untagged & it is > automatically > added to /interface/bridge/vlan table as an untagged= port (why the above config does NOT list any untagged= lines – since there dynamically added by used a pvid= on the /interface/bridge/port.. > The only nuance here is the above – basically your bridge needs to be a tagged= port in all the /interface/bridge/vlan entries.

Okay so if they are untagged then what VLAN would they get put into if they were plugged into the switchport? Anything plugged in I want to go to VLAN 10, so should I mark those ports as tagged then? Sorry for some reason I still find this confusing lol.

I would add all smart devices should get IP from trusted vlan, so even though each CAP is providing a different vlan they all need to receive the trusted vlan to get their IP address etc…
Post normal config, pcunite format makes me puke ( or at least feel queezy ).

I don’t understand what you are saying here.

Post normal config, pcunite format makes me puke ( or at least feel queezy ).

I’m trying to apply this config to the hEX but running into issues. First my config for the WAN is definitely wrong, so I commented that out. Second now when I plug my laptop into any of the ports I’m getting a 169 address instead of the 10.20.30 address. So I need to figure that out. It’s like the ports aren’t correctly handing out addresses for the VLAN.

/export file=anynameyouwish ( minus router serial number and any public wanip information )

It’s just confusing how VLAN tagging/untagging works in the bridge. Assuming vlan-filtering=yes…
If for every “/interface/vlan add interface=BRIDGE vlan-id=XX” you add, you do “/interface/bridge/vlan add tagged=BRIDGE vlan-id=XX” that’s first the critical element. Which you partially did originally…

Then for access port (e.g. your ether2, ether3, ether4 ports) you need to see the frame-type. So:

##############################

Access Ports

##############################

ingress behavior

/interface bridge port

all interfaces in the LAN VLAN

add bridge=BR0 interface=ether2 pvid=10 > frame-types=admit-only-untagged-and-priority-tagged
add bridge=BR0 interface=ether3 pvid=10 > frame-types=admit-only-untagged-and-priority-tagged
add bridge=BR0 interface=ether4 pvid=10 > frame-types=admit-only-untagged-and-priority-tagged

L3 switching so Bridge must be a tagged member

/interface bridge vlan
add bridge=BR0 tagged=BR0 vlan-ids=10

It’s the “admit-only-untagged-and-priority-tagged” that links the pvid=10 to “automatically” add the port as untagged= in the /bridge/interface/vlan table as a “true” access port – why you do NOT need to say what’s untagged= in the bridge vlan table via config is because comes from the pvid= on a port. But you DO need to say a bridge port should be untagged for that to happen by setting the frame-types= along with pvid=

It’s hybrid ports where things get a little weird (e.g. frames-type=admit-all). This is the default value however, so why always setting frame-types= to either “admit-only-untagged-and-priority-tagged” or “admit-only-vlan-tagged” will make your life simplier.

Ah okay, that makes sense! Thank you!


I’m running into an error when I apply the script:

error while running run-after-reset script: failure: vlan already added

Once I get that resolved I can move forward with the rest.

/system reset-configuration no-defaults=yes keep-users=yes file=hex-config.rsc

if that doesn’t work… Then you use just “/system/reset-configuration no-defaults=yes keep-users=yes” to a clean router. Then connect via the MAC address in winbox, copy the hex-config.rsc, and use the following the import the configuration with “verbose=yes”:
:import verbose=yes hex-config.rsc

This will report the line that is failing in the config, so you can fix your config script, and then retry the reset-configuration with file= again – hopefully without errors in log.

Or…

egress behavior

/interface bridge vlan
add bridge=BR0 tagged=> BR0,> ether5 vlan-ids=20
add bridge=BR0 tagged=> BR0,> ether5 vlan-ids=30
add bridge=BR0 tagged=> BR0,> ether5 vlan-ids=40
set [find vlan-ids=10] > bridge=BR0 tagged=BR0,ether5 vlan-ids=10

I didn’t notice it was added in the “access port” section, so you need to “set” it instead in your trunk section… since it was added already (as indicated by error).

edit: I copied your original configuration, but you still need the bridge “BR0” in the tagged= …

Looks like it’s failing on adding the first interface to the bridge here. It fails on the line for ether2:

##############################
# Access Ports
##############################

# ingress behavior
/interface bridge port

# all interfaces in the LAN VLAN
add bridge=BR0 interface=ether2 pvid=10 frame-types=admit-only-untagged-and-priority-tagged
add bridge=BR0 interface=ether3 pvid=10 frame-types=admit-only-untagged-and-priority-tagged
add bridge=BR0 interface=ether4 pvid=10 frame-types=admit-only-untagged-and-priority-tagged

The second time I ran it (using Winbox connecting via MAC) it fails here on adding ether3:

# L3 switching so Bridge must be a tagged member
/interface bridge vlan
add bridge=BR0 tagged=BR0,ether2 vlan-ids=10
add bridge=BR0 tagged=BR0,ether3 vlan-ids=10
add bridge=BR0 tagged=BR0,ether4 vlan-ids=10

That’s not right. None of those are needed. You need just one vlan-ids=10 & to get your diagram in first spot, ether2-4 are not tagged so they do not need to be mentioned in /interface bridge vlan.

Basically you need ONE /interface/bridge/vlan per vlan-ids=XX – otherwise the 2nd config needs to be a “set” since a VLAN can only have one entry in the bridge vlan table. e.g. You can only add a bridge vlan ONCE, after added by config it needs to be set.

Repost your config.

Okay, I finally got the config to apply. It all seems to work except for the trunk on ether5, and the VLAN tagging on my WAN interface. At least as much as I can test right now with it on my bench and not connected to the network yet.

I’ve posted the updated config in both “pretty” format and the output straight from the hEX.
hex-config-no-format.rsc (3.55 KB)
hex-config.rsc (6.31 KB)

Well, you have 5 “/interface/vlan add”, so you need 5 /interface/bridge/vlans… AND, you have 5 physical ports on the router (ether1-5), so you need 5 /interface/bridge/port – that’s the double check if things look right: 5 items in each section (/interface/vlan, /interface/bridge/port, and /interface/bridge/vlan)…

You’re missing the vlan201 and didn’t define ether5 as a tagged port, so the bridge vlan should look like:

/interface bridge vlan
add bridge=BR0 tagged=BR0,ether5 vlan-ids=10
add bridge=BR0 tagged=BR0,ether5 vlan-ids=20
add bridge=BR0 tagged=BR0,ether5 vlan-ids=30
add bridge=BR0 tagged=BR0,ether5 vlan-ids=40
add bridge=BR0 tagged=BR0 vlan-ids=201

(edit: VLAN 201 is WAN so you may not want the WAN VLAN in the trunk - why it’s not tagged= in the last line…)

Similar with the bridge vlan above, you have 5 physical ports that makeup the bridge – but only define 3 of them… you forgot the WAN/ether1 and the switch-trunk-port/ether5 in the bridge ports so ADD 2 more /interface/bridge/vlan items:

/interface bridge port
add bridge=BR0 frame-types=admit-only-vlan-tagged interface=ether5 pvid=1
add bridge=BR0 frame-types=admit-only-untagged interface=ether1 pvid=201

And leave the existing 3 ports alone – those look right.


And to use ether1 as a VLAN in the bridge, it needs to listen on on the bridge, NOT interface=ether1… so the following needs to CHANGE TO interface=BR0:

/interface vlan 
add interface=BR0 name=WAN_VLAN vlan-id=201

The WAN is the same as any other bridge port… so it’s interface= the same bridge as the LANs… and why it needs to be defined as a /interface/bridge/port and /interface/brdige/vlan the same as the “VLAN_LANS”…

And, assuming the above is correct, your WAN MAY need an DHCP client to pickup a WAN address:

/ip dhcp-client add interface=WAN_VLAN

Hi,

I would definitely change hex for HAP AC3/AC2 and I would change all caps for new caps AX.

AC3 is one more time powerful and you can use wifivawe2 much better drivers than on cap xl…

Okay, so first off, thank you! Your help has been incredible and also very insightful! I am learning a ton!

I think the WAN setup is working now, but again I won’t be able to test it until I can put it into service later in the week. I’m curious when you say that the WAN is the same as any other bridge port. I have to admit it’s slightly confusing to me to think of the WAN as the same as the rest. Would it be part of the bridge if it didn’t require a VLAN? Also, does this change any of the routing? I guess I’m confused because I think of the bridge as a bridge of all my VLANs, rather than a bridge of ALL packets.

For the trunk port I am still running into issues. It’s failing here with “input does not match any value of interface”:

# egress behavior
/interface bridge vlan
add bridge=BR0 tagged=BRO,ether5 vlan-ids=10

But what is really strange to me, is if I run

/interface bridge vlan add bridge=BR0 tagged=BR0,ether5 vlan-ids=10

in the console it runs just fine.

I’ve included the full config again just for context with the changes I made from your other comment. Side note that now I see why anav doesn’t like this format, as I’m learning more it’s confusing to split it out like this. Once I get it working I need to move stuff around to make it more intuitive for sure!
hex-config.rsc (6.65 KB)

Your script is using a letter O not a 0 in “add bridge=BR0 tagged=BR0,ether5 vlan-ids=10” - if you fix that in the initialization script, you’ll get past the error.


It nice to see the parts that go into how this all works… But @anav has a point – I missed the same bridge port being added twice originally…

Now, the flip side is the “organized import” style (e.g. using /system/reset-configuration file=hex-config.rsc) allows for moving between different routers more easily down the road. Otherwise, it more difficult to adapt a working export’ed config, that you then want to import someplace else… At the end of the day, RouterOS doesn’t care about the order that much - people reading it do…

But I think your close.

FWIW ALL the bridge vlans have BRO not the actual bridge name, BR0 in tagged= - so not just vlan-ids=10…

Minor point from latest config… In RouterOS, you technically don’t need to use the full-names of the config values if they are unique. But since your config is pretty clean, theoritically this:

/interface bridge port
add bridge=BR0 interface=ether1 pvid=201 frame-types=admit-only-untagged

should be:

/interface bridge port
add bridge=BR0 interface=ether1 pvid=201 frame-types=admit-only-untagged> -and-priority-tagged

(and I think you got that from my example, as I said it doesn’t matter much - both do same)



I’m curious when you say that the WAN is the same as any other bridge port. I have to admit it’s slightly confusing to me to think of the WAN as the same as the rest.

In terms of WAN / ether1 / VLAN 201… I just meant that it’s an “access port” in /interface/bridge, so configured the same (e.g. it gets a bridge port+pvid and has to listed in bridge vlan table – that part is same). And logic of a “WAN VLAN” is similar other VLANs in the @pcunite scheme – it gets an interface-list assigned that used in firewall to control what it does. It what happens in the firewall rules is what makes a WAN different from a LAN (or VLANS list) - based on the indirect address-list being the glue.

Okay fixed all the BRO’s lol. Good catch thank you!

I’ve started to clean this up a bit and noticed that it seems like this section:

/interface bridge port
add bridge=BR0 interface=ether2 pvid=10 frame-types=admit-only-untagged-and-priority-tagged
add bridge=BR0 interface=ether3 pvid=10 frame-types=admit-only-untagged-and-priority-tagged
add bridge=BR0 interface=ether4 pvid=10 frame-types=admit-only-untagged-and-priority-tagged
# this should allow ether5 to act as a trunk
add bridge=BR0 interface=ether5 pvid=10 frame-types=admit-only-vlan-tagged
# wan port on ether1 with the 201 vlan
add bridge=BR0 interface=ether1 pvid=201 frame-types=admit-only-untagged

is duplicated again further down in my “VLAN security” section:

#######################################
# VLAN Security
#######################################

# Only allow ingress packets without tags on Access Ports
/interface bridge port
set bridge=BR0 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether2]
set bridge=BR0 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether3]
set bridge=BR0 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged [find interface=ether4]

# Only allow ingress packets with tags on Trunk ports
# /interface bridge port set bridge=BR0 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether5]

Looks like the only difference is the inclusion of ingress-filtering=yes and setting the pvid. Can I add that to the above section and then remove the “Security” section entirely? If I understand the syntax correctly set is just changing options on something that is already added.

Besides that this now applies cleanly. Just need to wait for a time when everyone is out of the house and I am going to try and put it into “production” and see if it works.

You have it right. You can only use “add” once to create the entry. So the 2nd “VLAN security” ones use a “set” operation to modify an existing item. And, yes seem it just adds ingress-filtering=yes.

It be safe to move the ingress-filtering=yes to the first “add” ones – actually that one of the benefits of apply a config via “/system/reset-configuration file=” method… See if you entered each on of the config lines “manual” (e.g. config lines entered one-by-one in CLI), the process of changing the bridge ports/vlans configs (e.g. the port you’d be using if done manually…) can result in your terminal access being dropped and/or losing terminal access…

But since the system runs your config script when it’s done at boot via the reset-configuration, it doesn’t need a working port in the process of config. Thus, the need for seperate operations that could lock you out are unnecessary (like the VLAN security “set” of bridge ports in @pcunite examples)