Troubleshooting/Fehlersuche in der Netzwerktechnik

Wo fängt man an?

Die wichtigste Regel ist, mit der Fehlersuche auf der untersten Ebene des OSI-Modells zu beginnen und sich von dort dann nach oben zu arbeiten. Auf den höheren Schichten gibt es zwar viel mehr und komplexere Fehlerquellen, aber eine Fehlersuche in einer Anwendung ist vergeudete Zeit, wenn schlussendlich nur das Netzwerkkabel ausgesteckt war. Dumm läuft es dann, wenn man dabei auch noch die Netzwerkeinstellungen verbogen hat und das dann wieder rückgängig machen muss.

Das bedeutet, dass bei Netzwerk-Problemen der Blick zuerst auf die Kabelverbindungen zu richten ist. Sind die Patchkabel in Ordnung und richtig eingesteckt? Hilfreich sind dabei die LEDs an den LAN-Buchsen. Wenn hier nichts blinkt, dann ist das Problem mit Sicherheit nicht in den Netzwerkeinstellungen zu suchen, sondern ein Hardware-Problem.

Kann man ein Hardware- oder Verkabelungsproblem ausschließen, sind die Netzwerk-Komponenten, wie Router, Switch und Hub zu überprüfen. Haben die noch Strom? Sind sie richtig angeschlossen? Wenn auch hier der Fehler nicht zu finden ist kann man sich schon mal an die Netzwerk-Einstellungen machen. Ist das Problem nur bei einem einzelnen Computer, dann ist dieser zu untersuchen. Betrifft es alle Computer, kann auch ein zentraler Router dafür verantwortlich sein.

Netzwerkeinstellungen

Unerklärliche Verbindungsprobleme können zum Beispiel durch doppelt vergebene IP-Adressen hervorgerufen werden. Das passiert nicht nur bei händisch vergebenen IP-Adressen, sondern auch dann, wenn ein neues Gerät mit eingeschaltetem DHCP-Server ans Netz geht.

Begrenzung der Übertragungsgeschwindigkeit

Gelegentlich kommt es vor, dass die Übertragungsgeschwindigkeit irgendwelchen Begrenzungen unterliegt, obwohl die Übertragungsstrecke bei weitem noch nicht ausgelastet ist. In einem solchen Fall sollte man sich mit folgenden Fragestellungen beschäftigen:

Welche Protokolle über das Netz kommunizieren?
Welche davon produzieren viel Overhead und haben ein intensives Kommunikationsverhalten?
Wie verhalten sie sich bei Engpässen im WAN?
Welche Folgen hat das auf die Anwendung?

Ein Beispiel: TCP mit systembedingten Fehlern

Das verbindungsorientierte Protokoll TCP soll Datenverluste auf IP-Ebene verhindern. Dazu arbeitet TCP mit einer Windows-Size (Paketgröße) von 64 kByte. TCP sendet dieses Paket an einem Stück (unabhängig davon, wie IP die Pakete anschließend stückelt). Nach der Übertragung wartet TCP auf eine Bestätigung (ACK) vom Empfänger. Da auf große Distanzen mehrere hundert Millisekunden zusammenkommen, bis das Paket ankommt, liegt die Verbindung bis zum Eintreffen des ACK brach. Um die ungenutzte Zeit möglichst klein zu halten, wird die Windows-Size möglichst groß gewählt. TCP regelt das in Abhängigkeit der Bandbreite und Störungsfreiheit auf der Verbindung. Generell besteht das Problem, dass bei Störungen und Datenverlusten, die Pakete nochmals übertragen werden müssen. Je größer die Datenmenge, desto mehr muss nochmals übertragen werden.

Doch nicht nur TCP ist so gestrickt, sondern auch Notes oder TNS von Oracle haben einen Wartemechanismus für übertragene Pakete. Ein weiterer Knackpunkt mancher Protokoll ist die Geschwätzigkeit, wie zum Beispiel beim CIFS-Protokoll. Die Broadcasts solcher Protokolle können WAN-Verbindungen verstopfen. In der Regel versucht man dieses Protokoll im lokalen LAN zu halten, damit WAN-Verbindung nicht blockiert werden.