Bridge VLAN Filtering

Bridge VLAN Filtering

Summary

Bridge VLAN filtering is the RouterOS mechanism for building VLAN-aware Layer 2 switches using the software bridge. When enabled on a bridge, it enforces VLAN membership rules per port — defining which VLANs each port may carry and whether frames are transmitted tagged or untagged. This allows a single RouterBOARD or CRS switch to function as a managed VLAN switch with full trunk/access port semantics.

RouterOS 7 bridge VLAN filtering supersedes the older switch-chip VLAN configuration paths for most use cases and is compatible with hardware offloading on supported platforms.

Note

Before enabling vlan-filtering=yes on a bridge, complete all VLAN table and port configuration first. Enabling filtering before the VLAN table is ready will drop traffic to unregistered VLANs — including your management connection.

Legacy vs Modern Bridge VLAN Approach

RouterOS has two distinct methods for building VLAN-segmented networks. Understanding the difference helps avoid a common class of misconfiguration.

Legacy Approach (avoid)

The legacy pattern creates /interface vlan sub-interfaces directly on physical ports, then bridges those VLAN interfaces together:

# Legacy pattern — do not use for new deployments
/interface vlan
add name=vlan10-ether1 interface=ether1 vlan-id=10
add name=vlan10-ether2 interface=ether2 vlan-id=10

/interface bridge
add name=br-vlan10

/interface bridge port
add bridge=br-vlan10 interface=vlan10-ether1
add bridge=br-vlan10 interface=vlan10-ether2

Problems with this approach:

• Requires a separate bridge per VLAN, or mixing VLAN sub-interfaces with physical ports in the same bridge — both patterns are documented by MikroTik as misconfiguration.
• Mixing VLAN interfaces and physical interfaces in one bridge violates IEEE 802.1Q/802.1W semantics and breaks RSTP interoperability with external switches.
• No centralized per-port ingress policy. Frame tagging behavior depends on where interfaces are created rather than a unified policy table.
• Does not benefit from hardware switch-chip offloading.

Modern Approach (vlan-filtering)

The modern approach uses a single bridge with vlan-filtering=yes. All VLAN policy is defined in the /interface bridge vlan table with explicit per-port tagged/untagged membership. VLAN sub-interfaces are only created on the bridge itself (not on physical ports) when L3 participation is required.

This is the approach documented throughout this guide. It is compatible with hardware offloading on CRS and CCR2116/CCR2216 platforms, standards-compliant, and supports all RouterOS 7 bridge features.

Caution

Even with vlan-filtering=yes, a misconfigured bridge VLAN table can leak traffic between VLANs. Verify that each VLAN entry has the correct tagged and untagged port membership, and that ingress-filtering=yes is set on all ports.

How Bridge VLAN Filtering Works

A VLAN-aware bridge maintains a Bridge VLAN Table (/interface bridge vlan) that defines:

• Which VLAN IDs exist on the bridge
• Which ports carry each VLAN as tagged (trunk behavior)
• Which ports carry each VLAN as untagged (access behavior)

When a frame arrives on a bridge port:

1. If the frame is untagged, it is assigned to the VLAN defined by the port’s PVID (Port VLAN ID).
2. The bridge checks the VLAN table to verify the port is a member of that VLAN.
3. If ingress-filtering=yes is set on the port, frames for VLANs not in the VLAN table are dropped.
4. On egress, frames destined for ports in the tagged list leave with the VLAN tag; frames destined for ports in the untagged list have the tag stripped.

The bridge interface itself acts as the CPU port — adding the bridge to a VLAN’s tagged list allows the router to participate in that VLAN (required for routing, DHCP, and management).

The Bridge VLAN Table

The /interface bridge vlan table is the central VLAN policy store. Each entry maps a VLAN ID to its port membership.

/interface bridge vlan print detail

Key parameters:

Parameter	Description
bridge	The bridge this entry applies to
vlan-ids	VLAN ID (1–4094); supports ranges like 10,20,30 or 100-200
tagged	Ports that transmit frames with the VLAN tag (trunk ports, CPU port)
untagged	Ports that transmit frames without the VLAN tag (access ports)

A port may not appear in both tagged and untagged for the same VLAN.

Port Configuration

PVID — Port VLAN ID

PVID controls how untagged ingress frames are classified:

/interface bridge port set [find interface=ether2] pvid=10

An untagged frame arriving on ether2 is assigned to VLAN 10. The PVID must match an entry in the bridge VLAN table where that port is listed as untagged, otherwise the frame will be dropped when ingress-filtering=yes.

frame-types

The frame-types parameter controls which frame types are accepted on ingress:

Value	Behavior
admit-all	Accept tagged and untagged frames (default)
admit-only-vlan-tagged	Drop untagged frames — use for trunk ports
admit-only-untagged-and-priority-tagged	Drop tagged frames — use for access ports

ingress-filtering

