VLAN configuration on RouterOS trips up more newcomers than routing or firewalling do. The reason is that RouterOS exposes the mechanism rather than hiding it behind a wizard, so you have to understand what a bridge actually does with a tagged frame before the configuration makes sense.
For the initial login, management restrictions and recovery preparation, start with the MikroTik router setup checklist. Then use the port plan below before enabling VLAN filtering.
The bridge is the switch
On RouterOS, a bridge is the software switch. Ports added to a bridge share one broadcast domain. Turning on VLAN filtering on that bridge changes it from a flat switch into a VLAN aware one, and from that moment every frame is evaluated against the bridge VLAN table.
Two settings govern each port. The PVID is the VLAN assigned to untagged frames arriving on that port. The frame types setting controls whether the port accepts tagged frames, untagged frames, or both. An access port carrying one VLAN has that VLAN as its PVID and admits only untagged frames. A trunk port carrying several VLANs admits only tagged frames and appears in the tagged list for each VLAN it should carry.
The bridge VLAN table is the other half. Each entry names a VLAN ID and lists which ports are tagged members and which are untagged members. Egress membership decides where that VLAN can leave. RouterOS can also add untagged membership dynamically from a port’s PVID, so inspect the current table as well as the static entries. Enable ingress-filtering to check arriving frames against the ingress port’s membership too.
PVID, tagged and untagged port plan
This illustrative plan uses VLAN 10 for trusted clients, VLAN 20 for IoT and VLAN 99 for management. ether1 remains outside this bridge for WAN or another separate role. ether2 connects to a VLAN-aware switch. The other ports serve untagged clients. Match the far-end switch configuration to this plan; these port numbers are examples.
| Port | Role | PVID for untagged ingress | frame-types | ingress-filtering |
|---|---|---|---|---|
ether2 | Tagged trunk: 10, 20, 99 | Unused for admitted traffic | admit-only-vlan-tagged | yes |
ether3 | Trusted access | 10 | admit-only-untagged-and-priority-tagged | yes |
ether4 | IoT access | 20 | admit-only-untagged-and-priority-tagged | yes |
ether5 | Management access | 99 | admit-only-untagged-and-priority-tagged | yes |
Keep a separate bridge VLAN table row for each access VLAN:
| VLAN ID | Tagged members | Untagged members | Intended traffic |
|---|---|---|---|
| 10 | ether2 | ether3 | Trusted clients to the upstream switch |
| 20 | ether2 | ether4 | IoT clients to the upstream switch |
| 99 | ether2,bridge1 | ether5 | Management client and router management interface |
Here bridge1 is the bridge/CPU port, with a VLAN 99 interface above it for the management address. It is not an untagged access port. This example only needs CPU membership in VLAN 99. If RouterOS must also route or serve DHCP for VLANs 10 and 20, add bridge1 as a tagged member of each and create the corresponding VLAN interfaces. The DHCP server setup guide covers those separate scopes.
MikroTik’s Bridge VLAN Table documentation distinguishes ingress classification from egress tagging. A PVID classifies admitted untagged traffic; it does not rewrite an ordinary tagged frame’s VLAN ID. Tagged membership preserves the tag on egress, while untagged membership removes it.
Avoid grouping several VLAN IDs in one row that also lists access ports: it can permit unintended untagged egress. Also inspect dynamic VLAN 1 membership. A trunk and the bridge retaining PVID 1 can accidentally share an untagged management path unless frame admission prevents it.
Ingress filtering: check arrivals as well as exits
With ingress-filtering=yes, a frame must belong to a VLAN allowed on the port where it arrived. On the example trunk, an arriving VLAN 99 frame is admitted; an unlisted VLAN is rejected. On the IoT access port, admitted untagged traffic is classified into VLAN 20. Restricting frame types there prevents a client from supplying ordinary tagged frames.
Inspect /interface bridge port print detail and /interface bridge vlan print detail together. Check CURRENT-TAGGED, CURRENT-UNTAGGED and dynamic rows against the design. A working PVID alone does not prove that trunk membership or CPU access is correct.
Where management lives
This is where people lock themselves out. Once VLAN filtering is enabled, the bridge interface itself is treated as a port. If you want to manage the device from a tagged VLAN, you create a VLAN interface on top of the bridge, put the management IP address there, and add the bridge to that VLAN’s tagged member list. Skipping that last step means the router has an address it can never receive frames for.
Enabling VLAN filtering before the table is complete cuts access immediately. The safe pattern is to build the entire VLAN table and the management VLAN interface first, verify the entries, and only then flip filtering on. Doing that work over a console connection, or through a port deliberately left outside the bridge, gives you a way back in. Use Safe Mode for small batches of changes: it can undo them if its session ends abnormally. Release it only after confirming access; the setup checklist covers the recovery preparation.
MAC WinBox is the other route back, since it reaches the device over Layer 2 without needing an IP address to be reachable. That only helps if the service was left enabled and scoped to an interface you can still reach, which is one of the decisions made during initial setup of a new RouterOS box.
Hardware offload
Many MikroTik switch models have a switch chip that can perform VLAN filtering in hardware rather than in the CPU. Eligible traffic can stay in the switch chip, subject to port and switch-fabric capacity. Traffic to the router, routing between VLANs and unsupported features can still involve the CPU. A working VLAN therefore does not prove that every flow is hardware offloaded.
Which combinations qualify depends on the switch chip and RouterOS version. MikroTik documents that devices using a Marvell Prestera chip, along with the RTL8367, 88E6393X, 88E6191X, 88E6190, MT7621, MT7531, and EN7523 chips, can run bridge VLAN filtering and hardware offloading at the same time under RouterOS v7. Boards outside that list will accept the same configuration and forward it in software instead. Which chip a given model carries is listed on its product page, and the practical consequences per tier are compared in the MikroTik router buying guide.
The switch-chip model table and bridge hardware-offload matrix explain the main differences:
| Switch chip or family | Bridge VLAN filtering with hardware offload | Caveat to check |
|---|---|---|
| Marvell Prestera | Supported on listed devices | Verify the exact model’s bridge-feature matrix; Layer 3 offload is separate |
| 88E6393X, 88E6191X, 88E6190 | Supported in RouterOS v7 | Check chip-specific feature limits and physical port mapping |
| MT7621, MT7531, EN7523 | Supported in RouterOS v7 | hEX RB750Gr3 and hEX S RB760iGS use MT7621; hEX Refresh E50UG lists EN7523 for ether2-ether5 |
| RTL8367 | Supported in RouterOS v7 | RB1100AHx4 uses three separate RTL8367 port groups; inspect the inter-chip path |
| QCA8337 and Atheros8327 | Not supported by the bridge VLAN-offload method | Consult switch-menu VLAN configuration; do not assume vlan-filtering=yes keeps forwarding in hardware |
Read /interface bridge port print after the change: hw=yes requests offload, while the H flag reports active hardware offload. Most devices support one offloaded bridge per switch chip, with documented exceptions. Use the model’s block diagram when traffic crosses chip groups; support on two ports does not imply an unlimited path between them.
Practically this means checking whether hardware offloading is actually active on your bridge ports after making changes, rather than assuming it. Certain features force traffic into software, and several bridge and port properties are tied directly to switch-chip settings, so changing them can reset the chip and briefly disable every port on it. Discovering that after deployment, when the device is under load, is a bad time to learn it. If traffic that should never reach the CPU is showing up in the CPU profile, the diagnostic order is set out in why RouterOS throughput drops when CPU load climbs.
Common mistakes
Leaving a port’s PVID at the default while expecting it to carry a different VLAN. Adding a VLAN to a trunk but forgetting the far end of the link. Mixing tagged and untagged membership for the same VLAN on the same port. Treating a VLAN interface on a physical port and a VLAN interface on the bridge as interchangeable, since only one of them sees bridged traffic.
Draw the intended tagged and untagged membership for every port before typing anything. Most VLAN faults are design errors, not syntax errors.
Before you commit to a design
Two things are worth settling before the first bridge command. The first is where management will live and how you get back in if it goes wrong, which is part of the initial hardening pass on a new device. The second is whether the hardware can hold the design in the switch chip at all, because a VLAN plan that falls back to software forwarding turns a wire-speed switch into a CPU-bound one. The RouterOS FastPath and switch-chip sizer shows the difference between offloaded and CPU-bridged forwarding for each hardware tier.
