Grundprinzipien von AES67-Netzwerken

Bevor wir uns mit spezifischen Fehlern befassen, ist es wichtig, ein klares mentales Modell der Kerntechnologien zu erstellen, die einem AES67-System zugrunde liegen. Im Gegensatz zu einer einfachen analogen Schlange beruht ein AES67-Stream auf einem empfindlichen Gleichgewicht mehrerer voneinander abhängiger Standards. Eine Schwäche in einer dieser Säulen kann sich als frustrierendes Audioproblem manifestieren.

Das Precision Time Protocol (PTPv2 / IEEE 1588-2008)

PTP ist der Herzschlag eines jeden AES67-Netzwerks. Es stellt die gemeinsame Zeitreferenz bereit, die für alle Geräte erforderlich ist, um Audio zu genau dem gleichen Zeitpunkt zu scannen und die Uhr aus eingehenden RTP-Paketen zu rekonstruieren. Ohne genaue PTP-Synchronisation werden Empfänger von Pufferunterschreitungen oder Überläufen betroffen sein, was zu Pops, Klicks oder vollständigem Audioverlust führt. AES67 schreibt speziell die Verwendung von PTPv2 (IEEE 1588-2008) in einem Profil vor, das so definiert ist, dass es neben anderen Protokollen funktioniert. Konzepte wie den Best Master Clock Algorithm (BMCA), Uhrklasse, Domänennummern und Unicast-Verhandlungen sind für die Fehlersuche unerlässlich.

Eine Fehlanpassung in der PTP-Domäne zwischen Geräten ist einer der häufigsten Konfigurationsfehler, die im Feld auftreten. Darüber hinaus wählt der BMCA automatisch die beste Uhr basierend auf Prioritätswerten, Uhrklasse und Uhrgenauigkeit aus. Ingenieure müssen überprüfen, dass der beabsichtigte Großmeister mit der höchsten Priorität konfiguriert ist (niedrigste Priorität1 und Priorität2) Werte und dass kein Rogue-Gerät mit einer niedriger

Echtzeit-Transportprotokoll (RTP) und Multicast-Management

AES67-Audio wird in RTP-Paketen gekapselt und über UDP/IP übertragen. Der Standard unterstützt sowohl Unicast- (Point-to-Point) als auch Multicast-Transporte. Multicast ist sehr effizient für die Verteilung eines Streams an viele Empfänger, stellt aber Anforderungen an die Netzwerkinfrastruktur. Es erfordert die Netzwerk-Switches, um sicherzustellen, dass der Multicast-Datenverkehr nur an Ports weitergeleitet wird, die ihn angefordert haben. Ohne richtig konfiguriertes IGMP-Snooping kann Multicast-Audio-Verkehr das Netzwerk überfluten und zu Staus führen, die sowohl Audio- als auch andere Datendienste stören.

Techniker müssen die IGMP-Abfrageeinstellungen und Multicast-Gruppenmitgliedschaften auf ihren verwalteten Switches überprüfen können. Der IGMP-Abfrager muss auf dem richtigen VLAN aktiviert sein; andernfalls werden Multicast-Gruppen Timeout ausführen, was zu Stromverlust führt. Ein üblicher Test besteht darin, IGMP-Snooping an einem Testport vorübergehend zu deaktivieren, um zu sehen, ob der Stream passiert - dies hilft, IGMP-Probleme von

Servicequalität (QoS) und VLANs

