Zurück Weiter Inhalt

14. Diagnose-Hilfsmittel: Wenn etwas nicht funktioniert

In diesem Abschnitt werden einige der Standard-Diagnoseprogramme für das Linux Netzwerk beschrieben. Man kann sie einsetzen um die Ursache von Störungen näher einzukreisen, oder einfach nur damit spielen, um mehr über die Interna eines TCP/IP-Netzwerkes zu lernen. Einige der vorgestellten Programme sind weit mächtiger als hier beschrieben, sie in ihrem vollen Leistungsumfang zu erläutern ist aber weit außerhalb der Intention dieser Einführung. Die gegebene Information sollte aber ausreichen um diese Programme für einfache Zwecke zu benutzen.

14.1 Ping - ist da wer ?

ping ist Teil der NetKit-B Distribution. Das Programm sendet ein spezielles Datagramm über das Netzwerk an einen anderen Rechner. Wenn dieser eingeschaltet ist und es empfängt sendet er es wieder zurück und man weit, daß Rechner und Netzwerk in Ordnung sind. In der einfachsten Form sieht das so aus:

% ping gw
PING gw.vk2ktj.ampr.org (44.136.8.97): 56 data bytes
64 bytes from 44.136.8.97: icmp_seq=0 ttl=254 time=35.9 ms
64 bytes from 44.136.8.97: icmp_seq=1 ttl=254 time=22.1 ms
64 bytes from 44.136.8.97: icmp_seq=2 ttl=254 time=26.0 ms
^C

--- gw.vk2ktj.ampr.org ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 22.1/28.0/35.9 ms

ping sucht zunächst die richtige IP-Adresse zu dem angegebene Rechnernamen heraus (Voraussetzung ist natürlich, daß /etc/hosts und der Nameserver richtig konfiguriert sind) und sendet dann in regelmäßigen Abständen ein bestimmtes Datagramm an diese Adresse. Für jeden dieser icmp echo requests wird der andere Rechner dann ein icmp echo reply als Antwort zurücksenden. Jede der Zeilen 64 bytes from ... stellt eine solche empfangene Rückantwort dar. In jeder Zeile ist auch die Adresse des Absenders dieses Paketes angegeben, die Nummer des echo requests, auf den mit diesem Paket geantwortet wurde, die time to live (Lebensdauer) sowie die round trip time, das ist die Zeit in Millisekunden zwischen Absendung des request und Empfang des entsprechenden echo reply. Damit ist dies in gewissen Grenzen ein Maß für die Geschwindigkeit des Netzwerkes.

ping würde endlos weiter seine Pakete senden, deshalb muß es abgebrochen werden. Dies geschieht durch gleichzeitiges Drücken der Tasten Control (Strg) und C. Danach gibt ping noch eine Statistik der gesendeten Pakete aus, dies sind die letzten beiden Zeilen: Die Anzahl der gesendeten, empfangenen sowie unbeantworteten Pakete sowie kürzeste, längste und mittlere Antwortzeit. Eine hohe Verlustrate an Paketen deutet auf Probleme mit der Verbindung hin, diese können durch schlechte Verbindungen, überlastete Router oder Kollisionen im lokalen Ethernet verursacht werden. Man kann mit ping die schadhafte Stelle lokalisieren, indem man nacheinander alle Knotenpunkte der Verbindung an-pingt und nachsieht, ab welchem Punkt die Verlustrate stark ansteigt.

14.2 Traceroute - Wo gehts lang ?

