PRTG Ping-Sensor und VoIP

Mit dem PING-Sensor kann man ansatzweise auch die Laufzeit und Erreichbarkeit von Gegenstellen testen. Das ist zwar kein richtiger Check aber bessre als gar nichts. Der PRTG-Sensor kann sogar sehr gut und schnell ICMP-Nachrichten senden.

Einschränkungen

Ehe sie nun flohlockend PRTG einrichten, möchte ich die Grenzen von ICMP als Check aufzählen. Der einzige Vorteil ist eigentlich nur, dass quasi jede Gegenstelle, die auf einem PING antwortet, als Probe-Gegenstelle genutzt werden kann

  • Kein QoS-Markierung
    Grupenrichtlinien zu QoS Kennzeichnung oder Regeln auf Routern nutzen meist Ports als Kriterium. ICMP hat keine Ports und wird daher nicht wie ein VoIP-Paket gekennzeichnet und entsprechend nicht bevorzugt behandelt. Die Daten sind also meist schlechter aber können auch "besser" sein, wenn der VoIP-Kanal schon durch QoS begrenzt wird
  • ICMP ist kein UDP
    Nicht alle Router und Systeme behandeln ICMP wie UDP. Auch hier kann eine "Umsortierung" erfolgen
  • DDoS-Schutz
    Da jeder "Pingen" kann und auch die Absenderadresse eines ein PING gefälscht ist, gibt es Firewalls und IDS-Systeme, die sehr viele Pings von einer Quelle als Angriff sehen und nicht mehr darauf antworten. Es ist sehr wohl ein Unterschied, ob sie ab und an einen PING als Check senden oder sie per ICMP eine !VoIP-Verbindung mit 50 Paketen/Sek simulieren.
  • WAN-Optimierer
    Bandbreite ist ein kostbares Gut. Speziell im internen Netzwerk gibt es gerne Systeme, die Protokolle optimieren. ICMP gehört dazu, insbesondere, wenn es viele Pakete in kurzer Zeit mit gleichem Inhalt sind.
  • Variable Paketlänge nicht immer gewährleistet
    Das klassische PING-Paket ist 64byte. Klar kann ich auch 160bytes oder noch viel mehr senden aber nicht jede Gegenstelle antwortet mir darauf.

Stellen Sie daher nicht zu hohe Erwartungen an die Ergebnisse und deren Aussagekraft. Sie sind in einem internen LAN/WAN mit bekannten Wegen und einem entsprechenden Vertrauensvorschuss der Gegenstelle eine erste Abschätzung aber ein Missbrauch der PING-Funktion als Bandbreiten-Test mittels fremder Systeme würde ich mir verkneifen.

PRTG-Ping Basis

Der PING-Sensor bei PRTG wird in der Regel unter einem Device eingerichtet, welches seinerseits direkt oder einer Gruppe unter einer Probe angelegt wurde. Beim Device ist die IP-Adresse oder der Name des Zielsystems definiert. Der PING-Sensor wird also auf der Probe ausgeführt und nutzt das Device als Ziel. Beim PING-Sensor können aber dennoch einige Werte eingestellt werden, die für das Verhalten wichtig sind. Hier die Default-Werte:

Mein Sensor sendet also alle 60 Sekunden eine Gruppe von 5 ICMP-Requests mit 5ms Abstand an die Gegenseite, die alle 32 Byte groß sind. Das lässt sich mit NETMON auch kontrollieren:

In dem Beispiel werden auch 5 Pakete mit der angegeben Größe gesendet und der Inhalt verrät sogar die Quelle. Das angegebe Pauseintervall beim Versand zwischen Paketen (5ms) kann ich so aber nicht bestätigen. Ich lese hier eher 113ms, 78ms, 89ms und 56ms beim Versand und selbst wenn man die Zeit auf den Empfang des vorherigen Pakets bezieht, kommen 40ms, 38ms, 69ms und 44ms heraus. Wie PRTG da auf 5ms kommt erschließt sich mir erst einmal nicht.

