Dante Routing über Subnetze: Domains, Clocks und Verifikation
8 Min. Lesezeit · Aktualisiert am 8. Oktober 2026 · AV-Netzwerktechniker, Systemtechniker, Integratoren, technische Leiter in Venues, Broadcast-Operator, FOH- und Monitortechniker, Produktionsleiter und Touring-Audioteams
Plane Dante-Routing über IP-Subnetze hinweg mit DDM-Domains, gerouteter Konnektivität, Discovery, Boundary Clocks, Testschritten und Übergabe in die Produktion.
TL;DR — Dante kann Medien über IP-Subnetze hinweg routen, wenn die Geräte derselben verwalteten Domain angehören und das geroutete Netzwerk die erforderlichen Pfade für Steuerung, Medien und Clocking unterstützt. Plane Adressierung, Routing, Discovery oder Enrollment, Firewall-Regeln und einen Boundary Clock für jedes Subnetz. Verifiziere danach Login, Geräte-Sichtbarkeit, namensbasiertes Abonnieren, Clock Lock, echtes Audio und das Verhalten bei Ausfällen. Betrachte reine IP-Erreichbarkeit nicht als Beweis dafür, dass ein produktionsreifer Cross-Subnetz-Pfad bereit ist.
Cross-Subnetz-Dante ist eine verwaltete Architektur
Ein klassisches, nicht verwaltetes Dante-Netzwerk wird normalerweise innerhalb eines IP-Subnetzes entdeckt und getaktet. Eine verwaltete Plattform wie Dante Domain Manager (DDM) kann Geräte aus mehreren Subnetzen in einer logischen Dante-Domain zusammenfassen. Geräte in dieser Domain können namensbasiertes Routing über geroutete Grenzen hinweg nutzen und bleiben dabei auf einen gemeinsamen Domain-Clock synchronisiert.
Die Domain ist die operative Grenze. Geräte in unterschiedlichen Domains interagieren nicht allein deshalb miteinander, weil ein Router Pakete zwischen ihren Adressen weiterleiten kann. Ein Gerät kann immer nur in einer Domain gleichzeitig enrolled sein, während ein autorisierter Benutzer Zugriff auf mehrere Domains haben kann.
| Ebene | Erforderliche Frage | Nachweis für die Akzeptanz |
|---|---|---|
| IP | Kann jeder erforderliche Endpunkt die verwalteten Dienste und gerouteten Peers erreichen? | Korrekte Adresse, Maske, Gateway, Routen und freigegebene Ports |
| Discovery/Enrollment | Wie finden Controller und Geräte den Manager? | DNS/DHCP-Discovery, mDNS im gleichen Subnetz oder freigegebene statische Enrollment-Methode |
| Domain | Befinden sich Quelle und Ziel in derselben vorgesehenen Domain? | Enrollment und Domain-Auswahl sind bestätigt |
| Clock | Wie erhält jedes Subnetz den Domain-Clock? | Aktiver Boundary Clock, nach Möglichkeit Backup, stabiles Lock |
| Medien | Läuft das echte Abonnement unter Show-Last? | Route-Status, Audio, Latenz, Zähler und Recovery-Test |
Der Dante-Geräte-Discovery-Leitfaden behandelt die Sichtbarkeit im gleichen Netzwerk und lokale Fehlersuche. Dieser Leitfaden behandelt das zusätzliche Design für geroutete Domains, das nötig ist, wenn ein Produktionspfad Subnetze überquert.
Definiere die Domain, bevor du Routen konfigurierst
Gruppiere Geräte nach der Produktions- und Kontrollgrenze, die Medien und Clock gemeinsam teilen sollen. Eine Domain kann einen Raum, ein Studio, ein Gebäude, ein System oder eine andere bewusst gewählte Betriebseinheit darstellen. Erzeuge nicht einfach eine große Domain nur deshalb, weil jedes VLAN erreichbar ist.
Für jede vorgesehene Quelle und jedes vorgesehene Ziel dokumentiere:
- Gerätename, Hersteller, Modell, Firmware und physischer Standort;
- primäre und sekundäre IP-Adresse, Subnetz, Gateway und Switch-Port;
- vorgesehene Domain und verantwortlicher Operator;
- erforderliche Sende- und Empfangskanäle;
- Medienformat, Samplerate, Receiver-Latenz und Redundanzmodus;
- Zuständigkeit für Wartung, Ausfall und Rollback.
Halte primäre und sekundäre Netzwerke getrennt, wenn Dante-Redundanz verwendet wird. Cross-Subnetz-Routing macht ein geswitchtes Design nicht automatisch redundant, und ein Gerät mit nur sekundärem Pfad bleibt möglicherweise nicht in jeder Plattform vollständig verwaltbar.
Baue das geroutete Fundament auf
1. Mache die Adressierung bewusst
Verwende einen Adressplan, der jedes Dante-Subnetz und seine Router-Schnittstelle eindeutig identifiziert. Bestätige die korrekte Subnetzmaske und das Default-Gateway auf jedem Endpunkt. Link-Local-Adressierung ist innerhalb eines einzelnen lokalen Segments nützlich, ersetzt aber keinen gerouteten Multi-Subnetz-Plan.
Der Dante-IP-Adressierungsleitfaden erklärt DHCP, Link-Local und statische Wiederherstellung. Für ein verwaltetes Multi-Subnetz-Design werden häufig DNS und DHCP genutzt, um Adressen und Service-Discovery bereitzustellen. Eine statische Enrollment-Methode über die Geräte-IP kann kontrollierte Netzwerke unterstützen, die diese Dienste nicht bereitstellen können.
2. Stelle Manager-Discovery oder explizites Enrollment bereit
Controller und Geräte müssen den Management-Dienst finden, bevor Domain-Zugriff funktionieren kann. In einem einzelnen Subnetz kann mDNS-basierte Discovery ausreichen. Über Subnetze hinweg nutze die dokumentierten DNS-Service-Records und DHCP-Konfigurationen des Produkts oder einen freigegebenen statischen Enrollment-Workflow.
Route nicht einfach pauschal alles Multicast zwischen VLANs als Discovery-Abkürzung. Das vergrößert die Fehler- und Sicherheitsgrenze und beweist trotzdem nicht, dass Domain-Enrollment, Berechtigungen, Clocking oder Medien korrekt sind.
3. Erlaube nur den erforderlichen Verkehr
Bestätige geroutete Erreichbarkeit und Firewall-Policy anhand der aktuellen DDM- oder Plattform-Dokumentation. Dokumentiere exakt Quelle, Ziel, Protokoll und Portbereich, die das Design verwendet. Ein Ping beweist nur einen engen ICMP-Pfad; er validiert weder Authentifizierung noch Discovery, Steuerung, Clock oder Medien.
4. Enrolle und identifiziere jedes Gerät
Enrolle Geräte in die vorgesehene Domain und prüfe ihre Identität anschließend anhand von physischem Standort, MAC-Adresse, Modell und Kanalbezeichnungen. Ein vertrauter Anzeigename reicht nicht aus. Geräte behalten Domain-Zugangsdaten über einen Neustart hinweg, daher kann ein veraltetes Enrollment dazu führen, dass ein Gerät auf einem anderen System als nicht verfügbar oder eingeschränkt erscheint.
Takte jedes Subnetz als eine Domain
Alle Geräte in einer Dante-Domain müssen letztlich einem einzigen Domain-Grand-Leader folgen. Innerhalb eines Subnetzes kann Dante den Clock per Multicast-PTP verteilen. Über geroutete Subnetzgrenzen hinweg verwendet DDM geeignete Boundary Clocks, um den Clock per Unicast-PTP zwischen den Subnetzen zu übertragen und ihn dann lokal zu verteilen.
Jedes Subnetz benötigt einen geeigneten aktiven Boundary Clock. Konfiguriere nach Möglichkeit einen sekundären Kandidaten, wenn Plattform und Gerätemix das unterstützen. Wähle Geräte, die stabil und entsprechend geeignet sind und während der Produktion wahrscheinlich nicht ausgeschaltet oder entfernt werden.
| Clock-Zustand | Betriebsrisiko | Erforderliche Reaktion |
|---|---|---|
| Kein Boundary Clock in einem Subnetz | Die Cross-Subnetz-Synchronisation kann ausfallen oder Medien können aussetzen | Vor der Abnahme wiederherstellen oder einen geeigneten Clock zuweisen |
| Nur ein geeigneter Clock | Geplante Strom- oder Netzwerkarbeiten können das Subnetz isolieren | Nach Möglichkeit Backup ergänzen und testen |
| Ungeeignetes Gerät gewählt | Es kann die erforderliche Boundary-Rolle nicht ausführen | Modell-/Plattformfähigkeit vor der Zuweisung prüfen |
| Clock-Änderungen während des Ausfalltests | Audio kann stumm schalten, aussetzen oder langsam neu einrasten | Ereignis erfassen und Design oder Recovery-Erwartung korrigieren |
Der Dante-Guide zum Clock Leader behandelt die Leader-Wahl innerhalb eines Produktionssystems. Die Abnahme über Subnetze hinweg muss zusätzlich die Boundary-Clock-Kette und das Verhalten des Backups belegen.
Erstelle und verifiziere das Abonnement
- Melde dich mit einem Konto an, das für die Ziel-Domain autorisiert ist.
- Wähle in Dante Controller die korrekte Domain aus.
- Bestätige Quelle und Ziel, Formate und Clock-Status.
- Erstelle das vorgesehene namensbasierte Abonnement.
- Warte auf einen stabilen Erfolgszustand; prüfe jede Warnung oder Fehlermeldung, statt die Route blind neu anzulegen.
- Spiele repräsentatives Audio durch und höre an jedem erforderlichen Ziel ab.
- Bestätige Receiver-Latenz, Clock Lock, Paketfehler-Status und Switch-Zähler.
- Wiederhole den Test unter erwartetem Peak Load und prüfe die freigegebene Ausfall- und Wiederherstellungssequenz.
Ein sichtbarer Endpunkt ist nicht dasselbe wie eine nutzbare Route. Das Konto kann nur Leserechte haben, die Geräte können in unterschiedlichen Domains liegen, der Receiver kann ein inkompatibles Format aufweisen oder der Clock-Pfad ist möglicherweise noch nicht bereit. Nutze den Dante-Leitfaden zu Subscription-Fehlern, um den Routenstatus zu interpretieren, bevor du die Infrastruktur veränderst.
Teste Ausfallgrenzen bewusst
Cross-Subnetz-Systeme fügen der Abhängigkeitskette Router, Firewalls, Manager-Dienste, DNS/DHCP und Boundary Clocks hinzu. Teste nur innerhalb eines freigegebenen Wartungsfensters und ändere jeweils nur eine Grenze.
- Trenne das aktive Boundary-Clock-Gerät und bestätige, dass das erwartete Backup übernimmt.
- Unterbrich einen gerouteten Link und erfasse, welche Abonnements, Steuerungen und Clocks betroffen sind.
- Starte einen repräsentativen Endpunkt neu und prüfe die automatische Domain-Wiederverbindung.
- Bestätige autorisierten Controller-Login und Domain-Auswahl nach einem Neustart der Workstation.
- Teste in einem redundanten Design primäre und sekundäre Pfade separat.
- Stelle den Normalzustand wieder her und prüfe echtes Audio, nicht nur grüne Anzeigen.
Bewahre Logs und Zeitstempel auf, bevor du neu startest oder Alarme zurücksetzt. Der Dante-Leitfaden zur Netzwerkgesundheit erklärt, wie sich Link-, Clock-, Latenz- und Fehlernachweise korrelieren lassen.
Cross-Subnetz-Abnahme-Checkliste
- Domain-Umfang und Geräteverantwortung sind dokumentiert.
- Jeder Endpunkt hat die vorgesehene Adresse, Maske, Gateway, Subnetz und den Switch-Port.
- Discovery oder statisches Enrollment ist über jedes Subnetz hinweg nachgewiesen.
- Firewall-Regeln folgen der aktuellen Plattformdokumentation und dem Prinzip des kleinsten erforderlichen Umfangs.
- Quelle und Ziel sind in derselben vorgesehenen Domain enrolled.
- Jedes Subnetz hat einen geeigneten aktiven Boundary Clock und nach Möglichkeit ein getestetes Backup.
- Formate, Samplerate, Latenz, Namen und Redundanzmodus entsprechen dem Design.
- Jedes Abonnement gibt bei repräsentativem Peak Load echtes Audio aus.
- Verhalten von geroutetem Link, Clock, Endpunkt-Neustart und Wiederherstellung ist dokumentiert.
- Owner, Eskalation, Wartungsfenster, Spare Path und Rollback sind klar definiert.
FAQ
Kann Dante über Subnetze routen?
Ja. Eine verwaltete Dante-Domain kann Geräte auf mehreren IP-Subnetzen enthalten und namensbasiertes Medienrouting über geroutete Grenzen hinweg unterstützen, wenn Konnektivität, Enrollment, Berechtigungen und Clocking korrekt geplant sind.
Braucht Dante Domain Manager für mehrere Subnetze?
Klassisches, nicht verwaltetes Dante-Discovery und -Clocking sind auf ein lokales Subnetz ausgelegt. Verwende für eine bewusst geplante Multi-Subnetz-Domain eine unterstützte verwaltete Plattform wie DDM, statt lokales Multicast-Verhalten als improvisierten Workaround zu verlängern.
Wie funktioniert das Dante-Clocking über Subnetze?
Die Domain folgt einem einzigen Grand Leader. Ein geeigneter Boundary Clock in jedem Subnetz überträgt den Clock zwischen den Subnetzen per Unicast-PTP und verteilt ihn lokal. Jedes Subnetz benötigt einen geeigneten aktiven Clock und sollte nach Möglichkeit ein getestetes Backup haben.
Warum sehe ich ein Dante-Gerät, kann aber nicht darauf routen?
Sichtbarkeit beweist weder Autorisierung noch Kompatibilität. Prüfe die ausgewählte Domain, die Kontenrolle, das Enrollment des Geräts, das Quell- und Receiver-Format, den Clock-Status, den Route-Status und ob beide Geräte derselben Domain angehören.
Wie teste ich Dante-Audio über Subnetze hinweg?
Erstelle das freigegebene Abonnement, spiele echtes Audio durch, prüfe Clock, Latenz, Fehler und Switch-Zähler und teste dann Peak Load und jeweils nur eine Ausfallgrenze. Verifiziere die Wiederherstellung und den zurückgekehrten Audio-Pfad vor der Abnahme.
Übergib das geroutete Design an die Produktion
Dokumentiere Domains, Subnetze, Gateways, Discovery-Methode, Firewall-Verantwortung, Boundary Clocks, Abonnements, Formate, Ausfalltests und Rollback in Techrider.live. Lade die verantwortlichen Ingenieure ein, denselben Rider zu bearbeiten, das akzeptierte Design zu speichern und die Historie vor Systemänderungen zu prüfen.
Ähnliche Anleitungen
AES3 vs. analoges Audio im Live-Sound: die richtige Verbindung wählen
Vergleiche AES3 und analoge Audioverbindungen für Live-Sound – inklusive Kanälen, Verkabelung, Clocking, Patchen, Testen und Fallback-Planung.
8 Min. LesezeitGrundlagenAktive vs. passive PA-Lautsprecher für Live-Sound
Vergleiche aktive und passive PA-Lautsprecher nach Verstärkung, Stromversorgung, Verkabelung, DSP, Einsatz, Service und den Details, die ein Technical Rider festhalten sollte.
7 Min. LesezeitGrundlagenAnaloger Split vs. digitale Stagebox: So wählen Sie die richtige Live-Audio-Übergabe
Vergleichen Sie analoge Mikrofon-Splits und digitale Stageboxes für FOH, Monitore, Recording und Broadcast – inklusive Gain-Verantwortung, Redundanz, Verkabelung und Rider-Dokumentation.
8 Min. Lesezeit