There is a specific kind of AV-over-IP failure that looks like a bandwidth problem but isn't. Audio drops out for half a second. A camera feed appears, then vanishes, then reappears. The touch panel takes three seconds to answer a button it used to answer instantly. Someone checks the switch, sees traffic everywhere, and blames the uplink. The real culprit is almost always multicast being handled wrong — and the setting that fixes it is IGMP snooping.
Most AV networks that "mostly work" are one config setting away from just working.
This post explains what IGMP snooping does, why it isn't optional on a multicast AV network, and the handful of mistakes that cause more dropouts than any hardware fault.
Unicast, multicast, and why AV is different
With unicast, one source sends a separate copy to each receiver — one sender, three receivers, three streams. Simple, but it multiplies bandwidth per listener. With multicast, the source sends one stream to a group address and receivers join it — one stream on the wire until the switch fans it out. That efficiency is why large AV-over-IP systems lean on multicast for one-to-many.
unicast by default and only moves to multicast when one source feeds many receivers. Small Dante systems may need no multicast at all. Add NDI or SDVoE — which are multicast-heavy — and snooping stops being optional.Here's the catch that bites everyone. A switch left on defaults doesn't know which ports want a multicast stream, so it does the dumb-safe thing: treats multicast like broadcast and floods every port.
What IGMP snooping actually does
IGMP is how receivers announce which multicast groups they want. A device sends a join when it wants a stream and a leave when it's done. IGMP snooping is the switch listening in on those messages, building a table of which port wants which group, and forwarding each stream only to the ports that asked.
The querier: the piece everyone forgets
Devices announce membership once, then go quiet. Something has to periodically re-ask "who still wants which groups?" That something is the querier — usually the core or a Layer 3 switch on the AV VLAN.
A sane baseline
Target state on the AV VLAN, vendor-independent:
On a Cisco-style CLI, snooping plus a pinned querier for VLAN 2:
ip igmp snooping
ip igmp snooping vlan 2
ip igmp snooping querier
ip igmp snooping vlan 2 querier address 10.20.2.1
ip igmp snooping vlan 2 querier version 3Quick way to confirm which switch actually won querier election:
The three mistakes behind most failures
- Snooping enabled
- One querier defined deliberately (not by accidental lowest-IP election)
- IGMP version matched across all switches
- Single switch vendor across the AV network
Work down that list in order — most "mostly works" networks have the first box ticked and the rest empty.
Frequently asked questions
Do I need snooping for a small Dante system? Not always — Dante defaults to unicast. The moment you multicast to many receivers, or add NDI/SDVoE, you do.
Is enabling snooping enough on its own? No. Without a working querier it can drop the very traffic it's meant to manage.
Can I run two queriers for redundancy? No. Multiple queriers de-sync membership and cause intermittent failure. One per VLAN.
Why does multicast work on PCs but not Macs? Almost certainly an IGMP version mismatch — modern macOS speaks v3, and v2 switches can starve it.
Should I mix switch brands? Avoid it. IGMP implementations differ between vendors and don't always coordinate group lists.
Does snooping replace QoS and VLANs? No — snooping stops flooding, QoS protects timing under load, VLANs segment AV from everything else. A solid design needs all three.