Einen Fehler im Netzwerk zu beheben erweist sich oft als schwierige Angelegenheit. Viele Schichten des OSI-Referenzmodells werden durchlaufen und daher lässt sich nicht immer lässt von einem Symptom auf eine eindeutige Ursache schließen. Allerdings gibt es bewährte Konzepte, wie man die Ursache lokalisieren und beheben kann. Wichtig ist dabei eine strukturierte Vorgehensweise, so dass andere Fehlerquellen ausgeschlossen werden können und man sich nicht in der Fehlersuche verläuft.

Das folgende Schema soll einen dabei unterstützen. Sicherlich sind dort nicht alle Optionen und Maßnahmen aufgeführt. Das würde zu einem kaum überschaubaren Diagramm führen. Aber aufgrund von Erfahrungswerten lässt sich voraussagen, dass damit mit sehr hoher Wahrscheinlichkeit ein Fehler im Netzwerk gefunden wird.

Das Schema arbeitet quasi die Schichten des OSI-Referenzmodells, bzw. TCP/IP-Modells aufsteigend durch und folgt dem Prinzip:

• Schritt prüfen
• ggf. Maßnahmen durchführen und erneut prüfen
• bei Erfolg zum nächsten Schritt
• bei Misserfolg zum vorherigen Schritt

Eine ordentliche Vorgehensweise beginnt normalerweise beim ersten Schritt und endet mit der Fehlerbehebung. Nun bringt aber die Fehlerbehebung in der Regel das Problem mit sich, dass sie zeitnah zum Erfolg führen sollte. Situationsbedingt kann man oft schon Fehler niedriger Schichten mit hoher Wahrscheinlichkeit ausschließen. Aber eben nicht mit absoluter Sicherheit. Jetzt steht man vor der Entscheidung, ob man trotzdem am Anfang des Schemas beginnen soll aber damit evtl. unnötig kostbare Zeit investiert oder ob man mit der Fehlerlokalisierung direkt in den höheren Schichten beginnt.

Nun, die Erfahrung hat gezeigt, dass sich die meisten Fehler bei den Einsprungspunkten 3, 4 und 5 abspielen, also bei der TCP/IP-Konfiguration, den Routingeinträgen, der Namensauflösung und bei den Firewall-Einstellungen. Daher ist es auch gerechtfertigt, wenn man im ersten Durchlauf bei diesen Schritten beginnt. Das Schema bietet aus diesem Grund auch mehrere Einsprungspunkte die verdeutlichen sollen, dass eine schnelle Fehlerbehebung von den erfassten Informationen zum Problem, wie auch von der Erfahrung des Technikers abhängt.

Eine sinnvolle Vorgehensweise sieht daher wie folgt aus:

• Informationen erfassen
• sinnvollen Einsprungspunkt auf Basis der Informationen und Erfahrung wählen und Maßnahme druchführen
• bei Misserfolg das Schema von Einsprungspunkt 1 an durcharbeiten

Einsprungspunkt 1:

Die Status LEDs von Netzkoppelelementen geben Auskunft über die Konnektivität und optional über den aktuellen Übertragungmodus. Bei IEEE 802.3 Technologien z.B. 10/100/1000 Mbit. Der exakte Informationsgehalt der LEDs sind den Herstellerangaben zu entnehmen. Im Minimum versichert einem eine leuchtende Status LED in jedem Fall die physische Verbindung zwischen zwei Netzkoppelelementen, wie einer Netzwerkkarte und einem Switch.

Bei IEEE 802.3 Technologien beherrschen immer mehr Netzkoppelelemente Auto MDI-X, welches die automatische Anpassung an die jeweilige Verdrahtungsart gewährleistet. Ist diese Technologie nicht vorhanden, muss man die Auswahl zwischen 1:1 oder Crossover selber treffen. Umfassende Erläuterungen zu den Entscheidungskriterien und Merkmalen sind in den weiteren Beiträgen unter Grundlagen zu finden.

Mit einem einfachen Kabel-Testgerät kann man die Verdrahtungsart eines Kabels prüfen. Dies sagt allerdings noch nichts über die Qualität des Kabels aus. Funktioniert eine Netzwerkverbindung zwar grundsätzlich, führt aber zu sporadischen Leistungs- oder Verbindungsabbrüchen, dann liegt wahrscheinlich ein Qualitätsmangel am Kabel vor.

Einsprungspunkt 2:

Damit eine Netzwerkkarte genutzt werden kann, benötigt sie einen Treiber für das jeweilige Betriebssystem. Hat man den richtigen Treiber installiert, wird die Netzwerkkarte vom System auch erkannt und angezeigt. Die Ansicht erfolgt unter Windows im Gerätemanager. Dieser ist über den Befehl devmgmt.msc aufzurufen. Unter Linux prüft man die Treiber z.B. mit lshw -class Network.

In der Regel funktionieren Netzwerkkarten nach der Installation des Treibers problemlos. Wenn dies nicht der Fall ist, dann muss man die Einstellungen der Netzwerkkarte überprüfen. Möglicherweise muss man grundlegende Verhaltensweisen anpassen. Dazu zählen z.B. die Übertragungsgeschwindigkeit, Flusskontrolle, Framegröße, unsw.

