Monitoring und Fehlersuche im Veranstaltungsnetzwerk

Da ein Netzwerk ungleich viel mehr Aufgaben erledigen kann und meist auch wesentlich größere Ausmaße annimmt – ansonsten hätte man ja die standardmäßige DMX-512-Verkabelung vorgezogen – ist die Fehlersuche durch die Komplexität auch ein wenig aufwendiger. Auch sollte man noch über die Übertragungscharakteristika zwischen Broadcast (UDP) und Peer to Peer bzw. Multicast (TCP) unterscheiden, da sie im Netzwerk unterschiedliche Erscheinungsbilder beim Monitoring bilden. Aber nun erst mal an die Wurzel:

 

Netzwerkfehler erkennen

Der einfachste Fehler, den man suchen kann, ist natürlich ein Fehler, der konstant vorhanden ist. Man erkennt sofort, dass man den Fehler behoben hat. Dagegen sind Fehler, die nur sporadisch auftreten wie z. B. ein Wackelkontakt, nicht nett.

So kann z. B. ein ruckelndes oder stehendes LED-Bild zwar vorgaukeln, dass das Netzwerk in Ordnung ist, da ja alle Geräte miteinander kommunizieren, denn es ist ja ein Bild zu sehen. Dennoch ist hier z. B. das Ruckeln oder gar Einfrieren ein typisches Anzeichen dafür, dass der Datendurchsatz im Netzwerk nicht stimmt. Medienserver und Pult sind wahrscheinlich nicht das Problem.

Auch wenn die einzelnen Netzwerkstationen mal miteinander verbunden sind und dann mal nicht, ist das wahrscheinlich kein Pultproblem, sondern ein Netzwerkproblem. Am Beispiel von MA-Net kann man z. B. sagen, dass dort ein „Bin noch am Leben“-Signal über das Netz gesendet wird. Dies wird benötigt, damit das System erkennt, wenn eine Komponente ausgefallen ist, um dann wie beim Ausfall eines rechnenden Netzwerkknotens (NDP) die Gegenmaßnahmen zur Neuverteilung der Rechenleistung auf andere rechnende Netzwerkknoten zu veranlassen, damit das System Lichtsprung-frei weiterarbeitet.

Wurde dann das „Bin noch am Leben“-Signal aufgrund eines Netzwerkfehlers zu spät gesendet, meldet das Pult, dass das Gerät die Session verlassen hat. Somit vermutet man, dass das Gerät das Problem darstellt und nicht das Netzwerk, denn das hat ordnungsgemäß eine Meldung veranlasst.

Auch wenn man ein stabil stehendes Netzwerk aufgebaut hat, kann es vorkommen, dass sich im Laufe der Zeit (der fortlaufenden Programmierung der Show) plötzlich ein Ruckeln bei den Überblendungen einstellt oder Geräte sich ab- und wieder anmelden. Auch hier sind weniger die Geräte selbst gestört, sondern durch das Arbeiten an der Show werden die Showdateien, die übertragen werden müssen, immer größer. Und so kann es vorkommen, dass zu Beginn das Showfile der Anlage und die Übertragung von 8 DMX-Universen über ArtNet einwandfrei funktioniert haben. Aber nachdem das Showfile so groß geworden ist und eventuell noch ein paar LED-Panels dazugekommen sind, benötigt das Ganze zu viel Übertragungszeit zusammen mit der ArtNet-Übertragung und das Netzwerk kann dann einbrechen.

Reihenfolge bei der Fehlersuche

Eine systematische Suche kann man anhand des OSI-Schichtenmodells vornehmen und sich Schicht für Schicht dem Problem nähern. Dabei hat sich gezeigt, dass es oft sinnvoll ist, nicht in der Anwendungsebene zu beginnen – zumal dort auch die meisten Möglichkeiten vorhanden sind etwas zu verstellen – sondern man startet besser unten von der Basis aus.

Um sicher vom kleinen auf größere Systeme zu „wachsen“, kann man auch erst mal zwei Geräte mit einem Crossover-Kabel verbinden. Laufen diese beiden Geräte einwandfrei, kann das  System schrittweise erweitert werden. Man fügt dann den Switch ein. Achtung: Crossover-Kabel weglegen und nun normale Patchkabel verwenden!

