Dante-Geräte werden in Controller nicht angezeigt: So findest du fehlende Geräte

Kurzfassung — Dante-Geräte melden ihre Identität und Kanäle normalerweise automatisch an, aber die Erkennung hängt davon ab, dass der Controller-Computer die richtige Netzwerkschnittstelle verwendet und den korrekten Discovery-Scope teilt. Beginne mit Stromversorgung und physischer Verbindung, prüfe dann die Interface-Auswahl in Controller, die Adressierung von Computer und Gerät, Primary-vs.-Secondary-Verkabelung, VLAN- oder Subnetz-Grenzen, Firewall-Richtlinien und den Login in ein Managed Network. Behebe zuerst die früheste fehlgeschlagene Grenze, bevor du Routen, Namen, Clocking oder Audio-Einstellungen änderst.

Discovery passiert vor dem Routing

Dante Controller kann Audio erst routen, nachdem die Endpunkte entdeckt wurden. Ein Gerät meldet seinen Namen, seine Kanäle, Fähigkeiten und Formatinformationen an; Controller liest diese Informationen aus und zeigt sie in der Network View an.

Wenn das Gerät fehlt, sind Subscription-Änderungen nicht der erste Schritt. Die Ursache liegt früher: physische Verbindung, Auswahl der richtigen Computer-Schnittstelle, Adresskompatibilität, Discovery-Traffic, Netzwerk-Scope oder Management-Anmeldung.

Nutze einen festen Discovery-Workflow

1. Stromversorgung und physische Verbindung prüfen

Prüfe die Stromversorgung des Endpunkts, die Netzwerk-LEDs, den richtigen Dante-Port, das Kabel, den Switch-Port und die ausgehandelte Geschwindigkeit. Bestätige, dass der Switch-Port aktiviert und dem vorgesehenen Netzwerk zugeordnet ist. Vergleiche das Verhalten mit einem funktionierenden Gerät am selben Switch.

Starte nicht damit, alle Switches neu zu starten. Ein einzelnes fehlerhaftes Gerät verlangt normalerweise zuerst einen Nachweis auf Geräteebene.

2. Die Controller-Schnittstelle prüfen

Dante Controller merkt sich seine ausgewählten primären und sekundären Computer-Schnittstellen. Ein Laptop kann also dem richtigen Ethernet-Netzwerk beitreten, während Controller weiterhin WLAN, einen Dock-Adapter, eine VPN-Schnittstelle oder eine andere NIC verwendet.

Öffne den Interface-Auswahldialog und identifiziere den Adapter anhand von Name, Link und Adresse. In einem normalen primär-only Netzwerk wähle die kabelgebundene Schnittstelle, die mit diesem Netzwerk verbunden ist. Wenn der Computer mehrere kabelgebundene Adapter hat, vermeide es, zwei davon im selben IP-Subnetz zu betreiben.

Der Dante Controller-Leitfaden zur Netzwerkschnittstelle behandelt Multi-NIC- und Redundanz-Entscheidungen.

3. Adressschemata vergleichen

Computer und Endpunkte müssen für das Netzwerkdesign kompatible Adressierung verwenden. In einem Standalone-Primary-Netzwerk ohne DHCP verwenden Link-Local-Adressen normalerweise 169.254.x.x. Mit DHCP sollten Computer und Geräte dem freigegebenen DHCP-Scope folgen. Statische Adressen müssen das vorgesehene Subnetz, die Maske und die Gateway-Policy verwenden.

Nutze Device Info, sobald Geräte sichtbar sind, und prüfe die Adressierung der Betriebssystem-Schnittstelle. Werte eine einzelne 169.254-Adresse nicht vorschnell als Fehler; Link-Local-Adressierung ist in einem einzelnen Standalone-Netzwerk gültig.

Folge dem Dante-Leitfaden zur IP-Adressierung, bevor du DHCP- oder statische Einstellungen änderst.

4. Primary- und Secondary-Netzwerke trennen

In redundanten Dante-Systemen sind Primary und Secondary getrennte physische Netzwerke. Verbinde die beiden Switches nicht miteinander. Verbinde die primäre Dante-Schnittstelle des Computers mit dem Primary-Netzwerk und, wenn zwei NICs verfügbar sind, die sekundäre Schnittstelle mit dem Secondary-Netzwerk.