Mit traceroute, einem Teil der NetKit-A Distribution, kann man den Weg, den die Datagramme bei einer Verbindung zwischen zwei Rechnern zurücklegen, testen und anzeigen. Wie auch ping verwendet traceroute dazu das icmp Protokoll. Es verwendet jedoch einen Trick, um von jeder durchlaufenen Knotenstelle eine Rückmeldung zu bekommen, und das geht so: Das Feld time to live eines icmp-Datagramms dient eigentlich dazu zu verhindern, das das Datenpaket ewig im Netz herumgeschickt wird, z.B. wenn es in eine Routing-Endlosschleife gerät. Zu diesem Zweck verringert jeder Router, der das Paket weiterleitet, den Zähler in diesem Datenfeld um eins. Wird dabei der Wert Null erreicht, so wird der Router, bei dem dies geschehen ist, eine icmp time to live expired Meldung an den ursprünglichen Absender des Datagramms senden um ihm mitzuteilen daß das Datagramm `abgelaufen' ist. traceroute sendet nun nacheinander Datagramme ab, deren time to live, beginnend bei eins, jeweils um eins erhöht wird. Indem es nun die eingehenden icmp time to live expired Meldungen auswertet kann es genau den Weg, den die Datagramme nehmen, verfolgen, bis der wirkliche Zielrechner erreicht ist. Das sieht dann so aus:

% traceroute minnie.vk1xwt.ampr.org
traceroute to minnie.vk1xwt (44.136.7.129), 30 hops max, 40 byte packets
 1  gw (44.136.8.97)  51.618 ms  30.431 ms  34.396 ms
 2  gw.uts (44.136.8.68) 2017.322 ms  2060.121 ms 1997.793 ms
 3  minnie.vk1xwt (44.136.7.129) 2205.335 ms  2319.728 ms  2279.643 ms

Die erste Spalte gibt die `Entfernung' an, also der wievielte Knoten (Hop) in der Verbindung der bezeichnete Rechner ist. Dies entspricht dem Eintrag im time to live Feld des Datagramms, das vom angegebenen Rechner als expired gemeldet wurde. Der nächste Eintrag ist der Rechnername (falls dieser anhand der IP-Adresse herausgefunden werden kann) und dessen IP-Adresse. Dann kommen drei Einträge mit den Antwortzeiten für drei aufeinanderfolgende Datagramme an diesen Rechner. Der erste Punkt in der Verbindung ist also der Rechner gw. Seine Antwortzeiten sind sehr kurz, die Verbindung ist ein lokales Ethernet. Der nächste Router ist gw.uts, von dort kommen die Datagramme sehr viel langsamer zurück als von gw. Der Grund ist hier eine sehr langsame Verbindung über eine Funkstrecke. Der nächste Knoten ist bereits der gesuchte Rechner, minnie.vk1xwt. Auch hier kommen die Antworten nur sehr langsam. Dies liegt aber daran, daß die Antwortzeit jedes Rechners natürlich die Summe der Verbindungszeiten aller dazwischenliegenden Teilstrecken ist, in diesem Falle also vom eigenen Rechner zu gw, von dort zu gw.uts und schließlich von gw.uts zu minnie.vk1xwt. Berücksichtigt man diese Aufsummierung der Zeiten sieht man, daß die letzte Verbindung von gw.uts zu minnie.vk1xwt ebenfalls sehr schnell ist, diese beiden Rechner hängen also vermutlich auch an einem lokalen, schnellen Netzwerk.

Taucht bei einem traceroute Aufruf hinter den Zeiten ein !N auf so weist dies auf ein nicht erreichbares Netzwerk hin. Es ist ein Zeichen dafür, daß ein Router nicht wußte, wohin er das Datagramm weiterleiten soll. Er sendet dann ein network unreachable Datagramm an den Absender zurück. Meist deutet es darauf hin, daß eine Netzverbindung (zeitweise) zusammengebrochen ist. Anhand der letzten angegebenen Adresse vor dieser Fehlermeldung kann man die defekte Stelle lokalisieren.

Ebenfalls auftauchen kann ein !H als Hinweis darauf, daß ein Rechner (Host) nicht erreicht werden konnte. Dies bedeutet i.A. daß man bis in das lokale Netzwerk des Zielrechners gelangt ist, dieser sich aber nicht meldet weil er z.B. abgeschaltet ist.

14.3 Tcpdump - Was tut sich im Netz ?

Adam Caldwell (acaldwel@103mort2.cs.ohiou.edu) hat das Hilfprogramm tcpdump für Linux portiert. tcpdump kann die gesamte Aktivität auf dem Netzwerk überwachen indem es sämtlich Datagramme auf dem Weg in den eigen Rechner hinein oder heraus abhört. Damit lassen sich vom erfahrenen Administrator auch schwer zu identifizierende Netzwerkprobleme lokalisieren.

Quellen und ausführbare Programme bekommt man von

ftp.funet.fi:/pub/OS/Linux/PEOPLE/Linus/net-source/tools/tcpdump-3.0.3.tar.gz

tcpdump dekodiert jedes abgefangene Datagramm und zeigt es - in einer etwas kryptischen Form - als Text an. tcpdump bietet sich an um Protokollfehler oder plötzliche Verbindungsabbrüche aufzuspüren, denn man kann damit sehen, was auf dem Netzwerk passiert. Um es jedoch sinnvoll einsetzen zu können bedarf es eines tieferen Verständnisses der Protokolle und wie sie arbeiten, doch es kann auch einfach dazu benutzt werden um sicherzustellen, daß z.B. Datagramme den eigenen Rechner wirklich über die richtige Schnittstelle verlassen oder um zu überprüfen, ob irgendwelche Datagramme von außerhalb empfangen werden. Eine typische Ausgabe von tcpdump sieht etwa so aus:

