VLANs on a MikroTik can be done two ways: tagging traffic in software with a stack of separate VLAN interfaces, or using bridge VLAN filtering so the switch chip itself handles tagging in hardware. The second one is what you want on any device with a hardware switch chip — it keeps VLAN traffic off the CPU entirely, which matters a lot once you're pushing real throughput. The catch is that turning it on incorrectly, or in the wrong order, is one of the more common ways people accidentally lock themselves out of a MikroTik they're managing over that same bridge.
Create the bridge with VLAN filtering disabled
Always start with vlan-filtering=no. You'll turn it on only at the very end, once every port and VLAN is already configured.
/interface bridge add name=bridge1 vlan-filtering=noAdd the physical ports to the bridge
Set the untagged access port's PVID to the VLAN it should belong to. A port with clients that don't understand VLAN tags (a normal switch or an end device) should stay untagged and just get a PVID.
/interface bridge port add bridge=bridge1 interface=ether2 pvid=10Define the VLAN and which ports carry it tagged vs. untagged
tagged=bridge1 here means the VLAN is tagged on the bridge's own CPU-facing side (needed if the router itself has an IP in that VLAN); untagged=ether2 means traffic leaves that physical port without a tag, matching the PVID from the previous step.
/interface bridge vlan add bridge=bridge1 vlan-ids=10 tagged=bridge1 untagged=ether2Repeat this for each VLAN, adding every port that should carry it — tagged for uplinks to switches/APs, untagged for access ports.
Only now, turn VLAN filtering on
/interface bridge set bridge1 vlan-filtering=yesFrom this point, the bridge actually enforces the VLAN table you just built — any port or VLAN you forgot to add is now unreachable through the bridge.
Verify before you walk away
Check that hardware offload actually engaged — hw should show yes for offloaded VLAN entries:
/interface bridge vlan printIf you're making this change remotely, keep a second session or console access open until you've confirmed you can still reach the router — if a port you manage through got left off the VLAN table, this is where you'd find out.
Why do it this way
The order here isn't arbitrary: RouterOS starts enforcing the VLAN table the instant vlan-filtering flips to yes, not before. If you configure ports and VLANs one at a time with filtering already on, every intermediate state is a live, enforced (and incomplete) VLAN table — including the moment your own management connection's port and PVID haven't been added yet. Building the whole table first with filtering off, then flipping it on as the last step, means the switch only ever enforces a complete configuration, never a half-finished one you're sitting inside of.
How MoniTik helps
MoniTik graphs per-interface traffic and CPU usage, so you can confirm hardware offload is actually doing its job — CPU should stay flat as VLAN traffic scales, and a graph that doesn't is a sign something's still being switched in software. And if a VLAN change does lock you out of a router's local management access, MoniTik's remote WinBox tunnel reaches the router through its outbound connection to us, independent of whatever just happened to the bridge — no truck roll required to undo a mistake.
Mateo supports wireless ISPs running MikroTik gear, from first install to day-two troubleshooting.