Dank des Troubleshooters an die Verursacher von Fehlern

Kommentieren Drucken

In den 1980er und den Anfängen der 1990er Jahre verdankte der LAN-Troubleshooter seine meisten Aufträge den Verursachern von Fehlern in den untersten Schichten des Kommunikationsmodells. Beliebt war zum Beispiel der fehlende Abschlusswiderstand des busförmigen Koaxialkabels, ein Fehler der schnell zu finden war, weil über den Bus gar nichts mehr ging. Schon etwas tückischer war der dreifache niederohmige Abschluss (statt des erforderlichen zweifachen Abschlusses an den beiden Enden), der zum Beispiel dadurch zustande kam, dass vom sogenannten T-Stück ein Kabel zum nahen PC führte und dort wiederum mittels eines zweiten T-Stücks abgeschlossen wurde. In einem solchen Fall gab es eine erhöhte Fehlerrate auf dem Bus.

Später, im Zeitalter von Twisted Pairs, machte es Spaß, einen holprigen Token-Ring wieder flott zu machen, indem man das Nahnebensprechen an den ungewohnten kleinen Steckern (RJ45 genannt) beseitigte. Immer war der Ausdruck der Erlösung im Gesicht der Kunden eine viel wertvollere Entlohnung als das Honorar.

Die Verkabelung wurde standardisiert, das Hochfrequenzmessgerät zum Standardinhalt des Elektrikerkoffers, und die Häufigkeit von Verkabelungsfehlern ging drastisch zurück. Aber für den Troubleshooter gab es weiterhin Arbeit genug, denn die IT-Infrastruktur wurde immer größer und komplexer, die Innovationszyklen der Produkte immer kürzer. Die 1990er Jahre waren das Jahrzehnt der Broadcast-Stürme. Address Resolution Protocol (ARP), Windows Internet Name Service (WINS), Netware Service Advertisement Protocol, NetBIOS Datagram Distribution (NBDD) – um nur ein paar Beispiele zu nennen – sorgten für viele Probleme in Netzen, die manchmal nicht an Grenzen der Lokalen Netze halt machten und ganze Wide Area Networks lahmlegten. Die Ergebnisse der Fehlersuche gingen häufig mit der Umstellung der Netze auf Layer-3-Strukturierung einher.

Um die Jahrtausendwende erwies sich die Firma Microsoft als treue Arbeitsbeschafferin für die Troubleshooter. Alles fing zu Windows-NT-Zeiten mit Windows Load Balancing Service (WLBS) an. Vielen Windows-Administratoren gelang es mit nur ein paar Häkchen und Klicks, die Antwortzeit in ihren Netzen bis ins Unerträgliche zu verlängern. Microsoft hatte nämlich mit WLBS die „Lastverteilung für Arme“ in das Betriebssystem eingebaut. Die Methode war ziemlich plump: Durch das Verstecken der MAC-Adressen der Server eines Clusters brachte Microsoft das Netz dazu, die Pakete an den Cluster zu „fluten“, damit sie von allen Clusterknoten empfangen werden konnten.

Erstaunlicherweise rettete sich WLBS über die Jahrtausendwende hinaus als „Network Load Balancing“ (NLB) in das heutige Register der Netzkrankheiten. Der Erreger wechselte den Namen, die Krankheitssymptome blieben dieselben: Switches gingen in die Knie, Antwortzeiten der Anwendungen in die Länge. Bis heute müssen wir immer wieder Probleme analysieren, die auf die Flutung durch NLB zurückzuführen sind.

Voice over Internet Protocol (VoIP) sorgte in den 2000er Jahren für viele Aktivitäten der Fehlersuche. In den meisten Fällen wurde das Netz als mutmaßliche Ursache von Verbindungsabbrüchen, Rauschen, Echo, Hall und einseitiger Kommunikation entlastet. VoIP-Komponenten wie Endgeräte und Gateways waren die häufigste Ursache von diesen Problemen, sei es durch mangelhafte Produktentwicklung oder falsche Konfiguration.

Aber in den 2010er Jahren werden möglicherweise vor allem Firewalls und Proxy-Systeme für die Beschäftigung des Troubleshooters sorgen. Erstens werden die Netze zunehmend in Zonen eingeteilt, zwischen denen Firewalling angewandt wird. Zweitens nutzen immer mehr Anwendungen den Internet-Zugang und müssen somit über Firewalls und Proxy-Systeme übertragen werden. Drittens sind über solche Systeme immer mehr Applikationen wie Voice und Video abzuwickeln, die eigentlich Firewalling nicht gut vertragen. Die Folge ist eine steigende Zahl von Problemen, als deren Ursachen sich immer wieder Proxy- und Firewall-Systeme entpuppen. Mal sind die Einträge in den Session Tables der Firewalls zu kurzlebig, sodass Pakete einer noch genutzten Verbindung verworfen werden, mal zu langlebig, sodass neue Verbindungen mit derselben Portnummer nicht aufgebaut werden können. Oder die Firewalls bringen die Reihenfolge der Pakete durcheinander. Oder ein Proxy-System antwortet mit der falschen HTTP-Response.

Nicht so häufig wie die Sicherheitssysteme erweisen sich WAN Optimisation Controller (WOC) als Fehlerursache. In vielen Fällen profitiert eine Anwendung vom WOC-Einsatz, während andere Anwendungen darunter leiden. „Out of the box“ bedeutet WAN-Optimierung immer ein Risiko.

In jüngster Zeit erweisen sich nach der subjektiven Erfahrung des Autors die Anwendungen als zunehmend empfindlich, wenn es im Netz Paketverluste gibt. Anders als allgemein angenommen sind es nicht Voice oder Video, die am empfindlichsten auf Paketverluste reagieren, sondern einige Datenanwendungen, zum Beispiel Terminal Sessions, die auch bei wenigen Paketverlusten abbrechen können. Erstaunlicherweise sichern die WAN Provider die niedrigsten Grenzen für die Häufigkeit von Paketverlusten der sogenannten Voice-Klasse zu, während einige interaktive Datenanwendungen die höchsten Garantien der Paketzustellung benötigen. Würden die WANs nicht wesentlich besser als ihre zugesicherten Übertragungsparameter sein, müsste der Troubleshooter noch häufiger ausrücken.

Bei keiner anderen Tätigkeit hat der Autor mehr über die Funktionsweise von Netzen, Protokollen und Anwendungen gelernt als bei Troubleshooting. Keiner anderen Tätigkeit in IT-Umgebungen geht der Autor daher lieber nach als Fehlersuche. Und es scheint, dass genau diese Begeisterung, dieses Interesse an Details die Grundvoraussetzung für erfolgreiche Fehlersuche ist. Die beste Mess- und Analysetechnik ist wertlos, wenn die Begeisterung und das Interesse an Troubleshooting fehlt. Diese Begeisterung wird mit jeder erfolgreichen Fehlersuche gesteigert.

Dafür gebührt der aufrichtige Dank des Troubleshooters den Verursachern von Fehlern in Netzen. Bitte, liebe Hersteller, machen Sie weiter so!

zugeordnete Kategorien: Endgeräte, LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.