Dante Network Switch Requirements: Choose and Verify the Path

TL;DR — Dante uses standard Ethernet, but a production switch must fit the real channel count, topology, traffic, and recovery plan. Prefer managed gigabit switches that expose link speed, bandwidth, and error counters; support DSCP QoS and required multicast controls; and let you disable Energy Efficient Ethernet on Dante ports. Verify every uplink and endpoint negotiation, then run clock, audio, load, multicast, and failure tests before approving the model and configuration.

Dante does not require a proprietary switch

A Dante network can run on standard Ethernet hardware. That does not make every consumer or enterprise switch equally suitable for a show.

The useful question is not “Does the box say Dante?” It is “Can this switch carry, prioritize, expose, and recover the planned traffic on every real link?”

Choose against the system design, not a brand list copied from another production.

Prefer gigabit links and verify negotiation

Gigabit Ethernet is the normal baseline for scalable Dante systems. Audinate permits 100 Mbps in limited, low-channel-count cases with proper QoS, but a slow endpoint or uplink changes the traffic and latency budget.

Count traffic per link, not just per switch. A rack may have gigabit access ports while two switches share one undersized uplink. A damaged cable can also make a gigabit-capable port negotiate at 100 Mbps.

Before the show:

1. List every endpoint, switch, and inter-switch link.
2. Record the negotiated speed and duplex state.
3. Estimate ordinary and peak media load in both directions.
4. Include multicast fanout and non-Dante services.
5. Leave operating margin instead of designing to the label maximum.
6. Recheck negotiation after repatching or replacing cables.

The Dante latency settings guide explains how switch hops and link speed affect receiver buffering.

Managed and unmanaged switches have different operational value

An unmanaged switch can work for a small, dedicated, simple Dante network when its fixed behavior is known and suitable. The limitation is not only configuration; it is visibility. The crew may be unable to inspect errors, speed, utilization, queue behavior, or multicast state.

A managed switch is preferred when the system needs any of the following:

• shared data, video, control, or other services;
• multiple switches or constrained uplinks;
• QoS configuration or verification;
• multicast snooping and querier control;
• VLANs or routed boundaries;
• redundant paths;
• port security, monitoring, logging, or remote support;
• a saved configuration that can be audited and restored.

Management also creates responsibility. A default or copied configuration is not automatically safe. Name the owner, restrict access, export the approved baseline, and document how to replace the switch.

Disable Energy Efficient Ethernet on Dante ports

Energy Efficient Ethernet, also called EEE, Green Ethernet, or IEEE 802.3az, lets a link enter a lower-power state during idle periods. Real-time clock and media traffic depend on predictable packet delivery, and unsuitable EEE behavior can contribute to synchronization problems or audio dropouts.

For a managed production switch, confirm that EEE can be disabled and verify its actual state on every port carrying Dante traffic. With an unmanaged switch, avoid models whose EEE behavior cannot be disabled or confidently verified.

Do not assume a global menu setting covers every port, module, or firmware release. Read the running configuration and retest after firmware or hardware changes.

QoS is a switch-path property

Dante endpoints mark traffic with DSCP values, but the switch must preserve or classify those markings and map them to appropriate queues. A “QoS enabled” checkbox does not prove that clock is highest, media is next, and ordinary traffic cannot starve the real-time queues.

Check:

• DSCP trust or classification at ingress;
• at least the required number of hardware queues;
• queue mapping for clock, media, control, and best effort;
• strict-priority behavior where the design calls for it;
• whether another policy rewrites markings;
• every switch along the path, not only the edge switch.

Use the Dante QoS settings guide for the complete configuration and stress-test workflow.

Multicast features must match the flow plan

Unicast is the ordinary Dante media behavior. When one transmitter feed is intentionally distributed to several receivers, multicast can reduce transmitter-flow use but also spread traffic across unnecessary ports without correct control.

A managed multicast design commonly requires IGMP snooping plus one correctly placed querier for the VLAN. Enabling snooping without a functioning querier can leave membership state unreliable. Built-in “IGMP optimization” on an unmanaged switch may be impossible to inspect or correct.

Document which flows are multicast, which switch owns the querier role, and which ports should receive each group. The Dante unicast versus multicast guide covers the decision and verification steps.

