Multicast video is one of those things that works perfectly in the lab, works perfectly at commissioning, and then takes the video wall down four minutes after the network team makes a change that had nothing to do with video. Every one of those incidents I have investigated came back to the same two items: IGMP snooping was on, and there was no querier. This page is about why that combination fails, and how to build multicast so it does not.
When multicast is worth it
A camera stream sent by unicast goes once to every consumer. Ten operators watching the same camera at 8 Mbps costs 80 Mbps at the source and along every shared link. Multicast sends it once and the network replicates it where the paths diverge. The saving is real when the same streams are watched in many places at once: video walls, control rooms, federated monitoring, and any site where operators habitually pull the same feeds.
It is not worth it when most viewing is one operator, one camera, for a short time. Then it adds a control-plane dependency for no bandwidth benefit, and the dependency is the part that fails. Most sites under a hundred cameras with a handful of operators are better served by unicast and a properly sized network. Most sites with a video wall are not.
In Security Center, the Media Router role makes the choice per stream. It will use multicast from a camera that supports it to any client on a multicast-capable path, and fall back to unicast otherwise. The default multicast base address is 239.0.0.1 and the default port is 47806; the Media Router allocates addresses upward from there. Milestone and Avigilon offer the same choice with different names. The network requirement is identical in every case.
What IGMP snooping actually does
A switch without IGMP snooping treats multicast like broadcast. Every multicast frame goes to every port in the VLAN. On a camera VLAN carrying two hundred multicast streams that is a full-time flood into every port, including the ports that connect to cameras, which promptly drop everything that is not addressed to them and get on with life, but only after the switch has spent the bandwidth delivering it.
IGMP snooping fixes this by listening to the IGMP conversation between hosts and routers. When a client wants a group it sends an IGMP membership report. The switch sees the report, notes which port it came from, and forwards that group only to ports where someone asked for it. Cameras that nobody is watching send to nobody. The mechanism is described in RFC 4541 and implemented on every managed switch built this century.
The subtlety is in the word conversation. IGMP membership is not permanent. The router in the VLAN sends a general query at intervals, hosts respond with reports for the groups they still want, and the switch refreshes its table. Membership that is not refreshed ages out, typically after two query intervals plus a margin, which on default timers is around 260 seconds.
The querier, and why its absence is an outage
That query has to come from somewhere. In a routed network it comes from the multicast router on the VLAN. On a CCTV VLAN there is often no multicast router at all. Video is layer two, the VLAN has a gateway that does not run PIM, and nothing is sending queries.
Now the timeline. The system is commissioned. Operators open the video wall; clients send reports; the switch learns the ports; video flows. Nothing sends a query, so nothing refreshes the table. Around four minutes later the entries age out. On most switches the result is that the multicast groups are now unknown, and unknown multicast is either flooded to every port or dropped, depending on the platform and on whether the snooping implementation floods or prunes unknown groups. Either the VLAN floods and the cameras start missing frames, or the video wall goes black.
The fix is a querier. Any device that sends IGMP general queries on the VLAN keeps the snooping tables alive. The switch itself can do it, and on a video VLAN with no multicast router, it should.
The four-minute rule. If multicast video works at commissioning and fails a few minutes after clients connect, then recovers when a client reconnects, then fails again, there is no querier on the VLAN. I have seen this diagnosed as a camera fault, a Media Router fault, a driver fault, and a cabling fault, in that order, over three weeks. It was a missing line of switch configuration.
Where the querier lives
One querier per VLAN is the goal. If several switches are configured as queriers on the same VLAN, IGMP elects the one with the lowest IP address and the rest go quiet. That is safe, and it is why the normal pattern is to enable the querier on every switch in the video VLAN and let election sort it out. The alternative, enabling it on one switch and hoping that switch never reboots, is a single point of failure that will find you during a firmware upgrade.
The querier needs an IP address in the VLAN. On a switch that is a pure layer two device in that VLAN, that means a switched virtual interface with an address whose only job is to source queries. Reserve an address for it in the VLAN plan; a querier with no address does not query.
Where the VLAN is routed and the gateway runs PIM, the router is the querier and the switch queriers should still be enabled, because they yield to it and take over if it goes.
Configuration
These are the multicast lines that belong in the video VLAN on each platform. They are extracted from the full switch templates linked at the end, which carry the rest of the baseline. VLAN 20 is the camera VLAN in every example.
Cisco Catalyst (IOS-XE)
ip igmp snooping
ip igmp snooping vlan 20
ip igmp snooping vlan 20 querier
ip igmp snooping vlan 20 querier address 10.20.0.2
!
interface Vlan20
description CAMERA-VLAN-QUERIER
ip address 10.20.0.2 255.255.0.0
!
! If unknown multicast must not flood the camera ports:
ip igmp snooping vlan 20 immediate-leave
Snooping is on by default on Catalyst; the querier is not. The querier address form lets the querier source from an address even where the SVI is not the gateway. Immediate-leave, also called fast-leave, prunes a port as soon as the client sends a leave rather than waiting a query interval, which suits video wall ports with one client each and does not suit ports with a hub or an unmanaged switch behind them.
Aruba CX (AOS-CX)
vlan 20
name CAMERAS
ip igmp snooping
ip igmp snooping querier
ip igmp snooping fastleave
interface vlan 20
ip address 10.20.0.2/16
AOS-CX enables snooping per VLAN. The querier sources from the VLAN interface address, so the interface needs one.
Juniper EX (Junos)
set protocols igmp-snooping vlan CAMERAS
set protocols igmp-snooping vlan CAMERAS immediate-leave
set protocols igmp-snooping vlan CAMERAS l2-querier source-address 10.20.0.2
set interfaces irb unit 20 family inet address 10.20.0.2/16
set vlans CAMERAS l3-interface irb.20
Junos calls the switch-based querier an l2-querier, which is the accurate name for what it is.
Group addressing
Keep video multicast inside the administratively scoped range, 239.0.0.0/8, which is what the platforms default to. Within it, avoid groups that map to the same layer two MAC address as something else. Multicast IP maps to Ethernet MAC by taking the low 23 bits, so 32 different IPv4 groups share every MAC, and 239.0.0.x collides at layer two with 224.0.0.x, which is the range reserved for local control protocols like OSPF and VRRP. A camera group that lands on the same MAC as OSPF hello traffic works, mostly, and then produces the strangest fault you will see all year.
Set the platform’s multicast base to something like 239.192.0.0 and let it allocate from there. The change is one field in the Media Router or the equivalent, and it removes an entire category of intermittent problem.
Set the TTL on multicast streams to what the topology needs and no more. A TTL of 1 stays on the VLAN, which is right for a layer two video network and wrong the moment federation or a remote operator needs the stream across a router.
Things that fight multicast
- Storm control. A multicast storm threshold set low enough to protect against a loop will drop legitimate video on a busy VLAN. Set the multicast threshold with the actual stream load in mind, or apply storm control to broadcast only on video ports.
- Unmanaged switches at the edge. A desktop switch under a console does not snoop. Every multicast group any client behind it joins floods to every port on it. Replace it, or accept that those ports see everything.
- Unknown multicast flooding. Some platforms flood groups with no known members; others drop them. Know which yours does, because it decides whether a querier failure looks like a flood or a blackout.
- Trunk pruning and VLAN mismatches. A trunk that does not carry the video VLAN, or a port in the wrong VLAN, produces a client that can see the camera’s configuration but never receives its multicast. The unicast fallback in the VMS hides this until someone looks at the bandwidth graphs and asks why multicast is not saving anything.
- IGMP version mismatches. IGMPv3 clients and an IGMPv2 querier interoperate, but source-specific joins do not. Most video platforms use any-source multicast, so this rarely matters, and when it does, the symptom is a client that joins and receives nothing.
Verification
On the switch, look at the snooping table and confirm the querier is present and that groups have members on the ports you expect:
! Cisco
show ip igmp snooping querier vlan 20
show ip igmp snooping groups vlan 20
# Aruba CX
show ip igmp snooping vlan 20
show ip igmp snooping groups vlan 20
# Junos
show igmp snooping membership vlan CAMERAS
show igmp snooping statistics
Then wait ten minutes with the video wall up and check again. If the groups are still there, the querier is doing its job. If they have gone and the wall is still showing video, the VMS has quietly fallen back to unicast and the exercise was pointless. If they have gone and the wall is black, you have reproduced the outage under controlled conditions, which is the best possible time to find it.
The full switch baselines for each platform, including the rest of the camera VLAN configuration, are in the Cisco Catalyst, Aruba CX, and Juniper EX templates.