PING und die Grenzen von ICMP

Eine Anfrage in einer Newsgroup hat mich zu dieser Seite inspiriert. Nebenbei ist es ein schönes Beispiel, wo Monitoring auch falsche Daten liefern kann.

Wenn ich in meinem Netzwerk einen Dauerping absetze, dann habe ich 0% Verlust. Setze ich aber einen Ping auf meine öffentliche IP meines Mailservers, dann habe ich immer so 2% Verluste.

Nun könnten Sie verunsichert sein, dass 2% "Verlust" ja ein Problem des Servers oder der Leitung bedeuten können, dem unbeding nachzugehen ist. Aber schauen wir uns die Analyse genauer an

PING ist ICMP

PING nutzt das Protokoll ICMP, welches auf der Ebene 3 im OSI-Schichtenmodell angesiedelt ist, wie IP. Es ist also etwas "tiefer" als TCP und UDP, die auf Ebene 4 sind. ICMP kennt daher auch keine "Ports". ICMP arbeitet wie UDP komplett ohne Handshake, den erst TCP mitbringt. Wenn ein Paket verloren geht, dann sorgt der IP-Stack nicht für eine erneute Übertragung. Aber das ist bei PING ja gerade gewollt, da ansonsten das System ja keine Verluste feststellen kann.

Nun kann es aber sein, dass durch eine hohe Last auf der Leitung der Ping 1,5 Sekunden für die Antwort braucht. Das "zu späte" Paket wird also nicht gezählt.

Das Paket, welches zum Zeitpunkt 3 gesendet wird, kommt nicht mehr vor Zeitpunkt 4 an und daher gibt PING zum Zeitpunkt 4 schon ein "Timeout" aus und sendet das nächste Paket auf die Reise. Das Paket am Zeitpunkt 5 geht nun wirklich verloren (Rot) und so gibt PING zum Zeitpunkt 6 auch ein "Timeout" an.

PING sendet seine Pakete mit einer Sequencenummer, d.h. Ping könnte sowohl eine verspätete Antwort als auch eine verdrehte Reihenfolge erkennen, nur ist die Bildschirmausgabe mit "Timeout" natürlich schon geschrieben.

Also müssen Sie herausbekommen, ob die Pakete wirklich "fehlen" oder einfach nur "nach Torschluss" eintreffen. Ein paar "Verluste" sind meist ganz in Ordnung, wenn diese in Wirklichkeit nur aufgrund "verspäteter Pakete" entstanden sind. Eine Erreichbarkeitsüberwachung sollten Sie mit einem höheren Protokoll machen. Um also einen Webserver zu "testen" sollten Sie auch den Webserver fragen, z.B. mit WGET oder anderen Tools.

PING mit Optionen

Um das Verhalten etwas zu verdeutlichen schauen wir uns vier verschiedene PING-Aufrufe an.

ping -t servername

Dieser Aufruf sendet nun alle Sekunde einen PING an den angegebenen Server und wartet demnach auch bis zu eine Sekunde auf die Antwort. Das funktioniert in einem LAN recht gut, aber bei einem Ping über eine WAN-Verbindung kann es hier schon zu Aussetzern kommen. Dies bedeutet aber nicht gleich, dass die Gegenstelle nicht erreichbar ist, sondern einfach dass vielleicht der Weg sehr lange ist oder eine Teilstrecke eben so belastet ist, dass unser Paket und die Antwort sich mit einreihen müssen.

Also ändern wir den Aufruf, so dass PING länger wartet:

ping -t -w 5000 servername

Nun sendet PING alle 5 Sekunden ein Paket. Wichtiger ist aber, dass PING auch bis zu 5 Sekunden auf die Antwort wartet. Mit diesen Einstellungen wird die Fehlerrate bei sonst gleichen Eckwerten sehr viel geringer sein, weil die Zeit einfach länger ist.

Allerdings sollten Sie natürlich schon hellhörig werden, wenn die Rundlaufzeit generell sehr lange ist. Das ist dann schon ein Hinweis auf eine partiell überlastete Verbindung zwischen ihnen und dem Server

Wenn Sie nun keine "langsame" Leitung haben, aber das Verhalten von fehlenden Paketen beobachten wollen, dann können Sie mit folgender Zeile einfach die Größe des Pakets steuern

ping -t -l10000 server

Nun sendet PING ein 10kbyte Paket an die Gegenstelle, die ebenfalls mit einen 10KByte Paket antwortet. Die Obergrenze ist bei 64Kbyte oder genauer 65535 Bytes. Frühere IP-Stacks waren hier angreifbar (Ping of Death) indem Sie einfach ein noch größeres Paket gesendet haben und die Gegenseite beim Reservieren des Empfangsspeicher dann seinen Nachbar mit überschrieben hat. Sehr viele Firewall blockieren daher überlange PING-Pakete als möglichen Angriff. Auch einige Router sind nicht korrekt in der Lage, solche Pakete zu verarbeiten, da ein Paket auf dem Kabel nur eine bestimmte maximale Länge haben darf (MTU-Size), die von Medium zu Medium unterschiedlich ist. Entsprechend muss ein Router das Paket aufteilen und die Gegenseite dieses wieder zusammen setzen.

  • 314825 How to Troubleshoot Black Hole Router Issues

