Understanding the Network Foundation for AES67

AES67 is the open standard that enables interoperability between different audio-over-IP (AoIP) systems, ensuring that devices from multiple manufacturers can exchange high-quality audio streams over standard Ethernet networks. The standard relies on three critical network services: Quality of Service (QoS), multicast delivery, and precise timing via IEEE 1588 Precision Time Protocol (PTP). To achieve reliable, low-latency performance, every network switch in the path must be configured to support these services. Without proper switch configuration, even the best audio equipment will suffer from dropouts, jitter, and synchronization failures.

AES67 operates over Layer 3 IP networks, but the underlying Layer 2 switching must be tuned for audio traffic. Unlike file transfers or web browsing, real-time audio is extremely sensitive to latency and packet loss. A single lost packet can cause an audible click or pop, and excessive jitter can break synchronization. Therefore, network engineers must approach switch configuration with the same rigor as broadcast engineers calibrating a mixing console. Every setting that touches QoS, multicast, or timing must be verified against AES67's recommended profiles.

Core Switch Configuration Requirements for AES67

1. Quality of Service (QoS) – Prioritizing Audio Traffic

AES67 audio streams are marked with Differentiated Services Code Point (DSCP) values to indicate their priority. Per the AES67 standard, audio data should be marked with DSCP EF (Expedited Forwarding) (value 46) for the lowest possible latency, while stream discovery and control traffic can use AF41 (value 34). The switch must be configured to honor these markings and map them to appropriate priority queues.

On managed switches, enable trust DSCP (or IEEE 802.1p to DSCP mapping) so that incoming frames retain their markings. Then, configure egress queues to ensure EF traffic is always placed in the highest-priority queue (Queue 3 on typical Cisco/Juniper switches, or Queue 4 on others). Define strict-priority scheduling for the audio queue, and set bandwidth guarantees for lower queues to prevent starvation of other services. Running a queuing test with a packet generator (e.g., iperf with DSCP markings) can validate that audio packets receive preferential treatment under load.

2. Multicast Optimization – IGMP Snooping and Filtering

AES67 uses multicast to deliver audio streams from one source to many receivers efficiently. Without multicast optimizations, a switch would flood every multicast frame to all ports, wasting bandwidth and potentially overwhelming devices. The key feature to enable is IGMP Snooping, which allows the switch to listen to IGMP membership reports and build a table of which ports want which multicast groups.

Enable IGMP Snooping globally and on each VLAN that carries AES67 traffic. Configure the switch with a querier if no other router provides one—some switches have a built-in IGMP querier feature for layer-2-only networks. Use fast leave or immediate leave to remove groups quickly when a device departs, preventing stale entries. For static multicast groups (fixed stream addresses), you can also configure static IGMP group memberships on ports that always receive those streams. Additionally, avoid using IGMP versions older than v2, as v1 lacks leave messages; v3 is preferred for source-specific multicast (SSM) which AES67 can use.

3. Precision Timing – IEEE 1588 (PTP) Configuration

Synchronization is the heart of AES67. The standard mandates support for IEEE 1588-2008 (PTPv2) with a default profile that uses a multicast, two-step clock. The switch must pass PTP messages with minimal delay variation and should be configured to support boundary clock or transparent clock functionality for higher accuracy.

If the switch supports PTP, enable boundary clock mode on the ports connecting to PTP-aware devices. This allows the switch to synchronize to the grandmaster and then re-sync its own ports, eliminating asymmetry in the network. For switches that cannot act as boundary clocks, at least enable end-to-end transparent clock functionality, which corrects for residence time in the switch. Critical settings include:

  • PTP domain number: AES67 uses domain 0 by default.
  • Delay mechanism: Use end-to-end delay request/response (E2E) unless the switch supports peer-to-peer (P2P).
  • Announce interval: 1 second (log -3 or 0) for fast failover.
  • Sync interval: 1 second (log 0) is typical; some systems use faster rates.

Test PTP stability by monitoring offset from master (should be < 1µs on a well-configured network) and mean path delay (should remain constant). Jitter in PTP packets can cause audio dropouts, so ensure no other traffic interferes with PTP frames—ideally, mark PTP with a higher or equal priority to audio.

Network Design and Isolation Strategies

