End2End-PathPing

Dieses Skript erwartet eine Liste von Stationen, die zwischen ihrem Sender und der Gegenstelle liegen. Es sendet dann PINGs an die Gegenstelle und sobald die Antwort ausbleibt, sendet es ganz schnell PING an die vorab festgelegten Zwischenstationen, damit so die Stelle erkannt wird, an der die Verbindung nicht mehr beantwortet ist.

Pingplotter und Traceroute

Sie kennen sicher das Programm Traceroute, mit dem Sie den Weg zwischen zwei Stationen ermitteln können. Das Windows TraceRoute sendet dazu jeweils drei ICMP-Pakete mit aufsteigendem TTL zum Ziel und sammelt die Rückmeldungen (TTL Exceeded) ein. Das macht es aber einmal und hintereinander. Wer eine GUI-Version sucht, kann mit PingPlotter hier sehr viel freundlicher Bilder einsammeln.

Sie sehen hier die verschiedenen Stationen aber rechts auch die Antwortzeit und die Varianz. PingPlotter sendet also sehr viele ICMP-Pakete weg. Bei 15 Stationen also 15 pro Sekunde mit unterschiedlichem TTL, sammelt die Ergebnisse ein und stellt sie rechts als Balkendiagramm an. Hier ist gut zu sehen, dass mein Ping zur Fritz!Box noch OK war aber schon die nächste Strecke über DSL teilweise 100ms gebraucht hat. der übernächste Hop von meinem DSLAM zum nächsten Router sogar noch mehr. Da dürfte wohl der Uplink temporär überlastet gewesen sein. Erst danach wird es dann entspannt.

Sie sehen aber schon, dass eine Dauerüberwachung durchaus interessante Daten liefern kann. In der unteren Grafik sehen Sie die Treppe, als ich eine Teams Konferenz gestartet und daher etwas Bandbreite belegt habe. Auch die ICMP-Pakete wurden entsprechend langsamer. Ich möchte natürlich nicht auf PCs so eine Software laufen lassen, deren Ergebnisse nach dem Schließen auch wieder weg sind. Mein Wunsch war es eine Dauerüberwachung zu bauen, die kontinuierlich die Qualität prüft und kritische Moment eindeutig kennzeichnet.

Umsetzung

Das Script testet erst mal genau ein Ziel und erwartet die Zwischenstationen im Fehlerfall 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.

Hier ist gut zu sehen, dass in der gesamten Test-Zeit 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-pathping.2.2.ps1
Bitte nach dem Download die Erweiterung nach ps1 umstellen.

Die vorab hinterlegten Adressen sind "internetbeacon.msedge.net"" als Ziel und die Hops, die für mich als T-DSL-Kunde im Bereich Bielefeld und der Telekom-Übergang interessant sind:

Achtung
Wenn Sie sinnvolle Ergebnisse erhalten wollen, dann müssen Sie die Parameter an ihre Umgebung anpassen! Suchen Sie sich das interessante Ziel und starten Sie einen TraceRoute um die Zwischenstationen zu ermitteln

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

Rimscout

Wenn Sie nicht auf dem Client ein PowerShell-Skript laufen lassen wollen, dann könnte Rimscout (https://www.rimscout.com) eine interessante Alternative sein. Ein Programm auf jedem Client führt zentral gesteuert diverse Prüfungen aus und meldet diese an ein Backend zur Auswertung in einem Portal. Eine Funktion ermittelt die wichtigsten Stationen auf dem Weg in die Cloud und misst z.B. die Latenzzeit des Clients zum Default Gateway, zum Internet Breakout über die erste öffentliche IP-Adresse und z.B. Microsoft. Anhand der Linien sehen Sie über die Zeit genau wie weit die Stationen in Millisekunden entfernt sind:

Hier sehen Sie aber auch, das schon der erste Hop zum Default Gateway von ca. 7:50 bis 09:40 mit 25-75ms schon deutlich zu langsam ist. Wir haben hier dem Kunden geraten seinen DSL-Router neu zu starten und das sehen Sie an der Unterbrechung gegen 09:10 Uhr. Nach dem Neustart hat es noch einige Minuten gedauert aber dann sind die Werte in einen regulären Bereich gesunken.

Bei diesem Bild sehen Sie die Auswirkungen eines VPNs. Rimscout ermittelt trotz VPN immer den echten "ersten Router" und die dunkelblaue Linie ist etwa im Bereich von 2-10ms.

Aber gegen 08:30 werden sowohl die Laufzeit zur ersten öffentlichen IP als auch zu Microsoft deutlich langsamer. Ursache ist hier ein VPN, welches entgegen der Vorgaben auch den Traffic zur Microsoft Cloud durch den Tunnel gesendet hat. Dies sind nur zwei Beispiele, wie solche Daten bei der Fehlersuche helfen und speziell der Vergleich zwischen Clients, Standorten, Providern etc. dabei hilft, Probleme zu erkennen.

Wenn Sie mehr über Rimscout und den Einsatz in ihrem Unternehmen wissen wollen, dann besuchen Sie einfach https://www.rimscout.com

Offen

Nur eine Gegenstelle "anzupingen" ist etwas trivial. Interessanter könnte es sein, wenn man parallel mehrere Systeme und auch sehr häufig anpingt. Auch den Weg zum Ziel könnte man am Anfang oder auch immer mal dazwischen eigenständig ermitteln.

Es bleibt als noch etwas zu tun.

Weitere Links