When ingress-filtering=yes, the bridge drops ingress frames for VLANs where the port is not a member. This prevents VLAN spoofing and should be enabled on both trunk and access ports.

/interface bridge port set [find interface=ether2] ingress-filtering=yes

Access Ports

An access port connects end devices. It receives untagged frames, assigns them to a single VLAN via PVID, and sends frames untagged.

# Configure ether2 as an access port for VLAN 10
/interface bridge port set [find interface=ether2] \
    pvid=10 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes

# Register VLAN 10 — ether2 is untagged member
/interface bridge vlan add bridge=br1 vlan-ids=10 tagged=br1,ether1 untagged=ether2

Trunk Ports

A trunk port carries multiple VLANs simultaneously, all tagged. Typical use: uplink to a router, another switch, or a wireless AP with VLAN-tagged SSIDs.

# Configure ether1 as a trunk port
/interface bridge port set [find interface=ether1] \
    frame-types=admit-only-vlan-tagged \
    ingress-filtering=yes

# ether1 is tagged member of all VLANs it carries
/interface bridge vlan add bridge=br1 vlan-ids=10 tagged=br1,ether1 untagged=ether2
/interface bridge vlan add bridge=br1 vlan-ids=20 tagged=br1,ether1 untagged=ether3

Native VLAN on a Trunk

To carry one VLAN untagged on a trunk (native VLAN), set the trunk port’s PVID to that VLAN ID and add it to untagged in the VLAN table:

/interface bridge port set [find interface=ether1] pvid=99
/interface bridge vlan add bridge=br1 vlan-ids=99 tagged=br1 untagged=ether1

VLAN Filtering vs VLAN Interfaces

Bridge VLAN filtering and /interface vlan solve different problems and are used together, not in place of each other.

Mechanism	Layer	Purpose
Bridge VLAN filtering	L2	Enforces VLAN membership across bridge ports; controls tagged/untagged egress
/interface vlan	L3	Creates a logical interface for router participation in a VLAN (IP, DHCP, firewall)

Use bridge VLAN filtering to define which ports carry which VLANs and how (tagged/untagged). This is the switching policy.

Use /interface vlan on the bridge when the router itself needs an IP address, DHCP server, or firewall rules in a given VLAN. Create one VLAN interface per VLAN that requires L3 termination:

/interface vlan add name=vlan10 interface=br1 vlan-id=10
/ip address add address=192.168.10.1/24 interface=vlan10

Important: For a VLAN interface to receive traffic, the bridge interface (br1) must be listed in tagged for that VLAN in the bridge VLAN table. Without this, the CPU cannot participate in the VLAN even if the interface exists.

Do not attempt to model trunk/access port policy using only VLAN sub-interfaces — this does not enforce L2 VLAN membership on bridge ports.

Hardware Offloading

On supported switch-chip hardware, bridge forwarding can be offloaded to the switch ASIC, achieving wire-speed performance without CPU involvement.

Supported Hardware

Hardware offloading of bridge VLAN filtering is supported on:

• CRS3xx series (Marvell 98DX3xxx/98DX2xxx switch chips) — full support
• CRS5xx series — full support
• CCR2116, CCR2216 — full support

On platforms without switch-chip support (hAP, RB4xx, standard RouterBOARD), VLAN filtering is performed in software. This is functionally correct but CPU-bound; throughput will be limited accordingly.

Caution

On non-switch-chip hardware, enabling bridge VLAN filtering with many ports under load may significantly increase CPU usage. Monitor CPU utilization after enabling filtering on such platforms.

Enabling Hardware Offloading

Set hw=yes on each bridge port to enable hardware switching:

/interface bridge add name=bridge1 vlan-filtering=yes

/interface bridge port
add bridge=bridge1 interface=ether2 hw=yes pvid=10
add bridge=bridge1 interface=ether3 hw=yes pvid=20
add bridge=bridge1 interface=sfp-sfpplus1 hw=yes frame-types=admit-only-vlan-tagged

Caveats

• Only one bridge per device can be hardware-offloaded on most platforms. A second bridge will fall back to software forwarding.
• Ports from different switch chips on the same device (e.g., CPU-connected ports mixed with switch ports) may not offload as expected. Keep data-plane VLAN switching within the hardware-switch domain.
• Hardware offloading behavior for Layer 3 (inter-VLAN routing) requires additional L3 Hardware Offloading configuration — see CRS3xx, CRS5xx, CCR2116, CCR2216 Switch Chip Features.

Verifying Hardware Offload Status

/interface bridge port print
# Ports with active hardware offload show the H flag in the Flags header

/interface bridge port print detail
# Look for hw=yes on individual ports, or the H flag in the Flags header
# Example output: Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload

Complete Multi-VLAN Setup Example

This example configures a router as a VLAN-aware switch with three VLANs, a trunk uplink, multiple access ports per VLAN, and a DHCP server for each VLAN.

