How do I troubleshoot an Enterprise Network for audio?
Shure Network Audio Devices have a number of specific requirements in order to operate correctly. This FAQ is intended to help Enterprise Network Administrators ensure that Shure devices will fully function on their networks.
Overview of Network Requirements and Assumptions for Network Audio Devices Network audio devices, such as Shure products with Dante, behave differently than other media-over-IP solutions such as IPTV, multicast video, and streaming audio. Because audio is sent in real-time, low latency and low jitter are required for solid and reliable performance. Additionally, multicast traffic is used for control traffic and clocking, and in some cases for audio data transport as well.
This guide walks through the various recommendations and requirements to make your network audio deployment successful.
Physical Layer and Network Topology
Generally, Shure devices expect to all be on the same VLAN and to be able to communicate between each other and management computers using multicast traffic. You will generally get the best performance if all devices are plugged into the same physical switch or switch stack.
If your device network/VLAN has segments which pass through a layer 3 router or a firewall, unexpected behaviour may result. If you run into issues, simplify your network to one switch and check for functionality, then slowly introduce more complexity.
We generally recommend that all switches be from the same manufacturer and the same line of products. Mixed-vendor networks can present problems. We do not recommend mixing "small-business" switches with enterprise-grade switches.
Shure devices expect all links within the network to be symmetric (in terms of bandwidth, transit time, and jitter). Normal copper and fiber Ethernet links are almost always fine. Technologies such as MPLS, Metro Ethernet, GPON, BPON, and MoCA may violate these assumptions. Traffic shaping should be disabled (see QoS below for more).
Ensure uplink ports are of sufficient bandwidth to carry all multicast media streams present on the network. On networks with video, this may mean using 10 Gbps+ links.
Be careful when configuring LAGs to ensure that all components of the lag have identical latency and performance.
Always use a cable certifier to ensure all cables are terminated correctly and will be error-free.
Most Shure devices support Gigabit networks, including all Dante-enabled devices. Some devices, such as chargers, are 10/100 Ethernet ("Fast Ethernet"). We highly recommend all devices be connected to Gigabit switchports regardless of device.
Device Addressing, Port Security, and Authentication
Shure Dante-enabled devices contain two Ethernet devices internally with separate MAC addresses, and require two IP addresses.
For Shure devices with a single Ethernet port, we require that both the Control and Network Audio interfaces be in the same VLAN and within the same subnet.
We do not support VLAN Tagging (802.1q) on any Shure products.
Products with Ultimo and UltimoX chipsets will not permit firmware updates if the two NICs are configured in different subnets.
For Shure devices with multiple network ports (excluding MXWANI), you may elect to separate the Shure Control and Dante traffic if you would prefer to do so. This is a configurable option on the device; see the User's Guide for more information.
Shure devices respond to DHCP out of the box and after factory reset, and will self-assign an IP address in the 169.254.0.0/16 range if no DHCP server is present. There is no hard-coded default address.
We recommend DHCP with address reservations for most users. Static address assignment is discouraged due to the potential for accidentally entering duplicate IP addresses.
If using switchport security on your switches, ensure that multiple MAC Addresses are permitted on a single switchport.
If you are using MAC address authentication with Cisco switches, you may need to configure your switch for authentication host-mode multi-host or multi-auth rather than multi-domain or single-host for Shure devices with two MAC addresses.
Some, but not all Shure devices support 802.1x authenticaion. Please consult the product documentation.
Shure devices will not register a hostname with the DHCP server (option 12) for the Shure Control interface. This is expected behavior. The Dante interface will register a hostname.
Shure devices don't require a DNS server to be configured.
Pro tip: Shure MAC Addresses generally begin with 00:0E:DD.
Shure devices use both Shure Discovery and Bonjour (mDNS) for discovery. Dante uses Bonjour (mDNS) exclusively.
Shure Discovery is on multicast address 239.255.254.253:8427.
Bonjour/mDNS is on multicast address 224.0.0.251:5353.
NOTE: Some switches have an mDNS Capture/Propagation feature, which when enabled can "capture" all mDNS traffic for the purpose of flooding it out. This feature generally needs to be disabled so that the switch does not attempt to block/capture the mDNS traffic. If devices do not appear in Dante Controller or Shure Web Device Discovery, this may be the reason.
Inter-device communication is via unicast UDP traffic, and on a randomly-assigned UDP port per device.
Shure Designer, Shure Update Utility, and Wireless Workbench permit management of devices across VLANs ("Remote Devices"). This allows you to manage and update an entire campus from one location. Communication is via unicast UDP, and we expect no packet filtering between VLANs. NAT is not supported due to the UDP sessions.
Updates can only be installed with Shure Update Utility or Shure Designer. There is no web page upload option. Download firmware through these programs.
Shure Update Utility needs to be bonded to a specific NIC on a computer, and must be allowed through the PC's Firewall.
Multicast Settings
Multicast is used for control traffic and audio clocking, even if multicast audio streams are not used.
Ensure IGMP Snooping is enabled on your switch for the VLAN with Shure devices. Enterprise networks should have IGMP enabled; running without IGMP snooping is only advised for small networks with a single switch and no AES67 or Dante multicast audio streams.
One switch must serve as the IGMP Querier. This is often automatically elected in homogeneous switch environments. The core switch is the preferred querier.
The Querier generally needs to have an IP address in the same Layer 3 subnet as the Shure devices. Some switches have workarounds for this requirement; contact your switch manufacturer for more details.
All other switches should see the switch with the querier as their mrouter, and the port headed to that switch as an mrouter port.
We recommend a querier interval of 30s or less to minimize long outages when the IGMP Snooping table must be rebuilt.
Verify that the following multicast groups are present in the multicast forwarding database and not blocked by any ACL:
Dante Control Traffic: 224.0.0.230-224.0.0.233 (Dante Cards and Dante Controller - may not be registered via IGMP; we expect these to flood the subnet)
Bonjour/mDNS: 224.0.0.251:5353 (Shure Web Device Discovery, Dante Controller - may not be registered via IGMP; we expect these to flood the subnet)
PTP Clock: 224.0.1.129:319-320 (Dante Cards - should register with IGMP)
Shure Discovery: 239.255.254.253:8427 (Shure Update Utility, Designer, SystemOn, Wireless Workbench - should register with IGMP)
SAP (AES67): 239.255.255.255:9875 (AES67 Announcements - should register with IMGP)
NOTE: We expect traffic in the 224.0.0.0/24 range to flood the VLAN. Some networks do not always flood this traffic, especially in environments where a L2 VLAN spans multiple switches connected via a router. You may need to make adjustments to your switch or router to ensure this traffic floods, including manually adding required groups to the multicast forwarding database.
Shure devices generally do not expect multicast to be routed across subnets. In networks where multicast is permitted to flow across VLANs, unexpected behaviour may occur. Contact Shure Applications Engineering if this is the case for your network.
If a device is not seeing some multicast traffic, check the switch to ensure that switchport is joined to the correct multicast groups.
In larger networks, where traffic must traverse a core switch from one edge switch to another, it may be necessary to enable PIM Sparse Mode on the core switch. Confer with your network engineering team before making this change.
Ensure Multicast Storm Control is disabled on switchports that Shure devices are connected to.
In some cases, customers may wish to block multicast traffic between switchports on the same VLAN. This is done sometimes when each room has its own small switch to create small multicast domains which do not flood the entire VLAN. In this case, you will not be able to remotely discover Shure devices from a central location. You will need to connect to the devices via IP Address from Designer, Shure Update Utility, or Wireless Workbench.
QoS Settings
Shure Network Audio devices assign DSCP values to traffic. You should configure your network to trust these values.
Here are the recommend settings:
DSCP 56 should be assigned to a dedicated queue with the highest priority on the network.
DSCP 46 should be assigned to a dedicated queue with the second highest priority on the network.
DSCP 34 should be assigned to a dedicated queue with the third highest priority on the network.
Ensure that trunk ports respect DSCP tags, even across VLANs. This is critical to ensure clock traffic timing is maintained.
IMPORTANT: Shure devices which support DDM and are running Dante firmware 4.x use different QOS settings for AES67 compared to devices running Dante firmware 3.x.
Dante 4.x: Clock is DSCP 46; Audio is DSCP 34 (matches AES67 standard).
Dante 3.x: Clock is DSCP 56, Audio is DSCP 46 (matches Audinate standard).
Clock Traffic (PTP)
Clock traffic is the most important network traffic exchanged by Shure Network Audio devices.
Clock traffic is in multicast group 224.0.1.129:319-320.
Review the QOS notes above. There are differences between Dante firmware versions used in Shure devices.
If multiple leader clocks are detected, this means that all devices are not seeing the PTP traffic, some packets are getting dropped, or that packets are being delayed excessively. Check multicast group membership for group 224.0.1.129 and check Multicast Storm Control. Ensure all devices appear fully in Dante Controller.
If excessive jitter is detected, this means that QOS is not configured correctly. Verify clock traffic is in a dedicated queue with the highest priority, including on trunk and LAG interfaces.
Ensure no devices are connected to an unmanaged switch which is connected to an enterprise switch. Some low-end switches employ low cost store-and-forward chipsets which are not compatible with network audio traffic.
If your switches support PTPv2 E2E Transparent Clock, we recommend enabling it. Note that this only affects AES67 clocking. Dante clocking with PTPv1 does not support Transparent Clocks.
Audio Traffic (RTP/RTSP)
Review the QOS notes above. There are differences between Dante firmware versions used in Shure devices.
If packets are lost or delayed, QOS may not be not configured correctly. Verify audio traffic is in a dedicated queue with the second highest priority, including on trunk and LAG interfaces. Also verify that there are no 100 Mbps switches or trunk ports on the network. Ensure uplinks are not saturated.
AES67 streams are announced via SAP on multicast group 239.255.255.255:9875 Verify all devices are subscribed to this group.
If devices cannot subscribe to Dante Multicast flows or AES67 flows, this means that all devices are not able to join the AES67 group. Check multicast group membership for that group. Recreating the AES67 flow in Dante Controller may help.
