Bridge Configuration

Bridge Configuration

Summary

A RouterOS bridge is a virtual Layer 2 switch. Physical interfaces added as bridge ports share the same broadcast domain and forward frames by learned MAC addresses. The bridge also acts as the CPU-facing (management) interface for that switched segment.

Key capabilities:

Feature	RouterOS setting
Loop prevention	protocol-mode (STP / RSTP / MSTP)
VLAN-aware switching	vlan-filtering=yes + /interface bridge vlan
Switch-chip acceleration	hw=yes on bridge ports
Layer 3 inter-VLAN routing	VLAN interfaces on the bridge

Note

Always add bridge ports and configure the VLAN table before enabling vlan-filtering=yes. Enabling filtering on a live bridge drops traffic to VLANs not yet in the table — including your management session.

---

Creating a Bridge

/interface bridge add \
    name=br1 \
    protocol-mode=rstp \
    vlan-filtering=no \
    comment="Main bridge"

Key bridge-level properties:

Property	Default	Description
name	—	Interface name
protocol-mode	rstp	STP variant: none, stp, rstp, mstp
vlan-filtering	no	Enable VLAN-aware forwarding and table enforcement
priority	0x8000	Bridge priority for root election (lower = preferred root)
arp	enabled	ARP handling on the bridge interface
mtu	1500	Bridge MTU
igmp-snooping	no	Constrain multicast floods using IGMP/MLD listener data
auto-mac	yes	Use lowest-MAC port as bridge MAC (disable to set fixed MAC)
max-message-age	20s	STP max-age timer
forward-delay	15s	STP forward-delay timer
hello-time	2s	STP hello interval

---

Adding Bridge Ports

/interface bridge port add \
    bridge=br1 \
    interface=ether2

Each physical (or logical) interface added here becomes a member of the bridge domain.

Key port-level properties:

Property	Default	Description
bridge	—	Parent bridge
interface	—	Member interface
pvid	1	Port VLAN ID — classifies untagged ingress frames into this VLAN
frame-types	admit-all	admit-all, admit-only-vlan-tagged, admit-only-untagged-and-priority-tagged
ingress-filtering	no	Drop ingress frames whose VLAN is not in the bridge VLAN table for this port
edge	auto	yes/no/auto — edge-port status for RSTP fast transition
point-to-point	auto	yes/no/auto — P2P link for RSTP fast transition
bpdu-guard	no	Disable port if BPDU received (protects access ports)
path-cost	auto	STP path cost (lower = preferred)
priority	0x80	STP port priority
hw	no	Request switch-chip hardware offloading for this port
horizon	none	Split-horizon group (for mesh/stub port isolation)

Verify bridge membership

/interface bridge port print

---

Spanning Tree Protocol (STP / RSTP / MSTP)

STP prevents Layer 2 loops by blocking redundant paths. RouterOS supports three variants selectable via protocol-mode on the bridge.

Choosing a Protocol Mode

Mode	Standard	Use case
none	—	No loop protection; only safe on loop-free topologies
stp	802.1D	Legacy interop; slow convergence (30–50 s)
rstp	802.1w	Fast convergence (< 1 s on point-to-point links); recommended default
mstp	802.1s	Multiple spanning tree instances per VLAN group; enterprise multi-VLAN environments

Root Bridge Election

The bridge with the lowest bridge ID (priority + MAC) becomes the root. Set a lower priority on the intended root:

# Make br1 the root bridge
/interface bridge set br1 priority=0x1000

# Make br1 the backup root
/interface bridge set br1 priority=0x2000

Priority must be a multiple of 4096 (0x1000). The default 0x8000 (32768) leaves room for both lower and higher values.

Port Path Cost and Priority

Ports with lower accumulated path cost to root are preferred. Tune per-port:

/interface bridge port set [find interface=ether3] path-cost=10
/interface bridge port set [find interface=ether4] path-cost=100

