1.9. Diagnose

1.9.1. Verbindungstest

Wenn eine Netzanwendung nicht oder schlecht funktioniert, kann das alle möglichen Ursachen haben. Eine erste wichtige Differenzierung der Störungsursache ist die Frage, ob das Problem netzseitig liegt (d.h. in der IP-Schicht oder darunter) oder eher anwendungsseitig (Transport und Anwendung).

Einen einfach handhabbaren Verbindungstest brauchen Sie auch, wenn Sie z.B. eine neue Netzkonfiguration aufgebaut oder Routen neu eingestellt haben.

Die technische Basis dazu haben Sie bereits im Abschnitt "ICMP" in Form der Nachrichten Echo Request und Echo Reply kennengelernt. Die Benutzeroberfläche dafür stellt das Programm ping dar, das auf praktisch allen Rechnern mit TCP/IP verfügbar ist. Hier soll die Linux-Variante näher vorgestellt werden, die einen recht repräsentativen Funktionsumfang hat: 

  ping Optionen Zieladresse
Wesentliche Optionen sind:
-c Anzahl
ping nach dem Senden der angegebenen Paketanzahl beenden.
Manche ping-Varianten senden standardmäßig nur ein Paket aus und werden durch die Option -s zum ständigen Senden veranlaßt.
-f
"Fluten" des Netzes, d.h. Senden in möglichst dichter Folge.
Das sollten Sie keinesfalls auf einem vielgenutzten Netz ausprobieren!
-i Sekunden
Intervall zwischen den Paketen einstellen (Standard: 1 s).
-l Anzahl
Die angegebene Paketanzahl so schnell wie möglich senden ("preload"), danach im normalen Intervall fortfahren.
-n
IP-Adressen numerisch angeben (sinnvoll, wenn DNS gemieden werden soll).
-p Datenmuster
Angabe eines Datenmusters für das ping-Paket.
Damit kann man datenmuster-abhängigen Problemen auf die Spur kommen. Problemträchtig sind z.B. Pakete, die nur aus 1-Bits bestehen. Dann gibt man -p ff an.
-s
Paketgröße (size) festlegen. Standard ist 56 Byte (dazu kommen noch die 8 Byte ICMP-Kopf, 20 Byte IP-Kopf und eventuelle Köpfe der Link-Schicht).
-R
Record-Route-IP-Option einstellen. Es können maximal 9 Zwischenstationen registriert werden (siehe auch den nächsten Abschnitt "Routenermittlung").
-r
Routingtabelle ignorieren, z.B. für automatisch ausgeschaltete Routen, um die Ursache des Ausschaltens zu erkunden.
Ältere ping-Varianten warten nur eine Antwort ab. Die Ausgabe ist dann nicht sehr informativ, aber wenigstens weiß man jetzt, daß die IP-Pakete den anderen Rechner erreichen: 
  % ping 134.109.192.128
  134.109.192.128 is alive
Die oben beschriebene Variante sendet kontinuierlich Pakete und liefert zum Schluß (nach Abbruch mit Ctrl-C) eine Statistik: 
  # ping localhost
  PING localhost (127.0.0.1): 56 data bytes
  64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.7 ms
  64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.5 ms
  64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.5 ms

  --- localhost ping statistics ---
  3 packets transmitted, 3 packets received, 0% packet loss
  round-trip min/avg/max = 0.5/0.5/0.7 ms
Die wichtigste Information hieraus ist die Zeit vom Abschicken der Anforderung bis zum Eintreffen einer Antwort; diese "Round-Trip"-Zeit beträgt hier etwa 0.5 ms. 
  % ping -s -n 134.109.192.128 100 3
  PING 134.109.192.128: 100 data bytes
  108 bytes from 134.109.192.128: icmp_seq=0. time=3. ms
  108 bytes from 134.109.192.128: icmp_seq=1. time=1. ms
  108 bytes from 134.109.192.128: icmp_seq=2. time=1. ms

  ----neptun PING Statistics----
  3 packets transmitted, 3 packets received, 0
  round-trip (ms)  min/avg/max = 1/1/3