Wird ihr großes PING Paket wirklich übertragen, dann sollten Sie nun eher Pakete vermissen. Mit 64Bit und selbst bei DSL mit 192kbit upstream reicht die Zeit einfach nicht mehr, um das Paket und die Antwort in 1 Sekunden zu übertragen. Es sieht so aus, als ob gar kein Paket mehr durchkommt.

Um diesen "Fehler" zu verdeutlichen wird nun PING wieder angewiesen, einfach länger zu warten.

ping -t -l10000 -w 5000 server

In 5 Sekunden solle auch ein 10KByte Paket hin und her übertragen worden sein. Der Ping meldet nun wieder Ergebnisse.

PING verbessert und Alternativen

Auch wenn Sie eine Dauerüberwachung wünschen, so ist es nicht wirklich hilfreich, jede Sekunde den Server mit einem Ping anzusprechen. Die Ergebnisse sind nicht wirklich besser, ob Sie nun sekündlich oder nur alle 10 Sekunden einen Ping senden. Durch einen 10-Sekunden-PING haben Sie aber die Möglichkeit, auch Laufzeiten über 1 Sekunde bis zu 10 Sekunden zu erkennen.

Nebenbei entlasten Sie die Leitung, den Server und ihr Volumen. Folgende kleine Rechnung soll dies verdeutlichen:

1 Ping = 64byte (gerundet) * 86400 Sekunden *2 = 5,4Mbyte/Tag oder 162 Megabyte pro Monat

Wenn Sie aber selbst mit langen Wartezeiten noch Aussetzer haben, dann sollten Sie ihren Windows Server darauf hin überprüfen, ob auch höhere Protokolle wie TCP so genannt "Retransmissions" durchführen. Das können Sie relativ einfach mit dem Windows Performance Monitor ermitteln.

Dieser Counter meldet ihnen die Rate, mit der der TCP/IP-Stack Pakete erneut überträgt. Sie sollte möglichst niedrig sein, aber erwarten Sie nicht, dass hier immer eine 0 steht.

Sie sehen aber, dass ein PING nur bis zu einer gewissen Grenze für Überwachung genutzt werden kann. Es ist ein erster Test, der die generelle Erreichbarkeit des anderen Systems sicherstellt, ehe eine Software dann die höheren Protokolle anspricht. Wenn Sie  weiterhin aber mit "Ping" die Erreichbarkeit prüfen wollen, dann könnten Sie mittels QoS z.B.: diese Pakete priorisieren, so dass Verluste dann eher einen Rückschluss auf die Erreichbarkeit der Gegenstelle schließen lassen.

Ping mit VBScript

Es gibt leider kein direktes "COM-Objekt", welches sie mit VBScript ansprechen können oder gar einen VBScript-Befehl. Sie können per VBScript daher zwei Optionen nutzen

  • PING.EXE starten
    Sie starten einfach die Kommandozeilenversion und werten die Ausgaben aus.
  • WMIPING
    Sie nutzen die WMI-Funktion, um damit einen PING zu senden. Da WMI "remote"-fähig ist, können Sie damit zumindest mit einem Windows Server als  Host auch in der Ferne einen Ping anstarten
Function wmiping(strComputer)
   Dim PingResults, Pingresult
   Set PingResults = GetObject("winmgmts://localhost/root/cimv2"). ExecQuery("SELECT * FROM Win32_PingStatus WHERE Address = '" + strComputer + "'") für Each PingResult In PingResults
       If PingResult.StatusCode = 0 Then
          wmiping = True
       Else
          wmiping = False
       End If
   Next
End Function

Ping mit PowerShell

Per PowerShell haben Sie gleich zwei native Optionen, einen PING zu starten. Sie können natürlich auch weiterhin die "PING.EXE" aufrufen oder einen WMI-Ping machen aber eleganter sind die beiden folgenden Methoden:

  • PING per Commandlet
    Mit "Test-Connection" können Sie einfach System anpingen und erhalten direkt die Antwort
  • PING per .NET-Klasse
[string]$target= 127.0.0.1"
$result = (new-object System.Net.NetworkInformation.Ping).Send($target)

Test-Connection ist sicher der einfachste Weg, wenn keine erweiterten Funktionen erforderlich sind:

Test-Connection `
   -ComputerName] <string[]>  `
   -BufferSize 160  `
   -Count 1  `
   -TimeToLive xx

Weitere Links