Plan mDNS Discovery Across AV VLANs

mDNS is designed for local link discovery, so a service found beside a projector may disappear when an operator tablet moves to another VLAN. Use an approved, service aware discovery gateway if cross VLAN discovery is required, and separately allow the actual service connection. Seeing a device name is not proof that its advertised address and port are reachable.

Confirm that the missing feature uses mDNS

Do not assume every automatic device list is mDNS. Capture one search and look for the actual query names, transport and destination. Record the service type and the response records associated with the target. A product may combine mDNS with proprietary broadcast discovery, so identify the failing mechanism before requesting a gateway change.

RFC 6762 defines Multicast DNS, including its local link operation. RFC 6763 describes DNS based service discovery records. Together they explain why service discovery is more than forwarding a friendly name: the client needs the advertised target, port and address information to be useful.

Build an explicit discovery policy

Ask which operator groups need to find which endpoint services. A venue may permit tablets to discover one presentation service while withholding printers, engineering tools and management consoles. Keep those decisions in the network policy rather than making every service visible across all VLANs.

The policy should name source VLANs, destination VLANs, allowed service types and the administrator who maintains it. Record whether the gateway reflects packets, proxies records or provides another vendor specific mechanism; these are not necessarily equivalent.

Commission discovery and operation independently

• Place a test tablet and endpoint on the same approved link and save a successful reference exchange.

• Move the tablet to its intended production VLAN while keeping the endpoint unchanged.

• Enable the supported gateway policy with the network owner's approval.

• Inspect the records received by the tablet and note the actual target address and port.

• Test that service through the normal client application.

• Repeat from a network that should not see the service.

If a tablet sees an address from an unreachable interface, broadening every ACL is not the first remedy. Review the endpoint's interface advertisements, the gateway's filtering capabilities and the supported topology. Do not manually forge records unless the vendor supports that deployment and the records can be maintained reliably.

Test cache and recovery behavior

Restart the endpoint, change its approved address in a maintenance test, and observe how the tablet updates its service list. Use actual record lifetimes and application behavior to choose an observation interval. A cached entry can make a broken discovery path appear functional until the cache expires.

Also restart the discovery gateway and verify the expected recovery process. If the application supports a manual destination, document it as a fallback only after testing it with the installed release. This guide does not assert that SoftControl provides mDNS browsing or any particular gateway integration.

Accept the design when authorized tablets find the intended service, connect to its advertised endpoint and recover after changes, while unauthorized networks do not receive the advertisement. Keep a small capture and the gateway policy with the handover.

The Android tablet control article covers the operator perspective. Use AV control VLAN design to document the separate discovery and application flows.