In einem konvergierten Netzwerk, das Daten-, Video- und Kontrolldatenverkehr neben Echtzeit-Audio transportiert, ist die Paketpriorisierung obligatorisch. AES67 spezifiziert strenge QoS-Anforderungen unter Verwendung von DSCP-Markierungen (Differential Services Code Point, DSCP). Audio-Datenverkehr muss mit einem DSCP-Wert hoher Priorität (z. B. EF oder CS7) markiert werden, um sicherzustellen, dass er in der Prioritätswarteschlange des Switches vor dem Standard-Datenverkehr platziert wird. Darüber hinaus ist die Verwendung von dedizierten VLANs (IEEE 802.1Q) zur Segmentierung des Audioverkehrs aus dem allgemeinen Netzwerkverkehr eine bewährte Vorgehensweise, die die Fehlerbehebung erheblich vereinfacht. Wenn ein Switch-Port nicht konfiguriert ist, um den eingehenden DSCP-Markierungen von einem AES67-Gerät zu vertrauen, oder wenn der Audio-Datenverkehr nicht in der richtigen Prioritätswarteschlange platziert ist, sind intermittierende Audio-Abbrüche unter Netzwerklast nahezu garantiert.

Viele Switches ermöglichen es Ihnen, den Vertrauenszustand pro Port zu konfigurieren. Stellen Sie sicher, dass die mit AES67-End

Systematische Fehlerbehebung bei gemeinsamen Fehlern

Wenn ein AES67-System ausfällt, ist es leicht, dem Netzwerk die Schuld zu geben, aber ein strukturierter, geschichteter Ansatz für die Diagnose ist viel effektiver. Die folgenden Abschnitte skizzieren die häufigsten Symptome, ihre Ursachen und systematische Verfahren zur Auflösung.

Problem 1: Geräte können sich nicht gegenseitig entdecken oder Streams

Symptom: Der Empfänger kann den Sender im Netzwerk nicht finden, oder die Streamverbindung schlägt sofort nach der Auswahl fehl.

Ursachen und Diagnosen:

  • Layer-2-Segregation (VLANs & Subnetze): Die häufigste Ursache für einen Entdeckungsfehler ist, dass die Geräte nicht im selben VLAN- oder IP-Subnetz sind. AES67 stützt sich häufig auf Standard-Netzwerkerkennungsprotokolle (wie mDNS oder SAP), die Layer-3-Grenzen nicht ohne Router oder mDNS-Reflektor durchlaufen. Ping Befehl zur Bestätigung der Basisverbindung von Layer 3. Wenn sie sich nicht gegenseitig pingen können, überprüfen Sie die Switch-Port-VLAN-Zuweisungen.
  • IGMP Snooping Fehlkonfiguration: Wenn der Sender einen Multicast-Stream sendet, muss der Empfänger sein Interesse über IGMP signalisieren. Wenn IGMP-Snooping am Switch aktiviert ist, der Abfrager jedoch nicht konfiguriert ist oder sich auf dem falschen VLAN befindet, wird der Multicast-Datenverkehr blockiert. Überprüfen Sie den IGMP-Snooping-Status des Switches und stellen Sie sicher, dass ein Abfrager auf dem richtigen VLAN aktiv ist. Das vorübergehende Deaktivieren des IGMP-Snooping kann ein gültiger Test sein, um zu sehen, ob der Stream passiert, aber dies ist keine Produktionslösung aufgrund der Gefahr von Überschwemmungen.
  • Firewall oder ACLs: Stellen Sie sicher, dass keine Zugriffskontrolllisten (ACLs) oder Firewall-Regeln die von AES67 verwendeten UDP-Ports (normalerweise den konfigurierten RTP-Portbereich) oder die PTP-Ereignis-/Allgemeinnachrichten-Ports (319/320) blockieren.
  • Sitzungsbeschreibung Protokoll (SDP) Mismatch: Der Empfänger benötigt eine gültige SDP-Datei, die den Stream beschreibt. Wenn das SDP-Format nicht unterstützt wird (z. B. Nutzlasttyp, Anzahl der Kanäle oder Paketzeit), kann die Suche erfolgreich sein, aber die Verbindung wird fehlschlagen.

Problem 2: Intermittierende Audio-Dropouts oder Pops und Klicks

Symptom: Audio spielt für ein paar Sekunden oder Minuten vor dem Aufbrechen, Aussteigen oder die Produktion von hörbaren Artefakten.

