End2End-Ping

Diese Test ist vielseitig nutzbar. Ich lege hier aber meinen Schwerpunkt auf "Lync", um die angepassten Parameter zu erklären und einen direkten Praxisbezug herzustellen.

Achtung
ICMP ist nur ein bedingt gültiger Test für VoIP-Qualität.

"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.

Aber auch bei Computern sind die Programm 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.

Vorbemerkungen

Das ist aber nicht immer möglich, da viele Dienste eine Antwort auf eine ICMP-PING-Anfrage unterbinden. Früher waren IP-Stacks über einen PING angreifbar (Siehe Ping of Death http://de.wikipedia.org/wiki/Ping_of_Death). Solche Fehler gelten mittlerweile als gelöst. Da über ICMP-Anfragen aber auch Netzwerke "abscannen" lassen, ist das ein weiterer Grund, wenn ein System nicht per ICMP antwortet.

Hier geht sogar Windows 2008 als Beispiel voran. Ein Windows 2008 Server antwortet nicht auf ICMP-Anfragen, es sei denn man aktiviert diese Funktion. Sie wird aber z.B. automatisch aktiviert, wenn Sie die Rolle eines Dateiservers addieren. Denn viele Clients macht erst mal einen "PING" ehen 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 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.

Es gibt leistungsfähigere Programme wie Visual TraceRoute von IPSwitch, die den Weg und die Laufzeiten schön grafisch aufzeigen:

Wenn Sie sich die Linie anschauen, dann erkennen Sie, dass von dem 10ten auf den 11ten Hop die Antwortzeit wieder kürzer ist. Das Paket mit einen TTL=11 ist entweder einen anderen Weg gelaufen oder die Auslastung davor war vorher etwas höher. Wenn Sie dann aber mal auf die Topologie umschalten, dann wird das Bild verständlich:

Ich habe einen DSL-Anschluss der Telekom und an der 4. Position gibt es redundante und lastverteilte Wege. Die Position 6 ist wohl der einzige "Interconnect" von der Telekom zu TeliaNet, die aber eine vermaschte Struktur haben. Wenn man mal 100 ICMPs los sendet, dann wird die Masche noch größer. Über die Stationen 9 und 10 geht es dann zur EWETEL, die als Provider für EGGENET dient. Von dort ist es dann immer der gleiche Weg bis zu meinem Edge Server. Der Abstand der Striche ist ein Maß für die Laufzeit.

Mit dem gezielten Einsatz von aufsteigenden TTLs können Sie auch UDP und TCP-Ports indirekt prüfen. Wenn das UDP/TCP Paket die Router entlang des Weges passiert und der Router an der TTL=0-Stelle ein "Exceeded" sendet, dann wissen Sie zumindest dass das Packet nicht schon vorher durch eine Firewall geblockt wurde.

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.

Sinnvoll testen

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
$pingresult= $ping.send($target,$timeout,$buffer
write-host $pingresult.Status
write-host $pingresult.roundtriptime

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:

Umsetzung

Das Script testet erst mal genau ein Ziel und erwartet die Zwischenstationen im Fehlerfall als auch die Ausgabeziele als Parameter. Folgende Parameter sind verfügbar

  • Ziel
    Sie können hier einen Namen angeben aber ich ziehe eine IPv4-Adresse vor, da VoIP in der Regel noch nicht mit IPv6 arbeitet und die Namensauflösung ebenfalls entfällt.
  • hoplist []
    Ein Array von IP-Adressen oder Namen der vom Administrator als interessant bestimmten Zwischenstationen, die im Fehlerfall geprobt werden.

Wenn Sie Verbindungen über das Internet prüfen, sollten Sie regelmäßig die Hopliste überprüfen. Im internen LAN dürfte das seltener erforderlich sein.

  • buffersize (default 160)
    Größe des Buffers, der übertragen wird. Ich nutze hier 160 Byte, da VoIP bei G.711 mit 20ms und Narrowband diese Paketgröße nutzt
  • timeout (Default 1000ms)
    Das Skript wartet bis zu eine Sekunden auf die Rückantwort. Das sind also 500ms in jede Richtung, die ein Paket verzögert sein muss, ehe ich von einem "Vorfall" ausgehe, welcher dann eine weitere Prüfung nach sich zieht.
  • sleeptime
    Per Default lässt das Skript immer 100ms zwischen zwei Pings vergehen. Damit werden nur 20% der bei VoIP üblichen Paketanzahl gesendet. Wer mag kann den Wert gerne auf 20ms heruntersetzen und hat dann annähernd die VoIP-Rate.
  • CSVFile
    Dateiname der Ausgabedatei.

Das Skript initialisiert das ICMP-Objekt und den Sendepuffer und versendet über eine Endlosschleife die ICMP-Pakete und sammelt die Ergebnisse ein. Sollte ein Paket Ausbleiben oder zu lange brauchen, dann werden die hinterlegten Zwischenstationen mit 5 Sekunden Timeout angesprochen und das Ergebnis in eine CSV-Datei protokolliert.

Da das Skript ICMP-Pakete immer "hintereinander" und Synchron sendet, ist die maximale Anzahl der Pakete abhängig von der Roundtripzeit. Es sind also nie mehrere ICMP-Pakete parallel "unterwegs", wie dies bei VoIP aber natürlich der Fall ist. Ich habe mir nur nicht die Mühe gemacht, die ganzen Prozesse asynchron auszulegen.

Ausgabe

Natürlich wollten wie ja noch wissen, wie die Ausgabe aussieht. In der PowerShell Box ist die Arbeit des Skripts zu sehen:

Interessanter ist natürlich, später die Ausgabe in der CSV-Datei auszuwerten.

Gut zu sehen, das in der gesamten Testzeit drei mal ein Timeout aufgetreten ist und die drei "Prüfpunkt" auf dem Weg zum Edge-Server ganz normale Laufzeiten hatten. Also muss es zwischen dem letzten Stück und dem Edge- Server ein kurzes aber seltenes Problem geben. Es kann aber auch sein, dass der "Engpass" so kurz war, dass nach dem Timeout zum Prüfsystem die nachfolgenden Tests schon wieder hinfällig waren. Die ist aktuell noch eine Einschränkung die nur lösbar wäre, indem mehrere ICMPs parallel gesendet werden.

Mittelfristig könnte das Skript natürlich gleich noch eine Alarmierungsmail, einen Eventlog-Eintrag o.ä. generieren. Das ist sicher interessant, wenn das Skript unbewacht im Hintergrund läuft.

Download

Für die Ausführung sind keinerlei privilegierte Rechte erforderlich. Das Skript kann auf jedem PC mit PowerShell 2.0 ausgeführt werden.

end2end-ping.2.0.ps1.txt
Bitte nach dem Download die Erweiterung nach ps1 umstellen.

Die vorab hinterlegten Adressen sind "www.google.de" als Ziel und zwei Hops, die für mich als T-DSL-Kunde im Bereich Bielefeld und der Telekom-Übergang zu Google interessant sind:

Wenn Sie sinnvolle Ergebnisse erhalten wollen, dann müssen Sie die Parameter anpassen !!!

Es bietet sich an, das Skript in einem leeren Verzeichnis zu starten.

Offen

Nur eine Gegenstelle "anzupingen" ist etwas trivial. Interessanter könnte es sein, wenn man parallel mehrere Systeme und auch sehr häufig anpingt. Aktuell habe ich aber noch kein Skript, welches dies macht.

Weitere Links