PING zu www.msxfaq.de mit VoIP Charakterisik

Ich habe dann die Werte mal auf ein "VoIP-Maß" gebracht und 1000 Pakete a 160bytes mit 20ms Abstand konfiguriert. Das sollte also einen 20Sek Sturm geben. Über das Wiederholintervall könnte ich den Sensor dann alle 30Sek laufen lassen und damit fast eine "Vollabdeckung" erreichen. Die Pakete in Netmon sagen aber was anderes:

Das Paket ist mit 188 Bytes natürlich größer aber man sieht sehr wohl, dass hier schon erste "ICMP not reachable" Meldungen kommen und auch die 20ms Verzögerung passen nicht. Zwischen dem Request Paket 2755 und 2757 liegen 84ms. Selbst wenn der Abstand vom letzten Empfang gerechnet wäre, sind 50ms immer noch zu lange. Zudem ist es kein kontinuierlicher Versand. Anscheinend wartet PRTG erst auf die Antwort auf ein Paket, ehe es weiter sendet.

In der Auswertung der Daten sind aber zumindest passende Zahl für Min/Mac und Paket Loss zu sehen. Das kann dann schon mal eine Einschätzung hinsichtlich "Veränderungen" liefern.

Auch in der Liste ist nach der Änderung zu sehen, dass viele etwas größere Pings mit mehr Abstand viel schlechter sind.

Ich kann mir das nur so erklären, dass über das Internet ein ICMP-Paket früh verworfen wird, wenn es nicht zeitnah weiter geleitet werden kann. 30% Paketloss bei ICMP ist aber keine qualifizierte Aussage, dass die auch für UDP/TCP-Pakete gilt. Insofern ist solcher ICMP-Test gegen Office 365 oder andere Server nicht sinnvoll zu nutzen.

PING im LAN

Anders sieht es wie zu erwarte im lokalen LAN aus. Ich habe per PING einen erreichbaren Server mit der gleichen Last (160bytes, 20ms, 1000 Pakete) belastet. Hier ist Paketloss durchgehen auf 0% und auch die Laufzeit ist schnell genug. Aber in der Grafik zeigt sich, dass laut PRTG die Messwerte nicht lückenlos sind. 1000 Pakete mit 20ms Abstand sollten nach 20 Sek erledigt sein und wenn der Sensor alle 30 Sekunden gestartet wird, dürfte es keine Lücken geben. Dass es aber Lücken gibt liegt meiner Einschätzung nach daran, dass der Sensor immer 1000 Pakete sendet auch wenn es länger dauert.

Insofern kommt hier sicher nicht die gewünschte 100KBit/Sek Netzwerklast zusammen und es fehlt auch eine Warnung, dass der Sensor auf diesem System nicht schnell genug ist. Ein Check mit einem UDP-Send per Powershell konnte 1000 Pakete in 68ms senden.

$udpClient = new-Object system.Net.Sockets.Udpclient($sourceport) 
$byteBuffer  = [System.Text.Encoding]::ASCII.GetBytes("SendUDP Message by msxfaq")
(1..1000) | %{
	$sendbytes = $udpClient.Send($byteBuffer, $byteBuffer.length, "192.168.178.1", 50000)
}

Das Skript hat natürlich auch keine Antworten verarbeitet. Die Fritz!Box hat aber auch nur 6 "ICMP NotReachable" zurück gesendet.

Einschätzung

Egal wie wir es drehen. Der PING-Sensor ist eine sehr einfache Möglichkeit die Erreichbarkeit eines entfernten Systems zu prüfen und groß geschätzt auch Veränderungen der Antwortzeit zu erfassen aber die Daten sind qualitativ nicht gut genug, um damit eine VoIP-Messung durchzuführen. Dafür gibt es dann doch wieder andere Sensoren wie z.B. den PRTG QoS Sensor oder PRTG QoS mit UDP-Mirror. Allerdings brauchen beide entsprechende Mithilfe auf dem entfernten System in Form einer Remote Probe oder eines passenden UDP-Mirror.

Weitere Links