Ursachen und Diagnosen:

  • Packet Loss und Jitter: Dies ist das klassische Symptom eines überlasteten oder schlecht konfigurierten Netzwerks. Wenn ein Switch-Buffer überläuft, muss er Pakete fallen lassen. Hoher Jitter (Variation der Paketankunftszeit) kann auch dazu führen, dass der De-Jitter-Puffer eines Empfängers unterschritten wird. Verwenden Sie einen Netzwerkanalysator wie Wireshark, um den RTP-Stream zu erfassen. Überprüfen Sie auf Lücken in den RTP-Sequenznummern (Anzeige des Paketverlusts) oder übermäßige Jitterwerte, die von Wiresharks RTP-Analysetools bereitgestellt werden. Ein Jitterwert, der durchweg über 2-3 Millisekunden liegt, führt oft zu Artefakten.
  • QoS-Fehlkonfiguration oder -Mangel: Selbst eine kleine Menge konkurrierenden Datenverkehrs (z. B. eine Dateiübertragung) kann dazu führen, dass ein nicht priorisierter Audiostrom Pakete abgibt. Vertrauensvoll Diese Markierungen auf den Eingangsports: Wenn ein Switch-Port so konfiguriert ist, dass der gesamte Datenverkehr mit niedriger Priorität erneut markiert wird, funktioniert QoS nicht. Außerdem ist sicherzustellen, dass die Ausgangswarteschlangen des Switches ordnungsgemäß konfiguriert sind (z. B. strenge Priorität für die höchste Warteschlange).
  • Duplex Mismatch oder Bad Cabling: Physikalische Schichtprobleme können zu umfangreichen Paketfehlern führen. Stellen Sie sicher, dass alle angeschlossenen Ports mit der erwarteten Geschwindigkeit und Duplex (im Allgemeinen 1 Gbps Full Duplex) verhandeln. Ein einzelnes Gerät, das zu Half Duplex gezwungen wird, kann CRC-Fehler und Kollisionen verursachen, die den Datenverkehr für das gesamte Switch-Segment stören. Überprüfen Sie die Schnittstellenzähler des Switches auf CRC-Ausrichtungen, Runts oder Giganten.
  • Energy Efficient Ethernet (EEE / 802.3az): Elektro- und Elektronikgeräte können Jitter einführen, wenn Verbindungen in und aus stromsparenden LPI-Zuständen (Low Power Leerlauf) gelangen. Elektro- und Elektronikgeräte müssen an allen Switch-Ports, die AES67-Datenverkehr transportieren, oder am gesamten Switch deaktiviert werden. Viele verwaltete Switches ermöglichen die globale Deaktivierung von Elektro- und Elektronikgeräten oder pro Port.
  • Übermäßige Pufferlatenz: Wenn der Puffer des Empfängers zu klein für den Netzwerkjitter ist, treten Aussetzer auf. Umgekehrt fügt ein zu großer Puffer eine inakzeptable Latenz hinzu. Überprüfen Sie die Größe des Paketpuffers des Empfängers und passen Sie sie auf der Grundlage des beobachteten Jitters aus der Wireshark-Analyse an.

Problem 3: PTP-Synchronisierungsfehler

Symptom: Empfänger zeigen einen "Lock Lost"- oder "Unlocked"-Zustand an, oder Audio ist trotz der etablierten Netzwerkverbindung stark verzerrt.

