Dante Routing Across Subnets: Domains, Clocks, and Verification

TL;DR — Dante can route media across IP subnets when the devices belong to the same managed domain and the routed network supports the required control, media, and clock paths. Plan addressing, routing, discovery or enrollment, firewall rules, and a boundary clock for every subnet. Then verify login, device visibility, name-based subscriptions, clock lock, real audio, and failure recovery. Do not treat basic IP reachability as proof that a cross-subnet production path is ready.

Cross-subnet Dante is a managed architecture

A conventional unmanaged Dante network is normally discovered and clocked inside one IP subnet. A managed platform such as Dante Domain Manager (DDM) can place devices from multiple subnets into one logical Dante domain. Devices in that domain can use name-based routing across the routed boundaries while remaining synchronized to one domain clock.

The domain is the operational boundary. Devices in different domains do not interact merely because a router can pass packets between their addresses. A device can be enrolled in only one domain at a time, while an authorized user may have access to several domains.

The Dante device discovery guide owns same-network visibility and local troubleshooting. This guide owns the additional routed-domain design required when a production path crosses subnets.

Define the domain before configuring routes

Group devices by the production and control boundary that should share media and clock. A domain may represent a room, studio, building, system, or another deliberate operational unit. Do not create one large domain solely because every VLAN is reachable.

For each proposed source and destination, record:

• device name, manufacturer, model, firmware, and physical location;
• primary and secondary IP address, subnet, gateway, and switch port;
• intended domain and responsible operator;
• required transmit and receive channels;
• media format, sample rate, receiver latency, and redundancy mode;
• maintenance, failure, and rollback ownership.

Keep primary and secondary networks separate when using Dante redundancy. Cross-subnet routing does not convert a switched-mode design into a redundant one, and a secondary-only device may not remain manageable through every platform.

Build the routed foundation

1. Make addressing intentional

Use an address plan that identifies each Dante subnet and its router interface. Confirm the correct subnet mask and default gateway on every endpoint. Link-local addressing is useful inside a single local segment but is not a substitute for a routed multi-subnet plan.

The Dante IP addressing guide explains DHCP, link-local, and static recovery. For a managed multi-subnet design, DNS and DHCP are commonly used to provide addresses and service discovery. Static enrollment by device IP can serve controlled networks that cannot provide those services.

2. Provide manager discovery or explicit enrollment

Controllers and devices must locate the management service before domain access can work. On a single subnet, mDNS-based discovery may be sufficient. Across subnets, use the product's documented DNS service records and DHCP configuration, or an approved static enrollment workflow.

Do not route all multicast between VLANs as a discovery shortcut. It widens the failure and security boundary and still does not prove that domain enrollment, permissions, clocking, or media are correct.

3. Permit only the required traffic

Confirm routed reachability and firewall policy from the current DDM or managed-platform documentation. Record the exact source, destination, protocol, and port scope used by the design. A ping proves only one narrow ICMP path; it does not validate authentication, discovery, control, clock, or media.

4. Enroll and identify every device

Enroll devices into the intended domain, then verify their identity by physical location, MAC address, model, and channel labels. A familiar display name is not enough. Devices retain domain credentials across a power cycle, so stale enrollment can make a device appear unavailable or restricted on a different system.

Clock every subnet as one domain

All devices in a Dante domain must ultimately follow one domain grand leader. Inside a subnet, Dante can distribute clock with multicast PTP. Across routed subnet boundaries, DDM uses suitable boundary clocks to carry clock between subnets with unicast PTP, then distribute it locally.

Each subnet needs an eligible active boundary clock. Configure a secondary candidate where the platform and device mix support it. Choose devices that are stable, appropriately capable, and unlikely to be powered down or removed during production.

The Dante clock leader guide covers leader election inside a production system. Cross-subnet acceptance must additionally prove the boundary-clock chain and its backup behavior.

Create and verify the subscription

1. Log in with an account authorized for the target domain.
2. Select the correct domain in Dante Controller.
3. Confirm both source and destination identities, formats, and clock state.
4. Create the intended name-based subscription.
5. Wait for a stable success state; inspect any warning or error instead of recreating the route blindly.
6. Pass representative audio and listen at every required destination.
7. Confirm receiver latency, clock lock, packet-error state, and switch counters.
8. Repeat at expected peak load and test the approved failure and restore sequence.

A visible endpoint is not the same as a usable route. The account may be read-only, the devices may be in different domains, the receiver may have an incompatible format, or the clock path may not be ready. Use the Dante subscription errors guide to interpret the route state before changing infrastructure.

Test failure boundaries deliberately

Cross-subnet systems add routers, firewalls, manager services, DNS/DHCP, and boundary clocks to the dependency chain. Test only inside an approved maintenance window and change one boundary at a time.

• Disconnect the active boundary-clock device and confirm the expected backup takes over.
• Interrupt one routed link and capture which subscriptions, controls, and clocks are affected.
• Restart a representative endpoint and verify automatic domain reconnection.
• Confirm authorized Controller login and domain selection after a workstation restart.
• Exercise primary and secondary paths independently in a redundant design.
• Restore the normal state and verify real audio, not only green indicators.

Preserve logs and timestamps before rebooting or clearing alerts. The Dante network health guide explains how to correlate link, clock, latency, and error evidence.

Cross-subnet acceptance checklist

• Domain scope and device ownership are documented.
• Every endpoint has the intended address, mask, gateway, subnet, and switch port.
• Discovery or static enrollment is proven across every subnet.
• Firewall rules follow current platform documentation and least-required scope.
• Source and destination are enrolled in the same intended domain.
• Each subnet has an eligible active boundary clock and tested backup where possible.
• Formats, sample rate, latency, names, and redundancy mode match the design.
• Every subscription passes real audio at representative peak load.
• Routed-link, clock, endpoint-restart, and restore behavior are recorded.
• Owner, escalation, maintenance window, spare path, and rollback are clear.

FAQ

Can Dante route across subnets?

Yes. A managed Dante domain can include devices on multiple IP subnets and support name-based media routing across routed boundaries when connectivity, enrollment, permissions, and clocking are correctly designed.

Does Dante need Domain Manager for multiple subnets?

Conventional unmanaged Dante discovery and clocking are designed around a local subnet. Use a supported managed platform such as DDM for an intentional multi-subnet domain rather than extending local multicast behavior as an improvised workaround.

How does Dante clocking work across subnets?

The domain follows one grand leader. A suitable boundary clock in each subnet carries clock between subnets with unicast PTP and distributes it locally. Each subnet needs an eligible active clock and should have a tested backup where possible.

Why can I see a Dante device but not route to it?

Visibility does not prove authorization or compatibility. Check the selected domain, account role, device enrollment, source and receiver format, clock state, route status, and whether both devices belong to the same domain.

How do I test Dante audio across subnets?

Create the approved subscription, pass real audio, inspect clock, latency, errors, and switch counters, then test peak load and one failure boundary at a time. Verify recovery and the restored audio path before acceptance.

Put the routed design in the production handoff

Document domains, subnets, gateways, discovery method, firewall owner, boundary clocks, subscriptions, formats, failure tests, and rollback in Techrider.live. Invite the responsible engineers to edit the same rider, save the accepted design, and inspect history before the system changes.