Unter Windows sind dazu einfach die Eigenschaften der Netzwerkkarte im Gerätemanager aufzurufen und unter Linux eignet sich dazu das Programm ethtool.

Einsprungspunkt 3:

Hier beginnen die meisten Fehlerursachen bei Netzwerkproblemen. Bevor aber entfernte Systeme angesprochen werden, muss erstmal der lokale Netzwerkstapel bis zur physischen Netzwerkkarte selbst getestet werden.

Als erstes überprüft man ob der Netzwerkkarte eine IP-Adresse und Subnetzmaske zugewiesen sind. Unter Windows ist der schnellste Weg dafür der Aufruf des Befehls ipconfig in der Eingabekonsole. Unter Linux bewirkt der Befehl ifconfig selbiges.

Anschließend wird die Netzwerkkarte lokal ansgesprochen. Dazu dient der Befehl ping, gefolgt von der ermittelten IP-Adresse. Dabei durchläuft der Befehl den Netzwerkstapel und wird von der Netzwerkkarte selbst beantwortet. Ein möglicher Fehler, der durch diesen Test nicht auszuschliesen ist, wäre noch ein Defekt an der Anschlussbuchse der Netzwerkkarte.

Einsprungspunkt 4:

Auch wenn die Netzwerkkarte eine IP-Adresse und eine Subnetzmaske besitzt, bedeutet dies noch nicht, dass es eine brauchbare ist. Brauchbar bedeutet in diesem Fall, dass sie auch ins logische Netzschema passen muss, um mit anderen Systemen kommunizieren zu können. Alle Systeme die über einen Switch im Local Area Network miteinander kommunizieren wollen, müssen im selben logischen Subnetz liegen.

Bei der Verwendung von DHCP wird den Systemen automatisch eine gültige IP-Konfiguration von einem Server zugewiesen. Geschieht dies nicht oder erscheint die IP-Adresse seltsam, dann gibt es zwei wahrscheinliche Gründe. Zum einen ist der DHCP-Server nicht aktiviert, bzw. verweigert dem System eine IP-Zuweisung oder eine Firewall blockiert den Netzwerkverkehr.

Neben der IP-Adresse und der Subnetzmaske übermitteln DHCP-Server auch noch weitere Konfigurationen. Zwei weitere davon sind die Angabe des Gateways und eine oder mehrere DNS-Server. Diese Angaben sind vor allem für den Zugriff auf andere Netze wie das Internet wichtig. Nimmt man die logische Konfiguration der Netzwerkkarte manuell vor, dann muss man sich vorher die Informationen zu dem logischen Subnetz, freier IP-Adresse, Gateway und DNS-Server selbst beschaffen, bzw. festlegen.

Für die manuelle wie die automatische IP-Adressierung gilt, dass die IP-Adresse nur 1x pro Subnetz auftreten darf! Bei der automatischen IP-Vergabe muss zusätzlich beachtet werden, dass sich bei der Verwendung von mehreren DHCP-Servern der Verwaltungsbereich der IP-Adressen nicht überschneidet. Zusätzlich sollte die Lease-Time für IP-Adressen 24h nicht überschreiten.

In größeren Netzwerken gibt es oft unterschiedliche Subnetze, die mit Routern untereinander verbunden sind. Schlägt das Ansprechen eines entfernten Ziels fehl, dann hilft unter Windows der Befehl tracert, bzw. unter Linux traceroute. Dieser prüft alle Router im Netzwerkpfad bis zum Ziel rekursiv ab. Geht die Anfrage an einem Punkt nicht mehr weiter, dann kann man an diesem Router mit der Fehlersuche beginnen. Router lassen sich entweder durch ein Webinterface oder mit Hilfe des Programms Telnet konfigurieren.

Einsprungspunkt 5:

Sind alle physischen und logischen Konfigurationen getestet, aber eine Anfrage die über das DNS-System läuft schlägt fehl, dann liegt mit hoher Wahrscheinlichkeit ein Problem mit dem DNS-Server vor.

Die Funktion des verwendeten DNS-Servers lässt sich mit dem Befehl nslookup, gefolgt von einer Domain überprüfen. Ein erfolgloser ping auf die IP-Adresse des DNS-Servers muss nicht zwangsläufig bedeuten, dass dieser nicht erreichbar ist. Auch mit geblockten ICMP-Echos kann ein DNS-Server seiner Aufgabe zur Namensauflösung nachkommen!

Einsprungspunkt 6:

Letztendlich kann die komplette Netzwerkkonfiguration funktionstüchtig sein, aber trotzdem verweigern manche Applikationen ihre Funktion im Netzwerk. Entweder hat dann die Applikation einen Fehler oder in ihrer Konfiguration wurde ein Proxy-Server festgelegt. Ist allerdings kein aktiver Proxy-Server im Netzwerk, dann führen die Netzwerkzugriffe dieser Applikation zu Fehlschlägen.

Informationen zu Proxy-Servern können u.a. auch mittels DHCP übertragen werden. Verbindet man sich zu einem späteren Zeitpunkt in ein anderes Netz, dann können die Alteinträge zu dem Proxy-Server noch vorhanden sein. Das führt im neuen Netz natürlich zu Problemen.