Ursachen und Diagnosen:

  • PTP Domain Mismatch: Alle Geräte im selben AES67-Netzwerk müssen mit der gleichen PTP-Domänennummer konfiguriert sein (Standard ist oft 0), wenn sich ein Sender in der Domäne 0 und ein Empfänger in der Domäne 1 befindet, werden sie nicht mit der gleichen Taktreferenz synchronisiert.
  • Best Master Clock Algorithm (BMCA) Fehlverhalten: Ein unerwartetes Gerät kann zum Großmeister werden, wenn es eine höhere Priorität hat (niedrigerer Prioritätswert), was häufig dann der Fall ist, wenn sich ein Gerät mit einer weniger stabilen internen Uhr (z. B. ein gewöhnlicher PC mit einem Software-PTP-Stack) mit einer niedrigeren Uhrklasse ankündigt. Identifizieren Sie den beabsichtigten Großmeister und stellen Sie sicher, dass er mit der höchsten Priorität konfiguriert ist (niedrigste Priorität1 und Priorität2). Verwenden Sie PTP-Überwachungstools, um die Grandmaster-Identität auf allen Geräten anzuzeigen.
  • Netzwerkasymmetrie: PTP geht davon aus, dass die Netzwerkverzögerung von Master zu Slave dieselbe ist wie von Slave zu Master. Wenn der Netzwerkpfad asymmetrisch ist (z. B. unterschiedliche Switch-Hops oder Kabellängen in jeder Richtung), ist der PTP-Offset falsch. Dies ist insbesondere bei komplexen Layer-3-gerouteten Netzwerken oder Netzwerken mit Langstrecken-Glasfaserverbindungen üblich. Die Verwendung von Peer-to-Peer-Verzögerungsmechanismen (P2P) anstelle von End-to-End-Verzögerungsmechanismen (E2E) kann dazu beitragen, dies in einigen Topologien zu mildern, aber beide Enden müssen den gleichen Verzögerungsmechanismus unterstützen.
  • Unicast vs. Multicast PTP: AES67 unterstützt sowohl Unicast- als auch Multicast-PTP-Verhandlungen. Wenn ein Gerät für Unicast-Verhandlungen konfiguriert ist und der Peer nicht konfiguriert ist, um die Unicast-Zuteilung zuzulassen, schlägt PTP fehl. Stellen Sie sicher, dass alle Geräte dieselbe PTP-Transportkonfiguration haben. Einige Geräte erfordern die explizite Konfiguration einer Unicast-Zuteilungstabelle.
  • Uhrklasse vs. Uhrqualität: Selbst innerhalb derselben Domäne können Geräte mit unterschiedlichen Taktklassen dazu führen, dass BMCA einen suboptimalen Großmeister auswählt, beispielsweise ein Gerät mit Taktklasse 248, das eine niedrigere Priorität hat als ein beabsichtigter Master mit Taktklasse 6. Immer Taktklassenwerte überprüfen und Prioritätseinstellungen entsprechend anpassen.

Problem 4: Fehler bei hoher Latenz oder Audioausrichtung

Symptom: Audio ist nicht mehr mit Video- oder anderen Audiostreams synchronisiert, oder die Gesamtlatenz für die Rundreise durch das System ist höher als erwartet.

Ursachen und Diagnosen:

  • Übermäßiges Packet Buffering: Während einige Pufferungen notwendig sind, um Jitter zu absorbieren, können zu konservative Puffereinstellungen auf einem Empfänger eine erhebliche Latenzzeit einführen. Überprüfen Sie die Paketpuffergröße oder Latenzeinstellungen des Empfängers. Dies ist oft ein Kompromiss zwischen Zuverlässigkeit und niedriger Latenz. Bei der Live-Produktion sollten Sie die niedrigste Puffergröße anstreben, die eine stabile Wiedergabe ermöglicht.
  • Spanning Tree Protocol (STP) Konvergenz: Bei redundanten Netzwerktopologien kann STP Ports blockieren und temporäre Schleifen erzeugen. Wenn eine Verbindung ausfällt und STP wieder zusammenläuft, können Audioströme gestört oder verzögert werden. Mit dem Rapid Spanning Tree Protocol (RSTP) oder Multiple Spanning Tree Protocol (MSTP) und richtig konfigurierten Edge Ports (PortFast) können diese Störungen minimiert werden. Unerwartete Änderungen der STP-Topologie können ebenfalls Jitter verursachen. Überwachen Sie Switch-Logs für STP-Übergänge.
  • Sample Rate und Clock Domain Mismatches: Alle Geräte in einer einzigen AES67-Synchronisationsdomäne müssen mit dem gleichen PTP-Großmeister gesperrt sein. Wenn ein Gerät auf seiner internen Uhr freiläuft, driftet es im Laufe der Zeit, was zu Ausrichtungsfehlern führt. Stellen Sie sicher, dass die Uhrenquelle jedes Geräts auf PTP eingestellt ist. Einige Geräte ermöglichen ein Rückfall auf die interne Uhr - das Deaktivieren des Rückfalls auf kritischen Pfaden.
  • RTP Timestamp Drift: Selbst bei PTP kann eine unsachgemäße Handhabung von RTP-Zeitstempeln zu Ausrichtungsproblemen führen. Verwenden Sie Wireshark, um RTP-Zeitstempel verschiedener Streams zu vergleichen. Wenn sie im Laufe der Zeit divergieren, wird der Sender möglicherweise nicht korrekt auf PTP basierend timestamping. Dies deutet oft auf einen Firmware-Fehler oder eine Fehlkonfiguration der Sample-Rate-Konvertierung hin.