Mit einem Switch ist auch bereits ein Tool zur Hand, mit dem man die Ports betrachten und damit bereits auf den Zustand der Kabel Rückschlüsse ziehen kann. Aber auch die Status-LEDs an den Ports zeigen an, ob auf der Hardwareseite alles in Ordnung ist. Die LEDs an den Ports bzw. direkt neben den Ethernet-Steckverbindern der Ethernet-Karten zeigen sehr zuverlässig die hardwareseitige Verbindung an. Es ist kaum ein Fall bekannt, dass diese LED-Anzeige mal defekt war. Also: die LEDs der Netzwerkkarten kontrollieren, ob sie erwartungsgemäß blinken. Wenn trotz funktionierender Kabel die Geräte nicht miteinander kommunizieren, kann man die Adressierung prüfen. Eigentlich alles, was beim DMX auch zu machen ist. Nur prüfen wir nun den IP-Adressraum. Die IP-Adressen und die Subnet-Mask sind bei den angeschlossenen Geräten zu erfragen oder bereits über Funktionen vom Switch. Dann muss man die Switch-Einstellungen kontrollieren, ob z. B. ein V-LAN eingestellt ist oder eine Strom-Protection oder, oder, oder. Weiterhin, ob die eingestellten Ports für V-LAN 1 auch mit den Geräten für das V-LAN angeschlossen sind, denn jetzt darf man nicht mehr alles einfach in den Switch reinstecken wie es kommt, sondern muss die Ports benutzen, die zum eingestellten virtuellen LAN gehören. Manchmal hilft auch ein Reset am Switch oder das Einstellen der Werkseinstellung (Default-Werte), um das Problem zu lösen. Letztendlich auch den Switch mal austauschen. Schließt man einen Laptop mit einem Windows-Betriebssystem an, so liefert Windows zwei Programme mit, die auf unterster Ebene die Kommunikation überprüfen können.

Mit ipconfig sind die Einstellungen des eigenen Rechners auszulesen und mit Ping die einzelnen Verbindungen zu überprüfen. Ist die Hardware OK, folgen die Software und die Konfigurationen, die so vielfältig und schnell geändert werden, dass dies hier nicht erläutert werden kann.

Kabel

Werden Kabel im Installationsbereich verlegt, erfolgt danach eine Messung des Kabels. Die Messergebnisse sind dann in der Zertifizierung wiedergegeben. Es gibt verschiedene Stufen wie Cat.3, Cat.5, Cat.5e usw. Wenn das Kabel länger als 100 m ist, wird es automatisch zum Cat.3 Kabel, also ein Kabel für maximal 10 MBit/s. Interessant ist hierbei die Tatsache, dass für flexible Kabel wie wir sie in der Eventtechnik nutzen, die Segmentlänge nicht 100 m beträgt. Die Ursache liegt darin, dass man bei festverlegten Kabeln mit starren Adern, die aufgrund der starren Adern bessere elektrotechnische Eigenschaften aufweisen, eine 90-m-Strecke definiert hat, an deren Enden je ein 5 m langes, flexibles Verbindungskabel angebracht werden kann und somit 100 m im Ganzen ergibt. Im fliegenden Betrieb mit flexiblen „EtherCon-Kabeln“ können wir mit den flexiblen Litzen nur bis ca. 75 m gehen, wenn man bei 100 Mbit/s keine Paketverluste erleiden will. Werden aufgrund zu langer Kabelwege zu viele Pakete „verschluckt“, dann kann z. B. das bewegte Bild einfrieren oder springen. Das ist auch die Art von Fehlern, bei denen dann sporadisch mal einige Geräte von einer Session abspringen. Werden dennoch größere Strecken benötigt, kann man immer noch auf Glasfaser gehen. Die Glasfaserklasse kann 550 m im Multimode-Betrieb ohne Repeater schaffen. Im Singlemode sind auch 2 bis 10 km von Gerät zu Gerät zu überbrücken und damit auch die größten Themenparks wie Disney World zu handeln.