Mit nur einer Computer-NIC nutze das Primary-Netzwerk für die normale Steuerung. Ein Wechsel auf das Secondary-Netzwerk während eines Ausfalls erfordert ebenfalls eine Änderung der Interface-Auswahl in Controller. Ein Zugriff nur über Secondary kann eine eingeschränkte Identität sichtbar machen, verhindert aber die volle Steuerung von Geräten, die nur auf Primary vorhanden sind.

5. VLAN- und Subnetz-Grenzen beachten

Unmanaged Discovery ist normalerweise eine Funktion des lokalen Netzwerks. Ein Gerät in einem anderen VLAN oder IP-Subnetz kann völlig gesund sein und dennoch außerhalb des Discovery-Scopes des Controller-Computers liegen. Füge keinen ad hoc mDNS-Reflector hinzu und flache Produktions-VLANs nicht einfach ab, nur damit ein Symbol erscheint.

Multi-Subnet-Systeme benötigen ein bewusst geplantes Managed Design, etwa Dante Domain Manager oder Dante Director, mit Routing, Discovery, Clocking, Enrollment und Berechtigungen unter Verantwortung des Netzwerkadministrators. Link-Local-Adressierung und lokales mDNS sind für einfachere Single-Subnet-Systeme geeignet; sie sind kein Ersatz für eine geroutete Netzwerkarchitektur.

6. Host-Sicherheit und konkurrierende Software prüfen

Bestätige, dass die Firewall des Betriebssystems und die Endpoint-Sicherheitsrichtlinie die freigegebenen Dante-Anwendungen und den Discovery-Traffic im ausgewählten Netzwerkprofil zulassen. Das temporäre Deaktivieren aller Schutzfunktionen ist kein akzeptabler Produktions-Fix. Dokumentiere die blockierte Regel, setze die eng gefasste freigegebene Ausnahme und stelle die Basislinie wieder her.

Prüfe außerdem VPN-Software, Virtualisierungsadapter, Internetfreigabe und Hersteller-Utilities, die die Schnittstellenpriorität ändern oder die ausgewählte Dante-Schnittstelle teilen können.

7. Managed-Network-Zugriff bestätigen

In einer Managed-Umgebung prüfe, ob Controller mit der richtigen Dante Domain Manager-Domain oder Dante Director-Site verbunden ist und ob der Operator die Berechtigung hat, das Gerät zu sehen oder zu konfigurieren. Unterscheide zwischen einem unmanaged lokalen Gerät, das noch auf Enrollment wartet, und einem enrolten Gerät, das das aktuelle Konto nicht verwalten darf.

Setze ein Gerät nicht auf Werkseinstellungen zurück, um Eigentumsrechte zu umgehen. Eskaliere an den benannten Domain- oder Site-Administrator.

Diagnose nach Scope, nicht nach Bauchgefühl

Nutze funktionierende Vergleiche, um den Fehlerbereich einzugrenzen:

1. Sieht derselbe Computer ein anderes Gerät an diesem Switch?
2. Sieht ein anderer freigegebener Computer das fehlende Gerät?
3. Erscheint das Gerät, wenn es an einen bekannten guten Port im selben VLAN gesteckt wird?
4. Ist der Fehler auf Primary, Secondary, ein Subnetz oder eine Site begrenzt?
5. Begann es nach einer Änderung an Dock, VPN, DHCP, VLAN, Firmware oder Management?

Ändere nur eine Variable und dokumentiere das Ergebnis. Wenn Discovery zurückkehrt, prüfe den Gerätenamen, den Kanalbestand, die Adresse, den Clock-Status und echtes Audio, bevor du von Wiederherstellung sprichst.

Discovery-Übergabe dokumentieren

Dokumentiere:

• Gerätename, Modell, Firmware, MAC-Adresse und physische Position;
• Primary- und Secondary-Ports, Switches, VLANs und Adressschemata;
• Controller-Computer, Adaptername und ausgewählte Interface-Rolle;
• DHCP-, statische oder Link-Local-Zuständigkeit;
• Managed Domain oder Site und verantwortlichen Administrator;
• funktionierenden Discovery-Scope und bekannte Einschränkungen;
• getestetes Fehlverhalten, Wiederherstellung, Ersatz- und Rollback-Verfahren.