Problem 5: Interoperabilitätshemmnisse zwischen Anbietern

Symptom: Funktionale Streams zwischen Geräten von Vendor A scheitern beim Verbinden mit Geräten von Vendor B.

Ursachen und Diagnosen:

  • SDP File Mismatches: AES67-Streams werden mit Session Description Protocol (SDP)-Dateien beschrieben. Ein häufiges Problem ist eine Uneinigkeit über den unterstützten Nutzlasttyp (z. B. L16 vs. L24) oder die Anzahl der Kanäle pro Stream. Stellen Sie sicher, dass der Sender einen Nutzlasttyp anbietet, den der Empfänger dekodieren kann. In ähnlicher Weise überprüfen Sie die maximale Paketzeit (ptime); AES67 unterstützt 1ms-Rahmen, aber einige Geräte unterstützen möglicherweise nur 125 Mikrosekunden oder 333 Mikrosekunden. Verwenden Sie ein Werkzeug, um den SDP vom Sender zu erfassen und zu überprüfen, ob er mit den Empfängerfähigkeiten übereinstimmt.
  • Multicast-Adresse / Portkonflikte: Einige Geräte können die dynamische Multicast-Adressenzuweisung möglicherweise nicht gut handhaben oder hart codiert sein, um bestimmte Portbereiche zu verwenden, die mit anderen Diensten in Konflikt stehen. Überprüfen Sie die SDP-Datei, um zu bestätigen, dass der Ziel-IP- und UDP-Port gültig ist und an anderer Stelle im Netzwerk nicht verwendet wird. Wenn möglich, konfigurieren Sie feste Multicast-Adressen innerhalb des empfohlenen Bereichs (239.xxx.xxx.xxx.xxx).
  • Redundanz (ST 2022-7) Kompatibilität: Während der Standard AES67 keine Redundanz vorschreibt, ist es der eng verwandte Standard SMPTE ST 2110-30. Wenn ein Gerät eine nahtlose Schutzschaltung erwartet (hitless merge) und der andere einen einzelnen Stream sendet, kann Audio Alias oder Duplikat senden. Überprüfen Sie, ob der Redundanzmodus (redundant, nur primär usw.) an beiden Enden kompatibel ist. Einige Empfänger können so konfiguriert werden, dass sie einen einzelnen Stream akzeptieren, auch wenn sie Redundanz unterstützen.
  • Payload Type Registration: AES67 verwendet dynamische Nutzlasttypen (typischerweise 96–127). Wenn zwei Anbieter unterschiedliche PT-Werte für dieselbe Codierung zuweisen (z. B. einer verwendet 96 für L24, ein anderer verwendet 97), kann der Empfänger den Stream ablehnen.

