How to Inspect and Configure Linux Bridge Multicast Groups Using bridge mdb

In high-density networking environments—such as live video streaming clusters, financial market feeds, and containerized virtual switch fabrics—multicast traffic plays a critical role in distributing data efficiently from a single source to multiple interested subscribers. However, by default, an unmanaged Layer 2 Ethernet bridge treats incoming multicast frames similarly to broadcast packets, flooding them across every member port. This causes unnecessary network congestion, saturates unrelated network interfaces, and degrades performance.

To eliminate multicast flooding, the Linux kernel bridge driver provides IGMP and MLD Snooping, governed at the command line by the bridge mdb (Multicast Group Database) utility. Included within the standard iproute2 suite, bridge mdb enables system administrators to inspect dynamically learned multicast subscriptions, establish static multicast forwardings, and configure querier behaviour. In this comprehensive guide, we examine how to enable multicast snooping, audit active group memberships, configure permanent group entries, and troubleshoot bridge multicast distribution.

How Linux Bridge Multicast Snooping Operates

When an Ethernet bridge operates without snooping, any IP packet sent to a class D multicast address (224.0.0.0/4 in IPv4) or ff00::/8 in IPv6 is replicated across all attached bridge ports. Enabling multicast snooping changes this behaviour fundamentally:

• IGMP/MLD Inspection: The kernel bridge driver inspects Layer 3 IGMP (IPv4) or MLD (IPv6) Membership Reports sent by client endpoints connected to member ports.
• Dynamic MDB Population: The bridge registers which physical or virtual port (e.g., eth1, veth0, tap0) requested which specific multicast group IP and updates its internal Multicast Group Database (MDB).
• Selective Frame Forwarding: When multicast traffic arrives at the bridge, it is forwarded exclusively out the ports listed in the MDB for that group, preventing unwanted traffic from reaching non-subscriber ports.

Step 1: Enabling Multicast Snooping and Querier on the Bridge

Before querying or managing the MDB, ensure that multicast snooping is actively enabled on your Linux software bridge (for example, br0):

# Enable IGMP/MLD multicast snooping
sudo ip link set dev br0 type bridge mcast_snooping 1

If your local subnet does not have an upstream multicast router generating regular IGMP Membership Queries, you must instruct the Linux bridge to act as the Multicast Querier. Without periodic queries, client devices will not send membership reports, causing dynamic subscriptions to expire:

# Enable local bridge multicast querier
sudo ip link set dev br0 type bridge mcast_querier 1

Verify that bridge multicast parameters are configured correctly:

ip -d link show br0

The output will display mcast_snooping 1 and mcast_querier 1 under the bridge link attributes.

Step 2: Inspecting Active Multicast Groups with bridge mdb show

To view all active multicast group subscriptions currently held in the kernel’s MDB table, execute the bridge mdb show command:

bridge mdb show

A typical output from an active bridge network appears as follows:

dev br0 port veth-app1 grp 239.255.255.250 permanent
dev br0 port eth1 grp 239.1.1.100 temp 248.50
dev br0 port eth2 grp ff02::fb temp 192.10
router port eth0

Output breakdown:

• dev br0: The parent bridge interface hosting the database.
• port eth1: The specific member port where the subscriber resides.
• grp 239.1.1.100: The multicast group IP address.
• temp <seconds>: Indicates a dynamic subscription learned via an IGMP report. The trailing number represents the remaining time-to-live before the entry must be refreshed by another report.
• permanent: Statically pinned multicast entries configured by the administrator that never expire.
• router port eth0: Indicates that port eth0 is recognized as connected to an upstream multicast router because it received IGMP queries.

For more detailed socket details and VLAN tags, append the detail flag: bridge -d mdb show.

Step 3: Adding Static Multicast Entries Using bridge mdb add

In virtualised environments or headless media nodes, applications may consume UDP multicast streams without sending standard IGMP join reports. In such cases, you can manually map multicast groups to specific bridge ports to ensure traffic delivery.

1. Adding a Permanent Multicast Group

To route multicast group 239.10.10.50 permanently out port eth1 on bridge br0:

sudo bridge mdb add dev br0 port eth1 grp 239.10.10.50 permanent

Permanent entries persist until explicitly removed or until the bridge interface is deleted, surviving client reboots and silence periods.

2. Adding an IPv6 Multicast Group

The bridge mdb tool supports IPv6 MLD multicast groups using identical syntax:

sudo bridge mdb add dev br0 port veth-node1 grp ff05::1:3 permanent

3. Pinning Multicast to Specific VLANs

If your Linux bridge operates in VLAN-filtering mode (vlan_filtering 1), you must associate the multicast entry with the relevant 802.1Q VLAN ID:

sudo bridge mdb add dev br0 port eth1 grp 239.20.20.10 permanent vid 100

Step 4: Deleting Multicast Entries from the Database

If a static mapping is obsolete or if you wish to revoke forwarding permissions for a specific multicast feed, use the bridge mdb del command:

sudo bridge mdb del dev br0 port eth1 grp 239.10.10.50

For VLAN-tagged entries, specify the matching vid flag:

sudo bridge mdb del dev br0 port eth1 grp 239.20.20.10 vid 100

Confirm the deletion by re-running bridge mdb show.

Troubleshooting Common Multicast Bridge Faults

If client devices attached to the bridge are failing to receive multicast packets, check these common diagnostic vectors:

Symptom	Likely Root Cause	Remediation Step
Multicast stream drops after 3 to 5 minutes	Dynamic IGMP membership expired because no queries were received.	Enable the internal bridge querier: ip link set dev br0 type bridge mcast_querier 1.
Multicast floods all ports regardless of membership	Multicast snooping is disabled or unsupported on parent bridge.	Verify mcast_snooping 1 is set in ip -d link show br0.
Link-local multicast (224.0.0.X) not filtered	RFC-standard behavior: link-local discovery (e.g., mDNS, OSPF) is intentionally flooded.	Standard link-local multicast (224.0.0.1 to 224.0.0.255) bypasses snooping by design to preserve basic network protocol discovery.
Firewall drops IGMP packets	Host iptables/nftables blocking protocol 2 (IGMP).	Add a firewall rule: sudo iptables -I INPUT -p igmp -j ACCEPT.