Auch ist auf Baustellen die Unsitte zu beobachten, dass Kabel für Festverlegung eingesetzt werden. Gut, deren elektrotechnische Eigenschaft ist zwar besser, aber spätestens nach zweimal Aufwickeln ist der Kabelbruch einer Ader doch sehr wahrscheinlich. Man sollte Kabel für die Veranstaltungstechnik in roadtauglicher Ausführung einsetzen. Bei Patchkabeln muss man auch damit rechnen, dass da jemand mal auf das Kabel tritt und bei diesen Querschnitten ist das sehr leicht beschädigt. Auch der Steckverbinder sollte dann als EtherCon ausgeführt sein.

Aber Kabel für Digitalsignale, die mit 100 Mbit/s übertragen werden, sind leider tückischer. Wie im Abschnitt Kabel bereits definiert, kann ein defektes oder Kabel von minderer Qualität sich so verhalten, dass es z. B. mit 10 m sehr gut überträgt, aber bereits nach 90 m wegen der Dämpfung sehr viele Signalrechtecke fehlinterpretiert werden und somit eine fehlerhafte Vermittlung stattfindet. Leider wird dann von dem System gemeldet, dass ein Protokollproblem vorliegt und nicht, dass das Kabel das Protokoll kaputt macht.

Switch

Es ist schon erstaunlich, dass bei Produktionen für 10.000 € und mehr netzwerkfähige Pulte zusammengeschaltet werden, für 100.000 € LED-Matrixwände aufgestellt werden, 300 Moving Lights dabeistehen, und das alles soll mit einem zentralen Gerät für den Datendurchsatz koordiniert werden, nennen wir es mal Switch. Der darf dann nicht mehr als 50 € kosten und den kauft man sich beim Discounter, denn dort hat man ihn ja günstig gesehen. Dass damit die Show auf die Nase fallen wird, ist vorprogrammiert. Abgesehen davon, dass diese Plastik-Switche nur für das Heimnetzwerk brauchbar, aber für unsere Zwecke hoffnungslos überlastet sind, abgesehen von dem schlecht abgeschirmten und nicht 19″-fähigen Plastikgehäuse und separatem Steckernetzteil made in China – aber für besonders wenig Geld. Hier muss man die Verantwortlichen ruhig mal schütteln, denn ein ordentlicher managebarer Switch, der auch einen ordentlichen Traffic auf dem Backbone erlaubt, kostet auch nicht mehr als 400 € und das ist immer noch ein Bruchteil der Pulte oder LED-Wände oder Moving Lights, die an den Start gehen.

Bei großen professionellen Shows werden oft Procurve Switche von HP eingesetzt. Diesen kann man über Ethernet mit einem Laptop verbinden und per Browser die Konfiguration komfortabel einstellen und viel mehr noch, man kann sehen, was dort auf dem Switch so alles angeschlossen ist und mit welcher Geschwindigkeit die Übertragung erfolgt. Wird z. B. an einem Port 10 Mbit angezeigt, obwohl dort eigentlich ein 100-Mbit-Gerät sein sollte, so kann man davon ausgehen, dass das Kabel zu viel dämpft, also defekt ist, oder dass der Port am Switch ein Problem hat – nächsten Port probieren. Natürlich muss man auch wissen mit welcher Geschwindigkeit das eingesetzte Gerät arbeiten muss. Beispielsweise ist ein alter ArtNet-Node, der auf 10 Mbit/s arbeitet, hoffnungslos überfordert bei einem 100 Mbit/s MA-Net, da er gar nicht so viele Informationen ignorieren kann, wie er müsste. Auch der Wille, das 100-Mbit/s-Netzwerk über WLAN zu übertragen, ist nicht von Erfolg gekrönt.

Für den Procurve Switch ist auch ein Management-Programm verfügbar, das sehr viele Analyse-Funktionen beinhaltet. Man kann anhand des Traffics z. B. erkennen, wenn ArtNet alles mit seinem Broadcast belegt und ein paralleles Protokoll wie z. B. MA-Net nicht rechtzeitig dazu kommt sein Lebenszeichen zu versenden. Dann macht es z. B. Sinn beide Protokolle auf getrennten Wegen zu übermitteln. Dazu benötigt man nicht unbedingt einen weiteren Switch, sondern es reicht, ein V-LAN einzurichten.

 