Fortgeschrittene Diagnosetechniken und Werkzeuge für Ingenieure

Über die grundlegenden Prüfungen hinaus müssen technische Fachleute ausgeklügelte Werkzeuge einsetzen, um tief sitzende Netzwerkprobleme zu isolieren. Das Ziel ist es, von Rätselraten zu datengesteuerter Analyse überzugehen.

Wireshark für Deep Packet Inspection

Wireshark ist ein unverzichtbares Werkzeug für die Diagnose von AES67-Netzwerken, mit dem Sie den Netzwerk-Rohdatenverkehr erfassen und auf Paketebene analysieren können.

  • Filterung für PTP: Verwenden Sie den Anzeigefilter , um PTP-Nachrichten zu isolieren. Überprüfen Sie die Nachrichten für Grandmaster-Priorität und Uhrenklasse ankündigen. Überprüfen Sie Sync- und Delay Req-Nachrichten auf genaue Zeitstempel. Suchen Sie nach Fehlern in den PTP-Statuscodes. Beachten Sie das -Feld; eine Fehlanpassung führt dazu, dass Slaves den Master ignorieren.
  • Filterung für AES67 RTP: Verwenden Sie einen Filter wie oder filtern Sie nach dem spezifischen Ziel-UDP-Port. Statistiken > RTP > Alle Streams anzeigenDies gibt einen Überblick über alle erkannten RTP-Streams, ihre SSRCs und ihre Synchronisationsquelle.
  • Analyse der RTP-Stream-Qualität: Wireshark kann Jitter berechnen und Paketverlust für einen ausgewählten RTP-Stream erkennen. Stream-Analyse. Dies erzeugt einen Graphen und einen detaillierten Bericht über Delta-Zeiten und Jitter. Ein Jitterwert, der die Puffertiefe des Empfängers konsequent überschreitet, führt zu Ausfällen. Achten Sie genau auf Lücken in den Sequenznummern. Beachten Sie auch die – doppelte SSRCs über verschiedene Streams hinweg weisen auf ein Konfigurationsproblem hin.
  • Überprüfen Sie auf doppelte Pakete: In Netzwerken mit falsch konfigurierter Redundanz oder Schaltschleifen können doppelte RTP-Pakete erscheinen. Dies kann Empfänger verwirren. Wireshark kann doppelte Sequenznummern erkennen und markieren. Verwenden Sie den -Filter, um Duplikate zu identifizieren.

Das Lesen dieser Metriken ist eine Kernkompetenz. RTP-Analysedokumentation von Wireshark.

PTP-Überwachung und Servo-Validierung

Viele professionelle AES67-Geräte bieten eine Statusseite für die PTP-Synchronisation. Ingenieure sollten lernen, diese Metriken zu lesen.

  • Offset vom Master: Dies ist die gemessene Zeitdifferenz zwischen der Slave-Uhr und dem Großmeister. Sie sollte idealerweise Null sein, in der Praxis ist jedoch ein stabiler Offset von unter 1000 Nanosekunden (1 Mikrosekunde) für AES67 in der Regel akzeptabel. Große oder schnell oszillierende Offsets deuten auf ein Zeitproblem hin.
  • mittlere Wegverzögerung: Dies ist die durchschnittliche Hin- und Rückfahrtzeit zwischen dem Slave und dem Master. Dieser Wert sollte stabil sein. Große Schwankungen der Pfadverzögerung können auf Netzwerkstaus oder Routenänderungen hinweisen.
  • Großmeisteridentität: Wenn sie verschiedene Großmeister sehen, ist das Netzwerk segmentiert oder die BMCA-Konfiguration ist inkonsistent.
  • Servostaat: Einige Geräte melden den PLL-Lock-Zustand (z. B. "verriegelt", "erfassend", "freilaufend"). Ein Gerät, das beim "erfassen" feststeckt, zeigt oft an, dass der Offset zu groß ist, um zu sperren, möglicherweise aufgrund von Netzwerkasymmetrie oder einer Fehlanpassung der Ferntaktdomäne.