When path cost is equal, port priority breaks the tie (lower = preferred):

/interface bridge port set [find interface=ether3] priority=0x40

Edge Ports and BPDU Guard

Access (host-facing) ports should be edge ports for immediate RSTP forwarding without the listening/learning delay:

/interface bridge port set [find interface=ether2] \
    edge=yes \
    point-to-point=yes \
    bpdu-guard=yes

bpdu-guard=yes disables the port if it receives a BPDU, protecting against accidental switch connections on access ports. Check and recover:

# See disabled ports
/interface bridge port print where disabled=yes

# Re-enable after root cause resolved
/interface bridge port enable [find interface=ether2]

MSTP — Multiple Spanning Tree

MSTP maps VLANs to independent spanning-tree instances (MSTIs), allowing different VLANs to use different topologies for load balancing. All switches in an MSTP region must share the same region name, revision, and VLAN-to-instance map.

MSTP requires vlan-filtering=yes on the bridge. Attempting to set protocol-mode=mstp without it fails with failure: mstp requires vlan-filtering. Enable VLAN filtering before switching to MSTP mode.

# Enable VLAN filtering first — required for MSTP
/interface bridge set br1 vlan-filtering=yes

# Set MSTP mode and region parameters
/interface bridge set br1 \
    protocol-mode=mstp \
    region-name=CORP \
    region-revision=10

# Map VLANs to instances
/interface bridge msti
add bridge=br1 identifier=1 vlan-mapping=10-19
add bridge=br1 identifier=2 vlan-mapping=20-29

# Set per-instance priority (optional)
/interface bridge msti set [find bridge=br1 && identifier=1] priority=0x1000

A region mismatch (different name, revision, or VLAN map) causes boundary port behavior: switches treat each other as external to the region and fall back to CIST-only interaction, negating per-VLAN topology control.

Monitoring STP State

# Overall bridge state (root bridge, root path cost, topology changes)
/interface bridge monitor br1 once

# Per-port state and roles
/interface bridge port print detail
/interface bridge port monitor [find bridge=br1] once

# Live STP log
/log print follow where topics~"stp"

Key port states: discarding → learning → forwarding Key port roles: root, designated, alternate, backup

---

Bridge VLAN Filtering

Bridge VLAN filtering enables VLAN-aware switching entirely within the bridge — no sub-interfaces required. Frames are assigned to VLANs via the PVID on ingress and selectively tagged/untagged on egress per the bridge VLAN table.

Concepts

• PVID — untagged ingress frames are placed in this VLAN
• Tagged port — egresses frames with the VLAN tag intact (trunk)
• Untagged port — egresses frames with the VLAN tag stripped (access)
• ingress-filtering — drop ingress frames whose VLAN has no entry for this port
• frame-types — control which frame types are accepted on ingress

Safe Enable Order

1. Add all ports to the bridge
2. Build the VLAN table (/interface bridge vlan)
3. Configure PVID and frame-types on each port
4. Then set vlan-filtering=yes

Configuring the VLAN Table

Do not use ether1 (the management interface) as a bridge port. Adding it to a bridge severs SSH/Winbox connectivity and requires console access to recover. Use ether2 or higher for trunk and access ports in these examples.

# Trunk port: ether5 carries all VLANs tagged; bridge (CPU) is tagged member
/interface bridge port
add bridge=br1 interface=ether5 \
    frame-types=admit-only-vlan-tagged \
    ingress-filtering=yes

# Access ports: untagged on VLAN 10 and VLAN 20 respectively
/interface bridge port
add bridge=br1 interface=ether2 pvid=10 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes
add bridge=br1 interface=ether3 pvid=20 \
    frame-types=admit-only-untagged-and-priority-tagged \
    ingress-filtering=yes

# VLAN table entries
/interface bridge vlan
add bridge=br1 vlan-ids=10 tagged=br1,ether5 untagged=ether2
add bridge=br1 vlan-ids=20 tagged=br1,ether5 untagged=ether3