% tcpdump -i eth0
tcpdump: listening on eth0
13:51:36.168219 arp who-has gw.vk2ktj.ampr.org tell albert.vk2ktj.ampr.org
13:51:36.193830 arp reply gw.vk2ktj.ampr.org is-at 2:60:8c:9c:ec:d4
13:51:37.373561 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request
13:51:37.388036 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply
13:51:38.383578 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request
13:51:38.400592 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply
13:51:49.303196 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: S 700506986:700506986(0) win 512 <mss 1436>
13:51:49.363933 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 1103372289 win 14261
13:51:49.367328 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: S 1103372288:1103372288(0) ack 700506987 win 2048 <mss 432>
13:51:49.391800 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 134 win 14198
13:51:49.394524 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: P 1:134(133) ack 1 win 2048
13:51:49.524930 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: P 1:28(27) ack 134 win 14335

 ..

tcpdump ohne Argumente gestartet überwacht das Netzwerk-Device mit der kleinsten Nummer, das kein Loopback-Device ist. Es kann aber - wie im Beispiel - auch ein spezielles Device angegeben werden. tcpdump dekodiert dann jedes Datagramm das über diese Device übertragen wird und zeigt es in einer lesbaren Form an. Der erste Eintrag ist wie leicht zu ersehen der Zeitpunkt, zu dem das Datagramm gesendet oder empfangen wurde. Der weitere Inhalt der Zeile hängt dann von der Art des Datagramms ab. Die ersten beiden Zeilen im Beispiel zeigen, wie ein arp request von albert.vk2ktj nach der Adresse von gw.vk2ktj aussieht. Die nächsten vier Zeilen sind zwei pings von albert.vk2ktj an gw.vk2ktj, tcpdump gibt dabei auch die genaue Art des icmp Datagramms an. Das Größer-Zeichen (>) gibt die Richtung an, in der das Datagramm übermittelt wurde, es zeigt vom Sender zum Empfänger. Die restlichen Zeilen protokollieren den Aufbau einer telnet Verbindung von albert.vk2ktj zu gw.vk2ktj.

Die Zahl am Ende jeden Rechnernamens gibt die verwendete Socket Nummer an, zu diesem Zweck wertet tcpdump die Datei /etc/services aus.

Alle weiteren Optionen werden in der Online-Hilfe behandelt.

Vorsicht PPP-Benutzer: Die derzeitige Version von tcpdump unterstützt das PPP-Protokoll nicht. Es gibt zwei Patches von Al Longyear die diese Unterstützung implementieren, es wurde jedoch bislang noch kein vollständiges tcpdump-Paket damit zusammengestellt. Diese Patchdateien sind auf sunsite.unc.edu im selben Verzeichnis wie tcpdump.

14.4 icmpinfo - Übersicht über empfangene icmp Meldungen

Das Internet Control Message Protocol (icmp) liefert hilfreiche Informationen über den Zustand des IP-Netzwerkes. Meist werden derartige Meldungen vom System direkt empfangen und verarbeitet, ohne daß man als Benutzer oder Netzwerkadministrator etwas davon mitbekommt. icmpinfo ist ein Programm, daß alle derartigen Meldungen ähnlich wie tcpdump mitprotokolliert und anzeigt. Laurent Demailly (dl@hplyot.obspm.fr) hat dieses Programm basierend auf den Quellen des BSD ping geschrieben.

Version 1.10 ist erhältlich über:

hplyot.obspm.fr:/net/icmpinfo-1.10.tar.gz

Kompilierung und Installation sind sehr einfach:

% cd /usr/src
% gzip -dc icmpinfo-1.11.tar.gz | tar xvf -
% cd icmpinfo-1.11
% make

Um icmpinfo zu benutzen muß man als root eingelogged sein. Die entschlüsselten Meldungen können wahlweise auf der Konsole ausgegeben oder via syslog protokolliert werden.

Um zu sehen wie icmpinfo arbeitet ist es sehr lehrreich, das Programm zu starten und dann ein traceroute auf einen entfernten Rechner auszuführen. Es werden dann die icmp-Meldungen, die traceroute verwendet, angezeigt.


Zurück Weiter Inhalt