Why NDI Sources Vanish When You Move to a New VLAN: A Discovery and mDNS Audit for Conference Networks

The source list is empty. The encoder is running, the sender machine is powered, the switch port light is green, and the operator who moved that machine to the new show VLAN an hour ago is now staring at a receiver that insists nothing exists. The instinct is to blame the video path. Most of the time the video path is fine. What broke is the browse step.

This is a discovery-plane failure, and it is worth treating as a separate ticket from a transport failure. A receiver that cannot see a source and a receiver that can see a source but cannot connect to it are two different problems with two different fixes. Conflating them is how a 20-minute VLAN correction turns into a two-hour load-in.

What the VLAN boundary actually removes

Multicast DNS is the default discovery mechanism for NDI on a flat network. The mechanism is specified in RFC 6762, which states that any DNS query for a name ending in .local must be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB). The same document defines .local names as link-local: names within that domain are meaningful only on the link where they originate. mDNS exists to provide DNS-like operations on the local link in the absence of a conventional unicast DNS server.

Read those two sentences together and the failure mode is not mysterious. A VLAN boundary is a link boundary. When you move a sender to a new VLAN, you have not necessarily changed whether its stream can be reached from the receiver’s subnet. You have changed whether the receiver’s mDNS query and the sender’s mDNS announcement share a broadcast domain. The browse step dies at the boundary; the stream may still be routable.

This is not a misconfiguration unique to your switch. Dell’s knowledge base describes Bonjour — the Apple trade name for the same zero-configuration stack — as designed for flat, single-subnet IP networks, and states plainly that Dell Networking switches do not support routing Bonjour across multiple VLANs. The same article notes that some switches support multicast routing but that Bonjour is incompatible with RFC-compliant multicast routing on those platforms. In other words, the behavior you are seeing is the documented architectural limit of the protocol, not a bug you can configure your way out of on every platform.

Separate the two planes before you touch anything

The first diagnostic question is not “why did discovery break” but “did discovery break, or did transport break, or both.” You can answer it in about five minutes per segment if you have a receiver and a source you can reach by direct address.

On the receiver, check whether the source appears in the source list at all. If it does not, note that. Then attempt a direct connection to the same source by IP address or by whatever manual-add mechanism your receiver supports. If the direct connection succeeds while the browse list is empty, you have isolated a discovery failure. If the direct connection also fails, you have a transport or firewall problem and the discovery audit is not your first priority.

NDI’s own switch-settings documentation draws the same line from the other side. It states that mDNS/Bonjour must be accessible for automatic discovery of NDI devices, and separately that manual discovery requires access to port 5960 for the NDI messaging server, with subsequent ports starting at 5961 for NDI video streams. Those are two different access requirements for two different planes. A firewall rule that permits 5960 and 5961 but drops UDP 5353 will give you a working manual connection and an empty browse list — which is exactly the confusing half-state that sends operators down the wrong path.

Audit step 1: map the discovery plane

Before load-in, list every device that must discover every other device, and record which VLAN each one sits on. The pairs that matter are not just sender-to-receiver. They include control laptops running monitoring or switching software, any machine acting as a receiver for confidence monitoring, and any device that needs to appear in someone else’s source list. For each pair, mark whether the two devices previously shared a broadcast domain and whether they will after the change.

This is a process recommendation, not a product claim. The point is to make the discovery topology explicit before the change, because the gap between intended configuration and observed behavior is where the post-mortem lives. A pair that was never on the same link was never discoverable by mDNS, and no amount of switch configuration will make it so without a gateway or a discovery service.

Audit step 2: capture before and after

On each segment, record two observations: whether mDNS traffic is present on that segment, and whether the source list populates. A packet capture filtered to UDP port 5353 on the receiver’s segment will tell you whether queries are leaving the receiver and whether any responses are arriving. If queries leave and nothing returns, the responder is on the other side of a boundary or is being filtered. If no queries leave, the receiver is not attempting mDNS discovery at all — which points at configuration, not at the network.

Record which specific sources are missing, not just a count. A source list that is short by one is a different problem from a source list that is empty, and the difference often identifies a single device that was left on the old VLAN or that has a second network interface selected.

Audit step 3: check the switch and firewall layer

Here the vendor guidance genuinely conflicts, and you should not resolve the conflict by picking the more authoritative-sounding document. Dell’s article recommends disabling IGMP snooping because snooping can lead to dropped link-local multicast traffic. NDI’s switch-settings documentation recommends enabling IGMP snooping if using multicast, and configuring an IGMP querier and query interval for each switch in multi-switch networks when using multicast. Both statements are about multicast handling; they are not obviously about the same traffic class, and neither document reconciles them.

The practical resolution is to test on the actual switch model with the actual traffic before doors open. Change one setting at a time, capture the source-list result, and record the setting you changed so you can put it back. A conference network is not the place to adopt a global multicast policy on the strength of a documentation page.

Also confirm that no firewall or ACL is dropping UDP 5353 between segments. If your platform implements an mDNS gateway or reflector, that is a deliberate feature you can enable for specific subnets; Cato Networks’ documentation describes exactly this pattern, where a host in one VLAN cannot reach a service in another without the gateway function enabled, and recommends enabling mDNS only for the subnets that require it because multicast traffic is noisy and considered not secure. That last point matters for a conference network: bridging discovery across every VLAN is a larger blast radius than bridging it across the two VLANs that actually need to see each other.

The decision fork: bridge, centralize, or flatten

