ICMP

"Bitte nur ein Ping" ist ein bekannter Satz im Film "Roter Oktober" zwischen Alec Baldwin und Sean Connery. Wird doch ein akustischer PING und das darauf zurückkimmende Echo genutzt, um über der Laufzeit die Entfernung genauer zu ermitteln. Im Wasser ist die Laufzeit des Schalls aber relativ konstant, wenn wir mal Temperatur und Salzgehalt vernachlässigen. ICMP ist nicht UDP und nicht TCP, sondern ein eigenes Protokoll, welches aber auf IP aufbaut. Die meisten Anwender und Administratoren wissen eigentlich nur, dass ICMP etwas mit PING und TraceRoute zu tun haben könnte.

Ping, Tracert, Traceroute, PathPing quasi die Standardwerkzeuge um zumindest die Erreichbarkeit, Entfernung und Laufzeit von Paketen zu Gegenstellen zu prüfen. Auch wenn damit keine absoluten Aussagen zu verfügbaren Bandbreiten etc. gemacht werden können, ist ICMP ein durchaus probates Mittel, eine Verfügbarkeit zu müssen.

Achtung
ICMP ist nur ein bedingt gültiger Test für Firewalls, Bandbreiten und VoIP-Qualität. ICMP wird von Firewalls und Routern oft anders behandelt als TCP/UDP-Pakete.

ICMP Grundlagen

Im Gegensatz zum U-Boot-Ping sendet die anfragende Station ihren Ping an eine Zieladresse, die dann über die konfigurierten Leitwege sich über Router hinweg auf den Weg macht bis es am Ziel ankommt und beantwortet wird. Das ist der "normale PING".

So kann der anfragende Client schon einmal erkennen, das das Ziel per IP und ICMP erreichbar ist und über die Zeit bis zur Antwort einen Hinweis auf die Laufzeit ermitteln. Über das "Time to Live"-Feld, welches in der Antwort enthalten ist, kann auch die Anzahl der Zwischenstationen ermittelt werden. Jeder Router subtrahiert dieses Feld, welche ursprünglich bei 128 (0x80) startet. Dieses Paket hat also schon 11 andere Stationen durchlaufen.

Will man nun den Weg zwischen zwei Stationen ermitteln, dann werden dazu einfach eine Menge ICMP-Pakete auf die Leitung gesendet, die aber nicht mit dem TTL=128 anfangen, sondern TTL=1 und aufsteigend. Damit beantworten der Router, bei dem der TTL dann auf 0 ankommt, die ICMP-Anfrage. Im Netmon kann man das schön sehen. Zuerst die DNS-Anfragen und dann aufsteigend die ICMP-Anfragen beginnend mit einem TTL=1.

Entsprechend verwerfen die Router das Paket mit einem "Time Exceeded Message". Übrigens haben auch diese "Rückantworten" einen TTL aus dem man erkennen kann, wie lange diese unterwegs sind. Und sie können hier schon sehen, dass der Rückweg für einige Pakete "kürzer" oder anders sein muss, ansonsten wäre der TTL=249 nicht so oft vertreten. An einem einfachen Bild lässt sich das anschaulich darstellen:

Der erste PING wird beim ersten Router schon mit "Exceeded" quittiert. Mit dem TTL=2 kommt der PING über den ersten Router hinweg aber wird dann von einem der beiden Router2A oder Router2B terminiert. Der Dritte Ping kommt bis zum Router 3. Allerdings gibt es keine Information, ob das Packet über Router2A oder Router2B gelaufen ist. die Rückantwort muss auch nicht den gleichen Weg gehen. Als Antwort-Adresse bekommen Sie in der Regel die IP-Adresse des Routers zu sehen, die sich zum Sender hin befindet. PING und TRACERT nutzen standardmäßig 64byte Pakete. Es ist erlaubt, diese Paketgröße zu ändern. Die Empfängerseite kopiert die Daten und sendet Sie zum Absender zurück. So kann dieser eine Veränderung der Daten erkennen. Allerdings ist dies auch ein mögliches DoS-Angriffsmuster, zumindest wenn die Router die Quell-IP-Adresse nicht überprüfen und gefälschte Quelladressen zulassen.

Ansonsten ist eine geänderte Paketgröße natürlich ein wirksames Mittel, um nicht nur die Erreichbarkeit, sondern z.B. auch die Fragmentierung und MTU-Size von Verbindungen zu prüfen oder einfach etwas mehr Last zu produzieren.

ICMP in der Praxis

