Dante IGMP Snooping and Querier: Configure Multicast Safely

6 min read · Updated October 13, 2026 · FOH and monitor engineers, system technicians, AV network engineers, venue technicians, integrators, broadcast operators, and production managers

Configure and verify IGMP snooping and an IGMP querier for Dante multicast without flooding ports, losing memberships, or masking switch faults.

TL;DR — IGMP snooping lets a switch forward Dante multicast only to ports whose receivers joined that group. A working IGMP querier keeps those memberships current. Use both deliberately on the same VLAN, confirm there is one elected querier, leave unknown-multicast behavior documented, and test joins, leaves, link recovery, and real audio. Do not treat IGMP as a substitute for bandwidth planning or QoS.

What IGMP changes on a Dante network

Dante normally uses unicast for one-to-one delivery and can use multicast when one transmitter must serve several receivers. Without multicast control, a switch may flood that traffic to every port in the VLAN. IGMP snooping listens to receiver membership messages and builds a forwarding table so subscribed groups reach only the ports that requested them.

Function	Job	Failure symptom
IGMP snooping	Learns which ports joined each multicast group	Multicast reaches unnecessary ports when absent or ineffective
IGMP querier	Periodically asks whether memberships are still active	Entries age out or behave inconsistently when no querier exists
VLAN boundary	Defines the membership and forwarding domain	A receiver outside the domain cannot join through ordinary Layer 2 switching
QoS	Prioritizes clock and audio classes	Congestion can still harm audio even when forwarding is selective

The Dante multicast flow setup guide explains when and how to create a flow. This guide owns the switch-side membership behavior after multicast is justified.

Configure snooping and the querier in order

1. Map the multicast domain

Record the switches, VLAN ID, uplinks, transmitter ports, receiver ports, and any routed boundary. Confirm the devices that must share multicast are in the intended Dante network. Never join primary and secondary redundant networks to create a common IGMP domain.

2. Enable IGMP snooping on the correct VLAN

Use the switch vendor's supported IGMP snooping implementation. Apply it to the Dante VLAN, not blindly to every VLAN. Preserve the current configuration and note whether the switch floods unknown multicast, filters it, or sends it to router ports.

3. Provide one active querier

A Layer 3 interface or a capable switch may act as querier. If several devices can query, normal IGMP election should leave one active querier, but the design still needs an intentional owner. Give the querier a stable address appropriate to the VLAN and document its priority or election behavior.

4. Verify memberships, not only settings

Create or use one known multicast flow. Confirm the switch table shows its group on the transmitter-facing path and only the subscribed receiver ports. Remove a subscription and verify the port leaves after the expected process; restore it and confirm the join returns.

5. Test under representative load

Pass real audio while observing link utilization, packet errors, late packets, clock status, and group membership. A correct IGMP table can coexist with an undersized uplink or incorrect QoS, so acceptance requires both forwarding evidence and clean audio.

Diagnose common IGMP patterns

Evidence	Likely cause	Controlled next check
Multicast appears on every access port	Snooping disabled, wrong VLAN, or unknown group	Compare VLAN membership and snooping table
Audio stops after several minutes	Membership aged out without working queries	Identify the elected querier and inspect query traffic
One switch receives traffic but downstream receivers do not	Uplink or router-port learning is wrong	Trace the group across each switch table
A removed receiver keeps receiving traffic	Leave processing or membership timeout	Inspect group members and configured leave behavior
Membership works until a switch reboot	Querier ownership or saved config is incomplete	Repeat election and persistence test after restart
Audio fails only during congestion	Capacity or QoS issue, not IGMP membership	Inspect every constrained link and queue

Avoid enabling fast-leave behavior unless the port can contain only one receiver and the switch vendor documents the consequence. On shared downstream segments, an immediate leave can remove traffic still needed by another receiver.

Acceptance checklist

Dante VLAN and every participating switch are documented.
IGMP snooping is enabled only where intended.
One active querier is visible and stable.
Known group memberships match subscribed receiver ports.
Join, leave, link interruption, and switch-recovery tests pass.
Unsubscribed ports do not receive sustained Dante multicast.
Real audio, clock, errors, latency, and utilization remain healthy under load.
The saved switch configuration matches the tested configuration.

For traffic sizing before the test, use the Dante multicast bandwidth guide. For queue policy, use the Dante QoS settings guide.

Document the multicast control plan

Record the VLAN, snooping state, querier device and address, election owner, switch firmware, unknown-multicast policy, uplinks, test group, expected receiver ports, and acceptance results. Add the network owner and rollback point. This turns a hidden switch feature into a repeatable production control.

In Techrider.live, keep the network notes beside the input list and stage plot, export the accepted plan as a PDF, and invite the system engineer to edit the same rider. The crew can save revisions and inspect history without calling the workflow real-time collaboration.

FAQ

Does Dante need IGMP snooping?

Small networks using only unicast may not benefit from it. Networks carrying meaningful Dante multicast commonly use IGMP snooping to prevent unnecessary flooding, provided the configuration is designed and tested.

Does a Dante network need an IGMP querier?

When IGMP snooping manages multicast memberships, a querier keeps those memberships refreshed. Confirm one active querier exists in the VLAN instead of assuming the switch creates one automatically.

What happens if snooping is enabled without a querier?

Behavior depends on the switch, but learned memberships can age out or become inconsistent. That can interrupt multicast or produce confusing forwarding after an initially successful test.

How do I stop Dante multicast flooding?

Confirm multicast is actually required, enable supported snooping on the correct VLAN, provide a working querier, and verify the forwarding table. Do not filter blindly; prove that subscribed receivers still receive clean audio.

How do I test IGMP on a Dante network?

Use a known multicast flow, inspect membership per switch and port, add and remove a receiver, interrupt and restore a link, and pass real audio under load while watching clock, packet, latency, and utilization evidence.

Related guides

Basics