Bridge IGMP Snooping

Bridge IGMP Snooping

Summary

Bridge IGMP snooping allows a RouterOS bridge to listen to IGMP (IPv4) and MLD (IPv6) membership control packets and build a multicast database (MDB). Instead of flooding all multicast streams to every bridge port, the bridge forwards each group only to ports that have active receivers — significantly reducing unnecessary multicast traffic on L2 segments.

IGMP snooping is commonly used in IPTV deployments, video surveillance networks, and any environment with high-bandwidth multicast streams.

How It Works

Without IGMP snooping, the bridge treats multicast frames like unknown unicast — flooding them to all ports. With snooping enabled:

1. The bridge inspects IGMP Join and Leave messages from hosts.
2. It builds a Multicast Database (MDB) mapping group addresses to interested ports.
3. Multicast streams for known groups are forwarded only to member ports.
4. Unknown multicast (no MDB entry) is handled according to unknown-multicast-flood settings on each port.

MLD snooping works identically for IPv6 multicast (MLDv1/v2).

Quick Start

Enable IGMP snooping on a bridge:

/interface bridge
set [find name=bridge1] igmp-snooping=yes

Enable a multicast querier (required when there is no upstream multicast router):

/interface bridge
set [find name=bridge1] igmp-snooping=yes multicast-querier=yes

Verify MDB entries are populated:

/interface bridge mdb print

Bridge Settings

igmp-snooping

Enables IGMP and MLD snooping on the bridge.

/interface bridge set [find name=bridge1] igmp-snooping=yes

When disabled (default), multicast is flooded to all ports. This setting must be enabled before any other IGMP snooping configuration takes effect.

multicast-querier

Enables the bridge to act as an IGMP/MLD querier, sending periodic General Query messages to prompt hosts to report their group memberships.

/interface bridge set [find name=bridge1] multicast-querier=yes

If there is no IGMP querier on the segment (no multicast router), memberships will age out and multicast forwarding will revert to flooding. Enable multicast-querier=yes on one bridge in each broadcast domain to prevent this.

Note

If an upstream multicast router is present, it already acts as querier. Enabling an additional querier is harmless — querier election follows the lowest IP address rule — but is unnecessary.

multicast-router (bridge level)

Sets the bridge’s own behavior when it receives multicast from its routing interface:

/interface bridge set [find name=bridge1] multicast-router=permanent

Values: disabled, temporary-query (default), permanent.

Port Settings

fast-leave

When enabled on a port, the bridge immediately removes that port’s group membership when an IGMP/MLD Leave message is received — without waiting for the standard leave query/response cycle.

/interface bridge port set [find interface=ether10] fast-leave=yes

Use fast-leave=yes only on single-host access ports (e.g., one IPTV set-top box per port). If multiple receivers share a port (e.g., through a downstream unmanaged switch), a Leave from one host will drop the stream for all others behind that port.

multicast-router (port level)

Controls whether a port is treated as a multicast router port — streams are always forwarded toward multicast router ports regardless of MDB membership.

/interface bridge port set [find interface=ether1] multicast-router=permanent

Value	Behavior
disabled	Port is never treated as mrouter port
temporary-query	Auto-detected by observing IGMP queries (default)
permanent	Always treated as mrouter port

Set multicast-router=permanent on uplink ports connected to a multicast-capable router to ensure all streams are forwarded upstream.

unknown-multicast-flood

Controls whether unknown multicast frames (no MDB entry) are flooded out this port:

/interface bridge port set [find interface=ether20] unknown-multicast-flood=no

Setting this to no on access ports prevents multicast streams for unregistered groups from flooding those ports. The uplink port should generally keep unknown-multicast-flood=yes.

Multicast Database (MDB)

The MDB stores learned and static multicast group memberships.

Viewing the MDB

/interface bridge mdb print detail

Output shows group address, member ports, VLAN ID (if VLAN filtering enabled), and whether the entry is static or dynamic.

Static MDB Entries

Pin a multicast group to specific ports permanently, bypassing IGMP learning. Useful for non-IGMP capable devices or fixed IPTV channel assignments:

/interface bridge mdb
add bridge=bridge1 group=239.1.1.1 ports=ether10,ether11

With VLAN filtering enabled, add the VLAN ID:

/interface bridge mdb
add bridge=bridge1 group=239.1.1.1 ports=ether10,ether11 vlan-id=20

Static entries are never aged out and take precedence over dynamic learning for the same group.

MLD Snooping for IPv6

