Introduction
Unicast offers significant advantages in terms of network simplicity and compatibility. It requires no special switch configuration, works reliably across subnets, and ensures that each receiver establishes a direct, point-to-point connection with the sender, making it the ideal default for most NDI workflows.
However, unicast traffic must be carefully monitored and managed in environments with a high number of receivers per source, such as broadcast production facilities, conference centers, or university campuses. Without proper planning, the aggregate bandwidth demand on transmitters and network uplinks can become significant, making the system harder to scale and maintain.
In these cases, adopting multicast can reduce network load and simplify bandwidth management, especially when the same source needs to be delivered to many endpoints simultaneously.
That’s where multicast becomes essential.
Multicast allows a single NDI stream to be transmitted once over the network, regardless of how many receivers are tuned to it. When properly configured, the switch infrastructure replicates the traffic only where it's needed.
This dramatically reduces bandwidth consumption and avoids saturating the sender's network interface or uplinks.
However, enabling multicast in NDI is not just a checkbox: it requires support from the network infrastructure (IGMP snooping and querier), an understanding of group management, and attention to compatibility across devices and switches. It's also a manual configuration step, since NDI streams are unicast by default.
In this module, we’ll examine when multicast is beneficial and necessary and how to implement it correctly in an NDI environment. We’ll also explore IGMP behavior, switch configuration, and common pitfalls to avoid when scaling your NDI system for multiple viewers and distributed locations.
The Role of IGMP in NDI Networking
As discussed earlier, NDI uses unicast by default, making it easy to deploy on even the most basic network hardware. However, proper configuration becomes essential in complex or large-scale installations where multicast is explicitly enabled. Without it, multicast traffic can flood the network, causing congestion, dropped packets, or complete system failure.
This is where IGMP (Internet Group Management Protocol) comes into play.
IGMP acts as a control mechanism for multicast distribution. Without IGMP, multicast behaves like a broadcast; every device on the network receives every multicast stream, regardless of whether it requested it. That’s like every monitor in a facility displaying the same source, even if nobody is watching.
With IGMP, only devices that explicitly request a given stream (via an IGMP "join") will receive it. For example, when an NDI receiver, like a video switcher or monitor, subscribes to a multicast stream, it sends an IGMP join request. The switch then forwards that stream only to the ports that need it, keeping the network clean and efficient.
However, this system only works correctly if:
IGMP snooping is enabled on the switches, and an IGMP Querier is present in each VLAN where multicast is used.
The IGMP Querier is the component that periodically polls the network to maintain group memberships. Without it, switches may not forward multicast traffic, even if snooping is enabled, leading to symptoms like intermittent stream loss or sources not appearing on receivers.
Not all switches handle IGMP the same way: some require the querier role to be manually enabled or assigned to a specific device (often the gateway). In contrast, others assign it automatically based on priority.
The takeaway:
IGMP is essential when using multicast with NDI, but it must be implemented correctly. Both IGMP snooping and a properly configured IGMP Querier are required for reliable multicast distribution. And as networks grow in complexity, managing multicast across multiple switches and subnets becomes a challenge that demands careful planning and testing.
Multicasting Between Subnets
As NDI systems grow, it’s common to distribute sources across multiple subnets, for example, in large production facilities, corporate campuses, or multi-building venues. While unicast NDI streams can be routed manually between subnets, multicast traffic does not cross subnet boundaries by default. This is because routers block multicast unless they’re specifically configured to support it.
The network must support multicast routing to make multicast work across subnets. This requires technologies such as PIM (Protocol Independent Multicast) and a proper understanding of how IGMP works at the subnet level. These protocols allow multicast streams to be delivered only where needed, avoiding unnecessary network load.
However, configuring multicast across multiple routers and VLANs is a complex task. It often involves setting up features like IGMP snooping, IGMP queriers, and designating a Rendezvous Point (RP) for multicast coordination.
In this module, we’re introducing these concepts to help you understand what’s involved. But in practice, designing and maintaining a robust multicast infrastructure at this scale should be done with the support of qualified network professionals experienced in multicast routing and IP video workflows.
Allowing NDI Receivers to Join Multicast from Other Subnets
By default, an NDI receiver will only negotiate a multicast stream from a sender in the same local subnet. This is a smart safeguard—it prevents the system from requesting multicast that could never actually reach the receiver.
However, if your network is correctly configured and can route multicast traffic across subnets reliably, you can allow an NDI receiver to join multicast groups from other networks.
This is done through the NDI configuration file, by explicitly listing the allowed subnets:
"multicast": {
"recv": {
"enable": true,
"subnets": [ "10.28.5.0/24", "10.28.4.0/24" ]
}
}
This tells the NDI receiver:
"Yes, it’s OK to request multicast from these networks, because we know the infrastructure is set up to handle it."
This feature is particularly useful in large or segmented NDI deployments, but it should only be used when the underlying multicast routing protocols (such as PIM and IGMP Querier) are correctly configured.
⚠️ Important Note
NDI receivers cannot guess whether multicast traffic will successfully cross subnet boundaries. This behavior must be explicitly configured via the NDI config file, and it only works if the network is fully multicast-aware and properly routed.
IGMP and PIM – Working Together in Multicast Networks
A common misconception is that IGMP and PIM are alternatives. In reality, they serve different purposes and often work together in multicast-enabled NDI networks.
IGMP (Internet Group Management Protocol) operates within a subnet or VLAN. It allows receivers (like NDI monitors or switchers) to signal interest in a multicast stream and enables switches to forward that stream only to ports that request it.
PIM (Protocol Independent Multicast) routes multicast traffic between subnets across routers. It ensures that multicast streams can reach receivers located in different parts of the network.
In practice:
Enabling IGMP snooping and ensuring the presence of an IGMP querier is usually sufficient in small or single-subnet networks.
PIM Sparse Mode is required to maintain efficient and reliable multicast routing in larger or segmented networks, especially where NDI sources and receivers span multiple VLANs or routed subnets.
Understanding how IGMP and PIM interact helps design a scalable infrastructure where multicast streams reach only the intended recipients, locally and across the wider network.
Summary & Key Takeaways
Configuring NDI for multicast is a powerful way to scale video-over-IP workflows in large or demanding environments. While NDI works out of the box using unicast, multicast becomes essential when a single source must be viewed by many receivers simultaneously, without overloading the sender or saturating network links.
We’ve seen that enabling multicast in NDI is not automatic: it requires a properly configured network infrastructure, including switch-level IGMP snooping and an IGMP querier. These components ensure multicast traffic is delivered only where needed, preventing flooding and preserving network performance.
For deployments that span multiple subnets, multicast traffic requires the implementation of multicast routing protocols like PIM Sparse Mode.
These advanced configurations allow multicast streams to traverse routers, reaching receivers across VLANs and network segments, but must be handled carefully by qualified network professionals.
