Dass Switche, insbesondere kleine Desktopswitche, häufig eher auf in Richtung Kostenoptimierung als in Richtung Qualität entwickelt wurden ist bekannt. Wenn solche Switche dann ausfallen, sind normalerweise die angeschlossenen Geräte nicht mehr im Netzwerk erreichbar, die Anzeigen der Switche gehen ganz aus oder fangen wild an zu blinken oder leuchten konstant; unauffällig, also blinkend im Rahmen des vermutlichen Netzwerkverkehrs, verhalten sich die Anzeigen in den seltensten Fällen.

Gestern trat bei einem Kunden jedoch folgendes Phänomen auf. Der Kunde, ein kleineres mittelständisches Unternehmen, betreibt virtualisiert mehrere Server, die Firewall zum Internet, die üblichen Drucker und Arbeitsplätze. Einer der Server ist ein virtualisierter Terminalserver, ein anderer ein virtualisierter SBS als Domänencontroller. Das auftretende Phänomen war nun, dass sich schlagartig keine Benutzer mehr neu am Terminalserver anmelden konnten und angemeldete Benutzer über ein langsameres Arbeiten klagten. Ein Blick auf das Virtualisierungssystem ergab, dass die virtualisierten Server alle sehr hoch ausgelastet waren, vor allem der SBS. Die erste Vermutung war also ein Problem mit dem SBS oder dem Virtualisierungssystem. Nachdem die virtuellen Maschinen beendet waren, war zwar die Rechenlast auf dem Virtualisierungssystem wieder normal, jedoch traten bei der Bedienung des Systems via SSH nachwievor Verzögerungen auf, einige Systeme (wie eine Netzwerksteckdose und ein Fernwartungssystem) waren nicht anpingbar.

Somit lag die Vermutung nahe, dass der Hauptswitch, an dem die Systeme hingen, nicht mehr korrekt arbeitete. Besonderen Datenverkehr zeigte dieser nicht an. Dieser wurde temporär getauscht und … es gab keine Veränderung. Sollte die Netzwerkkarte des Prüfrechners, von dem aus „gepingt“ wurde defekt sein? Die Prüfung mit einem anderen System ergab das selbe Verhalten.

Wir schlossen also portweise den Hauptswitch wieder an und fanden, dass die Störungen beim Anschluss eines Ports starteten und beendet waren, sobald dieser Port wieder getrennt wurde. Nun konnte ein defekter Port am Hauptswitch wegen des vorherigen Tausches ausgeschlossen werden, die Ursache musste also auf der eingehenden Leitung liegen.

Die Prüfung der Leitung ergab, dass dort mehrere Rechner über einen kleinen Desktopswitch angeschlossen waren. Nach einem Neustart dieses Switches, arbeitete auch das Hauptsystem wieder normal.

Der kleine Sekundärswitch hatte es also geschafft, das Netzwerk soweit zu stören, dass auch Netzwerksegmente, die vom regulären Datenverkehr eigentlich nicht betroffen waren, extrem zu behindern, ohne dass ein extremer Datenverkehr erkennbar gewesen ist.

Ein Nebeneffekt war, dass einige kleinere Netzwerkgeräte wie die o.g. Netzwerksteckdose und die Fernwartungskarte auch abgestürzt waren und erst nach einem Reset wieder arbeiteten.

Welcher Art die störenden Pakete waren, die der Desktopswitch verursacht hat oder ob er ein elektrisches Problem verursachte, dass die beiden gerüften Hauptswitche unterschiedlicher Hersteller so beieinflusste, konnte im nachhinein leider nicht geprüft werden: Nach dem Neustart des Desktopswitches arbeitete dieser ja wieder korrekt und das Problem konnte nicht wieder ausgelöst werden. Schade.

Being familiar with the case study method, you will learn to concentrate on key-points, avoiding unnecessary confusing facts.
Dr.-Ing. Martin H. Ludwig

Von Dr. Martin H. Ludwig

Dr. Martin H. Ludwig ist Geschäftsführer der ima GmbH, leidenschaftlicher IT-ler und Datenschutzexperte. Wenn er Zeit findet, schreibt er über IT-Probleme oder -Besonderheiten im Blog.

Schreibe einen Kommentar