VLAN Segmentation and Audio-Only VLANs

While AES67 can coexist with other traffic using QoS, dedicated VLANs for audio are strongly recommended. Create a separate VLAN (e.g., VLAN 100) for all AES67 devices, and disable unnecessary protocols on that VLAN. On trunk ports, ensure the native VLAN is different from the audio VLAN to avoid leaks. VLAN segmentation also simplifies QoS configuration: you can apply policies only to the audio VLAN without affecting other traffic. For larger installations, consider a separate audio backbone network physically isolated from corporate IT traffic to avoid interference and simplify troubleshooting.

Spanning Tree Protocol (STP) Considerations

STP (IEEE 802.1D) and its faster variants (RSTP, MSTP) can introduce latency and block ports momentarily during topology changes—a killer for real-time audio. In a well-planned AES67 network, you usually have a single path between switches (no loops). If redundancy is required, use Link Aggregation (LAG) or Media Redundancy Protocol (MRP) instead of STP. If STP must be enabled, set the bridge priority so that the root is a designated core switch, and tune timers (forward delay, max age) to the minimum values the network can tolerate. Alternatively, use RSTP with portfast on all edge ports to avoid delays when devices connect.

Many AES67 devices rely on PoE for power. Ensure the switch can supply adequate power budget and that PoE negotiation does not interfere with PTP or multicast. Set the speed and duplex to auto-negotiation; forced settings can cause mismatch errors. For 1GbE links, ensure the cable quality supports 1000BASE-T; for longer runs, use fiber with SFP transceivers to reduce jitter and EMI.

Additional Configuration Tips for Production Networks

  • Disable Energy-Efficient Ethernet (EEE): IEEE 802.3az can introduce latency spikes as it powers down links during idle periods. Disable EEE on all ports carrying AES67 traffic.
  • Control storm protection: Enable broadcast storm control to prevent malicious or accidental multicast storms from disrupting the network. Set the threshold high enough for normal audio streams (e.g., 500 packets per second per port).
  • Firmware and management: Keep switch firmware up to date to benefit from bug fixes related to PTP and IGMP. Use an out-of-band management network or a separate management VLAN to avoid SNMP/CLI traffic interfering with audio.
  • SNMP monitoring: Set up SNMP traps for critical events (link flapping, PTP clock status) and monitor switch CPU load—high CPU can cause packet delays and QoS violations.
  • Cable plant quality: Use shielded (STP) cat6a or better cabling to minimize electromagnetic interference and ensure stable link quality.

Testing and Validation Before Go-Live

After configuring the switches, perform thorough testing before deploying audio equipment. Use a tool like AES67 test streams or a dedicated analyzer such as QSC's QSYS or Focusrite's RedNet Control to verify QoS markings, multicast delivery, and PTP accuracy. Generate synthetic traffic to stress the network and confirm that audio priority holds. The EBU (European Broadcasting Union) provides a standardized method for PTP analysis—apply it to ensure the network passes professional reliability requirements.

Common Pitfalls and How to Avoid Them

  • IGMP Querier missing: Without a querier, switches will not forward multicast to new receivers after the group ages out. Always configure at least one querier on the audio VLAN.
  • PTP correction errors: Transparent clocks must be properly configured for the delay mechanism (E2E vs P2P). Mixing modes causes large timing offsets.
  • Over-polluting QoS queues: Assigning too many traffic types to the high-priority queue can cause it to saturate. Keep only audio and PTP in the strict-priority queue.
  • Forgetting about switch queues: Many switches have only 4 output queues. Map DSCP EF to queue 3, PTP to queue 2 (or share queue 3 if both are critical), and all other traffic to lower queues.

Conclusion

Configuring a network switch for AES67 is not a one-size-fits-all task; it requires understanding the interplay of QoS, multicast, and timing. By following these best practices—enabling strict priority for audio, IGMP snooping with a querier, precise PTP support, and segmenting the network with VLANs—you can build a rock-solid foundation for professional audio-over-IP. Every setting should be tested and documented, and the network should be monitored continuously. With careful planning, AES67 can deliver the low-latency, high-fidelity performance that modern broadcast, live sound, and installed sound systems demand. For further reading, refer to the AES67 standard document and the AV Network's best practices guide.