# Enable VLAN filtering only after table is complete
/interface bridge set br1 vlan-filtering=yes

br1 appears as tagged in each VLAN so the CPU (RouterOS) can reach those VLANs — required for management access and inter-VLAN routing.

Management VLAN

Isolate management access to a dedicated VLAN:

/interface bridge vlan
add bridge=br1 vlan-ids=99 tagged=br1,ether5

/interface vlan
add name=vlan99-mgmt interface=br1 vlan-id=99

/ip address
add address=192.168.99.1/24 interface=vlan99-mgmt

Only trunk ports with vlan-ids=99 carry management traffic; access ports on other VLANs cannot reach it at Layer 2.

Verifying VLAN Table

/interface bridge vlan print
/interface bridge port print detail

Check the H (hardware-offloaded) and D (dynamic/PVID-auto-generated) flags on VLAN table entries.

---

Hardware Offloading

On MikroTik devices with a built-in switch chip (CRS1xx, CRS2xx, CRS3xx, CRS5xx series), frame forwarding can be offloaded to the switch chip rather than handled by the CPU. This dramatically increases throughput and reduces CPU load.

Enabling Hardware Offload

Set hw=yes on each bridge port that should use the switch chip:

/interface bridge port
add bridge=br1 interface=ether5 hw=yes
add bridge=br1 interface=ether2 hw=yes
add bridge=br1 interface=ether3 hw=yes

Verifying Offload

/interface bridge port print

Ports successfully offloaded show the H flag in the FLAGS column. If the flag is absent, the port falls back to CPU (software) forwarding.

Platform Constraints

Platform family	L2 HW offload	L3 HW offload
CRS1xx / CRS2xx	Yes	No
CRS3xx (98DX3xxx)	Yes	Yes (with limitations)
CRS5xx / CCR2116 / CCR2216 (98DX7xxx)	Yes	Partial — some features in development
hEX, RB4xx, RB9xx etc.	No	No

Critical constraints:

• Only one bridge can be hardware-offloaded per device. Additional bridges fall back to software.
• L3 hardware offloading (routing between VLAN interfaces) requires L2 hardware offloading to be active first.
• Certain features force CPU path even on offload-capable hardware: connection tracking, NAT, firewall with per-packet inspection, VXLAN termination on some platforms.
• All ports in the hardware bridge must belong to the same switch chip; mixing ports from different chips disables HW offload.

L3 Hardware Offloading (CRS3xx / CRS5xx)

On supported platforms, inter-VLAN routing through VLAN interfaces on the bridge can also be accelerated by the switch chip:

# Enable L3HW (requires L2 HW offload already active)
/interface bridge set br1 vlan-filtering=yes

# Verify L3HW is active
/interface ethernet switch print detail

Look for l3-hw-offloading: yes in the switch output and check that routed flows are handled in hardware (monitor CPU utilization under load).

---

Inter-VLAN Routing

RouterOS performs inter-VLAN routing by creating VLAN interfaces on the bridge — each acts as a Layer 3 gateway (analogous to an SVI on Cisco IOS) for its VLAN.

Prerequisites

• Bridge VLAN filtering enabled
• Bridge VLAN table configured with the bridge (br1) as a tagged member of each routed VLAN (gives the CPU a presence in each VLAN)

Step 1 — Configure the Bridge and VLAN Table

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

/interface bridge port
add bridge=br1 interface=ether5                                       # trunk
add bridge=br1 interface=ether2 pvid=10 \
    frame-types=admit-only-untagged-and-priority-tagged               # access VLAN 10
add bridge=br1 interface=ether3 pvid=20 \
    frame-types=admit-only-untagged-and-priority-tagged               # access VLAN 20

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

Step 2 — Create VLAN Interfaces and Assign Gateway IPs

/interface vlan
add name=vlan10 interface=br1 vlan-id=10
add name=vlan20 interface=br1 vlan-id=20