Bewahre Zugangsdaten und sensible Netzwerkdetails außerhalb eines öffentlichen Riders auf. Lege die operative Zusammenfassung und die Eigentumsgrenze im digital audio network tech rider ab.

Dante-Discovery-Checkliste

• Stromversorgung, Link, Kabel, Port und ausgehandelte Geschwindigkeit des Endpunkts sind in Ordnung.
• Controller verwendet die vorgesehene kabelgebundene Netzwerkschnittstelle.
• Adressen von Computer und Endpunkt entsprechen dem freigegebenen Design.
• Primary- und Secondary-Netzwerke bleiben physisch getrennt.
• VLAN- und Subnetz-Scope stimmen mit der Management-Architektur überein.
• Firewall, VPN und virtuelle Adapter werden geprüft, ohne breit zu deaktivieren.
• Domain- oder Site-Login und Berechtigungen haben einen benannten Owner.
• Geräteidentität, echtes Audio, Recovery und Rollback sind verifiziert.

Häufige Fehler

Subscriptions bearbeiten, bevor der Endpunkt sichtbar ist. Routing kann keine Discovery-Grenze reparieren.

Annehmen, dass Link-Local kaputt bedeutet. 169.254.x.x ist auf einem Primary-Netzwerk ohne DHCP zu erwarten.

Primary und Secondary brücken. Redundante Netzwerke müssen getrennt bleiben.

Discovery-Traffic ohne Design reflektieren. Dante über Subnetze hinweg erfordert Managed Routing, Clocking, Enrollment und Sicherheit – nicht nur weitergeleitete Ankündigungen.

Ein enroltes Gerät zurücksetzen. Ein Berechtigungsproblem braucht den System-Owner, nicht eine gelöschte Konfiguration.

FAQ

Warum zeigt Dante Controller keine Geräte an?

Häufige Ursachen sind die falsche Computer-Schnittstelle, fehlende physische Verbindung, inkompatible Adressierung, ein falsches VLAN, eine Discovery-Grenze zwischen Subnetzen, Firewall-Richtlinien oder fehlender Zugriff auf die Managed Domain oder Site.

Wie funktioniert Dante Device Discovery?

Dante-Endpunkte kündigen Identität, Kanäle und Fähigkeiten automatisch im Netzwerk an. Controller lauscht auf der ausgewählten Dante-Schnittstelle und listet Geräte innerhalb des jeweils gültigen lokalen oder Managed-Discovery-Scopes auf.

Funktioniert Dante Discovery über Subnetze hinweg?

Normales unmanaged Discovery ist lokal begrenzt. Der Betrieb über mehrere Subnetze benötigt ein bewusstes geroutetes Design und eine unterstützte Management-Plattform mit den erforderlichen DNS-, Enrollment-, Routing-, Clocking- und Berechtigungsfunktionen.

Warum kann ich ein Dante-Gerät sehen, aber nicht konfigurieren?

Der Computer ist möglicherweise nur mit einem sekundären Pfad verbunden, oder das Gerät ist in eine Managed Domain oder Site eingebunden, in der das aktuelle Konto keine Berechtigung zur Konfiguration hat.

Wie behebe ich ein fehlendes Dante-Gerät?

Prüfe Strom und Link, die Controller-Interface-Auswahl, die Adressen von Computer und Gerät, die Primary-/Secondary-Verkabelung, VLAN- und Subnetz-Scope, Host-Security und danach den Managed-Network-Login. Behebe immer nur eine Grenze auf einmal und bestätige anschließend echtes Audio.

Mach die Ownership von Discovery sichtbar

Fehlende Geräte lassen sich schneller wiederherstellen, wenn der Rider das Netzwerk, die Interface-Rolle, den Adress-Owner, den Management-Owner und die getestete Fallback-Route benennt. Baue diese Übergabe in Techrider.live ein, damit die aktuellen Netzwerknachrichten, die Kanalliste, der Bühnenplan und die Recovery-Nachweise in einem Rider bleiben, den Mitarbeitende bearbeiten, speichern und über die Historie prüfen können.