Dante-Redundanz-Failover testen: Primäre und sekundäre Pfade verifizieren

5 Min. Lesezeit · Aktualisiert am 13. Oktober 2026 · FOH- und Monitoringenieure, Systemtechniker, AV-Netzwerkingenieure, Broadcast-Operatoren, Veranstaltungstechniker, Integratoren, Produktionsleiter und Touring-Audio-Crews

Redundante Dante-Netzwerke mit isolierten Pfadtests, kontrolliertem Failover, Ereignisnachweisen, Wiederherstellungszeiten und reproduzierbaren Abnahmekriterien prüfen und eingrenzen.

Kurz gesagt — Ein redundantes Dante-System ist erst dann nachgewiesen, wenn jeder Pfad allein funktioniert und ein kontrollierter Pfadverlust das akzeptierte Audio nicht unterbricht. Plane physisch getrennte primäre und sekundäre Netzwerke, dokumentiere beide im Ausgangszustand, trenne einen Pfad an einer definierten Grenze, beobachte Audio und Ereignisse, stelle den Pfad wieder her und wiederhole den Test in die andere Richtung. Verbinde die beiden Netzwerke niemals miteinander und bezeichne zwei Ports in ein und derselben gemeinsamen Fehlerdomäne nicht als redundant.

Redundanz sind zwei unabhängige Pfade

Im redundanten Modus senden unterstützte Dante-Geräte doppelte Daten über primäre und sekundäre Netzwerke. Der Empfänger kann beim Ausfall eines Pfads auf dem verbleibenden Pfad weiterarbeiten. Der Schutz hängt von der Trennung ab: unabhängige Switch-Fabrics, Verkabelung, Ports, Stromversorgung, wo erforderlich, und keine unbeabsichtigte Kreuzverbindung.

Design	Erwartetes Ergebnis	Nicht bewiesen durch
Getrennte primäre und sekundäre Fabrics	Ein Pfad kann ausfallen, während Audio weiterläuft	Zwei Kabel, die in denselben Switch führen
Passende kompatible Gerätekonfiguration	Beide Schnittstellen führen die vorgesehenen Kanäle und die Uhr	Nur grüner Primärstatus
Kontrollierter Failover-Test	Audio und Ereignisse erfüllen die Abnahmekriterien	Das Anpingen beider Schnittstellenadressen
Kontrollierter Wiederherstellungstest	Der wiederhergestellte Pfad wird ohne Instabilität gesund	Wieder anschließen und dann sofort nichts mehr ändern

Nutze den Leitfaden zu redundantem vs. geschaltetem Modus, um den Portmodus auszuwählen und zu verkabeln. Dieser Leitfaden behandelt den operativen Nachweis des Failovers und die Fehlerisolierung.

Einen Test aufbauen, der die ausgefallene Grenze identifiziert

1. Beide Pfade vor dem ersten Kabelzug zeichnen

Mappe jede Geräte-Schnittstelle, jeden Access-Switch, jeden Uplink, jede Glasfaser- oder Kupferstrecke, jede Stromquelle und jede überwachte Grenze. Beschrifte Primary und Secondary konsistent. Bestätige, dass die Netzwerke keinen unbeaufsichtigten Switch, keinen VLAN-Bridge, keine unbeabsichtigte Patchung oder keinen gemeinsamen Uplink teilen.

2. Den gesunden Systemzustand als Baseline erfassen

Dokumentiere Subscriptions, Leader- und Follower-Status, Schnittstellengeschwindigkeit, Link-Fehler, Paket- und Latenznachweise, Firmware und den Zeitstempel des Event-Logs. Spiele repräsentatives Programmaudio zu jedem kritischen Ziel. Ein Failover-Ergebnis ist nur im Vergleich zu einer bekannten sauberen Baseline aussagekräftig.

3. Den sekundären Pfad allein nachweisen

Trenne am geplanten Testpunkt den primären Pfad oder deaktiviere ihn, ohne Routen zu ändern. Überwache kritisches Audio kontinuierlich. Speichere die Ereignisfolge und bestätige, dass sekundäre Links, Taktverhalten, Paketübertragung und Subscriptions für die vereinbarte Verweilzeit gesund bleiben.

4. Den primären Pfad wiederherstellen und das Recovery beobachten

Verbinde den Pfad erneut und lass dann Link-Aushandlung und Netzwerkzustand zur Ruhe kommen. Bestätige, dass die wiederhergestellte Schnittstelle gesund ist und kein wiederkehrendes Link-, Takt- oder Subscription-Ereignis auftritt. Gehe nicht davon aus, dass Audio-Kontinuität allein beweist, dass der wiederhergestellte Pfad nutzbar ist.

5. Mit entferntem Secondary wiederholen

Kehre zu einer sauberen Baseline zurück, isoliere Secondary an derselben logischen Grenze und wiederhole die Beobachtung. Das Testen in beide Richtungen deckt einen sekundären Pfad auf, der nie gültigen Traffic getragen hat, und einen primären Pfad, dessen Wiederherstellung instabil ist.

Fehler nach Muster lesen