Build a topology that can be understood under pressure

Star connections to managed switches are often easier to inspect and isolate than long device chains. When dual-port Dante devices use switched mode, the second connector extends the same failure domain; it does not create redundancy.

For redundant mode:

• use genuinely separate primary and secondary networks;
• avoid shared switches, accidental bridges, and overlapping address scopes;
• match required link speeds on both sides;
• label every cable and switch port;
• test removal of one real component at a time.

The Dante redundant versus switched mode guide provides the port-mode checklist.

Test the switch instead of trusting the datasheet

1. Save a baseline

Export the running switch configuration. Record model, firmware, port map, VLANs, QoS, EEE, multicast settings, and management owner.

2. Verify idle health

With all planned endpoints online, confirm stable clocking, expected leaders, correct link speeds, clean error counters, subscriptions, and audio on every destination.

3. Apply realistic traffic

Run the planned channel count and multicast receivers. If the infrastructure is shared, add representative data or video traffic within the approved test window. Watch utilization, drops, queue counters, errors, and Dante latency events.

4. Exercise failure boundaries

Remove and restore one cable, endpoint, uplink, power feed, or redundant switch at a time. Confirm that the observed failure and recovery match the drawing.

5. Reboot and restore

Where operationally safe, verify that the switch returns with the approved configuration and that endpoints rediscover, resynchronize, and restore the intended subscriptions.

6. Record acceptance evidence

Save counter snapshots, test conditions, failures, corrective changes, final configuration, date, and approver. “Audio passed once” is not enough for a repeatable handoff.

Switch acceptance checklist

• Port count, PoE needs, optics, and physical format fit the deployment.
• Every endpoint and uplink negotiates the intended speed.
• Capacity covers media, multicast, control, and shared services with margin.
• DSCP QoS is mapped and verified on every required path.
• EEE is disabled on every port carrying Dante traffic.
• IGMP snooping and querier ownership are correct where multicast is used.
• VLAN and redundant-network boundaries match the drawing.
• Port errors, drops, utilization, and queue counters are observable.
• Running configuration, firmware, owner, spare, and rollback are documented.
• Full-load and component-failure tests pass with real audio.

Common mistakes

Buying only by port count. Link speed, queues, EEE control, multicast behavior, monitoring, and uplinks are part of the requirement.

Assuming gigabit removes the need for design. A gigabit link can still be congested, mis-prioritized, flooded, or negotiated at a lower speed.

Using an unmanaged EEE switch. If power-saving behavior cannot be disabled or verified, the crew cannot establish a known real-time baseline.

Enabling every advanced feature. Voice VLAN presets, spanning-tree changes, PTP features, storm control, and rate limits can alter traffic. Enable only what the approved design requires and test the effect.

Testing only discovery. Device names in Controller do not prove stable clock, adequate capacity, correct multicast scope, or audio recovery.

FAQ

Does Dante need a special network switch?

No proprietary switch is required. The switch must provide enough speed and capacity and must support the QoS, EEE, multicast, monitoring, and recovery needs of the specific Dante design.

Should a Dante switch be managed or unmanaged?

Managed is preferred for production, shared, multi-switch, multicast, or redundant systems because it provides configuration and visibility. A known suitable unmanaged switch may work for a small dedicated network.

Does Dante require a gigabit switch?

Gigabit is strongly recommended and essential for larger channel counts. Limited low-channel-count 100 Mbps operation may be possible with correct QoS, but every slow link must be included in capacity and latency planning.

Why should EEE be disabled for Dante?

EEE changes link power state during quiet periods. On unsuitable hardware that behavior can impair clock synchronization and cause dropouts, so Dante ports should use a verified non-EEE configuration.

How do you test a switch for Dante audio?

Verify link negotiation and configuration, run the complete media load plus representative shared traffic, inspect errors, drops and queues, listen to every destination, and exercise cable, uplink, switch, and power failures with a documented rollback.

Put the approved switch path in the Rider

Record switch models, ports, link speeds, VLANs, QoS, EEE state, multicast ownership, redundant paths, management owner, and tested rollback with the audio-network handoff. In Techrider.live, keep it in the same Rider as the patch and stage plan, invite the system technician to edit it, then save and inspect history before sending the current version.