Skip to content

Dante & sACN on the Network

What Dante (audio-over-IP) and sACN (lighting control, ANSI E1.31) actually demand from the switching infrastructure, and which "safe-sounding" switch features can break them. This page is the reference; the switch-side mechanics live on the pages linked throughout.

What They Need From the Network

Dante sACN
Transport UDP — unicast and multicast; multicast for device discovery and PTP clocking, plus any flows explicitly set to multicast UDP multicast, one group per universe
Timing sensitivity Extreme — PTP clock sync underpins every audio channel; late/lost PTP causes clock drift and audible dropouts Moderate — lost frames show as stuttering or frozen fixtures, but there's no clock sync to break
Bandwidth ~6 Mbps per 4-channel flow at 48 kHz; predictable and steady Small (~1 Mbps per universe worst-case); scales with universe count

Both protocols assume a switched LAN that delivers multicast promptly and doesn't reorder or starve it. They do not need — or want — to be routed: keep each in its own VLAN island, per the routing model already used on this network.

Dante QoS Markings

Dante hardware marks its own traffic with DSCP values, per Audinate's documentation:

Traffic DSCP name DSCP value Priority need
PTP clock sync (time-critical) CS7 56 Absolute — this is the traffic QoS exists to protect
Audio EF 46 High
Everything else (control, discovery) BestEffort 0 Normal

Two consequences for the switch config on QoS:

  1. Trust DSCP on every port carrying Dante — Dante marks correctly on its own; the switch just has to not destroy the markings. See the warning on the QoS page: enabling mls qos without mls qos trust dscp rewrites everything to 0.
  2. PTP (DSCP 56) must land in the strict-priority queue. The 3560-family default queue maps send DSCP 40–47 (EF included) to the expedite queue but not DSCP 56 — on a congested Dante uplink, verify where CS7 lands (show mls qos maps dscp-output-q, privileged EXEC) and adjust the map if PTP isn't in the priority queue.

On a dedicated Dante VLAN with gigabit links and light contention, Dante generally runs fine with no QoS at all — Audinate recommends QoS for gigabit networks primarily when Dante shares links with other traffic. Configure it in advance, not on a live network (see the mls qos warning).

sACN Multicast

sACN sends each universe to its own multicast group: universe N maps to 239.255.<high byte of N>.<low byte of N> (universe 1 → 239.255.0.1, universe 256 → 239.255.1.0). Practical implications:

  • A console transmitting many universes generates many distinct multicast groups — the group count, not the bandwidth, is what stresses switch multicast handling
  • Receivers (nodes, fixtures) join only the universes they're patched for — if the switch constrains multicast properly (next section); otherwise every port gets every universe

Multicast Controls That Can Hurt

Caution — storm control: multicast storm control filters all multicast above the rising threshold once tripped, regardless of the action setting (action trap only adds a notification — it does not replace the filtering). A large universe count or several Dante flows can legitimately exceed a low threshold, and the result is silently dropped audio or lighting traffic. Don't enable multicast storm control on VLANs carrying Dante or sACN — or if policy requires it, set the threshold far above worst-case traffic load. See Security Hardening.

IGMP snooping is the feature doing useful work here: with snooping active (Catalyst default) plus an IGMP querier on the VLAN, the switch delivers each multicast group only to ports that joined it, instead of flooding every group out every port. On a VLAN with no router/SVI acting as querier, snooping has nothing to learn from and multicast floods anyway — check for a querier before assuming containment:

Cisco IOS — privileged EXEC:

! Confirm snooping is active and a querier exists on the VLAN
show ip igmp snooping vlan 30
! Which ports have joined which groups
show ip igmp snooping groups

Keep It Per-VLAN

Dante and sACN multicast should stay inside their own VLANs — this is containment working as designed, not a limitation. Routing multicast between VLANs needs PIM and buys nothing for this traffic; the pfSense routing model deliberately doesn't do it. If one console must reach both networks, give it a leg in each VLAN rather than routing the multicast.