Once you have confirmed that discovery is the broken plane, you have three reversible options. They differ in blast radius and in what fails when they fail.

Option A: bridge or gateway mDNS across the boundary

Where your platform supports an mDNS gateway or reflector, enable it for the specific VLAN pairs that need discovery and no others. This preserves zero-configuration behavior on the endpoints and requires no change to sender or receiver settings. The cost is that it is platform-specific: Dell’s article states that custom mDNS bridging is not a feature of Dell Networking switches and that such workarounds break RFC compliance. So this option is available on some platforms and not others, and you should confirm support on your exact model before you plan around it.

Option B: deploy an NDI Discovery Server

NDI documents a Discovery Service as an alternative to mDNS that reduces network traffic compared to the latter. It runs as a standalone application or a system service, and it can be bound to a specific network interface with a command-line option such as -bind 192.168.1.100, which matters on a machine with more than one NIC. The documented default port is 5959, and the -port option allows a non-default port or multiple discovery servers for different groups of sources on the same machine.

The behavior change is the important part for planning. NDI’s documentation states that for source senders, if a discovery server is specified, the mDNS mechanism will not be used, and those sources will only be visible to other finders and receivers that are configured to use the discovery server. It also states that when a discovery server is present, the SDK will use both mDNS and the discovery server to locate sources on the local network that are not on machines configured to use discovery. That combination is powerful and easy to misconfigure: a sender pointed at the server disappears from the mDNS view, so any receiver still relying on mDNS will lose it. Roll this out to both sides of every pair, or expect a new and more confusing version of the same symptom.

The discovery server also introduces a component whose failure you must plan for. NDI’s documentation notes that receiver listeners currently rely on the implementer to detect when the server is no longer operational and then connect to an alternative redundant server. That is not automatic failover you can assume; it is logic someone has to build or verify. If you deploy a single discovery server for a show, treat it as a single point of failure and have a documented manual fallback — direct IP connection, or a second server with the client configured to use it.

Option C: keep the show network flat

If the discovery topology is the risk, one legitimate answer is to keep all devices that must discover each other on the same VLAN and isolate only the traffic that does not need discovery. This is the least clever option and often the most reliable. The tradeoff is segmentation: you give up the isolation between, say, control laptops and media senders. Document that tradeoff explicitly so the next operator understands why the network is shaped the way it is.

Make every change reversible

Whatever you choose, record the pre-change discovery configuration per device: whether it was using mDNS, a discovery server address, or manual IP entry, and what the source list looked like before the change. A fix that works for one show’s topology may be wrong for the next room, and the ability to put a device back the way it was between sessions is worth more than an elegant configuration that nobody can undo at 7 a.m.

The handoff between rooms and between operators is where this discipline pays off. If your show also runs a hybrid component, the same separation of planes applies to the room-to-chat handoff, which is covered in Why Hybrid Events Fall Apart at the Room-to-Chat Handoff.

Frequently asked questions

If the source list is empty, is the video stream definitely broken?

No. Discovery and transport are separate. Test a direct connection to the source by IP address before concluding anything about the stream. If the direct connection works, the stream is reachable and only the browse step is failing.

Can I just route mDNS across VLANs with a multicast route?

Not reliably, and not on every platform. RFC 6762 defines .local names as link-local, and Dell’s documentation states that Bonjour is incompatible with RFC-compliant multicast routing on its switches. Where a vendor provides an mDNS gateway or reflector, that is a deliberate feature, not ordinary multicast routing.

Should I disable IGMP snooping to fix dropped discovery traffic?

That depends on your switch and your traffic. Dell recommends disabling snooping to avoid dropped link-local multicast; NDI recommends enabling it when using multicast and configuring a querier in multi-switch networks. Test both states on the actual hardware and record which one produces a populated source list.

Does pointing senders at a Discovery Server break mDNS discovery for everyone else?

It can. NDI’s documentation states that when a discovery server is specified for source senders, mDNS is not used and those sources are visible only to finders and receivers configured for that server. Configure both sides of every pair before you rely on it.

Copyable artifact: Discovery Audit Sheet

For the conference network lead. Fill one row per device before load-in, and update the observed columns after each change. Keep the rollback note current.

DISCOVERY AUDIT SHEET — [Show name] — [Date/time] — [Network lead]

Columns:
  VLAN | Device | Role (sender / receiver / control) |
  Discovery method (mDNS / Discovery Server IP:port / manual IP) |
  Must discover (list device names) |
  Pre-change source list observed (Y/N, which sources) |
  Post-change source list observed (Y/N, which sources) |
  Direct connection works (Y/N) |
  mDNS traffic seen on segment (Y/N, capture point) |
  IGMP snooping state | IGMP querier present (Y/N) |
  Rollback note (exact setting to restore)

Example row:
  VLAN 20 | Encoder-A | sender | mDNS | Receiver-1, Control-1 |
  Y (Encoder-A) | N | Y | N (capture on Receiver-1 segment) |
  Enabled | N | Restore mDNS; no server configured

Sign-off before doors:
  [ ] Every sender/receiver pair on the same link, or bridged, or on the same Discovery Server
  [ ] Direct-connection fallback tested for every critical source
  [ ] Discovery Server single point of failure documented, with manual fallback
  [ ] Every change recorded with its rollback setting

The sheet is deliberately about observed behavior, not intended configuration. The gap between the two is where the post-mortem lives, and it is the only part of the audit that will still be useful when the next VLAN move happens.