Topology:

• ether1 — trunk uplink (carries VLANs 10, 20, 30 tagged)
• ether2, ether3 — VLAN 10 access (e.g., servers)
• ether4, ether5 — VLAN 20 access (e.g., workstations)
• ether6 — VLAN 30 access (e.g., IoT devices)

# Step 1: Create bridge with VLAN filtering disabled
# (prevents management lockout during configuration)
/interface bridge
add name=br1 vlan-filtering=no

# Step 2: Add ports to the bridge
# Trunk uplink — tagged only
/interface bridge port
add bridge=br1 interface=ether1 \
    frame-types=admit-only-vlan-tagged \
    ingress-filtering=yes

# VLAN 10 access ports
add bridge=br1 interface=ether2 pvid=10 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes
add bridge=br1 interface=ether3 pvid=10 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes

# VLAN 20 access ports
add bridge=br1 interface=ether4 pvid=20 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes
add bridge=br1 interface=ether5 pvid=20 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes

# VLAN 30 access port
add bridge=br1 interface=ether6 pvid=30 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes

# Step 3: Define VLAN membership
# br1 (bridge/CPU) is tagged in all VLANs for routing and DHCP
/interface bridge vlan
add bridge=br1 vlan-ids=10 tagged=br1,ether1 untagged=ether2,ether3
add bridge=br1 vlan-ids=20 tagged=br1,ether1 untagged=ether4,ether5
add bridge=br1 vlan-ids=30 tagged=br1,ether1 untagged=ether6

# Step 4: Create VLAN interfaces for L3 (routing, DHCP, firewall)
/interface vlan
add name=vlan10 interface=br1 vlan-id=10
add name=vlan20 interface=br1 vlan-id=20
add name=vlan30 interface=br1 vlan-id=30

# Step 5: Assign gateway IP addresses
/ip address
add address=192.168.10.1/24 interface=vlan10
add address=192.168.20.1/24 interface=vlan20
add address=192.168.30.1/24 interface=vlan30

# Step 6: Create DHCP address pools
/ip pool
add name=pool-vlan10 ranges=192.168.10.100-192.168.10.200
add name=pool-vlan20 ranges=192.168.20.100-192.168.20.200
add name=pool-vlan30 ranges=192.168.30.100-192.168.30.200

# Step 7: Configure DHCP server networks
/ip dhcp-server network
add address=192.168.10.0/24 gateway=192.168.10.1 dns-server=192.168.10.1
add address=192.168.20.0/24 gateway=192.168.20.1 dns-server=192.168.20.1
add address=192.168.30.0/24 gateway=192.168.30.1 dns-server=192.168.30.1

# Step 8: Start DHCP servers
/ip dhcp-server
add name=dhcp-vlan10 interface=vlan10 address-pool=pool-vlan10 disabled=no
add name=dhcp-vlan20 interface=vlan20 address-pool=pool-vlan20 disabled=no
add name=dhcp-vlan30 interface=vlan30 address-pool=pool-vlan30 disabled=no

# Step 9: Enable VLAN filtering (activates enforcement)
/interface bridge set br1 vlan-filtering=yes

Verification

After completing configuration, verify the setup:

# Check bridge VLAN table
/interface bridge vlan print detail

# Check bridge port settings and status (H flag = hardware offloaded)
/interface bridge port print detail

# Verify VLAN interfaces exist and have correct IP addresses
/interface vlan print
/ip address print

# Check DHCP server status
/ip dhcp-server print
/ip dhcp-server lease print

# Check bridge host (MAC) table — confirms L2 learning is working
/interface bridge host print

Common Issues

Management access lost after enabling vlan-filtering Ensure the bridge interface (br1) is in the tagged list for the management VLAN, and that your management port’s PVID matches. Always configure the full VLAN table before enabling vlan-filtering=yes.

Traffic not passing between access ports Verify that both ports share the same VLAN ID in the bridge VLAN table. A PVID mismatch (e.g., PVID=10 on one port but the VLAN table only has vlan-ids=20) will silently drop frames.

VLAN interface not receiving traffic The bridge interface must be listed in tagged for that VLAN. Without this, the CPU port has no VLAN membership and the VLAN interface will not see frames.

High CPU usage on non-switch hardware Software bridge VLAN filtering is CPU-bound. On non-CRS platforms under high traffic, consider hardware-accelerated alternatives or reduce the number of bridged VLANs.

See Also

• Inter-VLAN Routing — SVI-style gateway configuration, per-VLAN DHCP, firewall policy, and L3 hardware offloading on CRS switches
• VLAN Trunk and Access Configuration — worked examples for common trunk/access port topologies
• CRS3xx, CRS5xx, CCR2116, CCR2216 Switch Chip Features — full hardware offload capabilities and limitations
• Spanning Tree Protocol — loop prevention for multi-switch bridge deployments