Dedizierte PTP-Monitoring-Tools wie PTP-Tracker oder Hardware-basierte Analysatoren können eine High-Level-Ansicht der gesamten PTP-Domäne bieten, die den Taktbaum und die Qualität der Synchronisation über alle Knoten hinweg zeigt.

Switch und Infrastruktur Audits

Der Netzwerk-Switch ist die wichtigste Hardware in einem AES67-System, dessen Konfiguration oft gründlich überprüft werden muss.

  • MTU-Einstellungen: AES67-Pakete können größer sein als Standard-Ethernet-Rahmen, insbesondere wenn sie hohe Kanalzahlen tragen. Stellen Sie sicher, dass Jumbo-Rahmen auf den Switches aktiviert sind (oft erfordert eine MTU von 1500 Bytes oder höher; 9000 Bytes ist ein sicherer Standard für moderne Netzwerke). Wenn die MTU zu klein ist, werden Pakete fragmentiert oder fallen gelassen. Verwenden Sie einen Ping mit großer Nutzlast, um MTU über den Pfad zu testen: (mit 1500 MTU ist die maximale Nutzlast 1472; für Jumbo ist Test 8972).
  • IGMP-Schnüffelprüfung: Überprüfen Sie die IGMP-Schnüffeltabelle des Switches. Es sollten die Multicast-Gruppen und die Ports aufgelistet werden, die sie angefordert haben. Ein fehlender Port zeigt ein Problem mit der IGMP-Implementierung des Empfängers oder ein Layer-2-Pfad-Problem an. Überprüfen Sie auch, ob der IGMP-Abfrager auf dem richtigen VLAN aktiv ist und dass die Abfragewahl stabil ist.
  • Puffer- und Warteschlangenmanagement: Die Pufferarchitektur des Switches verstehen. Flache Puffer ("Cut-Through"-Schalter) können Pakete unter schweren Mikro-Burst-Lasten abwerfen. Tiefe Puffer sind vorteilhaft, um Datenverkehrsbrüche zu absorbieren. Stellen Sie sicher, dass die Prioritätswarteschlangen korrekt den von AES67 verwendeten DSCP-Werten zugeordnet werden.
  • Link Aggregation (LAG) Überlegungen: Wenn Sie LAG zwischen Switches verwenden, stellen Sie sicher, dass der Load-Balancing-Algorithmus keine Pakete innerhalb eines Streams neu ordnet. Verwenden Sie den Source-Destination-IP-Hash, um jeden RTP-Flow auf demselben Link zu halten. Einige Switches unterstützen "konversationsbasiertes" Hashing, das die Reihenfolge pro Flow aufrechterhält.

Design für Zuverlässigkeit: Präventive Strategien

Die effektivste Fehlerbehebung ist die Fehlerbehebung, die niemals passieren muss. Proaktives Netzwerkdesign und regelmäßige Wartung sind der Schlüssel zur langfristigen AES67-Zuverlässigkeit.

Strenge Netzwerksegmentierung mit QoS

Behandeln Sie Ihr AES67-Audionetzwerk als kritischen Infrastrukturpfad. Verwenden Sie dedizierte VLANs, um Audio-Control-Datenverkehr (RTP, PTP) von allgemeinen IT-Daten (Webbrowsing, Filesharing, E-Mail) streng zu trennen. Implementieren Sie robuste QoS-Richtlinien auf der Zugriffsebene, um den Datenverkehr am Rande des Netzwerks zu markieren und zu vertrauen. Dies verhindert, dass Nicht-Audiogeräte hochprioren Datenverkehr in das Netzwerk einspeisen. Verwenden Sie ein separates physisches Netzwerk für Audio in missionskritischen Installationen.

Redundanz und nahtloses Schutzschalten

