MikroTik RouterOS Bridge VLAN Filtering Configuration

MikroTik RouterOS 7 handles VLANs through the bridge: every physical port joins one bridge, and the bridge VLAN table decides which VLANs each port may carry and whether frames egress tagged or untagged. The single setting that turns VLAN-awareness on is vlan-filtering=yes — everything else is port PVIDs plus table entries. This guide explains the model and walks through a typical trunk/access setup on a CRS or CCR router.

Prerequisites and Scope

The examples below assume RouterOS 7.1 or newer on a device whose switch chip supports VLAN filtering — CRS1xx/2xx/3xx series switches, most CCR routers, and the hAP/ac models that include an internal switch chip. Two hardware facts decide whether the configuration behaves as expected: whether the physical ports are attached to a hardware-offloaded switch group, and whether the bridge can keep offload enabled after filtering is turned on. On a platform without a switch chip, filtering still works exactly as described, but every frame is forwarded by the CPU and throughput falls off a cliff as soon as the traffic is not trivial.

Before you touch anything, collect three things:

• Access through the serial console, MAC-telnet/MAC-winbox on the layer 2 address, or a management port that stays in an untagged VLAN for the whole change window.
• A written plan that lists, for every port, its role (access, trunk or hybrid), its PVID, and the VLAN IDs it must carry in each direction.
• A rollback export taken before the change: /export show-sensitive file=before-vlan.

The rollback export is not a formality. Enabling vlan-filtering with an incomplete table is the single most common way engineers lock themselves out of a RouterOS device, because the management VLAN is the first thing that stops passing traffic.

How Bridge VLAN Filtering Works

• Tagged port: egress frames keep their VLAN tag (your trunk port).
• Untagged port: egress frames have the tag stripped (your access port); ingress untagged frames are assigned to the port's PVID.
• Bridge VLAN table: lists which VLAN IDs are allowed on which ports. A frame whose VLAN is not in the table for the egress port is dropped — a misconfigured table either leaks VLANs to the wrong access port or black-holes traffic.

Every bridge port also has one PVID (port VLAN ID). A frame arriving untagged on that port is assigned the PVID and from then on is treated as a member of that VLAN; a frame arriving already tagged keeps its tag. On egress the bridge consults the VLAN table and applies three outcomes: listed as tagged means the frame leaves with the tag intact, listed as untagged means the tag is removed, and not listed at all means the frame is dropped. That third outcome is what makes VLAN filtering a security control rather than just a tagging convention — an unlisted VLAN cannot leak anywhere, no matter what the sender does.

Frame Flow: Following One Frame Through the Bridge

Walking a single frame through the bridge makes the design concrete. A PC in VLAN 20 sends an untagged Ethernet frame to ether2.

1. Ingress. ether2 has pvid=20, so the bridge internally marks the frame as VLAN 20.
2. Learning. The source MAC address is recorded in the bridge host table together with VLAN 20 and the ingress port.
3. Lookup. The destination MAC is searched in the host table. A hit on another port in VLAN 20 is forwarded; a hit on a port that is not a member of VLAN 20 is treated as unknown and flooded instead of leaked.
4. Egress decision. For each candidate port the bridge checks the VLAN 20 table entry: tagged ports keep the tag, untagged ports strip it, and unlisted ports drop the frame.
5. CPU path. If the destination is the router itself (an IP address configured on a VLAN interface), the bridge interface has to be a tagged member of that VLAN so the frame is delivered up to the CPU.

Two corollaries follow from that sequence. First, an access port with a PVID must also appear as an untagged member of its VLAN in the table, otherwise egress frames are dropped even though ingress worked. Second, traffic to the router only works when the bridge interface itself is a member of the VLAN — which is why every routed or management VLAN lists bridge1 in the tagged column.

Hardware Offload and the CPU Path

On CRS switch platforms the bridge ports are backed by a switch chip with its own forwarding tables. Whether offload stays active after vlan-filtering=yes depends on the chip generation and on whether the bridge is configured in a way the offload path supports. Check it with:

/interface bridge port print detail
# look at the H (hardware) flag and the "hw" column
/interface ethernet switch print

If the H flag disappears from a port after you enable filtering, packets are being processed by the CPU. Symptoms are a hard throughput ceiling, high CPU at modest traffic levels, and a jump in latency under load. On some CRS1xx/2xx models offload requires the VLANs to be configured on the switch chip rather than in the bridge /interface vlan style; on CRS3xx and newer the bridge itself performs hardware VLAN filtering, but only when all ports of the bridge are on the same switch chip and the bridge has no unusual features enabled.

Features that silently disable hardware offload include spanning tree protocol modes other than the chip's supported set, bonding on top of hardware-offloaded ports, IGMP snooping in some versions, and mixing ports from two switch chips in one bridge. If performance matters, verify the H flag rather than assuming it survived the change. Before the change you can also confirm the baseline with a bandwidth test between two hosts on different ports.

Configuration Example: Two Access VLANs and One Trunk

Goal: ether1 is a trunk carrying VLANs 20 and 30; ether2 is an access port in VLAN 20; ether3 is an access port in VLAN 30.

