Fehlersuche in IP-Netzen

Ich möchte hier eine kleine Anleitung geben, wie man Netzwerkprobleme in TCP/IP-Netzen finden und beseitigen kann. Wenn der PC nicht erreichbar ist oder nicht ins Internet kommt, dann kann das sehr viele Gründe haben. Wenn man aber eine gewisse Reihenfolge bei der Fehlersuche einhält, dann kommt man dem Problem sehr schnell auf den Grund. Internetprobleme werden hier allerdings nur behandelt, wenn man sich über das LAN ins Internet begibt. Auf Probleme mit Einwahl, Providern, ... werde ich hier nicht weiter eingehen.

Wenn man die Link-LEDs nicht einsehen kann oder schlecht an das Kabel kommt, dann kann man auch erst einmal grundlegende Tests von der Konsole starten (DOS-Fenster, Shell, ...). Man sollte sich bei der Fehlersuche soviel Arbeit wie möglich sparen. Das spart auch Zeit. Logisches Denken ist dabei nicht abzulehnen. Wahlloses Rumstochern bringt einen bei der Fehlersuche nicht weiter und man sieht nachher den Wald vor Bämen nicht mehr.

Zuerst den am meißten verkannten Fehler - hat der PC überhaubt einen Link? An der Netzwerkkarte und am Switch sollten die Link-LEDs leuchten. Wenn eine der beiden oder sogar beide LEDs aus sind, so ist entweder das Kabel defekt, der Switchport oder die Netzwerkkarte. Also einfach mal einen anderen Switchport verwenden (das ist am einfachsten). Wenn es immer noch nicht leuchtet, dann einmal ein anderes Kabel verwenden. Wenn alles nicht hilft, dann kann man als letzte Möglichkeit noch einmal einen anderen PC oder einen kleinen Switch mit seinem Uplink-Port statt des fehlerhaften PCs an das Kabel anschalten. Bei dem kleinen Switch aber nur den Uplink-Port beschalten (damit man sich nicht auf einmal Netzwerk-Schleifen einfängt). Der Testswitch verhält sich mit seinem Uplink-Port wie ein normaler PC. Mit diesen Tests sollte sich auf jeden Fall eine Fehlerquelle gezeigt haben wenn es denn an der Physik gelegen hat (von internen Fehlern in der Karte und im Switch mal abgesehen). Noch einen Tip - der Link wird vom Switch/Netzwerkkarte mit einem 1MHz-Signal getestet. Wenn also die Link-LEDs an sind sollte man sich trotzdem nicht vollständig sicher sein. Die Daten laufen nachher mit 100MHz und mehr! Ich habe selber schon Kabel erlebt, die bei 10MBit ohne Probleme liefen und bei 100MBit Datenfehler erzeugt haben.

Jetzt haben wir also die physikalische Verbindung getestet oder hatten keine Lust unter dem Tisch rumzukrabbeln. Also zu den ersten Tests mit der Konsole.

Zuerst sehen wir uns einmal die IP-Konfiguration an. Es sollte eine IP-Adresse mit der passenden Maske vorhanden sein. Außerdem muß das Default-Gateway im selben Netz liegen. Hier schleichen sich schnell Schreibfehler oder Zahlendreher ein (Aufbau von IP-Adressen erkläre ich hier jetzt nicht). Die Abfrage geht mit "winipcfg" (Win95,98,ME), "ipconfig /all" (Win2k,NT,XP), "ifconfig -a"(Linux) für die Netzwerkschnittstellen und mit "netstat -rn" (bei allen) für das Default-Gateway. Hier ein paar Beispiele ...
Linux :

shogun:~ # ifconfig eth0 Link encap:Ethernet HWaddr 00:02:3F:54:32:10 inet addr:10.10.0.20 Bcast:10.10.0.255 Mask:255.255.255.0 inet6 addr: fe80::202:3fff:febd:c644/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:930 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:55900 (54.5 Kb) Interrupt:11 Base address:0x8000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5086 errors:0 dropped:0 overruns:0 frame:0 TX packets:5086 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:589317 (575.5 Kb) TX bytes:589317 (575.5 Kb) Die IP auf dem Netzwerkinterface ist 10.10.0.20 mit einer 24Bit-Maske (255.255.255.0). Jetzt zum Gateway shogun:~ # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.10.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 10.10.0.254 0.0.0.0 UG 0 0 0 eth0 Das Def.Gateway (zweite Zeile) ist die 10.10.0.254 (Erkennbar am Ziel 0.0.0.0 und Maske 0.0.0.0). In der ersten Zeile sieht man das angeschlossene Netz (10.10.0.0 = Netzadresse mit Maske 255.255.255.0 am Interface eth0).

