Clear-Com: Network Considerations for Routing Clear-Com AES67 Streams across Layer 3

Clear-Com has added support for routing AES67 streams across layer 3 starting in EHX version 12.1.

See Clear-Com 's general recommendations for configuring your network in this document:

https://clearcom.com/DownloadCenter/technicaldocs/AES67SwitchRecommendations/AoIP-AES67_Network_Recommendations.pdf

 

In the diagram above we have an Eclipse frame with an E-IPA card, connected via its AoIP port to a layer 3 routed network. There may be a PTP grandmaster in place already. If not, the E-IPA card assumes the role of grandmaster. IP transceivers or AES67 connected Iris panels are located one or more switch hops away, and the links are L3.

First, it is necessary to ensure the correct gateway and subnet mask information is correctly programmed into all the endpoints.

Next, it is important to ensure PTP clock is being correctly propagated throughout the network. Ideally, the switches support boundary clock, so that the PTP packets only have to traverse to the nearest switch. If they don’t support boundary clock, switch hops between the frame and endpoints should be limited to 3, and the switches need to be set up to route the PTP packets , which are multicast, and typically use the destination address 224.0.1.129.

It’s necessary that the PTP packets have the correct forwarding priority through the network. You will see this referred to by a variety of names - DiffServ, QOS, DSCP. They all refer to the same concept, the priority the switch gives to the packet in forwarding. The PTP packets have to be sent to “ the front of the line”, and given the highest priority in the switch to get good PTP clock sync across the network. To do this, PTP clocks will assign a DSCP value of 46 ( Expedited Forwarding) to the PTP packets. The QoS settings in the switch must be configured to place packets tagged this way in their highest priority output queue. Also, this value must be propagated throughout the network, as the packets traverse multiple L3 links. Wireshark is invaluable for this type of troubleshooting as it allows the QoS to be easily viewed, as the packets enter and leave the switch. ( As well as the rest of the packet contents)

It has come to our attention that the Cisco Nexus 7000 series of switches, as of this writing, (date Mar 25, 2021 ) has a bug which is causing it to not forward the DSCP value to the downstream switch. So even though the PTP packets are entering the switch with the correct DSCP value of 46 (Expedited Forwarding), they are leaving the switch marked 01 ( LE, or Lower Effort) In addition to these packets being “moved to the end of the line”, they may in fact be dropped altogether if the switch gets busy with other traffic. Needless to say, this wreaks havoc with the PTP clock at the destination and prevents it from acquiring sync. The solution is the downstream switch(s) must be programmed to restore the proper DSCP value of 46 to the PTP packets.

The audio packets are marked with a DSCP value of 34 ( AF41, Assured Forwarding). This is set slightly lower than PTP, but is still expedited through the switch. The same considerations apply to the audio packets. Ensure they are propagating throughout the network with the proper DSCP value of 34.

If QoS trust options are available on the switch, ensure DSCP is trusted.

Prior to EHX v12.4

A second issue which arises when configuring a layer 3 network for Clearcom operation is proxy ARP. Due to the way Clearcom gear resolves the IP address, proxy ARP must be enabled on all the network switches along the path to the endpoints. Here is a description from Cisco on proxy ARP:

Cisco Proxy ARP

Even though the endpoints ( panels, IPT’s) will show a data connection in EHX, the audio packets will be lost on a L3 network without proxy ARP. The only indication you will get from EHX is DECT sync showing “unlocked”.

Using EHX v12.4 or later there is no requirement to enable proxy ARP on your switches