MikroTik VLAN Filtering on a Bridge: PVID, Ingress, Offload

MikroTik bridge VLAN filtering is off by default (vlan-filtering=no). Build the VLAN table and a management VLAN interface first, then run /interface bridge set bridge1 vlan-filtering=yes. After that, each port’s PVID tags untagged arrivals, frame-types sets what it admits, and ingress-filtering, on by default since RouterOS v7, drops frames from VLANs the port does not belong to.

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.

Defaults: PVID 1, admit-all, ingress filtering on

None of the port settings does anything until the bridge has vlan-filtering=yes. Defaults from MikroTik’s RouterOS manual:

Two cause most surprises: an access port left at PVID 1 puts its clients in VLAN 1, and admit-all accepts frames a client has already tagged.

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.

Keep a separate bridge VLAN table row for each access VLAN:

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.

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.

How to enable VLAN filtering on a RouterOS bridge

Order matters more than syntax: ports, then the VLAN table, then management, and vlan-filtering=yes last. MikroTik’s Bridge VLAN Table guide recommends a serial console, because filtering without management access locks you out. For the plan above:

1. Create the bridge with filtering off and add the ports. On an existing bridge, change the port entries with set [find interface=ether3] pvid=10 under /interface bridge port instead.

   /interface bridge add name=bridge1 vlan-filtering=no
   /interface bridge port
   add bridge=bridge1 interface=ether2 frame-types=admit-only-vlan-tagged
   add bridge=bridge1 interface=ether3 pvid=10 frame-types=admit-only-untagged-and-priority-tagged
   add bridge=bridge1 interface=ether4 pvid=20 frame-types=admit-only-untagged-and-priority-tagged
   add bridge=bridge1 interface=ether5 pvid=99 frame-types=admit-only-untagged-and-priority-tagged

2. Add one VLAN table row per access VLAN, with bridge1 tagged in VLAN 99.

   /interface bridge vlan
   add bridge=bridge1 tagged=ether2 untagged=ether3 vlan-ids=10
   add bridge=bridge1 tagged=ether2 untagged=ether4 vlan-ids=20
   add bridge=bridge1 tagged=ether2,bridge1 untagged=ether5 vlan-ids=99

3. Put the management address on a VLAN interface on the bridge, not on a port.

   /interface vlan add interface=bridge1 name=vlan99 vlan-id=99
   /ip address add address=192.168.99.1/24 interface=vlan99

4. Compare /interface bridge vlan print and /interface bridge port print detail with the tables above.

5. Press Ctrl+X or F4 to take Safe Mode, then run /interface bridge set bridge1 vlan-filtering=yes. The bridge resets itself to apply filtering, so a brief disconnect is normal.

6. Confirm a new session over VLAN 99. Then close the CPU port to untagged frames with /interface bridge set bridge1 frame-types=admit-only-vlan-tagged ingress-filtering=yes, test again, and only then leave Safe Mode.

Port ingress-filtering=yes is already the v7 default, so the commands omit it. If a terminal connection drops in Safe Mode, the rollback waits for the 9-minute TCP timeout, per MikroTik’s Configuration Management documentation; beyond 100 recorded actions, Safe Mode exits without undoing anything.

Ingress filtering: check arrivals as well as exits

MikroTik ingress filtering drops a frame on arrival when the receiving port is not a member of that frame’s VLAN in the bridge VLAN table. Without it, RouterOS drops VLANs missing from the table only at egress, per the Bridge VLAN Table guide. It is the port default since RouterOS v7 and acts only while vlan-filtering=yes.

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.

The second row shows why both controls matter: frame types decide whether a port takes tagged frames at all, ingress filtering decides which VLAN IDs it may introduce.

The bridge interface carries the same two properties, and they guard the CPU port. Per the Bridge VLAN Table guide, frame-types=admit-only-vlan-tagged on the bridge drops untagged frames to the router and stops RouterOS adding the bridge as a dynamic untagged member of its PVID VLAN. With management on tagged VLAN 99, that closes the VLAN 1 path described above.

Because the port default dates from RouterOS v7, read the actual ingress-filtering values on any device first configured under v6, particularly after a v6 to v7 upgrade.

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.

VLAN ID lists and ranges in one entry

vlan-ids accepts ranges and comma-separated values; MikroTik’s bridging documentation gives vlan-ids=100-115,120,122,128-130 as an example and reserves multi-VLAN entries for tagged ports. A trunk-only row such as add bridge=bridge1 tagged=ether2,ether6 vlan-ids=100-115, with ether6 as a second trunk, fits that rule.

Avoid grouping several VLAN IDs in one row that also lists access ports: it can permit unintended untagged egress. The Bridge VLAN Table page shows two access ports sharing a VLAN 20 and 30 row, each passing both VLANs. RouterOS warns “port with pvid added to untagged group which might cause problems, consider adding a separate VLAN entry”, as the Layer2 misconfiguration page records.

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, hence the order in the steps above. 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. If no path survives, the Netinstall recovery guide covers the full reflash.

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:

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.

VLAN filtering vs bridge filter rules

vlan-filtering and /interface bridge filter are different tools. VLAN filtering is switch logic (membership, tagging, PVID) that runs in hardware on the chips above. The bridge firewall is a Layer 2 rule set whose filter chains are input (frames for the bridge), forward (frames being bridged, not routed) and output (frames the bridge sends), per the RouterOS bridging manual. Its rules can match vlan-id, vlan-priority and vlan-encap.

The cost is offload. MikroTik’s Layer2 misconfiguration page states that bridge filter rules need all packets forwarded to the CPU, which requires hardware offloading to be disabled; frames the switch chip forwards itself never reach the rules. use-ip-firewall=yes also turns off bridge Fast Path. Segment with VLAN membership, and put policy between VLANs in the routed IP firewall covered in RouterOS firewall rules explained.

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: MikroTik’s Layer2 misconfiguration page says a VLAN interface on a bridge slave port “will never capture any traffic at all”.

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.

Related on this site

• MikroTik CAPsMAN Setup Guide for RouterOS 7: Controller, CAPs, and VLANs
• RouterOS DHCP Server Setup: Pool, Server, Network, and One Server per VLAN

FAQ

is ingress filtering enabled by default on mikrotik?

Yes. Since RouterOS v7, ingress-filtering defaults to yes on bridge ports, and MikroTik’s manual lists the same default for the bridge interface. It does nothing until vlan-filtering=yes is set on the bridge. On a device first configured under v6, print the port details to confirm the value instead of assuming it.

what is the default pvid on a mikrotik bridge port?

The default PVID is 1, on every bridge port and on the bridge interface itself, and a port accepts values from 1 to 4094. It only takes effect once vlan-filtering=yes. Set it on each access port to the client’s VLAN; leaving it at 1 quietly puts that client in VLAN 1.

why did i lose access after enabling vlan filtering on mikrotik?

Usually because the router’s address sat on a VLAN the bridge was not a tagged member of, or on a VLAN interface built on a port instead of the bridge. Filtering then drops frames destined to the CPU. Wait out Safe Mode’s rollback, or reconnect over the serial console or MAC WinBox and add the bridge to that VLAN.

can you use vlans on mikrotik without vlan filtering?

Yes, for limited jobs. A VLAN interface on the bridge can tag the router’s own traffic with vlan-filtering=no, but the bridge then ignores PVID, frame types and ingress filtering, so ports are not separated by VLAN. Boards whose switch chip cannot combine VLAN filtering with offload can use MikroTik’s Basic VLAN switching method instead.