Um die Funktion von ICMP zu zeigen, habe ich meinen PC im Homeoffice hinter einer Fritz!Box genutzt, um den den Weg zu meinem Lync Edge Server zu ermitteln. Diese Verbindung ist für mich besonders interessant, da ich ja per Lync/VoIP auch telefoniere und hier kurze und gleiche Laufzeiten als auch wenig Paketverluste wünschenswert sind. Natürlich meldet Lync auf dem Client als auch auf dem Server, wenn es für den Anwender "hörbare" Probleme gibt, aber ich weiß dann immer noch nicht, an welcher Stelle der Verbindung es knirscht. Mit Bordmitteln kann ich natürlich einen ersten Blick erhalten:

C:\>tracert avedge.netatwork.de

Routenverfolgung zu avedge.netatwork.de [80.66.20.21] über maximal 30 Abschnitte:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.0.1]
  2    15 ms    15 ms    15 ms  87.186.224.81
  3    17 ms    17 ms    19 ms  87.190.172.202
  4    20 ms    20 ms    20 ms  hh-ea4-i.HH.DE.NET.DTAG.DE [62.154.33.34]
  5    20 ms    21 ms    22 ms  80.156.160.242
  6    21 ms    21 ms    21 ms  hbg-bb2-link.telia.net [213.155.135.88]
  7    58 ms    26 ms    27 ms  ffm-bb2-link.telia.net [80.91.249.88]
  8    27 ms    27 ms    28 ms  ffm-b12-link.telia.net [213.155.135.13]
  9    29 ms    28 ms    28 ms  ewetel-ic-153161-ffm-b12.c.telia.net [195.12.254.230]
 10    44 ms    44 ms    44 ms  bbrt.ol-1-10ge-0-0-0.ewe-ip-backbone.de [212.6.114.1]
 11    51 ms    51 ms    51 ms  212.6.114.69
 12   101 ms    51 ms    51 ms  interface-080-228-235-094.ewe-ip-backbone.de [80.228.235.94]
 13    48 ms    49 ms    48 ms  m7i-1.eggenet.de [80.66.0.153]
 14    52 ms    51 ms    51 ms  008-000-066-080.eggenet.de [80.66.0.8]
 15    53 ms    52 ms    53 ms  gate.netatwork.de [80.66.20.21]

Ablaufverfolgung beendet.

Aber wenn sie den Befehl ausführen, dann werden Sie sehen, dass es relativ lange dauert, bis das Ergebnis da ist. Das liegt zum einen daran, dass TRACERT die ICMP-Anfragen mit einem aufsteigenden TTL versendet, so dass es die Zwischenstationen ermitteln kann. Zudem sendet es mehrere ICMP-Pakete, um Min/Max/AVG-Werte zu erhalten und zuletzt versucht es zur IP-Adresse einen Namen zu finden. Die Daten sind zudem nur dann zutreffend, wenn der Weg immer der gleiche ist.

Wer antwortet auf ICMP?

Der Erreichbarkeitstest mittels ICMP ist seit den Anfangstagen des Internets ein wichtiges Werkzeug, um mehrere Faktoren zu prüfen.

  • Erreichbarkeit des Ziels
    Wenn eine Antwort zurückkommt, dann ist eigentlich davon auszugehen, dass sie die Gegenstelle tatsächlich erreicht haben. Sicher gibt es WAN-Optimierer, die auf ein PING antworten aber sie nehmen sich damit alle Möglichkeiten die Ende zu Ende Verbindung zu überprüfen.
  • Funktionierendes Routing
    Wenn ein System in einem anderen entfernten Netzwerk antwortet, dann können Sie zumindest sicher sein, dass es von ihrem System einen funktionierenden Leitweg zum Ziel-Netzwerk gibt und von dort auch ihr Netzwerk erreichbar ist. Ob das dann aber der gewünschte weg ist, steht auf einem anderen Blatt
  • Paketlaufzeit
    Anhand der Zeit, die ein Paket auf dem Hin und Rückweg braucht, können Sie die "Umlaufzeit" ermitteln. Wenn wir weiter davon ausgehen, dass die Geschwindigkeit in jede Richtung gleich ist, dann liefert die Hälfte dieser Zeit eine Aussage zur Entfernung. Es gibt natürlich sicher WAN-Stecken, die asymmetisch sind, z.B. ein klassische DSL-Anschluss oder überlastete Strecken. Das sind aber meist Teilstrecken und wer häufiger die Laufzeit prüft, sollte schon halbwegs sinnvolle Werte bekommen
  • Verlustrate
    Mit dem gleichen Test fällt natürlich auch auf, wenn Pakete gar nicht ankommen. Sie haben natürlich keine Aussage darüber, welche Station das Paket verworfen hat. Es ist aber das gute Recht von Routern, Pakete auch wieder zu verwerfen. Bei TCP kümmert sich dann das darüberliegende Protokoll darum. Bei UDP ist z.B. mit Audio oder Video ein Verlust sogar in Grenzen tolerierbar. Bei ICMP gibt es auch keine Sicherungsschicht.

