Tagged trunks, untagged access ports, and per-VLAN IP interfaces — on both hAP/RB and CRS hardware. The foundation every segmented network is built on.
A flat network puts every device — guest laptops, staff PCs, IP cameras, payment terminals, and management interfaces — on the same broadcast domain. One compromised device reaches all others. One misconfigured IoT thermostat can broadcast-storm the whole property. VLANs fix this by creating isolated Layer 2 segments that share physical infrastructure but cannot communicate without an explicit routing decision.
This tutorial builds a complete VLAN setup for a hospitality network: Management (VLAN 10), Servers (VLAN 20), Guest WiFi (VLAN 30), and IoT (VLAN 40). We cover the RouterOS v7 bridge-based VLAN model used on hAP / RB devices, and the hardware-offloaded switch chip model used on CRS devices. The trunk/access port model and IP interface configuration are identical for both — only the VLAN filtering approach differs.
01
Every VLAN confusion trace back to one misunderstood concept: where the tag lives and where it gets stripped.
An 802.1Q VLAN tag is a 4-byte header inserted into an Ethernet frame, carrying a 12-bit VLAN ID (1–4094). Switches use this tag to decide which broadcast domain a frame belongs to. The tag is added, passed, and removed at specific points in the network:
Access port — connects to an end device (PC, printer, IP camera). Receives untagged frames from the device, adds the VLAN tag before forwarding. Strips the tag before sending back to the device. The end device never sees a tag.
Trunk port — connects switches to each other, or a switch to a router. Carries multiple VLANs simultaneously, each frame tagged. The receiving device must understand 802.1Q tags.
PVID (Port VLAN ID) — the VLAN assigned to untagged frames arriving on an access port. On RouterOS, this is set per bridge port.
bridge1, tick VLAN Filtering = yes, Frame Types = admit-all. Click Apply.In RouterOS v6, VLANs were often configured directly on the switch chip using /interface ethernet switch. In v7, the correct and supported method is bridge-based VLAN filtering: all interfaces join a bridge, and VLAN policy is defined on the bridge and its ports. The old switch chip method still exists on some hardware but is not recommended for new deployments. Everything in this tutorial uses the v7 bridge method.
02
Write the plan before touching the CLI — every command you type should map directly to a row in this table.
03
On hAP and RB devices, VLANs live on the bridge. Three steps: build the bridge with VLAN filtering enabled, define trunk and access ports, create VLAN IP interfaces.
The RouterOS v7 bridge VLAN model works like this: one bridge holds all LAN ports. VLAN filtering is enabled on the bridge itself. Each port is assigned tagged or untagged membership for specific VLANs. The bridge enforces the tagging policy in software (or with switch chip offload on supported hardware).
# ── STEP ZERO: enable vlan-filtering on the bridge ─────────────────────── # Without vlan-filtering=yes the VLAN table and PVID settings are completely # ignored — all ports behave as if they are in the same flat network. # Set this FIRST, before adding ports or defining the VLAN table. [admin@MikroTik] > /interface bridge add \ name=bridge1 \ vlan-filtering=yes \ frame-types=admit-all \ comment="Main LAN bridge with VLAN filtering" # vlan-filtering=yes: enables 802.1Q enforcement on this bridge. # Without this, VLAN tags are ignored and all ports are in the same domain. # frame-types=admit-all: bridge accepts both tagged and untagged frames. # Individual ports will further restrict what they accept.
# ── TRUNK PORT (ether2 → downstream switch) ────────────────────────────── # Carries all VLANs tagged. frame-types=admit-only-vlan-tagged means # untagged frames arriving here are dropped. [admin@MikroTik] > /interface bridge port add \ interface=ether2 \ bridge=bridge1 \ frame-types=admit-only-vlan-tagged \ comment="Trunk → downstream switch" # ── ACCESS PORT (ether3 → VLAN 10, staff PC) ───────────────────────────── # pvid=10 means untagged frames arriving here are assigned to VLAN 10. # frame-types=admit-only-untagged-and-priority-tagged means tagged frames # arriving from the PC are dropped — end devices shouldn't send tags. [admin@MikroTik] > /interface bridge port add \ interface=ether3 \ bridge=bridge1 \ pvid=10 \ frame-types=admit-only-untagged-and-priority-tagged \ comment="Access port → VLAN 10 MGMT" # ── ACCESS PORT (ether4 → VLAN 40, IoT) ────────────────────────────────── [admin@MikroTik] > /interface bridge port add \ interface=ether4 \ bridge=bridge1 \ pvid=40 \ frame-types=admit-only-untagged-and-priority-tagged \ comment="Access port → VLAN 40 IoT"
The bridge VLAN table defines which ports are tagged or untagged members of each VLAN. This is separate from the port configuration — both must be set correctly.
[admin@MikroTik] > /interface bridge vlan # VLAN 10 — Management # ether2 (trunk): tagged member | ether3 (access): untagged member # bridge1 itself: tagged — needed for the router's own IP on this VLAN [admin@MikroTik] /interface/bridge/vlan> add \ bridge=bridge1 vlan-ids=10 \ tagged=bridge1,ether2 \ untagged=ether3 # VLAN 20 — Servers (trunk only — no local access ports in this example) [admin@MikroTik] /interface/bridge/vlan> add \ bridge=bridge1 vlan-ids=20 \ tagged=bridge1,ether2 # VLAN 30 — Guest WiFi (trunk only — AP on downstream switch handles access) [admin@MikroTik] /interface/bridge/vlan> add \ bridge=bridge1 vlan-ids=30 \ tagged=bridge1,ether2 # VLAN 40 — IoT [admin@MikroTik] /interface/bridge/vlan> add \ bridge=bridge1 vlan-ids=40 \ tagged=bridge1,ether2 \ untagged=ether4 # Verify: [admin@MikroTik] > /interface bridge vlan print # BRIDGE VLAN-IDS TAGGED UNTAGGED 0 bridge1 10 bridge1,ether2 ether3 1 bridge1 20 bridge1,ether2 2 bridge1 30 bridge1,ether2 3 bridge1 40 bridge1,ether2 ether4
admit-only-vlan-tagged (trunk). Add ether3 with PVID = 10, frame-types = admit-only-untagged (access). Repeat for each access port with its PVID.The bridge interface itself (bridge1) must be in the tagged= list for every VLAN you want the router to route or serve DHCP on. If you omit it, the VLAN interface you create in Step 4 will have no path to send or receive traffic. This is the most common reason DHCP doesn't work after adding VLANs — the bridge isn't a tagged member of its own VLAN table entry.
bridge1,ether2, set Untagged = the access port(s) for that VLAN. bridge1 must be in Tagged for every row.Create a VLAN sub-interface on top of bridge1 for each VLAN. Assign a gateway IP. This is where the router terminates each VLAN's traffic.
# Create VLAN interfaces on bridge1: [admin@MikroTik] > /interface vlan [admin@MikroTik] /interface/vlan> add name=vlan10 vlan-id=10 interface=bridge1 comment="MGMT" [admin@MikroTik] /interface/vlan> add name=vlan20 vlan-id=20 interface=bridge1 comment="Servers" [admin@MikroTik] /interface/vlan> add name=vlan30 vlan-id=30 interface=bridge1 comment="Guest WiFi" [admin@MikroTik] /interface/vlan> add name=vlan40 vlan-id=40 interface=bridge1 comment="IoT" # Assign gateway IPs: [admin@MikroTik] > /ip address [admin@MikroTik] /ip/address> add address=192.168.10.1/24 interface=vlan10 comment="MGMT gateway" [admin@MikroTik] /ip/address> add address=192.168.20.1/24 interface=vlan20 comment="Servers gateway" [admin@MikroTik] /ip/address> add address=192.168.30.1/24 interface=vlan30 comment="Guest gateway" [admin@MikroTik] /ip/address> add address=192.168.40.1/24 interface=vlan40 comment="IoT gateway" [admin@MikroTik] > /ip address print # ADDRESS NETWORK INTERFACE 0 192.168.10.1/24 192.168.10.0 vlan10 1 192.168.20.1/24 192.168.20.0 vlan20 2 192.168.30.1/24 192.168.30.0 vlan30 3 192.168.40.1/24 192.168.40.0 vlan40
192.168.10.1/24, Interface = vlan10. Repeat for vlan20, vlan30, vlan40 with their respective gateway IPs.# Add IP pool and DHCP server for each VLAN. # Example shown for VLAN 10 — repeat pattern for 20, 30, 40. [admin@MikroTik] > /ip pool add name=pool-vlan10 ranges=192.168.10.100-192.168.10.200 [admin@MikroTik] > /ip dhcp-server add \ name=dhcp-vlan10 \ interface=vlan10 \ address-pool=pool-vlan10 \ lease-time=12h \ disabled=no [admin@MikroTik] > /ip dhcp-server network add \ address=192.168.10.0/24 \ gateway=192.168.10.1 \ dns-server=192.168.10.1 \ comment="VLAN 10 MGMT network" # Repeat with vlan20/30/40 names and their respective subnets. # For Guest VLAN 30: consider shorter lease-time=2h and # a smaller pool — guests check in and out.
vlan10, fill the address pool range, gateway, and DNS. Repeat for each VLAN. Guest VLAN (30) should get a shorter lease time — 2h.Addendum to Section 03
VLAN filtering is not enabled by default on a new bridge. Without it, every port is in the same broadcast domain regardless of PVID, frame-types, or VLAN table entries — all 802.1Q tags are silently ignored. This is the single most common reason a "VLAN setup" appears to work but provides zero isolation.
The correct sequence is: create the bridge with vlan-filtering=yes set from the start. If you are retrofitting an existing bridge, enable it with caution — it takes effect immediately and will drop all traffic that doesn't match the VLAN table. Use /system safe-mode before doing this on a live network.
[admin@MikroTik] > /interface bridge print Flags: X - disabled, R - running 0 R name="bridge1" mtu=1500 vlan-filtering=yes ← must be yes # If vlan-filtering=no, every port is in the same domain. # To enable on existing bridge (caution — brief traffic drop): # /interface bridge set bridge1 vlan-filtering=yes
A bridge with vlan-filtering=no forwards all frames between all ports regardless of PVID or VLAN table. If you plug a guest device into ether3 (PVID 10) and a server into ether4 (PVID 40), they can communicate freely — as if no VLANs exist. The VLAN table is built but completely inoperative. Always verify this setting first when debugging "VLANs not isolating" complaints.
When the router's trunk port (ether2) connects to a downstream managed switch, that switch must also understand 802.1Q tags. It receives all VLANs tagged from the router and distributes them to access ports for end devices. The configuration on the downstream switch follows exactly the same bridge VLAN model — it's running RouterOS too.
The downstream switch needs: one trunk port facing the router (ether1, frame-types=admit-only-vlan-tagged), one access port per VLAN with the correct PVID, and a matching VLAN table. If any VLAN is missing from the downstream switch's VLAN table, frames for that VLAN are silently dropped at that switch — devices on it won't get DHCP responses and won't reach the network.
frame-types=admit-only-vlan-tagged, no PVID change. ether2–5 are access ports — one per VLAN, each with the correct PVID and admit-only-untagged. If an AP needs to carry a guest VLAN tagged (e.g. ether6 → AP with SSID on VLAN 30), that port also uses admit-only-vlan-tagged.# On the DOWNSTREAM switch — run same commands as router VLAN table. # ether1 is the trunk uplink from router. # Every VLAN that arrives tagged on ether1 needs an entry here. [admin@DownstreamSwitch] > /interface bridge vlan [admin@DownstreamSwitch] /interface/bridge/vlan> add \ bridge=bridge1 vlan-ids=10 \ tagged=bridge1,ether1 \ untagged=ether2 # bridge1 tagged = allows upstream router to route traffic for this VLAN # ether1 tagged = trunk uplink carries VLAN 10 tagged # ether2 untagged = staff PC connects here, receives untagged frames [admin@DownstreamSwitch] /interface/bridge/vlan> add \ bridge=bridge1 vlan-ids=20 \ tagged=bridge1,ether1 \ untagged=ether3 [admin@DownstreamSwitch] /interface/bridge/vlan> add \ bridge=bridge1 vlan-ids=30 \ tagged=bridge1,ether1,ether6 \ untagged=ether4 # ether6 is a trunk to an AP — it carries VLAN 30 tagged so the AP # can broadcast the guest SSID on VLAN 30. [admin@DownstreamSwitch] /interface/bridge/vlan> add \ bridge=bridge1 vlan-ids=40 \ tagged=bridge1,ether1 \ untagged=ether5 # Verify: # /interface bridge vlan print # Every VLAN must show ether1 in tagged and the correct port in untagged.
If VLAN 30 exists on the router but you forget to add it to the downstream switch's VLAN table, every frame tagged VLAN 30 that arrives on ether1 is dropped at that switch. Devices connected to ether4 (PVID 30) get no DHCP, no connectivity, and no error message — it just doesn't work. When debugging "one VLAN doesn't work", always check the downstream switch's VLAN table first.
Plugging an unmanaged (dumb) switch into a trunk port passes all tagged frames to whatever is connected to it. End devices receive raw 802.1Q-tagged frames they cannot process — they get no IP, and may log confusing errors. Unmanaged switches must only connect to access ports where frames are already untagged. If you need to extend a trunk to another room or floor, use a managed switch that understands 802.1Q.
Moving a device from one VLAN to another — say a staff PC on VLAN 10 being reassigned to VLAN 20 (Servers) — requires two changes: update the port's PVID, and update the bridge VLAN table so the port is an untagged member of the new VLAN (and removed from the old one).
# Step 1: Change PVID on the port [admin@MikroTik] > /interface bridge port set \ [find interface=ether3] \ pvid=20 \ comment="Servers — reassigned from VLAN 10" # Step 2: Remove ether3 from VLAN 10 untagged list [admin@MikroTik] > /interface bridge vlan set \ [find vlan-ids=10] \ untagged="" # If other ports are still untagged on VLAN 10, list them explicitly: # untagged=ether5,ether6 (keep all except ether3) # Step 3: Add ether3 to VLAN 20 untagged list [admin@MikroTik] > /interface bridge vlan set \ [find vlan-ids=20] \ untagged=ether3 # Verify the port now sees VLAN 20 traffic — device should get # a 192.168.20.x address from dhcp-vlan20 after reconnecting. [admin@MikroTik] > /ip dhcp-server lease print \ where server=dhcp-vlan20 # New lease should appear for ether3's connected device.
Setting PVID=20 on a port tells the bridge to tag incoming untagged frames as VLAN 20. But if VLAN 20's table entry doesn't list this port as an untagged member, the bridge won't send VLAN 20 frames back out that port untagged — the device receives nothing. Both the PVID and the VLAN table entry must be in sync. After every port reassignment, verify with /interface bridge vlan print that the port appears in the correct VLAN's untagged column.
04
CRS3xx devices can push VLAN tagging into the switch chip, wirebinding at line rate. The configuration model is the same — only the offload flag differs.
On CRS (Cloud Router Switch) devices, the bridge VLAN filtering configuration is identical to the hAP method above. The difference is that CRS hardware can offload VLAN tagging to the switch ASIC, bypassing the CPU entirely for switching decisions. This gives line-rate performance even at 1G/10G with many VLANs.
To enable hardware offload, set hw=yes on bridge ports that the switch chip supports. Not all ports on all CRS devices support offload — check the MikroTik wiki for your specific model.
# Same bridge and VLAN table as hAP method. # Add hw=yes to ports that support switch chip offload: [admin@MikroTik] > /interface bridge port set [find interface=ether2] hw=yes [admin@MikroTik] > /interface bridge port set [find interface=ether3] hw=yes [admin@MikroTik] > /interface bridge port set [find interface=ether4] hw=yes # Verify hardware offload is active: [admin@MikroTik] > /interface bridge port print # INTERFACE BRIDGE HW PVID FRAME-TYPES STATE 0 ether2 bridge1 yes 1 admit-only-vlan-tagged forwarding 1 ether3 bridge1 yes 10 admit-only-untagged-and-prio... forwarding 2 ether4 bridge1 yes 40 admit-only-untagged-and-prio... forwarding # HW=yes means the switch chip handles tagging — CPU is not involved # for transit switching traffic. Only routed traffic (inter-VLAN) hits CPU. # On CRS you can also verify switch chip port assignment: [admin@MikroTik] > /interface ethernet switch port print # Ports with "master-port" set are controlled by the switch chip.
bridge1 in the tagged column — this is what gives the router's VLAN interfaces their traffic path. Coloured rows correspond to the VLAN plan above.
Enabling vlan-filtering=yes on a bridge that already has active ports and clients causes an immediate traffic interruption. The bridge starts enforcing VLAN policy instantly — before you've defined the VLAN table. Frames that don't match any VLAN table entry are dropped. The correct sequence is: create the bridge with vlan-filtering=yes before adding any ports, build the complete VLAN table, then add ports. If you're reconfiguring a live network, use /system safe-mode first.
05
Four verification checks — one at each layer. Don't skip any of them.
# 1. Are VLAN interfaces up and have correct IPs? [admin@MikroTik] > /interface vlan print Flags: R - running # R NAME MTU ARP VLAN-ID INTERFACE 0 R vlan10 1500 enabled 10 bridge1 1 R vlan20 1500 enabled 20 bridge1 2 R vlan30 1500 enabled 30 bridge1 3 R vlan40 1500 enabled 40 bridge1 # All should show R (running). If not: bridge1 missing from tagged list. # 2. Are DHCP servers bound and leasing? [admin@MikroTik] > /ip dhcp-server print # NAME INTERFACE ADDRESS-POOL LEASE-TIME STATUS 0 dhcp-vlan10 vlan10 pool-vlan10 12h running 1 dhcp-vlan20 vlan20 pool-vlan20 12h running 2 dhcp-vlan30 vlan30 pool-vlan30 2h running 3 dhcp-vlan40 vlan40 pool-vlan40 12h running # 3. Are clients getting IPs? (after connecting a device to each VLAN) [admin@MikroTik] > /ip dhcp-server lease print # ADDRESS MAC-ADDRESS HOST-NAME SERVER STATUS 0 192.168.10.100 AA:BB:CC:DD:EE:01 staff-pc dhcp-vlan10 bound 1 192.168.40.10 AA:BB:CC:DD:EE:02 camera-1 dhcp-vlan40 bound # 4. Can the router ping each VLAN gateway? [admin@MikroTik] > /ping 192.168.10.1 count=2 src-address=192.168.10.1 0 192.168.10.1 56 64 0ms echo reply 1 192.168.10.1 56 64 0ms echo reply # Repeat for .20.1, .30.1, .40.1 # 5. VLAN isolation check — IoT should NOT reach MGMT # (run from a device on VLAN 40, should time out if firewall is correct) [admin@MikroTik] > /ip firewall connection print count-only where \ src-address~"192.168.40." and dst-address~"192.168.10." # Should be 0 if inter-VLAN firewall rules are in place. # Without firewall rules, VLANs can route to each other — see Defender's View.
Creating VLANs does not automatically isolate them. The router has IP interfaces on every VLAN and will happily route between them unless the forward chain explicitly drops inter-VLAN traffic. A guest on VLAN 30 can reach your NAS on VLAN 20 the moment you add IP interfaces — unless you add forward chain rules blocking it. See the Firewall Filter Chains tutorial for the complete inter-VLAN firewall ruleset. At minimum, add: chain=forward in-interface=vlan30 out-interface=!WAN action=drop to isolate guests immediately.
VLANs are a security boundary only if you treat them as one. The common mistake is creating VLANs for segmentation but leaving the firewall forward chain wide open. The VLAN tagging only guarantees Layer 2 isolation — Layer 3 routing between VLANs is still fully functional until the firewall stops it. After building VLANs, your next step is the forward chain rules from the Firewall Filter Chains tutorial.
Guest VLAN isolation is the most critical rule for hospitality. Add this to the forward chain immediately after creating VLANs: chain=forward in-interface=vlan30 out-interface-list=!WAN action=drop comment="isolate guest VLAN". This single rule prevents guests from reaching any internal network. Test it: connect to the guest SSID and confirm you cannot ping 192.168.10.1.
IoT VLAN should have WAN-only access too. IP cameras and smart devices have a poor security track record. Give them internet access only (firmware updates, cloud services) and block all access to management and server VLANs: chain=forward in-interface=vlan40 out-interface-list=!WAN action=drop.
Static DHCP leases for infrastructure. Servers, NAS devices, cameras, and access points should have static DHCP leases so their IPs never change. This makes firewall rules, monitoring, and troubleshooting predictable. Set them via /ip dhcp-server lease add mac-address=... address=... server=dhcp-vlan20.
Tag everything, trust nothing. Any unmanaged switch plugged into a trunk port will pass all VLAN tags to whatever is connected to it. An unmanaged switch should only connect to access ports — never trunk ports — unless it's a managed switch you control.
Takeaways
vlan-filtering=yes on the bridge before adding ports. Enabling it on a live bridge drops all traffic that doesn't match the (as-yet-empty) VLAN table. The correct order is: create bridge with filtering → build VLAN table → add ports → add IP interfaces.bridge1 must be in the tagged list of every VLAN you want the router to serve. Without it, the VLAN interface has no path to send or receive frames. This is the most common reason DHCP doesn't work after configuring VLANs.pvid= and frame-types=admit-only-untagged. Trunk ports get frame-types=admit-only-vlan-tagged. These two settings together enforce the boundary between tagged and untagged domains. Getting either wrong causes silent traffic loss that looks like a routing problem.hw=yes to bridge ports for line-rate VLAN switching. Without it, all switching goes through the CPU — which is fine for small networks but will bottleneck a busy property with many clients.NOCTIS designs and deploys segmented networks for hospitality properties — proper VLAN architecture with guest isolation, IoT containment, and management plane hardening. Most flat networks we find take half a day to segment correctly. Book a call to find out what your network actually looks like.
Book a Discovery Call →