/ip address
add address=192.168.10.1/24 interface=vlan10
add address=192.168.20.1/24 interface=vlan20

Hosts in VLAN 10 use 192.168.10.1 as their default gateway; hosts in VLAN 20 use 192.168.20.1.

Step 3 — DHCP per VLAN (Optional)

/ip pool
add name=pool-vlan10 ranges=192.168.10.100-192.168.10.199
add name=pool-vlan20 ranges=192.168.20.100-192.168.20.199

/ip dhcp-server
add name=dhcp-vlan10 interface=vlan10 address-pool=pool-vlan10
add name=dhcp-vlan20 interface=vlan20 address-pool=pool-vlan20

/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

Step 4 — Firewall Inter-VLAN Policy

Inter-VLAN traffic passes through the IP firewall forward chain. Without rules all routed traffic between VLANs is allowed by default (assuming no drop-all default rule).

/ip firewall filter
# Allow established/related sessions
add chain=forward action=accept connection-state=established,related

# Drop invalid
add chain=forward action=drop connection-state=invalid

# Example: allow VLAN 10 to reach VLAN 20 but block the reverse
add chain=forward action=accept \
    in-interface=vlan10 out-interface=vlan20 \
    comment="VLAN10 -> VLAN20 allowed"

add chain=forward action=drop \
    in-interface=vlan20 out-interface=vlan10 \
    comment="VLAN20 -> VLAN10 blocked"

Adjust the policy to match your security requirements. Traffic from a VLAN to the router itself (DNS, DHCP replies) uses the input chain.

Topology Diagram

                     RouterOS CPU
             ┌────────────────────────┐
             │  vlan10       vlan20   │
             │ 192.168.10.1  192.168.20.1 │
             └──────────┬─────────────┘
                        │ br1 (tagged member of VLAN 10 + 20)
             ┌──────────┴─────────────┐
             │         br1 bridge      │
             │  ether5 (trunk)         │
             │  ether2 (access VLAN10) │
             │  ether3 (access VLAN20) │
             └────────────────────────┘

---

Troubleshooting

Bridge not forwarding traffic

# Check bridge is up and ports are not blocked
/interface bridge monitor br1 once
/interface bridge port print detail

# Check VLAN table if vlan-filtering=yes
/interface bridge vlan print

Ensure vlan-filtering=yes bridges have VLAN table entries for the VLANs in use. A missing entry drops all traffic to/from that VLAN.

Loop detected / STP topology changes

# Check for frequent topology changes
/interface bridge monitor br1 once
# Look at: topology-change, topology-change-count

# Identify which port triggers changes
/interface bridge port print detail
# Look at: edge, designated-port, role, status

/log print follow where topics~"stp"

Ports connected to end-hosts should have edge=yes and bpdu-guard=yes to prevent accidental loops.

Hardware offload not active (H flag missing)

Common causes:

• Bridge has more than one bridge configured on the device (only one gets HW)
• Ports belong to different switch chips
• vlan-filtering=yes with a VLAN configuration not supported by the chip (check chip docs)
• Platform does not have a switch chip

/interface bridge port print
/interface ethernet switch print

Inter-VLAN traffic not routing

1. Confirm bridge VLAN table has br1 as tagged member of the VLAN — without this the CPU cannot inject/receive frames for that VLAN.
2. Confirm VLAN interface exists on the correct bridge and has an IP.
3. Check firewall forward chain is not dropping traffic.

/interface bridge vlan print
/interface vlan print
/ip address print
/ip firewall filter print

---

See Also

• Spanning Tree Protocol — in-depth STP/RSTP/MSTP reference
• Bridge VLAN Filtering — detailed VLAN table configuration
• Inter-VLAN Routing — full inter-VLAN routing guide with advanced scenarios
• CRS3xx/CRS5xx Switch Features — hardware offloading capabilities by platform