Bridge Port Isolation

Bridge Port Isolation

Summary

Bridge port isolation prevents direct Layer 2 communication between selected ports on the same bridge, while still allowing those ports to reach common uplinks or gateways. This is useful for guest networks, public Wi-Fi hotspots, and service provider deployments where clients must not communicate with each other at L2.

RouterOS implements port isolation through two complementary mechanisms:

• Split horizon (horizon) — prevents forwarding between ports assigned the same horizon group
• Flood controls (unknown-unicast-flood, unknown-multicast-flood) — reduces unnecessary L2 flooding on access ports

How Split Horizon Works

Each bridge port can be assigned a horizon value (an integer). Traffic received on a port is not forwarded to any other port sharing the same horizon value. Ports with different or no horizon values are unaffected and behave normally.

This mirrors the split horizon concept from routing: a port will not forward back toward the same “horizon” from which traffic arrived.

Topology:
  ether1 (uplink, no horizon)
  ether2 (client, horizon=1)
  ether3 (client, horizon=1)
  ether4 (client, horizon=1)

Result:
  ether2 ↔ ether1  ✓  (different horizons)
  ether3 ↔ ether1  ✓
  ether2 ↔ ether3  ✗  (same horizon — blocked)
  ether3 ↔ ether4  ✗  (same horizon — blocked)

Quick Start

Isolate client ports from each other while keeping uplink access:

/interface bridge
add name=bridge1

/interface bridge port
add bridge=bridge1 interface=ether1              ; uplink — no horizon
add bridge=bridge1 interface=ether2 horizon=1   ; client port
add bridge=bridge1 interface=ether3 horizon=1   ; client port
add bridge=bridge1 interface=ether4 horizon=1   ; client port

Clients on ether2, ether3, ether4 cannot communicate with each other at L2, but all can reach the gateway through ether1.

Configuration Reference

Setting the Horizon

/interface bridge port
set [find interface=ether2] horizon=1
set [find interface=ether3] horizon=1

The horizon value is an integer from 0 to 429496729. The default is none (no isolation). Ports sharing any non-none value are mutually isolated.

You can create multiple isolation groups using different horizon values:

/interface bridge port
add bridge=bridge1 interface=ether1              ; uplink
add bridge=bridge1 interface=ether2 horizon=1   ; group A — isolated from each other
add bridge=bridge1 interface=ether3 horizon=1   ; group A
add bridge=bridge1 interface=ether5 horizon=2   ; group B — isolated from each other
add bridge=bridge1 interface=ether6 horizon=2   ; group B

Group A and Group B ports can all reach ether1, but ports within the same group cannot reach each other. Ports from Group A and Group B can still reach each other (different horizon values).

Flood Control

The unknown-unicast-flood and unknown-multicast-flood port settings control whether the bridge floods unknown-destination frames out a given port.

Setting	Default	Description
unknown-unicast-flood	yes	Flood frames for unknown MAC addresses out this port
unknown-multicast-flood	yes	Flood unknown multicast frames out this port

Disabling these on isolated access ports reduces unnecessary traffic:

/interface bridge port
set [find interface=ether2] unknown-unicast-flood=no unknown-multicast-flood=no
set [find interface=ether3] unknown-unicast-flood=no unknown-multicast-flood=no
set [find interface=ether4] unknown-unicast-flood=no unknown-multicast-flood=no

Note

unknown-multicast-flood=no affects multicast groups that have no IGMP snooping entry. If IGMP snooping is in use, known multicast groups follow the MDB — only unknown groups are affected by this setting.

Configuration Examples

Guest Wi-Fi Client Isolation

A common use case: access point clients should reach the internet (via uplink) but not each other.

/interface bridge
add name=bridge-guest

/interface bridge port
add bridge=bridge-guest interface=ether1                        ; uplink to router
add bridge=bridge-guest interface=wlan1 horizon=10             ; AP — client-isolated
add bridge=bridge-guest interface=wlan2 horizon=10             ; second AP

Both APs share horizon=10 so APs themselves cannot bridge directly (protecting against AP-to-AP lateral traffic). Each AP’s clients inherit the L2 isolation boundary at the bridge level.

Multi-Tenant Access with Shared Uplink

/interface bridge
add name=bridge1

/interface bridge port
add bridge=bridge1 interface=sfp-sfpplus1                       ; core uplink
add bridge=bridge1 interface=ether2  horizon=100               ; tenant A
add bridge=bridge1 interface=ether3  horizon=100               ; tenant A
add bridge=bridge1 interface=ether4  horizon=200               ; tenant B
add bridge=bridge1 interface=ether5  horizon=200               ; tenant B

Tenant A ports are isolated from each other and from Tenant B ports. All tenants reach the core uplink.

Combined: Horizon + Flood Control

/interface bridge
add name=bridge1

/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2 horizon=1 unknown-unicast-flood=no unknown-multicast-flood=no
add bridge=bridge1 interface=ether3 horizon=1 unknown-unicast-flood=no unknown-multicast-flood=no
add bridge=bridge1 interface=ether4 horizon=1 unknown-unicast-flood=no unknown-multicast-flood=no

Monitoring

Verify bridge port settings:

/interface bridge port print detail where bridge=bridge1

Check that the horizon field shows the expected value for each port. There is no dedicated isolation monitoring command — the effective behavior can be confirmed with connectivity tests between isolated ports.

Common Issues

Ports That Should Communicate Are Blocked

If two ports that should communicate are blocked, check that they are not assigned the same horizon value:

/interface bridge port print detail

Only ports that must be isolated from each other should share a horizon value. Uplinks and inter-switch trunk ports should have no horizon (horizon=none).

Horizon Does Not Block All Traffic

Split horizon blocks forwarding between ports in the same horizon group but does not filter upper-layer traffic (e.g., IP). If a client has a route via the gateway and the gateway routes back to another client, traffic can still traverse at L3. Use firewall rules for L3 isolation in addition to split horizon for L2 isolation.

Multicast Not Reaching Access Ports

If unknown-multicast-flood=no is set and IGMP snooping is not enabled, known multicast groups may not be forwarded to access ports. Either:

• Enable IGMP snooping (see Bridge IGMP Snooping)
• Leave unknown-multicast-flood=yes on ports that need multicast without snooping

See Also

• Bridging and Switching
• Bridge VLAN Filtering
• Bridge IGMP Snooping
• Bridging and Switching Case Studies