Heute verwendet man gerne den HP Pro Curve SX LC Mini GBIC. Der Unterschied zu HP Pro Curve LX LC Mini GBIC ist, dass nur Multimode-LWL benutzt und somit nur Reichweiten von 550 m überbrückt werden können. Dies reicht aber für die meisten Projekte aus.

IPconfig

Um bei Problemen wenigsten festzustellen, dass bis zur TCP/IP-Ebene alles funktioniert, liefern Windows-Systeme über das DOS-Fenster Diagnoseprogramme an. Mit Ipconfig kann man die Einstellungen des eigenen Rechners auslesen.

 

Ping

Mit Ping und der Adresse des zu testenden Pults erhält man vom Testobjekt ein Replay. Hat man dieses erhalten, weiß man, dass die Hardware OK ist. Ansonsten hilft zur Fehlereingrenzung auch ein Blick auf die blinkenden Netzwerkkarten-LEDs.

Weitere Möglichkeiten der Fehlersuche

Ethereal (Wireshark)

Ethereal ist eine Freeware, die es in sich hat und ungemein hilft, Probleme im Netzwerk aufzuspüren. Die Anleitung ist auch unter Wikipedia abgelegt. Man sollte sich frühzeitig mit diesem Programm auseinandersetzen, damit man dann anschließend im Problemfall auch weiß was zu tun ist, denn es wird alles protokolliert, und dann muss man wissen, welche Protokolle für was benötigt werden.

So kann man die Zeitdifferenz der Übertragung zwischen Universe 1 und 121 sehen, wobei die Zeitdifferenz natürlich eine endliche Zeitspanne ist, aber immerhin nur so klein sein darf, dass das menschliche Auge diese Verzögerung nicht wahrnimmt. Der Protokoll-Sniffer geht dagegen sehr tief in die Netzwerk-Stacks im Rechner und dann sollte man Filter für die Protokolle wie ArtNet, ETC Net usw. angelegt haben, da ansonsten sämtliche Einträge, die in die Tausende gehen, angezeigt werden. Dagegen benötigen wir nur die Informationen der ArtNet- oder MA-Net-Pakete. Um an die Protokolle heranzukommen, muss man den Kontakt zu den Herstellern suchen, die dies bereits anbieten, zwar nicht alle, aber immerhin von den wichtigsten sind sie verfügbar. Aber man kann sich auch über Port-Tabellen weiterhelfen, bei denen eine Zuordnung welcher Port z. B. Multicast zugeordnet ist, angezeigt wird. Daraus sind zur Not auch eigene Filter zu bauen.

 

Netzwerkanalyse-Messgerät

Bei schwer aufzufindenden Fehlern benötigt man ein Netzwerkanalyse-Messgerät wie z. B. das Fluke networks EtherScope Serie II aus der 8.000-Euro-Klasse. Das Gerät arbeitet ähnlich wie Ethereal, ist allerdings vollkommen unabhängig von vorhandener Hardware und jederzeit einsetzbar. Man erhält darüber hinaus noch eine Bandbreitenauslastung in Prozent angezeigt und kann nach Protokollen sortieren, um z. B. zu sehen, dass an dieser Stelle ein Broadcaststurm vorhanden ist, der das Netzwerk einfach lahmlegt. Broadcast ist ja eine typische ArtNet-Eigenschaft und so kann man vermuten, dass der Medienserver, der das Pixelmapping ausgibt, auf den falschen Port oder Switch gesteckt wurde.

 

 

 

---

Mehr Themen zu Netzwerktechnik und Protokollen werden auf folgenden Seiten behandelt:

• Kabel und Leitungen
• Simplex, Dublex, Analog- oder Digitalsignal
• DMX 512 – Merger und Splitter
• DMX 512 mit dem Oszi gemessen
• RDM
• ACN
• Weitere Protokolle in der Lichttechnik
• Architekturprotokolle
• Ethernet, Topologie, CSMA/CA-Verfahren, Token, Osi-Schichtenmodel, V-Lan, Spanning Tree, Geräte
• TCP, UDP, Multicast, Broadcast, Unicast, Multiuser, Echtzeit
• MAC-Adressierung, IP

Eine Übersicht aller Themen finden Sie Hier.