Windows XP : F:\>ipconfig /all Windows-IP-Konfiguration Hostname. . . . . . . . . . . . . : GOMBAT Primäres DNS-Suffix . . . . . . . : Knotentyp . . . . . . . . . . . . : Unbekannt IP-Routing aktiviert. . . . . . . : Nein WINS-Proxy aktiviert. . . . . . . : Nein Ethernetadapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : VIA Rhine II Fast Ethernet Adapter Physikalische Adresse . . . . . . : 00-0C-76-67-98-53 DHCP aktiviert. . . . . . . . . . : Nein IP-Adresse. . . . . . . . . . . . : 10.10.0.23 Subnetzmaske. . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 10.10.0.1 DNS-Server. . . . . . . . . . . . : 10.10.0.21 10.10.0.4 Die IP auf dem Interface ist 10.10.0.23 mit Maske 255.255.255.0 F:\>netstat -rn Routingtabelle =========================================================================== Schnittstellenliste 0x1 ........................... MS TCP Loopback interface 0x2 ...00 0c 76 67 98 53 ...... VIA-kompatibler Fast Ethernet-Adapter - Paketpla ner-Miniport =========================================================================== =========================================================================== Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl 0.0.0.0 0.0.0.0 10.10.0.1 10.10.0.23 20 10.10.0.0 255.255.255.0 10.10.0.23 10.10.0.23 20 10.10.0.23 255.255.255.255 127.0.0.1 127.0.0.1 20 10.255.255.255 255.255.255.255 10.10.0.23 10.10.0.23 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 240.0.0.0 10.10.0.23 10.10.0.23 20 255.255.255.255 255.255.255.255 10.10.0.23 10.10.0.23 1 Standardgateway: 10.10.0.1 =========================================================================== Ständige Routen: Keine In der ersten Zeile der Tabelle mit den Routen ist das Default-Gateway mit 10.10.0.1 angegeben. Die restlichen Einträge werde ich jetzt nicht weiter erklären.

Wenn alles paßt, geht es mit dem Test des TCP/IP-Stacks weiter. Wir senden einen Ping an die Adresse 127.0.0.1 (localhost - der eigene PC). Das sieht dann so aus ... shogun:~ # ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.032 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.024 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.025 ms --- 127.0.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.024/0.027/0.032/0.003 ms Eventuelle Unterschiede zwischen DOS, Windows und Linux sollte man nicht zu eng sehen. Die Adresse sollte aber erreichbar sein. Wenn nicht, viel Spaß beim neu installieren vom TCP/IP-Protokollstack (grins). Identisches machen wir jetzt noch einmal mit der eigenen IP-Adresse ... shogun:~ # ping 10.10.0.20 PING 10.10.0.20 (10.10.0.20) 56(84) bytes of data. 64 bytes from 10.10.0.20: icmp_seq=1 ttl=64 time=0.031 ms 64 bytes from 10.10.0.20: icmp_seq=2 ttl=64 time=0.024 ms 64 bytes from 10.10.0.20: icmp_seq=3 ttl=64 time=0.028 ms --- 10.10.0.20 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.024/0.027/0.031/0.006 ms Sieht auch gut aus (Bei Linux den Ping mit Strg-C abbrechen sonst läft er bis ...). Wenn die eigene IP nicht erreichbar ist, kann das am TCP/IP-Stack liegen, oder eventuell weil kein Link da ist.