Für missionskritische Systeme ist eine Netzwerkredundanz gemäß SMPTE ST 2022-7 zu implementieren. Dieser Standard ermöglicht eine nahtlose Schutzumschaltung, indem er zwei identische RTP-Streams über zwei völlig getrennte, unabhängige Netzwerkpfade sendet. Der Empfänger führt die beiden Streams paketweise zusammen, so dass ein Paket, das in einem Netzwerk verloren geht, sofort durch das Paket aus dem anderen Netzwerk ersetzt wird. Dies erfordert dual-homed Endpunkte und redundante Switches, aber es bietet im Wesentlichen Null-Ausfallzeit für Netzwerkfehler.

Grundlagendokumentation und Überwachung

Dokumentieren Sie die gesamte Netzwerktopologie, einschließlich Switch-Modelle, Firmware-Versionen, Portkonfigurationen, VLAN-Zuweisungen, PTP-Domänennummern und Grandmaster-Prioritäten. Erstellen Sie eine Basislinie der normalen Netzwerkleistung, einschließlich PTP-Offset-Werte, mittlerer Pfadverzögerung und Jitter. Verwenden Sie Simple Network Management Protocol (SNMP), um Switch-Ports auf CRC-Fehler, Paketverwerfen und Schnittstellenstatusänderungen zu überwachen. Ein proaktives Warnsystem kann Ingenieure oft über einen verschlechternden Zustand (z. B. übermäßige CRC-Fehler) informieren, lange bevor es einen hörbaren Ausfall verursacht. Zentralisiertes Protokollieren von Switches und Endpunkten hilft, Netzwerkereignisse mit Audiofehlern zu korrelieren.

Bleiben Sie auf dem neuesten Stand mit Standards und Firmware

Der AES67-Standard entwickelt sich weiter und die Hersteller verbessern ihre Implementierungen ständig durch Firmware-Updates. Halten Sie einen strengen Zeitplan für die Aktualisierung sowohl der Endpunkt-Firmware als auch der Switch-Firmware ein. Überprüfen Sie die Release Notes für Fehlerbehebungen im Zusammenhang mit PTP, RTP oder Netzwerk-Interoperabilität. Die Verwendung veralteter Firmware ist eine häufige Ursache für obskure, schwer zu reproduzierende Fehler. Die offizielle Version ist eine der Hauptursachen für die Fehler, die nicht mehr in der Lage sind. AES67-Norm und die damit verbundenen Interoperabilitätsdokumente sind wesentliche Ressourcen für jeden Ingenieur, der AoIP-Systeme baut.

Letzte Gedanken zum Beherrschen von AES67-Netzwerken

Fehlerbehebung AES67 ist im Grunde genommen eine Disziplin des Systems Engineering. Es erfordert die Kombination von traditionellem Audio-Know-how mit modernen Netzwerk-Management-Fähigkeiten. Durch die methodische Isolierung des Problems auf die physische Ebene, die Switching-Infrastruktur oder die PTP-Synchronisationsdomäne können Sie schnell und sicher zu einer Lösung gelangen. Denken Sie daran, dass die überwiegende Mehrheit der AES67-Probleme aus drei Kernbereichen stammen: falsch konfiguriertes PTP, unzureichende QoS oder fehlerhafte Switch-IGMP / MTU-Einstellungen. Die Entwicklung eines tiefen Verständnisses dieser Technologien, gepaart mit der praktischen Verwendung von Diagnose-Tools wie Wireshark und PTP-Monitore, wird es Ihnen ermöglichen, robuste, qualitativ hochwertige AoIP-Systeme zu bauen und zu pflegen, die die Flexibilität moderner Netzwerkstandards voll ausnutzen.

IEEE 1588-2008 SpezifikationPraktische Anleitungen von Netzwerk-Switch-Herstellern, die sich auf Audio/Video-Bridgeing konzentrieren, sind ebenfalls sehr zu empfehlen, wie z. B. Ressourcen, die in der Netgear AV Networking Guides und die umfangreiche Technische Audinate.