Evidenzmuster	Wahrscheinliche Grenze	Nächste kontrollierte Prüfung
Audio stoppt, wenn Primary entfernt wird	Sekundärer Pfad, Modus, Route oder gemeinsame Abhängigkeit	Secondary-Ende-zu-Ende prüfen, während Primary weiter isoliert bleibt
Viele Secondary-Links fallen gleichzeitig aus	Gemeinsamer Switch, Uplink oder Stromversorgung	Die früheste gemeinsame Secondary-Grenze prüfen
Ein Gerät meldet einen Secondary-Fehler	Lokales Kabel, Port, Schnittstelle oder Gerätekonfiguration	Nur die bekannte gute Grenze tauschen und erneut testen
Audio bleibt bestehen, aber Taktwarnungen erscheinen	Taktpfad oder gemeinsame Leader-Abhängigkeit	Takt-Ereignisse und Follower-Offset auf beiden Fabrics korrelieren
Wiederherstellung flapped wiederholt	Kabel, Aushandlung, Loop oder Switch-Konfiguration	Zähler und Topologie vor einem weiteren Failover prüfen
Beide Netzwerke fallen durch eine Aktion aus	Verborgene gemeinsame Fehlerdomäne	Stromversorgung, Uplinks, Gehäuse und Kreuzverbindungen neu zeichnen

Ändere nicht mehrere Kabel, Switches und Einstellungen gleichzeitig. Bewahre das erste Ereignis, isoliere die früheste gemeinsame Grenze, ändere genau eine Bedingung und wiederhole denselben Abnahmetest.

Abnahme vor dem Test definieren

Primary und Secondary sind physisch und logisch getrennt.
Jedes kritische Gerät zeigt vor der Isolation zwei gesunde Links.
Repräsentatives Audio erreicht jedes kritische Ziel.
Das Entfernen eines der beiden Pfade verursacht kein inakzeptables Stummschalten, Klicken oder Dropout.
Uhr-, Paket-, Latenz- und Subscription-Nachweise des verbleibenden Pfads bleiben gesund.
Der ausgefallene Pfad ist im Monitoring und im Event-Log sichtbar.
Das Wiederherstellen des Pfads erzeugt einen stabilen gesunden Zustand.
Beide Testrichtungen bestehen für die dokumentierte Verweilzeit.
Gespeicherte Konfiguration und Beschriftungen stimmen mit dem getesteten System überein.

Wenn der Fehler Paketfehler oder verspätete Ankünfte umfasst, trenne diese mit dem Leitfaden zu Dante-Paketfehlern vs. Latenzfehlern. Wenn das Ereignis taktrelevant ist, folge dem Troubleshooting-Workflow für die Takt-Synchronisation.

Das Failover-Ergebnis dokumentieren

Dokumentiere Datum, Operator, Geräte- und Switch-Firmware, Topologie-Revision, Isolationspunkt, Start- und Recovery-Zeiten, einen Auszug aus dem Event-Log, überwachte Ziele, Audio-Abnahme, verbleibende Defekte und den Rollback-Status. Ein Foto eines abgezogenen Kabels reicht nicht aus; das nützliche Artefakt ist ein pfadspezifisches Ergebnis, das ein anderer Techniker wiederholen kann.

In Techrider.live hänge die Redundanz-Notizen an dieselbe Source of Truth wie Patch und Bühnenplan. Lade Mitwirkende ein, denselben Rider zu bearbeiten, speichere die akzeptierte Revision, prüfe den Verlauf und exportiere ein PDF für die Übergabe an Venue oder Touring-Team.

FAQ

Wie teste ich Dante-Redundanz?

Erfasse beide gesunden Pfade als Baseline, isoliere Primary an einer dokumentierten Grenze, prüfe Audio- und Netzwerknachweise auf Secondary, stelle den Pfad wieder her und bestätige das Recovery; wiederhole den Vorgang anschließend mit isoliertem Secondary.

Was passiert, wenn das primäre Dante-Netzwerk ausfällt?

In einem korrekt konfigurierten redundanten System verwenden die Empfänger weiterhin die doppelte Datenübertragung von Secondary. Das Monitoring sollte den ausgefallenen Primärpfad dennoch sichtbar machen, damit er repariert und nicht ignoriert wird.

Warum zeigt Dante auf dem Sekundärnetzwerk einen Fehler an?

Häufige Ursachen sind ein getrenntes Kabel, ein deaktivierter oder falsch konfigurierter Switch-Port, ein falscher Gerätemodus, geteilte oder gekreuzte Netzwerke, Geschwindigkeitshandshakes oder ein ausgefallener sekundärer Uplink. Untersuche die früheste gemeinsame Grenze.

Können Dante Primary und Secondary denselben Switch nutzen?

Das bietet keine Redundanz auf Switch-Ebene und kann eine ungültige Topologie erzeugen, wenn die Netzwerke gebridged werden. Verwende tatsächlich getrennte Netzwerkpfade gemäß Geräte- und Systemdesign.

Wie prüfe ich, ob Dante-Failover erfolgreich zurückgekehrt ist?

Bestätige, dass der wiederhergestellte Link stabil ist, die Fehlerzähler nicht weiter steigen, Subscriptions und Taktzustand gesund bleiben, echtes Audio durchläuft und während der dokumentierten Verweilzeit keine wiederholten Fail-/Recover-Ereignisse auftreten.