Understanding Multi-Switch Bandwidth Considerations
In a single-switch NDI deployment, bandwidth is relatively easy to manage: all devices communicate within the same switching fabric, and traffic remains internal. But as soon as the infrastructure grows and multiple switches are connected, inter-switch bandwidth becomes a critical factor.
When NDI streams need to travel across switches, especially from sources connected on one switch to receivers on another, the uplinks between switches carry that traffic.
If not properly dimensioned, these uplinks can quickly become saturated, leading to visible issues such as frame drops, stuttering video, or increased latency.
To avoid these problems, it's essential to approach multi-switch network design with the following strategies:
1. Assess Bandwidth Requirements Accurately.
Each NDI stream has a predictable bandwidth footprint
Full HD (1920x1080@60p): ~125 Mbps
4K: ~250–300 Mbps (depending on frame rate and format)
Multiply by the number of simultaneous streams traversing a link to understand the worst-case uplink load.
2. Use High-Capacity Uplinks and Link Aggregation (LACP).
Even a handful of Full HD NDI streams can saturate if two switches are connected with a single 1GbE link. Whenever possible, use 10GbE, 25GbE, or higher-capacity uplinks, such as 40GbE or even 100GbE, which are becoming more affordable. Implementing LACP (Link Aggregation Control Protocol) to bond multiple physical links further increases available bandwidth and adds redundancy in case of failure.
3. Implement VLANs for Logical Separation.
While VLANs don't directly reduce bandwidth usage, they help isolate traffic types, keeping NDI streams separate from management, control, or internet-bound traffic. This avoids unintended congestion and improves monitoring and troubleshooting.
With careful planning, including correct uplink sizing, logical segmentation via VLANs, and link aggregation, multi-switch NDI unicast networks can scale reliably, maintaining performance and stream integrity even in demanding environments.
Subnet Basics and Their Role in NDI
Until now, we’ve considered NDI operating within a single subnet, a flat Layer 2 network where devices can discover each other automatically using mDNS and broadcast-based mechanisms. But as deployments scale, dividing networks into multiple subnets is common to improve manageability, performance, and security.
However, by default, NDI discovery mechanisms like mDNS do not work across subnet boundaries. This means that a source in one subnet is not automatically visible to receivers in another, unless specific solutions are implemented.
Here are the primary options for enabling NDI across subnet boundaries:
1. NDI Discovery Server (Recommended)
The most robust and scalable method is to deploy the NDI Discovery Server. This replaces mDNS with a unicast-based registration system: all NDI devices (both senders and receivers) are configured to communicate with the Discovery Server. This allows devices across multiple subnets, or even routed networks, to discover each other reliably, without relying on multicast.
2. Manual Configuration via NDI Access Manager
In scenarios where a Discovery Server is unavailable, NDI Access Manager allows you to specify the IP addresses or hostnames of NDI sources manually. This method bypasses automatic discovery but requires precise planning and static IP management. It’s best suited for fixed installations with known devices.
3. Multicast Routing (Advanced)
The network must support multicast routing through protocols such as PIM Sparse Mode if multicast streaming is used across subnets. This allows NDI streams to reach receivers across routed segments, but does not solve discovery. Multicast routing is only part of the picture; it must be combined with manual configuration or a Discovery Server.
Choosing the right approach depends on your network topology, the scale of the deployment, and whether multicast is being used for streaming. In all cases, reliable NDI operation across subnets requires thoughtful planning and coordination with network infrastructure.
Comparing NDI with Dante for Multi-Subnet Deployments
NDI and Dante are two of the most widely adopted AV-over-IP protocols, each optimized for different use cases. Understanding their core differences in terms of transport, discovery, synchronization, and network requirements is essential when designing reliable and scalable systems, especially in multi-subnet environments.
Dante, explicitly developed for real-time audio, uses unicast transport by default. Multicast is supported for specific cases but must be explicitly enabled. Its low bitrate and deterministic behavior make it ideal for large-scale audio routing.
NDI, designed for high-quality video transport, also uses unicast by default, with multicast available starting from NDI 3 for high-density distribution scenarios. Unicast provides flexibility but requires careful bandwidth planning in larger deployments.
Dante devices rely on Dante Controller for centralized management. Discovery and synchronization require all devices to reside in the same Layer 2 domain, unless Dante Domain Manager (DDM) is used, a licensed, paid solution that enables secure cross-subnet operation, device authentication, and advanced policy control.
NDI uses mDNS by default for local discovery within a subnet.
While mDNS is suitable for small, flat networks, it has limitations, such as poor scalability, reliance on multicast, and incompatibility with routed environments. For this reason, the NDI Discovery Server is the recommended solution for all but the simplest deployments. It replaces multicast-based discovery with a reliable, unicast-based registration system that ensures consistent visibility of NDI sources across subnets and complex topologies.
Alternatively, NDI Access Manager can define static source IPs manually, but this requires careful planning and is less scalable than a Discovery Server.
Dante relies heavily on PTP (Precision Time Protocol) for clock synchronization across all devices. Accurate and consistent PTP distribution is critical for phase-accurate, low-latency audio transmission. Any disruption to PTP, such as jitter, loss, or asymmetric delay, can compromise the entire audio network.
NDI does not use any synchronization protocol like PTP. Each stream is self-contained, and synchronization is managed at the receiver level. While this makes NDI more flexible and resilient to timing inconsistencies, it also means that precise inter-device sync is not guaranteed.
⚠️ Important Note: In shared network environments, high-bandwidth NDI traffic can interfere with Dante’s PTP timing messages, especially if the two systems operate on the same VLAN or if network switches do not prioritize control of traffic correctly. For this reason, it is strongly recommended that Dante and NDI be isolated into separate VLANs or physical network segments to ensure the stability of both ecosystems.
When deploying both Dante and NDI in the same facility:
Use separate VLANs or dedicated switches to avoid traffic interference.
Ensure multicast and PTP settings are carefully controlled for Dante.
Avoid deploying NDI multicast on switches also carrying Dante traffic.
Monitor network utilization and latency to preserve audio timing integrity.
By understanding and respecting the distinct requirements of NDI and Dante, particularly regarding synchronization and traffic isolation, you can build high-performance AV networks where both protocols coexist without compromise.
NDI and Layer 3 Networking
Although NDI is designed primarily for Layer 2 (local subnet) environments, it can operate across Layer 3 networks, as long as the proper discovery mechanism is in place. By default, NDI uses mDNS, which relies on multicast and is limited to a single broadcast domain. This means that NDI sources and receivers on different subnets will not automatically discover each other.
The recommended approach is to use the NDI Discovery Server to enable reliable operation across routed networks (Layer 3). This replaces mDNS with a unicast-based discovery model, allowing devices to register and discover each other across subnets without requiring multicast routing.
Unlike other AV-over-IP systems, NDI does not require additional clock synchronization or domain management services at Layer 3. However, administrators must ensure that:
•The Discovery Server is reachable by all NDI devices over IP
•Routing between subnets is properly configured
•Firewall rules allow communication on the necessary NDI ports
These measures enable NDI to scale effectively across complex Layer 3 infrastructures, providing flexibility without centralized licensing or time-sensitive protocols.
