Dante Network Health: Read Errors, Utilization, and Clock Logs

TL;DR — Dante network health is a pattern across link state, utilization, packet errors, latency statistics, and clock history—not a single green subscription icon. Establish a known-good baseline, inspect the affected device and its switch path, correlate counters with timestamps and show events, then change one boundary at a time. Treat persistent errors, unstable clock offset, late packets, or sustained high utilization as evidence to investigate before they become audible failures.

A healthy route needs more than a green check

A subscription can be established while the path has marginal cabling, a congested uplink, unstable clocking, or a configuration that fails only under full load. Dante Controller exposes several views that help separate endpoint, link, timing, and traffic problems.

Use these signals together. One old counter without a time correlation is weaker evidence than a counter rising during the exact dropout.

Build a monitoring workflow

1. Capture a known-good baseline

Before doors, build the complete routing state and run realistic audio. Record primary and secondary link speeds, normal Tx/Rx utilization, latency settings and statistics, current clock leader, follower sync state, and error counters. A baseline makes later change visible.

2. Start at the affected device

Open Device View and inspect Status for the source and destination. Confirm connected state, expected link speed, IP address, utilization, and error counts on the active interface. On redundant systems, inspect primary and secondary separately; do not average them into one conclusion.

A 100 Mbps link is not automatically faulty, but it has less capacity and may constrain latency choices. Compare it with the device specification and designed traffic load.

3. Follow the switch path

Check the endpoint port, intermediate trunks, and uplinks in order. Look for negotiated-speed changes, CRC or physical-layer errors, dropped packets, queue congestion, topology changes, and unexpected multicast propagation. A clean endpoint counter does not prove the uplink is clean.

The Dante network switch requirements guide covers switch selection, EEE, capacity, and acceptance testing.

4. Correlate latency evidence

Receiver latency is a buffer against network delay variation. In Dante Controller, inspect latency history and late-packet indicators for the affected receiver. Late packets suggest that packets arrived after the configured buffer deadline; simply increasing latency may hide a marginal path, so first check link speed, hops, utilization, QoS, and errors.

Use the Dante latency settings guide to distinguish a valid buffer change from a network fault.

5. Read clock history, not only current state

Clock Status Monitor records warnings, unlocks, relocks, mutes, and unmutes. Its frequency-offset history shows how hard a follower clock is working to track the leader. A stable current lock does not erase a previous unlock during the reported incident.

Distributed or rapidly changing offset can accompany overloaded links, problematic Energy Efficient Ethernet, or an inaccurate external clock source. Confirm the clock architecture with the Dante clock leader guide.

Interpret utilization with margin

Audinate's Controller guidance uses roughly 85% of link speed as an upper rule of thumb for Tx or Rx utilization to preserve clock performance. Treat that as a warning boundary, not a design target. Production networks need margin for control traffic, clocking, bursts, backups, and route changes.

Rx utilization may include multicast or broadcast traffic not destined for the device. Unexpected receive load can therefore reveal a multicast-pruning or VLAN problem even when that endpoint subscribes to few channels.

Diagnose by evidence pattern

Do not clear logs or reboot devices until evidence is captured. Restarting resets useful counters and can turn an intermittent fault into an undocumented story.

Run a controlled acceptance test

1. Load every show route and multicast flow.
2. Run representative audio and control traffic.
3. Observe endpoint and uplink utilization.
4. Confirm packet-error counters remain stable.
5. Review receiver latency statistics.
6. Exercise the approved primary or uplink failure.
7. Confirm clock, audio, control, and redundancy recover.
8. Save timestamps, screenshots of data views when appropriate for internal records, and the final baseline.

Public Learn content and riders should contain text evidence, not sensitive network screenshots. Keep detailed diagnostic exports in the production's controlled documentation.

Network-health checklist

• Full-show routing and traffic are active during the test.
• Primary and secondary interfaces are inspected separately.
• Expected link speed is confirmed end to end.
• Tx/Rx utilization has operational margin.
• Error counters are stable, not merely small.
• Receiver latency statistics show no late packets.
• Clock warnings, offset, mutes, and leader changes are reviewed.
• Failure, recovery, timestamps, owner, and baseline are recorded.

FAQ

How do I check Dante network health?

Inspect link state and speed, Tx/Rx utilization, error counters, receiver latency statistics, and Clock Status history. Compare them with a full-load known-good baseline and the switch path.

What do Dante packet errors mean?

They indicate packets or frames were not handled cleanly on an interface or path. Track whether the count increases during the fault, then inspect cabling, ports, optics, negotiation, congestion, and switch counters.

How much Dante network utilization is too high?

Controller guidance treats about 85% of link speed as an upper rule of thumb, but a production design should stay comfortably below that and preserve margin for clock, control, bursts, and failures.

How do I read the Dante clock status monitor?

Review time-stamped warnings, unlocks, relocks, mutes, and unmutes, then inspect follower frequency-offset history. Correlate the event time with traffic, link, and external-clock changes.

What should I record when troubleshooting Dante dropouts?

Record the exact time, affected route, device and interface, link speed, utilization, changing errors, latency evidence, clock events, switch path, recent changes, corrective action, and result.

Turn monitoring into a shared handoff

A baseline only helps when the next engineer can find it. Keep the approved link speeds, routing load, latency, clock owner, failure test, and escalation notes in Techrider.live with the current technical rider so collaborators can edit, save, and inspect history from one maintained source.