Hier noch ein Beispiel mit eingeschalteter Record-Route-Option: 
  % ping -R www.uni-leipzig.de
  PING www.uni-leipzig.de: 100 data bytes
  108 bytes from rzaix530.rz.uni-leipzig.de (139.18.1.50): 
       icmp_seq=0. time=2192. ms
    IP options:   
      agsplus1.hrz.tu-chemnitz.de (134.109.2.251), 
      TUC-gate.HRZ.TU-Chemnitz.DE (188.1.132.114), 
      cisco-ulrz.rz.uni-leipzig.de (139.18.1.3), 
      rzaix530.rz.uni-leipzig.de (139.18.1.50), 
      WiN-cisco-ULRZ.RZ.Uni-Leipzig.DE (188.1.132.213), 
      tuc-gate.hrz.tu-chemnitz.de (134.109.2.250), 
      agsplus1.hrz.tu-chemnitz.de (134.109.192.254), 
  .
      venus.hrz.tu-chemnitz.de (134.109.192.45),  (End of record)
  
  ----www.uni-leipzig.de PING Statistics----
  1 packets transmitted, 1 packets received, 0
  round-trip (ms)  min/avg/max = 2192/2192/2192
Ein weiteres einfaches Experiment können Sie vielleicht auch selbst ausprobieren, wenn Sie noch einen zweiten Rechner in der Nähe haben (wenn nicht, können Sie unser fernbedienbares Labor nutzen).

Die Rechner werden durch ein "Nullmodemkabel" verbunden. Dann kann man eine SLIP-Verbindung aufbauen. Hier sind die erforderlichen Kommandos für Rechner 1 (192.168.7.1): 

  slattach -p cslip -s 19200 /dev/cua1 &
  ifconfig sl0 192.168.7.1 pointopoint 192.168.7.2 up
  route add default gw 192.168.7.1
Jetzt schauen wir sicherheitshalber einmal nach, ob die Schnittstelle auch richtig konfiguriert ist: 
  # ifconfig sl0
  sl0       Link encap:VJ Serial Line IP  
            inet addr:192.168.7.1  P-t-P:192.168.7.2  Mask:255.255.255.0
            UP POINTOPOINT RUNNING  MTU:296  Metric:1
            RX packets:0 errors:0 dropped:0 compressed:0
            TX packets:0 errors:0 dropped:0 compressed:0
Der Verbindungstest sollte folgendes liefern (wenn alles in Ordnung ist): 
  # ping 192.168.7.2
  PING 192.168.7.2 (192.168.7.2): 56 data bytes
  64 bytes from 192.168.7.2: icmp_seq=0 ttl=255 time=97.1 ms
  64 bytes from 192.168.7.2: icmp_seq=1 ttl=255 time=100.1 ms
  64 bytes from 192.168.7.2: icmp_seq=2 ttl=255 time=100.1 ms
  64 bytes from 192.168.7.2: icmp_seq=3 ttl=255 time=100.1 ms
  64 bytes from 192.168.7.2: icmp_seq=4 ttl=255 time=103.9 ms
  
  --- 192.168.7.2 ping statistics ---
  5 packets transmitted, 5 packets received, 0% packet loss
  round-trip min/avg/max = 97.1/100.2/103.9 ms
Frage 1.9.1.1.:

Wie kommt die relativ lange "Round-Trip"-Zeit von etwa 100 ms zustande?

Diskussion: 1.9.1.2.

Die Zahl der am Internet betriebenen Rechner (und deren Tendenz) ist eine interessante Größe. Diese Zahl ist aber sicher kleiner als die Zahl der ausgeteilten IP-Adressen, da viele Adressen "auf Vorrat" beschafft werden.
Man könnte nun "einfach" den gesamten (belegten) IP-Adreßraum mit Ping durchprobieren; dabei zählt man dann, bei wievielen Adressen man eine Antwort bekommt.

  1. Wie lange würde das dauern, wenn man eine Bandbreite von 64 kbit/s zum Internet ansetzt?
  2. Das beschriebene Verfahren geht sehr verschwenderisch mit Netzressourcen um. Es wird daher nicht empfohlen (und auch nicht geduldet). Überlegen Sie, ob es eine Modifikation des Verfahrens gibt, die auch mit wesentlich geringerer Inanspruchnahme von Ressourcen das gewünschte Ergebnis mit hinreichender Genauigkeit ermittelt (Denken Sie an die Hochrechnungen am Wahlabend!)!
  3. In den letzten zwei Jahren stagniert der so gefundene Wert. Wie kann man das erklären?
© Uwe Hübner, 29.09.96