Insofern wäre es doch super, wenn alle Systeme auf einen ICMP-Ping auch antworten würden.

Allerdings stehen viele Administratoren noch auf dem Standpunkt, dass ein Angreifer so natürlich auch eine Landkarte des Netzwerks mit den Verbindungen und Routern erstellen könnte. Zudem könnte er die Erreichbarkeit von Endsystemen, die Belegung eines Subnetzes etc. ermitteln. Diese Bedenken sind durchaus ernst zu nehmen. Früher waren IP-Stacks sogar über einen PING angreifbar (Siehe Ping of Death http://de.wikipedia.org/wiki/Ping_of_Death). Solche Fehler gelten mittlerweile als gelöst.

Aber auch Systeme sind oft per Default nicht per ICMP-Ping erreichbar. Ein Windows 2008+ Server antwortet z.B. nicht auf ICMP-Anfragen, es sei denn Sie aktivieren diese Funktion. Sie wird aber z.B. automatisch aktiviert, wenn Sie die Rolle eines Dateiservers addieren. Denn viele Clients macht erst mal einen "PING" ehe Sie eine teurere TCP-Verbindung aufbauen. Es hat sich aber als "gute Praxis" bewährt, wenn zumindest die aktiven Router auf ICMP-Anfragen antworten. Wobei auch hier wieder "WAN Optimizer" und Firewalls abgestuft reagieren und damit die Messwerte verfälschen können.

ICMP als Test

Vieleicht können Sie schon die Seiten End2End-File und End2End Mailbox, die durch synthetische Last nicht nur eine Art "Dauerüberwachung" auf "Erreichbar" sondern sogar Antwortzeit beschreiben. Natürlich kann ich auch Netzwerkverbindungen auf ihre "Belastung" per SNMP abfragen. Aber diese passiven Abfragen haben den Nachteil, dass Sie eben "Out of Band" erfolgen.

Von oben alle 5 Minuten auf eine Autobahn zu schauen um den Verkehrsfluss zu bewerten ist etwas ganz anderes, als ein paar Testfahrer einzusetzen, die laufend Bericht erstatten. Haben lange Zeit Fahrbahnsensoren die Dichte erfasst, so können heute "reisende Smartphones" viel besser die Fortbewegungsleistung berichten, sei es per GPS Signal und Datenverbindung oder einfach durch das Roaming entlang der Funkmasten.

Für eine Netzwerküberwachung kann, sofern technisch nicht verhindert, ein einfacher ICMP-Test schon erste Aussagen erlauben. Er ist natürlich nicht mit einem echten UDP/TCP-Test und einer simulierten VoIP-Verbindung gleichzusetzen. Hier können ja Priorisierung oder auch Drosslung seitens der Router angewendet werden. Da ICMP aber ganz einfach und günstig umzusetzen ist und sogar die Zwischenstationen prüfbar macht, kann man mit ein paar gezielten PINGs doch Aussagen treffen. In eine Richtung geht dies sogar per UDP/TCP, indem man den Roundtrip hierzu prüft.

Bleibt die Frage, wie man z.B. einen Test auf Basis von ICMP aufsetzt, der dem realen Anwendungsfall nahekommt ohne die Systeme zu überlasten. Am Beispiel einer VoIP-Verbindung wissen wir ja, dass die AudioDaten per RTP in der Regel über UDP "gestreamt" werden. Dabei kommen bei einer Abtastrate von 20ms mit G711 Narrow-Band (8Bit) also 50 Pakete pro Sekunden mit 160 Byte Nutzlast zzgl. Overhead zum Einsatz.

ICMP Varianten

Es gibt leider immer noch Firewall-Administratoren, die ICMP als Teufelszeug ablehnen und blocken. Zwar sind die Zeiten eines "Ping of Deatch" schon lange vorbei. Damals konnte man Cisco-Router u.a. Geräte mit übergroßen ICMP-Paketen lahmlegen. Aber auch heute wird PING gerne geblockt, da man damit ja eine "Netzwerkkarte" der möglichen Ziele erstellen könnte. ICMP ist aber nicht nur einfach ein PING sondern eine ganze Familie von Funktionen und zur Erreichbarkeitsprüfung könnten sie auch andere Optionen nutzen.

Option ICMP gesendet ICMP Antwort Beschreibung

Klassischer PING mit

Type=8/Code=0

 Type=0/Code=0
oder Timeout

Der klassische Ping ist gut beschrieben. Sie senden ein passend formatiertes Paket und bekommen von der Gegenstelle eine Antwort. Sie erhalten aber keine Information über den Weg oder Zwischenstationen.

Traceroute mit TTLExceed

Type=8/Code=0

Type=11/Code=0

Erst der Traceroute liefert auch die Zwischenstationen. Mehrere Pakete werden mit einem aufsteigenden TTL gesendet, bis sie am Ziel ankommen

DF Fragmentation Needed

Type=8/Code=0 mit großer Datenmenge

 Type=3/Code=4
oder Timeout

Wenn ich ein extra großes Paket send und die Fragmentierung verbiete, dann sollte ein Router, der nur kleinere Pakete erlaubt, darauf entsprechend antworten. Wenn nicht vorher ein anderer Router schon blockiert, kann man so einer Station manchmal eine Antwort entlocken.

Es sind noch viel mehr Konstellationen definiert.

Letztlich sind es aber alles ICMP-Echo Requests, die unterschiedliche Antworten bekommen. Allerdings ist Vorsicht bei den Ergebnissen walten zu lassen. Mein Client hat eine Ethernet-Verbindung mit MTU=1500Bytes. Nach Abzug des IP-Headsets kann ein ICMP-Ping bis zu 1472 Bytes groß sein.

PING-Kommando Ergebnis Wireshark 
ping 8.8.8.8

OK

 Das klassische PING mit einem kleinen 32 Byte Paket als Payload
 
ping 8.8.8.8 -l 1472

OK

 Mit 1472 Bytes erreiche ich gerade die MTU1500, mit der dann auf dem Ethernet 1514 Bytes landen
 
ping 8.8.8.8 -l 1473

Timeout

 Mit 1473 Bytes passt das Paket nicht mehr in ein
 
ping 8.8.8.8 -l 1473 -f

Fragmentation needed

 Auf dem Kabel kommt aber kein Paket an, d.h. mein lokaler IP-Stack verhindert schon den Versand
 
ping 8.8.8.8 -l 1473 -i 3

TTL Exceeded

 Wenn ich aber "DF" nicht setze, dann kann ich mit dem TTL arbeiten, um die Stelle zu finden, die mir kein "Fragmentation needed" sendet.

In meinem Fall was das mit Google gerade der Google-Server Der Router davor hat noch ein "TTL Exceeded" gemeldet aber die 8.8.8.8 hat mir mir erst geantwortet, wenn die Pakete nicht fragmentiert waren.

Das Verhalten ist zumindest bedenklich, denn wenn dies bei einer TCP-Kommunikation passiert, dann wartet der Client ewig auf die Meldung und die Funktion MTU Path Discovery ist nicht gegeben. Das kann aber auch irgendwo auf dem Weg zum Ziel passieren.

ICMP als Test für VoIP?

Nun muss man sich natürlich überlegen, wie so ein Test denn aussehen soll. Natürlich kann ich einfach hingehen und eine RTP-Verbindung indem 50 Pakete a 160byte permanent kreiseln. Damit wäre zumindest ein End2End Test bezogen auf eine VoIP-Verbindung in etwa abgebildet. QoS, Firewall-Filter ignoriere ich nun einfach mal. Aber reicht mir das ?. Wenn ich eine Trunk für 100 VoIP Kanäle überwachen oder müssen wollte, dann wäre es angebracht zu sehen, wie viele Verbindungen aktuell bestehen und dann vielleicht den Rest "aufzufüllen" und im Fehlerfall mich zurück zu nehmen. Das ist aber nicht einfach zu leisten.

Auf der anderen Seite habe ich nichts davon, so viel Last zu erzeugen. Kurze Probleme von weniger als 0,1Sek werden bei VoIP in der Regel gar nicht gemerkt. Also könnte ich es bei 10 Paketen/Sekunde belassen und vielleicht reichen auch weniger Bytes. Wobei dann echte "Engpässe" nicht unbedingt auffallen müssen.

Angenommen ich "erkenne", dass aktuell eine lange Laufzeit oder gar Paketverluste auftreten. Dann interessiert mich natürlich, an welcher Stelle diese vermutlich passieren. Dann reicht der PING bis zum Ende nicht mehr aus. Ich bin dann besser dran, einen Ping mit kleinen TTL-Werten analog zu einem TraceRoute zu senden. Nur welcher Weg hat das verlorene Paket gerade genommen und ist es ratsam, alle Zwischenstationen von Absender bis zum Empfänger mit ICMP-Paketen zu bombardieren die man idealerweise umgehend nach dem Erkennen des Ausfalls lossendet. Kann es dann aber nicht gerade sein, dass dies auch meine Messung verfälscht, wenn ich selbst bei 10 Hops mal eben 10 Pakete a 160 Byte mit Gigabit auf das Kabel setze und der nächte Router diese schon gleich verwirft?

Nein, jede Messung muss mit Augenmaß erfolgen und sollte letztlich zu verwertbaren Ergebnisse kommen. Daher habe ich mir folgendes ausgedacht.

  • Der Administrator definiert das Ziel anhand eines Namens oder einer IP-Adresse
    Einen Automatismus zum erkennen von z.B. Lync Servern (Konferenz, Mediation, Gateway, Edge) habe ich noch nicht vorgesehen.
  • Der Administrator definiert dazu gehörige "relevante" Zwischenstationen
    Wenn Sie oben das Tracert-Bild sehen, wären z.B. die Übergänge von Providern interessant. Eine automatische Ermittlung erspare ich mir hier und erwarte, dass derjenige, der das Ziel aussucht auch mit Tracert etc. die relevanten Zwischenstationen ermitteln kann.
  • Das Testprogramm sendet 1 Paket mit 160 Byte all 100ms an das Ziel
    Insgesamt wird also eine kontinuierliche Last von 1,6kbyte in jede Richtung erzeigt.
  • Von einem "Vorfall" wird ausgegangen, wenn ein die Antwortzeit über 500ms liegt
    Damit sind Totalverluste natürlich ebenfalls erfasst
  • Test der Zwischenstationen bei einem Vorfall
    Nur bei einem Vorfall macht sich das Skript die Mühe, auch die angegebenen Zwischenstationen abzuprüfen.

So werden nur wenige Pakete "zusätzlich" zur sowieso vorhandenen Last übertragen aber von Anwendern "merkliche" Ausfälle sowohl erkannt als auch die Teilstrecke im LAN gut eingegrenzt werden kann.

Sicher macht ein "einzelner Fehler" noch keine qualitative Aussage. VoIP-Debugging ist mehr als nur mal ein paar ICMP-Pakete zu versenden. Andere wichtige Kriterien wie unterschiedliche Laufzeiten (Jitter), Burst von Paketverlusten, umsortierte Pakete z.B. aufgrund unterschiedlicher Wege etc. können so nicht ermittelt werden. Das geht dann wirklich nur mit aktiven Probes an verschiedenen Stellen, die echte VoIP-typische Last generieren und auch auswerten.

Ping mit PowerShell

Natürlich bietet sich PowerShell hierzu an, da es mit "TEST-Connection" sogar ein Commandlet bereit stellt, welches einfach anzusprechen ist und die Ergebnisse als Objekt zurück liefert.

Hinweis: Test-Connection nutzt WMI und nicht PowerShell Remote, wenn andere Computer ferngesteuert werden.

Das Skript muss also nicht einen PING-Output "parsen". Hier die relevanten Parameter:

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

Relevant ist hier der Count 1 (statt default4) und die Erhöhung der Buffersize. Bei der Behandlung eines Vorfalls muss natürlich mit TimeToLive gearbeitet werden. Allerdings habe ich nach einigen Versuchen noch einen anderen Weg gefunden, einen ICMP-Ping abzusetzen, der scheinbar weniger Last verursacht, von WMI unabhängig ist, weniger Bugs hat und vor allem beim Timeout auch keinen Error wirft:

Man muss zwar den Buffer erst manuell als [byte[]] initialisieren, aber dann kann über den Status und die Roundtripzeit sehr einfach das Ergebnis abgegriffen werden.

$ping = new-object System.Net.NetworkInformation.Ping
[byte[]]$buffer = @(0,1,2,3)
#$pingresult= $ping.send($target,$timeout,$buffer)
$pingresult= $ping.send("8.8.8.8",500,$buffer)
write-host $pingresult.Status
write-host $pingresult.roundtriptime

PS C:\> $pingresult
Status        : Success
Address       : 8.8.8.8
RoundtripTime : 45
Options       : System.Net.NetworkInformation.PingOptions
Buffer        : {0, 1, 2, 3}

Ich bin immer wieder erstaunt, wie leistungsfähig doch PowerShell sein kann, da ein Zugriff auf .NET Klassen direkt möglich ist. Der Rest ist dann relativ überschaubar:

Weitere Links