You commission a new IPMX control room. Cameras, encoders, and displays are spec’d. The 10 GbE fabric is racked, the patch is clean, and everything passes acceptance. Two weeks later the calls start. Streams drop silently for no reason anyone can find. Restarting the receiver fixes it for a few hours. Nobody can reproduce the problem on the bench.
The cause, almost every time, is something that should have been configured at install: a network that nobody designed for multicast.
For integrators coming from SDI, this is the largest mental adjustment in moving to ST 2110, IPMX, and the rest of the media-over-IP world. SDI delivers what you wired. IP delivers what you configured and uncompressed video at multicast scale punishes networks that haven’t been configured for it.
What follows is a field guide to the parts of multicast that actually affect your installs, and the decisions you need to make before the first camera comes up.
Why multicast at all
In a small AV-over-IP system, you can sometimes get away with unicast. Each receiver opens its own connection to each source, the way a web browser fetches a page. NDI, SDVoE, and Dante AV all support unicast for simple deployments. It works because most systems are small and most streams are bandwidth-modest.
ST 2110 and IPMX break that model fast. Picture one 4K camera feeding four displays. With unicast, that’s four identical 12 Gb/s streams leaving the camera (using 12G-SDI’s line rate as a reference for 4K UHD60 4:2:2 10-bit). 48 Gb/s in total, all flowing out of one camera port. Add a second camera and you’re at 96 Gb/s. The math collapses immediately.
Multicast solves this by replicating traffic inside the network instead of at the source. The camera sends one stream to a special group address. The switches in the path make copies only where they’re needed. Each link carries one instance of the flow, regardless of how many receivers are watching.
That is the whole reason ST 2110 and IPMX assume multicast. Without it, you cannot scale.
The first piece: groups and snooping
Every multicast flow starts with a sender (a camera, an encoder, a server) transmitting to a destination address in the administratively scoped 239.0.0.0/8 range. The sender does not check whether anyone is listening. It simply sends.
Receivers join a group by sending an IGMP membership report, a small message that effectively says “I want to receive 239.1.1.1.” A switch with IGMP snooping enabled listens for these messages and adds the requesting port to its forwarding table. Packets for that group are then sent only to the ports that asked for them.
That last sentence is the important one. Without IGMP snooping, the switch treats multicast like broadcast and sends every stream to every port, which on a multi-gigabit AV fabric is unworkable. IGMP snooping is what separates a multicast-capable switch from one that will saturate the fabric the moment a 6 Gb/s flow shows up.
Most managed switches support snooping, but defaults vary. Some enable it globally; some require turning it on per VLAN. Verify before you commission, not after.
The second piece: the Querier
IGMP snooping by itself is not stable. Receiver subscriptions age out unless something keeps the table fresh. That something is the IGMP Querier, a device on each VLAN that periodically asks “is anyone still listening to this group?” Receivers respond, the table refreshes, and traffic keeps flowing.
In any network with a Layer 3 router on the VLAN, the router is automatically the Querier and you don’t have to think about it. In a flat Layer 2 AV network with no router, you have to configure one switch to act as the snooping Querier. This is the single most common cause of “the stream worked for a few minutes and then stopped.” The snooping table aged out, the switch stopped forwarding, and there was nobody asking the question that would have kept the table alive.
If you take one thing from this article, take that one. Confirm a Querier exists on every VLAN that carries multicast.
Crossing VLANs: PIM and the ASM/SSM choice
IGMP works inside a VLAN. The moment you have to move multicast across VLANs or subnets, you need something more, and that something is PIM (Protocol Independent Multicast). PIM runs on Layer 3 devices and uses the same unicast routing table the device already maintains to figure out how to deliver multicast traffic between subnets.
PIM operates in two flavors that matter for AV deployments. The choice between them is one of the few real architectural decisions you will make.
In Any-Source Multicast (ASM), receivers ask for a group without specifying which source they want. Because multicast addresses don’t reveal where the source lives, the network needs a Rendezvous Point (RP), a designated router that brokers the connection between sender and receiver. ASM works, it is robust, and the gear has supported it for two decades. The cost is configuration complexity and an RP that can become a bottleneck under load.
In Source-Specific Multicast (SSM), receivers specify both the source and the group as a pair. No Rendezvous Point is needed. Routers build a direct path between source and receiver. Configuration is simpler, behavior is more deterministic, and the RP bottleneck disappears. SSM uses the 232.0.0.0/8 address range by convention.
The catch is that SSM requires IGMPv3 at the receiver, and not every endpoint or control system supports it. If yours does, prefer SSM. If it doesn’t, ASM works fine for small to mid-size systems. What you cannot do is mix the two on the same address ranges without creating problems.
Designing the network around multicast
Once the protocols are sorted, the design rules are mercifully short.
Bandwidth is unforgiving. Multicast saves duplication, not bytes. A 6 Gb/s stream is still 6 Gb/s on every link it traverses. Provision your switch interconnects and uplinks for the worst-case sum of multicast traffic that will share them, plus headroom for bursts. Spine-leaf topologies are popular in ST 2110 networks specifically because they make this math predictable.
PIM does not see congestion. PIM forwards based on the unicast routing table’s Reverse Path Forwarding rule. It does not know whether a link is saturated. Two paths between leaves may have identical hop counts, but if one is busy carrying a 3 Gb/s video flow, PIM will still send the next flow down it. Engineers can influence this by tuning link costs or static routes, or by introducing an SDN controller that does have congestion awareness. In Cisco’s IP Fabric for Media, this role is filled by Nexus Dashboard Fabric Controller; in Arista deployments, it is Media Control Service running on a CloudVision eXchange node.
For smaller deployments, Netgear’s AV Line switches (the M4250, M4300, and M4350 series) take a different approach: they ship pre-configured for AV-over-IP, with IGMP snooping, a snooping querier, and AV-appropriate QoS profiles already enabled.
QoS still matters. Multicast does not change the rules of queueing. Make sure your switches honor DSCP markings, that PTP timing packets get the highest priority, and that video and audio queues are protected from data traffic under load. This is not multicast-specific advice, but it is part of any successful IPMX or ST 2110 design.
Why this matters at install time
Multicast does exactly what your network design and routing tables tell it to do. That is its strength, and the responsibility that comes with it. A well-designed multicast network is fast, deterministic, and quiet, the kind of network you don’t have to think about after handoff. A poorly designed one will look fine on the bench and fail mysteriously in production.
Most multicast problems in AV installs are configurable. They have to be configured on purpose. The defaults on most switches are tuned for general enterprise traffic, not for a 100 Gb/s media fabric. Read your switch vendor’s multicast configuration guide before you spec the network, not after. Cisco, Arista, NVIDIA, Aruba, and Extreme all publish detailed documentation. JT-NM TR-1001-1 is the deployment-oriented document worth reading next; it covers practical multicast addressing schemes and other ST 2110 design considerations that the standards documents themselves leave out.
None of this is exotic. Anyone who can commission a clean SDI router can commission a clean multicast fabric, given the time to learn the controls. The integrators who do this work up front are the ones whose phones do not ring at 2 AM two weeks after handoff.
Thanks to Ian Cobb, Senior Broadcast IT Systems Architect at Alpha, whose technical review shaped the gotchas section.