Weiter geht es mit der nächsten Station in der Kette. Dem Default-Gateway ... shogun:~ # ping 10.10.0.1 PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data. 64 bytes from 10.10.0.1: icmp_seq=1 ttl=255 time=1.45 ms 64 bytes from 10.10.0.1: icmp_seq=2 ttl=255 time=1.43 ms 64 bytes from 10.10.0.1: icmp_seq=3 ttl=255 time=1.50 ms --- 10.10.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2018ms rtt min/avg/max/mdev = 1.439/1.467/1.507/0.052 ms Wenn die Adresse des Default-Gateway mit Ping nicht erreichbar ist, so kann es daran liegen, das man es mit einer Firewall zu tun hat, die kein Ping zuläßt. Mit einem Trick kann man aber trotzdem feststellen, ob man eine Verbindung hat. Für die physikalische Adressierung auf dem Netzwerk muß die MAC-Adresse des Gateways bekannt sein. Mit dem Befehl "arp" kann man die sogenannte ARP-Tabelle (IP-MAC Zuordnung) abfragen ...

Windows XP : F:\>arp -a Schnittstelle: 10.10.0.23 --- 0x2 Internetadresse Physikal. Adresse Typ 10.10.0.20 00-02-3f-54-32-10 dynamisch Linux : shogun:~ # arp -a upuaut.nebula.lan (10.10.0.1) at 00:D3:4A:E0:35:A8 [ether] on eth0 Damit kann man absolut sicher sein, das die Netzwerkverbindung funktioniert. Der PC ist auf der IP-Ebene richtig konfiguriert. Weiter geht es mit der Welt jenseits des Gateways (DNS, Internet, ...). Wir machen jetzt einen Ping auf einen DNS-Server (am besten der oder die, die im PC konfiguriert sind) ... C:\WINDOWS>ping 194.25.0.60 Ping wird ausgeführt für 194.25.0.60 mit 32 Bytes Daten: Antwort von 194.25.0.60: Bytes=32 Zeit=99ms TTL=250 Antwort von 194.25.0.60: Bytes=32 Zeit=100ms TTL=250 Antwort von 194.25.0.60: Bytes=32 Zeit=103ms TTL=250 Antwort von 194.25.0.60: Bytes=32 Zeit=99ms TTL=250 Ping-Statistik für 194.25.0.60: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 99ms, Maximum = 103ms, Mittelwert = 100ms DNS-Server sind zum Beispiel 194.25.2.130, 194.25.2.131, 194.25.2.132 (3x t-online), 194.25.0.52, 194.25.0.60, 194.25.0.68 (3x telekom). Einer dieser Server sollte auf jeden Fall erreichbar sein. Wenn der/die konfigurierten Server erreichbar sind, dann kommen wir zum nächsten Schritt, die Namesauflösung. Jetzt pingen wir einen Hostnamen an ... C:\WINDOWS>ping www.sccweb.de PING wird ausgeführt für www.sccweb.de [62.67.200.10] mit 32 Bytes Daten: Antwort von 62.67.200.10: Bytes=32 Zeit=665ms TTL=56 Antwort von 62.67.200.10: Bytes=32 Zeit=121ms TTL=56 Antwort von 62.67.200.10: Bytes=32 Zeit=111ms TTL=56 Antwort von 62.67.200.10: Bytes=32 Zeit=116ms TTL=56 Ping-Statistik für 62.67.200.10: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 111ms, Maximum = 665ms, Mittelwert = 253ms Sollte es nicht funktionieren, ist der Eintrag mit dem DNS-Server zu kontrollieren (bei Linux die Datei /etc/resolv.conf , bei Windows in den Netzwerk-Eigenschaften/TCPIP/DNS).
Die IPs in der Konfiguration
sind in diesem Fall interne
DNS-Server aus dem LAN.
Entweder diese DNS-Server
arbeiten als Cache und leiten
Anfragen ins Internet weiter
oder man trägt einen externen
DNS-Server ein (z.B. einen
von t-online, freenet, arcor, ...).

Jetzt können wir als Abschluß mit einem Browser eine Internetseite aufrufen. Das sollte funktionieren. Wenn nicht, dann an die Proxy-Einstellungen im Browser denken. Normalerweise benötigt man keinen Proxy um über das LAN ins Internet zu gehen. Wenn in einem Netz ein Proxy zwingend erforderlich ist, dann wird man mit hoher Wahrscheinlichkeit schon beim anpingen des DNS-Servers Probleme bekommen haben. Im Notfall einfach mal den Admin fragen ob, und wen ja, welcher Proxy eingetragen werden muß.

Ein paar genauere Erklärungen auf sccweb.de :
Weitere empfehlenswerte Links :


Viel Spaß beim Fehler suchen und finden.


Erstellt am 05.08.2004
Artikel: Bernd Dähnrich