/interface bridge add name=bridge1 vlan-filtering=no
/interface bridge port add bridge=bridge1 interface=ether1
/interface bridge port add bridge=bridge1 interface=ether2 pvid=20
/interface bridge port add bridge=bridge1 interface=ether3 pvid=30
/interface bridge vlan add bridge=bridge1 tagged=ether1 vlan-ids=20
/interface bridge vlan add bridge=bridge1 tagged=ether1 untagged=ether2 vlan-ids=20
/interface bridge vlan add bridge=bridge1 tagged=ether1 untagged=ether3 vlan-ids=30
/interface bridge set bridge1 vlan-filtering=yes

Note the common trap: with vlan-filtering=no (default) the bridge ignores tags entirely and both VLANs leak everywhere. Enable filtering last, after the table is correct, or you can lock yourself out of the router. The untagged ports with the same PVID are grouped into the same table entry automatically.

Order of Operations: Building the Configuration Safely

The command order above is deliberate, and it is worth making it a habit because the reverse order is what causes lockouts:

1. Create the bridge with vlan-filtering=no and add every physical port as a bridge port, setting the PVID on the access ports as you go.
2. Create one VLAN table entry per VLAN ID, listing the trunk ports as tagged and the access ports as untagged.
3. Add the management VLAN to the table with bridge1 and the uplink port tagged, and give the VLAN interface an address.
4. Only now set vlan-filtering=yes.
5. Immediately verify management reachability from a second session before closing the console window.

Step 5 is the one people skip. Keep a second terminal open to the management IP while you work: if the first session dies and the second one still answers, the change is good; if both die, you still have the console or MAC-telnet to roll back.

A Trunk with a Native VLAN (Hybrid Port)

Some switches send one VLAN untagged onto a trunk — a "native" or "PVID" VLAN in Cisco terms. RouterOS models this by giving the trunk port a PVID and listing it as untagged as well as tagged for the other VLANs:

/interface bridge port set [find interface=ether1] pvid=20
/interface bridge vlan set [find vlan-ids=20] tagged=ether1 untagged=ether2,ether1
/interface bridge vlan set [find vlan-ids=30] tagged=ether1

The result: tagged frames from both VLANs are accepted on ether1, untagged frames are treated as VLAN 20, and VLAN 20 egresses untagged towards the upstream switch. Use this only when the other end really is configured the same way. A hybrid port facing a device that expects a pure 802.1Q trunk produces intermittent, hard-to-diagnose behaviour, because everything works until an untagged frame (ARP, DHCP, a looped broadcast) crosses the link.

Management Access Over a Specific VLAN

Many deployments restrict router management to one VLAN. Put the bridge itself in the table as a tagged port and give the VLAN interface the management address:

/interface vlan add name=vlan99 interface=bridge1 vlan-id=99
/ip address add address=10.0.99.1/24 interface=vlan99
/interface bridge vlan add bridge=bridge1 tagged=bridge1,ether1 vlan-ids=99

With the bridge listed as tagged, only frames tagged 99 reach the CPU path of the router — a cheap and effective management-plane filter for devices that support hardware offloaded filtering. Nothing else on the box is reachable from another VLAN unless you also build a routed path and permit it in the firewall, so combine the VLAN separation with an address list that restricts which subnets may open Winbox, SSH or the API.

Routing Between VLANs: Interfaces and Firewall Placement

VLANs isolate at layer 2, so any traffic that must cross a VLAN boundary has to be routed. On RouterOS you create one /interface vlan per VLAN on the bridge and give each one an address; the bridge stays a layer 2 construct and the router forwards between the VLAN interfaces. Place the filter rules on the interfaces, not on the bridge: input rules protect the router itself (management, SNMP, Winbox), forward rules govern inter-VLAN traffic. A minimal pattern looks like this:

/ip firewall filter add chain=forward action=drop connection-state=invalid
/ip firewall filter add chain=forward action=accept connection-state=established,related
/ip firewall filter add chain=forward action=accept in-interface=vlan20 out-interface=vlan30 protocol=tcp dst-port=445
/ip firewall filter add chain=forward action=drop in-interface=vlan20 out-interface=vlan30
/ip firewall filter add chain=input action=accept in-interface=vlan99 protocol=tcp dst-port=22,8291
/ip firewall filter add chain=input action=drop in-interface=!vlan99

Note the asymmetric-routing trap: if a device has a default gateway pointing into VLAN 20 but replies travel back through VLAN 30, stateful filtering drops the return packets and the connection appears to hang. Keep each host's gateway inside its own VLAN and let the router be the only path between them.

Verification and Inter-VLAN Routing

/interface bridge vlan print
/interface bridge port print
/interface bridge print
/ip address print

The VLAN table printout shows CURRENT-TAGGED and CURRENT-UNTAGGED columns so you can spot accidental leakage: an access port appearing under the wrong VLAN ID means its PVID or the table entry is wrong. To route between VLANs, create a VLAN interface on the bridge for each VLAN and address them — the bridge itself stays Layer 2 and RouterOS routes between the VLAN interfaces.

