| Netzwerk
- Monitoring und Fehlersuche |
Da ein Netzwerk
ungleich viel mehr Aufgaben erledigen kann, und meist auch wesentlich größere
Außmasse annimmt, ansonsten hätte man ja die standardmäßige
DMX512 Verkabelung vorgezogen, ist durch die Komplexibilität die Fehlersuche
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 zurück an die Wurzel: |
|
Netzwerkfehler
erkennen
Der Einfachste Fehler den man Suchen Kann, ist natürlich ein Fehler,
der konstant vorhanden ist. Man erkennt sofort, das man den Fehler behoben
hat. Dagegen sind Fehler die nur sporadisch auftreten wie ein Wackelkontakt
nicht nett.
So kann z.B. eine Ruckelndes oder stehendes LED-Bild zwar vorgaukeln,
das das Netzwerk in Ordnung ist, da ja alle Geräte miteinander kommuniezieren
denn es ist ja ein Bild zu sehen. Dennoch ist hier z.B. das Ruckeln oder
gar das Einfrieren ein typisches Anzeichen dafür das der Datendurchsatz
im Netzwerk nicht stimmt. Medienserver und Pult sind warscheinlich nicht
das Problem.
Auch wenn die einzelnen Netzwerkstationen mal miteinander verbunden sind
und dann mal nicht, ist das warscheinlich kein Pultproblem, sondern ein
Netzwerkproblem. Am Beispiel von MA-Net kann man z.B. sagen das 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
anderer rechnende Netzwerkknoten zu veranlassen, damit das System Lichtsprungfrei
weiterarbeitet. Wurde dann das "Bin noch am Leben" Signal aufgrund
eines Netzwerkfehlers zu spät gesendet, meldet das Pult das das Gerät
die Session verlassen hat. Somit vermutet man das das Gerät
das Problem darstellt und nicht das Netzwerk, denn das hat ordnungsgemäß
eine Meldung veranlaßt.
Auch wenn man ein Stabiel stehendes Netzwerk aufgebaut hat, kann es vorkommen,
das 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 wind weniger die Geräte
selbst nicht gestört, sondern durch das arbeioten an der Show werden
die Showdateien die Übertragen werden müssen immer größer.
Und so kann es vorkommen, daszu 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 evtl noch
ein Par LED-Panele noch dazugekommen sind , benötigt dies zuviel
Übertragungszeit zusammen mit der Artnetübertragung und das
Netzwerk kann dann einbrechen.
|
|
Reinfolge
bei der Fehlersuche
Eine Systematische Suche kann man anhand des OSI-Schichtenmodelles
vornehmen und sich Schicht für Schicht dem Problem nähern. Dabei
hat sich gezeigt, das es oft sinnvoll ist nicht in der Anwendungsebene
zu beginnen, zumal dort auch die meisten Möglichkeiten vorhanden
sind etwas zu verstellen, sondern besser man startet unten von der Basis
aus.
Um sicher von kleinem auf größere Systeme zu "wachsen",
kann man auch erst mal zwei Gerät mit einem Crossoverkabel
verbinden. Laufen diese beiden Geräte einwandfrei, kann man dann
sein System schrittweise erweitern. Mann fügt dann den Switch
ein. Achtung, Crossoverkabel weglegen und nun normale Patchkabel verwenden.
Mit einem Switch hat man auch bereits ein Tool zur Hand, mit dem man die
Ports betrachten kann und kann damit bereits auf den Zustand der Kabel
rückschießen. Aber auch die Status-LEDs an den Ports
zeigen an, ob auf der Hardewareseite alles in Ordnung ist. Die LEDs an
den Ports bzw. direkt neben den Ethernetsteckverbindern, der Ethernetkarten
zeigen sehr zuverlässig die Hardewarseitige Verbindung an. Es ist
kaum ein Fall bekannt, das 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
kommuniezieren kann man die Adressierung Prüfen. Eigentlich alles,
was man beim DMX auch gemacht hat. 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 Switcheinstellungen kontrollieren ob z.B. ein V-LAN
eingestellt ist oder eine Strom-Protection oder oder. Bzw. ob die eingestellten
Ports für V-LAN 1 auch mit den Geräten für das V-Lan angeschlossen
ist. 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 zugehören. Manchmal hilft auch ein Reset am Switch oder das Einstellen
der Werkseinstellung (default-werte) um das Problem zu lösen. Letzendlich
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
kann man die Einstellungen des eigenen Rechners auslesen und mit mit Ping
kann man die einzelnen Verbindungen überprüfen.
Ist die Hardeware OK, folgt die Software und die Configurationen, die
so vielfältig und schnell geändert werden, das dies hier nicht
erläutert werden kann.
|
|
Kabel
Werden Kabel im Installationsbereich verlegt werden, 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 100m ist, wird es automatisch zum Cat 3
Kabel also ein Kabel für maximal 10 MBit/s. Interessant ist hierbei
die Tatsache das für flexible Kabel wie wir Sie in der Eventtechnik
nutzen, die Segmentlänge nicht 100m beträgt. Die Ursache liegt
darin, das man bei festverlegten Kabeln mit starren Adern, die aufgrund
der starren Adern bessere elektrotechnische Eigenschaften aufweisen, eine
90m strecke definiert hat, an deren Enden je ein 5m flexibles Verbindungskabel
angebracht werden kann und somit 100m im ganzen erfolgt. Im fliegenden
Betrieb mit flexilblen "Ethercon-Kabeln" können wir mit
den flexiblen Litzen nur bis ca. 75m gehen, wenn man bei 100Mbit/s
keine Paketverluste erleiden will. Werden aufgrund zu langen Kabelwege
zu viele Pakete "verschluckt", dann kann z.B. das bewegte Bild
einfrieren oder springen. Das sind auch die Art von Fehlern, bei denen
dann sporadisch mal einige Geräte von einer Session abspringen. Benötigt
man dennoch größere Strecken kann man immer noch auf
Glasfaser gehen. Die Glasfaserklasse kann 550m schaffen im Multimode-Betrieb
ohne Repeater. Im Singelmode sind auch 2 Km bis 10 Km überbrücken
von Gerät zu Gerät und damit sind auch die größten
Themenparks wie Disney World zu händeln. Auch ist auf Baustellen
die Unsitte zu beobachten das Kabel für Festverlegung eingesetzt
werden. Gut deren elektrotechnische Eigenschaft ist zwar besser, aber
spätestens nach zwei mal aufwickeln ist der Kabelbruch einer Ader
doch sehr wahrscheinlich. Mann sollte Kabel für die Veranstaltungstechnik
in Roadtauglicher Ausführung einsetzen wie sie z.B. von Connex oder
Sommer. Bei Patchkabeln muss man auch damit rechnen, das 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.
Ein Kabel mit Leiterbruch oder verdrehten Kabeln ist schnell mit einem
Durchgangsprüfer wie folgt abgebildet schnell getestet.
Einfachster preiswerter Durchgangstester
entdeckt Kabelbrüche Crosskabel und Verdrahtungsfehler
Aber Kabel für Digitalsignale die mit 100Mbit/s übertragen werden
sind leider tückischer. Wie im Abschnitt Kabel bereits definiert,
kann ein defektes oder Kabel oder minderer Qualität sich so verhalten,
das es z.B. mit 10m sehr gut überträgt, aber bereits nach 90m
wegen der Dämpfung sehr viele Signalrechtecke fehlinterpretiert werden
und somit eine fehlerhafte Vermittlung stattfindet. Leider wird dann von
dem System gemeldet, das ein Protokollproblem vorliegt und nicht das das
Kabel das Protokoll kaput macht.
|
|
Switch
Es ist schon erstaunlich, das Bei Produktionen für 10.000 und
mehr Netzwerkfähige Pulte zusammengescahltet werden, für 100.000
LED-Matrixwäde aufgestellt werden, 300 Movinglights dabei stehen,
und das alles soll koodieniert werden mit einem Zentralen Gerät für
den Datenduchsatz, nennen wir es mal switch, der dann nicht mehr als 50
kosten darf und den man sich beim Discounter kauft, denn dort hat man
Ihn ja günstig gesehen. Das Damit die Show auf die Nase fallen wird
ist vorprogrammiert. Abgesehen das diese Plasik-Switche nur das Heimnetzwerk
brauchbar sind, aber für unsesre Zwecke hofnungslos überlastet
sind, abgesehen von dem schlecht abgeschirmten und nicht 19" fähigen
Plasitikgehäuse und separaten Steckernetzteil made in china für
besonders wenig Geld. Hier muss man die Verantwortlichen ruhig mal schütteln,
denn ein ordenlicher managebarer Switch der auch einen ordentlichen Trafik
auf dem Backbone erlaubt kostet auch nicht mehr als 400 und das
ist immer noch ein Bruchteil der Pulte oder LED-Wände oder Movinglights
die an den Start gehen. Bei großen professionellen Shows werden
oft Procurve Switch 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 10M/Bit angezeigt, obwohl dort eignetlich ein 100M/Bit Gerät
sein sollte, so Kann man davon ausgehen, das das Kabel zu viel dämpft,
also defekt ist, oder das der Prot am Switch ein Problem hat, nächsten
Port probieren. Natürlich muss man auch wissen mit welcher Geschwindigkeit
das eingesetzte Gerät arbeiten muss. Z.B. der Einsatz eines alten
Artnet-Node der auf 10MBit/s arbeitet ist hoffnungslos überfordert
bei einem 100MBit/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
W-Lan 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 Traffict
z.B. erkennen, wenn Artnet z.B. alles mit seinen Bradcast belegt und ein
parralelles 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
ein weiteren Switch, sondern es reicht ein V-LAN einzurichten.

