Enterprise Network Troubleshooting ChecklistFAQ #5903
Question:Enterprise Network Troubleshooting Checklist
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.
Device Addressing and Authentication
- Many Shure devices contain two Ethernet devices internally with separate MAC addresses, and require two IP address.
- Allocate two IP addresses for each Shure device that requires it. Shure devices support both Static and DHCP addressing. We recommend DHCP with address reservations.
- For Shure devices with a single Ethernet port, ensure that both the Control and Network Audio addresses are within the same subnet.
- If using switchport security, 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.
- Shure devices do not support 802.1x authentication.
- Pro tip: Shure MAC Addresses generally begin with 00:0E:DD.
Device Discovery and Updates
- Shure Devices use both Bonjour and a proprietary ACN-based protocol for discovery and inter-device communication.
- Ensure Bonjour traffic is allowed to flow on the Shure VLAN.
- Permit unregistered multicast traffic to flow to all Shure switchports.
- Shure Update Utility needs to be bonded to a specific NIC on a computer, and must be allowed through the Firewall.
- Updates can only be installed with Shure Update Utility.
- Ensure IGMP Snooping is enabled on your switch for the VLAN with Shure devices.
- One switch must serve as the IGMP Querier. This is often automatically elected in homogenous switch environments. The core switch is the preferred querier.
- The Querier must have an IP address in the same VLAN and layer 3 subnet as the Shure Network Audio devices.
- 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.
- If a device is not seeing some multicast traffic, check the switch to ensure that switchport is joined to the correct multicast groups.
- Shure switchports and the computer running Dante Controller must permit Unregistered Multicast Traffic.
- Shure Network Audio devices use DSCP for some types of traffic.
- Ensure that DSCP 56 is assigned to a dedicated queue with the highest priority on the network.
- Ensure that DSCP 46 is assigned to a dedicated queue with the second 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.
Network Audio Clocking
- Clock traffic is the most important network traffic exchanged by Shure Network Audio devices.
- Clock traffic is in Multicast group 188.8.131.52, UDP Ports 319-320 and is tagged DSCP 56.
- If multiple master clocks are detected, this means that all devices are not seeing the PTP traffic. Check multicast group membership for group 184.108.40.206.
- 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.
- Unicast Dante flows are sent with DSCP 46. Ensure these flows are assigned to the correct QOS queue.
- Multicast Dante and AES67 flows are also sent with DSCP 46. Ensure these flows are assigned to the correct QOS queue.
- AES67 streams are announced via SAP on multicast group 220.127.116.11, UDP Port 9875 Verify all devices are subscribed to this group.
- If packets are lost or delayed, QOS is 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.
- 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.