Dante Multicast Bandwidth: Measure, Control, and Verify Traffic

TL;DR — Dante multicast bandwidth must be evaluated on every link it crosses, not only at the transmitting device. Inventory multicast flows and listeners, read primary and secondary Tx/Rx bandwidth in Dante Controller, then trace switch uplinks, trunks, slower ports, and wireless boundaries. Correctly designed IGMP snooping can prune media from ports without listeners; otherwise assume multicast may flood broadly. Remove unnecessary flows, narrow the path, and verify real audio, clock, discovery, and failover after each change.

Multicast changes where traffic travels

A Dante multicast flow sends one media stream that multiple receivers can join. It can reduce transmitter flow use for a high-fanout source, but it may consume bandwidth on many network links. Without correctly working multicast control, assume the traffic can flood through the broadcast domain rather than traveling only to subscribed receivers.

That makes multicast bandwidth a path problem. A transmitter's total does not tell you whether a 100 Mbps edge, an inter-switch trunk, a secondary network, or a Wi-Fi uplink is overloaded.

The Dante unicast versus multicast guide explains when the flow types fit. This article owns the next question: whether the chosen multicast traffic fits and behaves correctly on the real network.

Do not use one universal bandwidth number

The bandwidth of a flow depends on its media format, sample rate, channel count, packetization, and implementation. Video can change the scale dramatically. Network links also carry control, clock, management, and other application traffic, so a link should not be designed to run at its theoretical line rate.

Use measured Controller values and the current device documentation instead of a remembered “megabits per channel” shortcut. Treat measurements as observations of the present route, not guarantees for a later show with more flows or listeners.

Read Dante Controller's bandwidth evidence

Network Status shows approximate transmit and receive traffic for individual primary and secondary interfaces. Sort or scan the Primary Tx, Primary Rx, Secondary Tx, and Secondary Rx bandwidth columns to find the largest endpoints and unexpected traffic.

Interpret the columns with topology:

• high transmitter bandwidth may be expected for a source creating several flows;
• high receive bandwidth on a device with few subscriptions can suggest flooded multicast;
• secondary traffic must be evaluated on the physically separate secondary path in a redundant design;
• low endpoint values do not prove that a shared uplink has spare capacity;
• current traffic does not reveal packet drops by itself, so compare switch and device errors.

The Dante network health guide covers the broader relationship among utilization, errors, latency, and clock history.

Build a link-by-link multicast budget

1. Inventory every multicast flow

Record transmitter, flow name, channels, media type, sample rate, intended receivers, primary or secondary network, and operational purpose. Remove abandoned test flows only after confirming that no production destination needs them.

2. Draw the physical path

Map the transmitter port, access switch, every uplink or trunk, receiver switch, and receiver port. Include control computers, wireless access points, routers, and any link whose speed differs from the rest of the path.

3. Record capacity and current load

Confirm negotiated link speed rather than assuming the port's advertised maximum. Capture device bandwidth, switch port utilization, discards, errors, and multicast counters during representative show conditions.

4. Add flows per link

For each link, total all traffic that actually crosses it, including multicast flows with listeners beyond that link and any flooded flows. Keep primary and secondary networks separate. Include non-Dante traffic when infrastructure is shared.

5. Reserve operating margin

Choose an engineering threshold that matches the equipment, traffic mix, burst behavior, and venue policy. There is no single safe utilization percentage for every network. The acceptance test is stable media, clock, control, and recovery under the expected worst case with documented margin.

Use IGMP snooping as a designed system

IGMP snooping allows a switch to observe multicast group membership and forward registered multicast media only toward ports that need it. Correct pruning can keep high-bandwidth media away from unrelated endpoints and Wi-Fi links.

It is not enough to tick one switch checkbox. The complete design may require an IGMP querier, consistent VLAN configuration, supported switch behavior, and correct settings across every switch carrying the multicast. Terms and defaults vary by vendor, so follow the switch and Dante design documentation.

After configuration, prove behavior with counters:

1. establish one known multicast source and receiver;
2. identify the exact ingress, uplink, receiver, and unrelated ports;
3. confirm traffic rises on the required path;
4. confirm unrelated ports are not carrying the media stream;
5. add or remove a listener and observe membership and forwarding change;
6. verify discovery, clock, control, and real media remain stable.