Brauchbarer Switch für die Veranstaltungtechnik
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 werden können und somit nur Reichweiten von 550m überbrückt
werden können. Dies reicht aber für die meisten Projekte aus.
|
IPconfig
Um bei Problemen wenigsten festzustellen das bis zur TCP/IP Ebene alles
funktioniert, liefern Windowssysteme über das Dosfenster Diagnoseprogramme
an. Mit Ipconfig kann man die Einstellungen des eigenen Rechners auslesen. |
 |
Ping
Mit Ping und der Adresse des zu testenden Pultes erhält man vom Testobjekt
ein Replay. Hat man dieses erhalten weiß man das die Hardeware OK
ist. Ansonsten hilft zur Fehlereingrenzung auch ein Blick auf die Blinkenden
Netzwerkkarten LED´s. |

|
|
Etherreal (Wireshark)
Eine Freeware die es in sich hat und ungemein hilft Problemen im Netzwerk
aufzuspüren ist Etherreal. Die Anleitung ist auch unter Wikepedia
abgelegt. Man sollte sich frühzeitig mit diesem Programm auseinander
setzen, damit man dann anschließend im Problemfall auch weiss was
man tut, denn es wird alles Protokolliert, und dann muss man wissen welche
Protokolle für was benötigt wird.
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, das dass 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 mann kann sich auch über Porttabellen weiterhelfen,
bei denen eine Zuordnung welcher Port z.B. Multicast zugeordnet ist, angezeigt
wird. Daraus könnte man ja zur Not auch seinen eignen Filter bauen.
|
|
Netzwerk-Analyse-Messgerät
Bei schwer aufzufindenden Fehlern,benötigt man ein Netzwerk-Analyse-Messgerät
wie z.B. das Fluke networks EtherScope Serie II aus der 8.000,00
Klasse. Das Gerät arbeitet ähnlich wie Etherreal ist aber jedoch
vollkommen unabhängig von vorhandener Hardeware 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
das an dieser Stelle ein Broadcaststurm vorhanden ist der das Netzwerk
einfach lahm legt. Broadcast ist ja eine typische Artnet-Eigenschaft,
und so kann man vermuten das der Medienserver der das Pixelmapping ausgibt
auf den falschen Port oder Switch gesteckt wurde.

Messgerät für Netzwerkanalyse, Bildschirmanzeige mit Impedanzen
der Kabelpaare und der Kabelstrecke

Netzanalyse-Tool Funktionsübersicht

Netzanalyse-Tool Grafische Belastungsdarstellung
|
|
|
|
Vielen Dank für Ihr Intresse
Copyright Herbert Bernstädt, eingestelt am 29.09.2002, last Update
07.03.2009
Ist auf der rechten Seite keine Navigationsleiste zu erkennen, können
Sie mit
Startseite
die Ausgangsseite und damit weitere Themen dieser Page erreichen.
|