Multicast Video Not Working: IGMP and Switch Configuration

Identify it by the symptom first

Three symptoms cover nearly every multicast fault, and each points at a different cause. Do not start by reading the switch configuration; start by noting exactly what the screen does.

Symptom	Most likely cause
Screens are live for a few minutes, then go black and stay black	Snooping enabled with no querier — group membership timed out
Video works but unrelated devices on the network slow down	No snooping — multicast is being flooded to every port
Video reaches ports that were never meant to receive it	Unknown-multicast flooding left on, overriding snooping
Nothing arrives at all, on any port	VLAN separation, TTL, or the stream is not leaving the encoder

The mechanism behind all of them is the same: a switch that does not know who asked for the stream has to guess, and the guess is always "everybody". The background is in Multicast, Unicast and Broadcast Explained.

Failure 1: no snooping, so the switch floods

Without IGMP snooping, a Layer 2 switch has no way to tell multicast from broadcast and forwards it out of every port in the VLAN. Your video lands on the CCTV network, the ticketing terminals and the building management system, none of which asked for it.

This one is easy to recognise because it does not look like a video fault. Video keeps playing; everything else gets slow. If the complaint arrives from the IT side rather than the AV side, suspect flooding first.

Failure 2: snooping without a querier

This is the most reported multicast fault in the field, and it is a partial configuration rather than a missing one. Snooping lets the switch learn which ports want a group, but that learned state has a lifetime. Something has to periodically ask who still wants the stream. That something is the IGMP querier.

With no querier, membership ages out and the switch stops forwarding. Screens go black a few minutes after the stream starts and do not recover until something re-triggers a join. The give-away is the delay: a stream that works on commissioning and fails before the client arrives is almost always this.

The fix is not to disable snooping — that converts the problem into failure 1. Enable snooping and make sure a querier exists. On many installations the querier is the router or Layer 3 switch; on a flat Layer 2 network with no router, the switch itself has to be configured to act as querier. Check which device is sending the queries rather than assuming one is.

Failure 3: unknown-multicast flooding left enabled

Plenty of switches ship with a feature that floods multicast traffic whose group has no learned membership. It is on by default on some models, and it silently undoes the snooping you just enabled: groups that should be constrained still reach every port.

Look for it under names along the lines of "flood unknown multicast" or "unknown multicast flooding", and turn it off where the option exists. If it cannot be disabled on the hardware in front of you, the workaround is to constrain the traffic at layer 2 with a separate VLAN so the flood is at least confined.

Two more that look identical: VLAN and IGMP version

VLAN separation. Multicast does not cross a VLAN boundary unless it is explicitly routed. If the encoder sits in one VLAN and the decoders in another, no amount of snooping configuration will deliver the stream. Put the video devices in one VLAN, or configure multicast routing between them deliberately.

IGMP version mismatch. IGMPv2 and IGMPv3 behave differently, and a source-specific setup that assumes v3 will not behave as expected against a switch running v2. Confirm the version on both ends rather than leaving it on a default. Where the network also carries other IP video, agree the version across all of it.

Diagnosing it with a capture

The decisive test is not a configuration review, it is a packet capture on a port that should not be receiving the stream.

1. Start the stream and confirm it is playing on a port that should receive it.
2. Capture on a port in the same VLAN that should not receive it.
3. Watch for the multicast group address in the capture. Traffic here means flooding is still happening.
4. Leave it running. If the capture is clean but the receiving screen goes blank after several minutes, the fault is querier or membership timeout, not flooding.

This distinguishes failure 1 from failure 2 in one session, which a configuration read cannot do because both present as "snooping is enabled".

The configuration sequence that works

1. Give video its own VLAN and keep it away from anything safety-critical or latency-sensitive that is not part of the design.
2. Enable IGMP snooping on every switch in the path, not just the core.
3. Confirm a querier exists and that queries are actually being sent. Configure one explicitly if nothing else is doing it.
4. Disable unknown-multicast flooding where the option exists.
5. Set and document the IGMP version on both encoder and switch.
6. Prove it with the capture above, then re-prove it after any firmware upgrade on the switches.

Step 6 is not ceremony. Switch firmware updates reset or change multicast defaults more often than anyone expects, and a network that worked before an upgrade is not evidence that it works after.

Address planning before you start

Assign multicast group addresses deliberately rather than accepting defaults. Use the administratively scoped range set aside for private use, give each programme or channel its own address, and write the allocation down. Two channels sharing an address, or a video group colliding with an unrelated multicast application, produces faults that look exactly like switch misconfiguration and are not.

Encoders expose the multicast address and port as configuration; the ZY-EH1304 and ZY-EH1308 both appear on the network as standard UDP multicast sources and are managed through the web interface, where address, port and per-stream protocol are set per channel.

Verification: the 30-minute test

Item	Pass criterion
Sustained membership	Screens still live 30 minutes after stream start, with no re-join triggered
Containment	Capture on a non-video port in the same VLAN shows no video multicast
Querier present	Queries observed on the wire from an identified device
Cross-port delivery	Every intended receiver port plays, including ports on a different switch in the path
Address allocation	Group addresses recorded, one per channel, no collisions with other multicast use
After upgrade	Capture repeated following any switch firmware change

Where multicast genuinely cannot be made to work — a network you do not control, for example — the fallback is unicast per receiver, with the bandwidth cost that implies. That trade-off is the subject of How Much Bandwidth Does an IP Video Link Need?.

Where to start

FAQ

Related reading

• Multicast, Unicast and Broadcast Explained
• How Much Bandwidth Does an IP Video Link Need?
• Designing a Rail Transit PIS Video Network
• Video Encoders