Moderne Netzwerkanalyse
Dem Fehler auf der Spur
Die Suche nach dem kleinen Bug, der das große IT-Konstrukt lahmlegt, ist oft mühsam. Die Zeit drängt, denn Ausfälle sind teuer. Häufig liegen dabei Ursache und Wirkung weit auseinander. Moderne Analysemethoden verkürzen die Fehlersuche.
Jeder Netzwerkadministrator kennt die Situation: Tritt ein Netzwerkfehler auf, wird der schwarze Peter immer zuerst dem Netzwerk zugeschoben, da es als kompliziert und schwer einsehbar gilt. Dabei entstehen Fehler jedoch zum überwiegenden Teil an anderer Stelle. Außerdem liegt es in der Natur der Sache, dass der Nutzer Störungen immer erst dann meldet, nachdem sie bereits aufgetreten sind. Für eine detaillierte Analyse des Netzwerkverkehrs muss der Administrator diesen mit entsprechenden Tools schon vorab aufzeichnen.
Um diese Crux aufzulösen, adressieren moderne Lösungen die Ursachenforschung inzwischen eleganter als ihre Vorgänger. Sie ermöglichen einen schnellen Zugriff auf die wesentlichen Netzwerkdaten, sowohl in Echtzeit als auch für vergangene Vorfälle. Bisherige Systeme, die ein breites Monitoring-Spektrum abbilden, besitzen oft eine Komplexität, die eine spontane, sporadische Fehlersuche erschwert oder viel Zeit zur Analyse in Anspruch nimmt. Nicht zuletzt behandeln herkömmliche Analyse-Tools nur einen eingeschränkten Bereich des Netzwerkes. Zeitgemäße Netzwerkanalysesysteme ermöglichen demgegenüber eine Vielzahl an Analyserückschlüssen und entsprechen den gewachsenen Anforderungen heutiger IT-Architekturen.
Die Komplexität heutiger Netzwerkaufbauten bildet auch eine Vielfalt an Fehlerquellen heraus. Viele Störungen lassen sich tatsächlich auf das komplexe Zusammenspiel von verschiedenen Geräten und Softwareprogrammen zurückführen. Das Debugging solcher Fehlerquellen ist zeitaufwändig und mühsam, da die Ursache der Störung häufig nicht in engem Zusammenhang mit der Wirkung steht. Andere Fehler wiederum sind - trotz der Schwierigkeit, sie zu finden - sehr einfacher Natur und basieren oft auf kleinen menschlichen Unzulänglichkeiten.
Analyse des Cisco-Managements im laufenden Betrieb
Eine fehlende Ursache-Wirkungsreaktion ist beispielsweise bei einer Firma aus dem Energiesektor aufgetreten, deren Cisco-Management wiederholt für mehrere Stunden nicht erreichbar war. Der Cisco-Switch verarbeitete jedoch weiterhin kontinuierlich Kundendaten. Somit war ein Neustart des Switchs keine Option. Auch ein Austausch der Hardware stand vorerst nicht zur Diskussion. Aus Kostengründen sollte der Administrator zunächst alle anderen Komponenten analysieren.
Nachdem die Möglichkeiten herkömmlicher Analysesysteme erschöpft waren, kamen moderne Lösungen zum Einsatz. Sie erlauben eine nachträgliche Analyse von exakt der letzten Verbindung vor dem Absturz. Diese lässt sich mit wenigen Klicks finden und das dazugehörige Pcap auf Knopfdruck extrahieren und analysieren. In diesem Fall stellte sich heraus, dass ein standardmäßiger, einem Software-Update vorausgehender SNMP-Befehl den Switch zum Absturz gebracht hat.
Das Unternehmen hatte es hier mit einem Netzwerkfehler zu tun, der durch das komplexe Zusammenspiel von unterschiedlicher Soft- und Hardware verursacht wurde. Gleichzeitig wies die Ursache keinerlei offensichtliche Relation zur Wirkung auf. Der Schlüssel zum Erfolg war hier der Einsatz eines Tools, das zwar im laufenden Betrieb aktiv war, aber nicht der kontinuierlichen Aufmerksamkeit des Netzwerkadministrators bedurfte. Durch passive Aufzeichnung und selektive Datenextraktion konnte dieser dadurch den Fehler ohne großen Zeitaufwand finden. Nachdem der Fehler erkannt war, lief die Fehlerbehebung reibungslos. Cisco erhielt einen detaillierten Bug-Report und schickte daraufhin eine neue Softwareversion, die den Fehler behob.
Hängender Citrix-Client legt Kundencenter lahm
Ein weiteres Beispiel für einen schwer zu ermittelnden Fehler ereignete sich bei einem Unternehmen mit großem Kundendatenaufkommen. Mehrmals täglich hingen die Citrix-Clients, sodass Kunden lange Wartezeiten in Kauf nehmen mussten. Der Fehler trat allerdings nur an einem Standort auf. Andere Standorte mit identischen Netzwerkaufbauten waren nicht betroffen.
Zunächst vermutete man den Fehler beim Server, doch ein Austausch blieb ohne Erfolg. Weitere Analyseschritte, wie das Vermessen von Leitungen, die Überprüfung der ISP-Anbindung sowie die Kontrolle der Konfiguration des Citrix-Clients führten ebenfalls zu keinem Ergebnis.
Schlussendlich half der Einsatz eines neuartigen Protokollanalysators, die Ursache aufzuspüren. Ein am Mirror-Port angeschlossener Debuggers erkannte, dass Pakete falsch geroutet wurden. Beim Router existierte eine Regel, die den Port für den Citrix-Terminal-Server über eine andere und damit schlechtere Route ins Internet geroutet hat. Die Regel war nur für diesen TCP-Port aktiv und ließ sich dadurch bei einem aktiven Vermessen der Leitung nicht anwenden.
Nach seiner Entdeckung ließ sich der Fehler schnell beheben. Insgesamt vereinnahmte aber die sukzessive Fehlersuche mit herkömmlichen Debuggern enorme Aufwände und Kosten. Dass hängende Citrix-Clients mit der Ursache, dem fehlerhaften Routing, in keiner Relation standen, erschwerte die Diagnose. Erst der Einsatz aktueller Messtechniken erlaubte ein schnelles Troubleshooting.
SPS meldet Netzwerkproblem
Ein letztes Beispiel für komplexe IT-Aufbauten lenkt den Blick auf eine große Automobilfertigung. Daten gehen dort von der SPS zu Switches, über die Firewall und einem Uplink zu einem Datacenter. Wochenlang stand das Team, welches das Netzwerk bis zum Uplink betreut, vor einem wiederkehrenden Problem: Die Fertigungsstraße stand still. Die SPS meldete "Netzwerkfehler". Fertigungszeiten gingen verloren und ließen sich nicht mehr aufholen.
Wo herkömmliche Analysesysteme an ihre Grenzen stoßen, konnte die jüngste Generation von Netzwerkanalysatoren nach ihrer Installation direkt am Uplink die Pakete extrahieren, die das System unmittelbar vor der Meldung "Netzwerkfehler" verarbeitet hat. Anhand der binnen weniger Minuten durchgeführten Pcap-Analyse konnte das Team den Fehler einkreisen.
Der Client schickte Retransmissions, da der Server nicht antwortete, und baute nach drei Minuten regulär die Verbindung wieder auf. Die Störung lag also darin begründet, dass der Server nicht erreichbar war. Der Systemadministrator in der Fertigungshalle konnte somit an die zuständige Abteilung weitergeben.
Die Schlussfolgerung vom Fehler auf das Problem war nicht einleuchtend. Das eingesetzte Messgerät musste man in einem Arbeitsmodus einsetzen, der keinerlei Änderungen am Netzwerk bedurfte und keinerlei Einfluss auf den Netzwerkverkehr nahm. Wenn, wie hier, der Fehler nur einen kurzen Zeitbereich betrifft, muss das System entsprechend sekundengenaue Messungen durchführen können, da ungenauere Messwerte das Nachvollziehen deutlich erschweren oder gar unmöglich machen.
Andere Fehlerquellen sind - obwohl sie nicht auf einem vielschichtigen Konstrukt beruhen - ebenso schwierig zu eruieren. Sie basieren auf kleinen Flüchtigkeitsfehlern des Anwenders. Hierfür ein Beispiel aus einer 20-köpfigen Firma mit starkem Vertriebszweig: Immer wieder um 11 Uhr - manchmal täglich - war das Netz so langsam, dass es fast nicht benutzbar war. Die Überprüfung aller augenscheinlich möglichen Fehlerursachen blieb ergebnislos. Die direkt im lokalen Netz gemessene Traffic-Analyse offenbarte schließlich große Windows-Updates, die regelmäßig um 11 Uhr vormittags gezogen wurden. Der Systemadministrator hatte bei der Zeiteinstellung "a.m." mit "p.m." verwechselt. Statt die Updates nachts zu laden, legten sie so vormittags den Betrieb lahm. Der Fix war denkbar einfach. Mit einem modernen Netzwerk-Debugger war der Fehler schnell erkannt.
Fazit
Die Beispiele zeigen, dass neuartige Netzwerkanalysesysteme dem Administrator bei Netzwerkproblemen neue Handlungsspielräume schaffen können. Sie zeigen Zusammenhänge auf, die nicht offenkundig sind. Sie weisen nach, dass der Fehler nicht im (eigenen) Netzwerk zu finden ist. Außerdem decken sie eigene Fehler auf, bevor diese Auswirkungen auf den laufenden Betrieb haben. Überdies verkürzt es die Zeit, bis die Fehler gefunden sind und das Netzwerk wiederhergestellt ist.
Lesen Sie mehr zum Thema