Do not block all multicast as a remedy. Dante discovery and control also use multicast mechanisms; an indiscriminate filter can make devices disappear while masking the original media-traffic problem.

Protect wireless control paths

Dante media should not be assumed to work like ordinary wired traffic over Wi-Fi. Multicast media that reaches an access-point uplink can degrade wireless control performance even when the computer is only running Dante Controller.

Keep media off the wireless branch through a verified design: correct IGMP pruning, an appropriate filtered control port where supported, or another manufacturer-approved boundary. Ensure the design still passes required discovery and control traffic. Test with the real access point and switch; wireless multicast behavior varies and has no universal safe traffic limit.

Reduce traffic at the narrowest cause

Do not convert everything to unicast without checking Dante flow limits. Moving traffic can solve one link problem while exhausting transmitter flows elsewhere.

Diagnose a multicast-bandwidth problem

1. Preserve the current route, topology, Controller views, and switch counters.
2. Identify the first affected receiver and the exact path back to its transmitter.
3. Check negotiated speed, utilization, discards, and errors on every link in order.
4. Compare intended listeners with observed multicast forwarding.
5. Temporarily remove or isolate one nonessential flow during a controlled window.
6. Confirm whether utilization, packet errors, latency warnings, control response, and audio improve together.
7. Apply the smallest permanent correction, then restore and test the complete show state.

Correlation matters. A high bandwidth value without errors may be normal; clicks or late packets with a clean endpoint total may originate on an oversubscribed uplink. Follow evidence instead of changing QoS, latency, and multicast simultaneously.

Verify redundancy and failure states

On a redundant Dante system, primary and secondary networks carry parallel responsibilities on separate infrastructure. Budget and inspect them independently. A healthy primary path does not prove the secondary path has correct speed, pruning, or capacity.

Run the approved failure test after the normal-state test. Confirm that a link or switch failure does not unexpectedly move unrelated traffic onto a constrained management path, and that media continuity, clock, control visibility, and recovery behave as designed. The Dante redundant versus switched guide explains the port-mode boundary.

Multicast-bandwidth checklist

• Every multicast flow has an owner, purpose, channels, and intended listeners.
• Physical paths, VLANs, trunks, Wi-Fi boundaries, and link speeds are mapped.
• Primary and secondary Tx/Rx bandwidth is captured in Dante Controller.
• Switch utilization, errors, discards, and multicast counters are recorded.
• IGMP snooping and querier behavior are verified across the whole path.
• Unrelated ports and wireless branches do not receive multicast media.
• Slow links and shared uplinks have documented worst-case margin.
• Flow-capacity consequences are checked before changing multicast to unicast.
• Real audio, clock, discovery, control, redundancy, and recovery pass.

FAQ

How much bandwidth does Dante multicast use?

There is no single value. It depends on media format, sample rate, channel count, packetization, and the number and location of flows. Measure the current endpoints and budget every network link they cross.

How do I check Dante bandwidth?

Use Network Status in Dante Controller for approximate primary and secondary interface Tx/Rx values, then correlate them with switch-port speed, utilization, discards, errors, and the physical topology.

Does Dante need IGMP snooping?

Small audio networks can operate without it, but multicast may flood broadly. Networks with meaningful multicast—especially video or wireless-control boundaries—need a deliberate, fully verified multicast design; follow current Audinate and switch-vendor guidance.

Why does Dante multicast affect Wi-Fi?

If multicast media reaches the access-point link, it can consume wireless airtime or degrade Controller connectivity. Prune media before the wireless branch while preserving required discovery and control traffic.

How do I reduce Dante multicast traffic?

Remove unused flows, use unicast where receiver count and transmitter capacity make sense, correct IGMP pruning, reduce or reroute the media load, and upgrade constrained links. Verify after each change.

Put the traffic plan in the rider

A green route matrix does not document network capacity. Keep the multicast-flow inventory, listener map, switch paths, link speeds, observed peak load, pruning evidence, change owner, and failure-test result in Techrider.live so invited collaborators can edit the same rider, save the approved plan, and inspect history before load-in.