MLD (Multicast Listener Discovery) snooping is the IPv6 equivalent of IGMP snooping. Enabling igmp-snooping=yes on a bridge simultaneously activates MLD snooping — there is no separate toggle. Both MLDv1 (equivalent to IGMPv2, ASM) and MLDv2 (equivalent to IGMPv3, SSM) are processed.

MLD Querier

multicast-querier=yes enables both IGMP and MLD querier functions on the bridge. When acting as MLD querier, the bridge sends periodic MLD General Queries sourced from its IPv6 link-local address. Verify a link-local address exists before relying on MLD querier:

/ipv6 address print where interface=bridge1

If no link-local address is present, the MLD querier cannot send queries and IPv6 group memberships will age out.

Viewing IPv6 MDB Entries

IPv6 multicast addresses use the ff00::/8 prefix and appear in the same MDB table as IPv4 entries:

/interface bridge mdb print

To filter for IPv6 groups only:

/interface bridge mdb print where group~"ff0"

Static IPv6 MDB Entry

Pin an IPv6 multicast group to specific ports without relying on MLD learning:

/interface bridge mdb
add bridge=bridge1 group=ff15::1:2:3 ports=ether10

With VLAN filtering enabled, include the VLAN ID:

/interface bridge mdb
add bridge=bridge1 group=ff15::1:2:3 ports=ether10 vlan-id=20

VLAN-Aware IGMP Snooping

When vlan-filtering=yes is enabled on the bridge, IGMP snooping becomes VLAN-aware: group memberships are tracked per VLAN, and streams are forwarded only within the correct VLAN context.

Ensure the VLAN table is fully configured before enabling snooping with VLAN filtering, or multicast will appear broken even though snooping is active.

/interface bridge
add name=bridge1 vlan-filtering=yes igmp-snooping=yes multicast-querier=yes

The querier sends queries with a source IP — assign an IP to the bridge VLAN interface if precise querier source addressing matters:

/ip address add address=192.168.20.1/24 interface=bridge1

Configuration Example: IPTV on VLAN 20

A complete setup with VLAN-aware IGMP snooping for IPTV set-top boxes:

/interface bridge
add name=bridge1 vlan-filtering=yes igmp-snooping=yes multicast-querier=yes

/interface bridge port
add bridge=bridge1 interface=ether1 multicast-router=permanent    ; uplink to IPTV headend
add bridge=bridge1 interface=ether10 pvid=20 fast-leave=yes       ; STB port 1
add bridge=bridge1 interface=ether11 pvid=20 fast-leave=yes       ; STB port 2
add bridge=bridge1 interface=ether24                              ; trunk to distribution

/interface bridge vlan
add bridge=bridge1 vlan-ids=20 tagged=bridge1,ether1,ether24 untagged=ether10,ether11

; Optional: pin a known IPTV channel to avoid join latency
/interface bridge mdb
add bridge=bridge1 vlan-id=20 group=239.10.10.10 ports=ether10,ether11

This configuration:

• Forwards multicast only to STB ports that have joined each group
• Removes membership immediately on Leave (fast-leave) for each STB port
• Always forwards toward the uplink (multicast-router=permanent)
• Scopes snooping to VLAN 20

Monitoring

Check bridge snooping state:

/interface bridge monitor bridge1

Key fields: igmp-snooping (enabled/disabled), multicast-querier state.

View MDB entries:

/interface bridge mdb print detail

Check port-level settings:

/interface bridge port print detail where bridge=bridge1

Common Issues

Multicast Still Flooded After Enabling Snooping

• Verify igmp-snooping=yes is set on the bridge, not just a port.
• If there is no querier, hosts may not send reports — enable multicast-querier=yes.
• Check MDB: if no entries exist, the bridge has no membership information and falls back to flooding behavior based on unknown-multicast-flood settings.

Multicast Stops After Join

• Confirm the upstream port has multicast-router set appropriately (permanent or auto-detected via temporary-query).
• With VLAN filtering, verify the VLAN table includes the receiving ports in the correct VLAN.

fast-leave Drops Stream for Other Viewers

• fast-leave is only safe for single-host ports. Remove it from ports with multiple receivers behind an unmanaged switch.

Snooping Not Working with VLAN Filtering

• IGMP snooping is VLAN-aware when vlan-filtering=yes. Ensure receiving ports appear as untagged (or tagged) in the correct VLAN entry in /interface bridge vlan.
• Check that the multicast source VLAN and receiver VLAN match.

See Also

• Bridging and Switching
• Bridge VLAN Filtering
• Bridge Port Isolation
• Spanning Tree Protocol
• CRS3xx, CRS5xx, CCR2116, CCR2216 Switch Chip Features