Reading the VLAN Table: Dynamic vs Static Entries

The table you type is not the whole picture. RouterOS merges your static entries with dynamically added ports, which is why an access port may show up under a VLAN ID you never listed it in. Dynamic membership comes from three sources:

• PVID membership. A bridge port with pvid=20 is automatically an untagged member of VLAN 20, and the row for VLAN 20 shows it in CURRENT-UNTAGGED even if you only configured tagged=ether1.
• The bridge interface itself. The bridge becomes a tagged member of every VLAN that has a matching /interface vlan on it.
• Port additions and removals. Moving an interface to another bridge or changing its PVID rewrites membership on the fly, so a table that looked correct yesterday can be wrong after a port swap.

A useful audit is a diff between intended and actual state: /interface bridge vlan print detail shows both the configured tagged/untagged lists and the resulting CURRENT- columns, so a misplaced port is visible at a glance. If the same VLAN ID appears twice with overlapping ports, the second entry is not what you think it is — merge them instead of trying to debug the odd behaviour.

Avoiding and Recovering from a Lockout

If management stops answering right after vlan-filtering=yes, do not reboot first. Work through the options in this order:

1. Try MAC-telnet/MAC-winbox from a device in the same broadcast domain on the port you know is in the right VLAN. The layer 2 address does not depend on the management IP.
2. Try a port you know is untagged in the management VLAN. A laptop plugged into an access port of the management VLAN usually gets in even when the uplink is misconfigured.
3. Use Safe Mode. Enter /system safe-mode from a working session before making risky changes; a lost session automatically reverts the pending change on disconnect.
4. Fall back to the serial console, which is unaffected by VLAN filtering, and remove the offending table row.
5. Last resort: reset and re-import. Hold the reset button while powering on (or run /system reset-configuration), then restore the export you took before the change and re-apply the VLANs step by step.

Two habits make recovery far less painful: keep a serial cable within reach on the first rollout, and never enable filtering over a session you cannot afford to lose.

Common Misconfigurations and Their Symptoms

Migration from RouterOS 6 master-port

RouterOS 6 configured switching with master-port on an /interface ethernet entry, and VLANs lived in /interface ethernet switch vlan for chips that supported it. RouterOS 7 removed both; the bridge is now the only supported model, and any leftover switch-chip configuration from a 6.x import must be cleaned up. When you upgrade, the switch chip tables can still exist alongside the bridge and produce confusing results: the bridge filters in software while the chip forwards by its own rules, or the chip duplicates frames. Audit with /interface ethernet switch print, remove stale switch VLAN entries, then build the equivalent configuration in /interface bridge vlan. Export the old configuration before the upgrade — after the migration the 6.x commands are simply gone, and the only path back is an import of a v6 export on a v6 image.

VLANs and Spanning Tree

Bridge VLAN filtering interacts with the spanning tree protocol running on the bridge. In RouterOS 7 the bridge has a single protocol-mode (rstp by default, stp or mstp where supported) and one spanning-tree instance per bridge unless you configure MSTP instance mappings. With filtering enabled, STP BPDUs are sent untagged on the port's PVID, not on every VLAN, so an upstream device that expects per-VLAN BPDUs should be configured accordingly. Two operational rules help: make one port explicitly designated where possible to avoid topology flaps during a VLAN change, and remember that a loop between two access ports on the same VLAN is handled by STP, but a loop between two different VLANs is not — that becomes a broadcast storm whose symptoms appear in the VLAN that has the loop.

Performance and MTU Notes

Each bridge configuration adds a small per-packet cost, and each VLAN interface on the CPU path adds another. Three practical consequences:

• VLAN interfaces used for routing are software constructs; traffic routed between two VLANs on the same switch chip is forwarded by the CPU, not the chip. Prefer inter-VLAN routing on a dedicated router or a switch with L3 offload for high-volume flows.
• L2MTU is negotiated on the physical ports, and VLAN tags consume bytes on the wire. If you run jumbo frames, set the L2MTU on the physical port generously enough to carry the tagged payload and keep the same value on every device in the path.
• The bridge host table is limited; on very large layer 2 segments, pruning the table or splitting the broadcast domain keeps lookups fast and predictable.

Best Practices Summary

1. Design the port/PVID/VLAN table on paper first, then type it in the order described above.
2. Leave vlan-filtering=no until the table is complete, then enable it and verify management from a second session.
3. Always list the bridge interface as tagged in every VLAN that has a VLAN interface, or the router will not answer.
4. Keep one management VLAN and filter the input chain by interface, not only by address.
5. Verify hardware offload after the change if the device has a switch chip.
6. Keep a rollback export and a serial cable for the first rollout on unfamiliar hardware.

VLAN design concepts transfer across vendors; compare the access/trunk model in our ArubaOS-CX access vs trunk comparison and the Linux-side tagging in Linux 802.1Q sub-interfaces. When the trunk runs over fiber, the module you choose has its own compatibility rules — see the SFP/SFP+/SFP28/QSFP28 transceiver comparison.

原文链接：https://help.mikrotik.com/docs/spaces/ROS/pages/28606465/Bridge+VLAN+Table