PRTG QoS mit UDP-Mirror

PRTG ist eine überschaubare aber leistungsfähige Software zur Überwachung von Diensten und Netzwerken und kann weit mehr als nur die Auslastung von ein paar Switchports zu loggen, wie diverse Beispielskripte von mir für Exchange und Lync sicher zeigen. PRTG basiert auf einem zentralen Server zur Datensammlung und Visualisierung und mindestens einer oder mehrerer Probes, die letztlich Aktionen ausführen. Die leistungsfähigen Probes sind nur auf Windows einsetzbar und überwachen das lokale System. Es ist aber auch möglich entfernte Systeme remote im Rahmen der Möglichkeiten zu überwachen. Das nutze ich gerne um die Anzahl der Probe-Installationen gering zu halten. für einige Sensoren, z.B. PRTG:QoS Sensor sind aber zwei Probes erforderlich. Das Senden und Zurücksenden von UDP-Paketen für QoS erforderte eine PRTG-Probe auf der Gegenseite.

Warum UDP, Reicht nicht auch ein ICMP (PING)
Nur Messung von Latenzzeiten etc. kann auch ein ICMP-PING reichen. Aber ICMP ist kein UDP und insbesondere mit QoS auf WAN-Leitungen macht es Sinn mit UDP-Paketen auch genau die Ports zu nutzen, die per QoS priorisiert werden.

Mini-Probe mit UDP

Ich habe im November 2012 (http://kb.paessler.com/en/topic/43963) schon den Vorschlag gemacht, dass die Gegenstelle auch einfach ein UDP-Echo-Device sein könnte. Damals wurde das als Feature-Request aufgenommen. Seit der PRGT-Version 14.x.10 scheint hier Bewegung rein zu kommen. Zuerst in Form einer "MiniProbe" auf Basis von Android. Damit kann man nun erstmals z.B. alte Smartphones als "Remote Probe" in der Fläche verteilen um z.B. die Erreichbarkeit per WiFi zu "messen". Viel interessanter fand ich aber, als ich wieder mal beim Einrichten es QoS-Sensor eine neue Auswahlbox gesehen habe:

Neben der "empfohlenen" PRTG Probe" kann man nun ein "Custom Target" angeben und in der Hilfe ist der Link zu GitHub schon enthalten, mit dem ein kleines Python-Skript als Spiegel dient.

https://GitHub.com/PaesslerAG/QoSReflect

UDP-Senderate

In der Konfiguration kann ich die Zeit zwischen den Paketen einstellen. Da habe ich dann mit Netmon mal genauer hingeschaut. Hier ein erfolgreicher UDP-Check

Auf das erste Paket kommt nach 14ms die Antwort an und 18ms danach sendet PRTG das nächste. Die 20ms beziehen sich also wohl nicht auf die Sendepakete, sondern die Verzögerung nach dem Empfang der Antwort. Auch auf das dritte Paket kommt die Antwort nach ca. 13ms an und 20ms später sendet PRTG das nächte Paket. Die "Zeit zwischen den Paketen" ist also nicht die Zeit zwischen dem Versand von Paketen sondern die Verzögerung nach einem Roundtrip. Das bedeutet aber auch, dass 1000 Pakete a 20ms eben nicht 20Sekunden dauern, sondern 20Sek + 1000mal die Roundtripzeit. Die ist hier mit 13-15ms durchaus relevant. Der Sensor läuft also 40-50Sekunden. Wenn die Probe nun aber alle 30 Sekunden gestartet wird, dann fehlen aus Sicht des PRTG Core Servers Messungen und in dem Diagramm tun sich Lücken auf.

Natürlich habe ich dann auch einen Probe zu einer Gegenstelle eingestellt, die nicht da ist um die Verzögerung hier auszuwerten. Sie sehen an dem Beispiel schön, dass die Abständ mit 31ms, 31ms, 32ms, 31ms schön gleichmäßig aber auch größer der eingestellten 20ms sind.

Insofern müssen Sie wissen, dass die QoS-Probe nicht 100% akkurat sich an die Einstellungen hält und eher mehr Pausen mache und die simulierte Bandbreite zu niedrig ausfällt. Das sehe ich aber nicht so kritisch. Kniffliger sind aus meiner Sicht die unschönen Lücken in der Grafik, wenn der Sensor länger läuft als das Scanintervall der Probe. Hier sollten Sie die Parameter entsprechend anpassen, damit besonders mit "langen Leitungen" der Sensor rechtzeitig fertig wird.

Tipp: Niemand hindert Sie daran ihren eigenen UDP-Sender zu bauen und die Daten z.B.: per PRTG - HTTP Push-Sensoren an PRTG zur Auswertung zu senden. Ich habe schon einige passende Skripte wie z.B. echo-udp.1.0.ps1 und auf der Seite PowerShell und UDP.

Port-Besonderheiten mit PRTG und UDP-Echo

Nicht immer gibt es einen Windows PC auf der anderen Seite, der die UDP-Pakete zurück sendet. Aber es tut auch ein beliebiger UDP-Mirror oder ECHO-Server, sofern er sich mit PRTG verträgt. In der Konfiguration von PRTG wird ein Port angegeben. Hier im Beispiel der Port 50.000.

Dieser Port ist zum einen der Ziel-Port, an den der Initiator die Pakete versendet aber es ist zugleich der Ziel-Port, auf dem der PRTG Initiator auch die Rückpakete erwartet! Leider geht PRTG selbst mit einem dynamischen High-Port als Quelle zum Ziel. In Wireshark ist das gut zu sehen, dass die Hinrichtung immer gleich ist aber die Rückrichtung hier aufsteigende Highports nutzt.

Nebenbei sieht man dabei, dass auch die Abstände zwischen den Paketen nicht genau die 20ms sind. Aus meiner Sicht ist das ein Bug und auch an Paessler gemeldet. Denn ein normaler UDP-Echo-Server sendet die Pakete normal wieder an den QuellPort der Anfrage zurück: Es gibt Firewalls, die einen solchen UDP-Sturm auf ein Ziel von immer anderen Quell-Ports als Angriff werden und die Verbindung blockieren.

Daher können Sie keinen beliebigen UDP Echo-Service nutzen, wie er in einigen Routern sogar vorhanden ist.

Es gibt aber von Paessler selbst ein Python-Script, welches schon etwas besser funktioniert. Es nutzt zumindest immer den gleichen Quell-Port aber noch immer überkreuzen sich die Ports.

Bei einem klassischen VoIP-Handshake per ICE teilt der Client dem Gegenüber seine "Kandidaten" mit, auf denn er Pakete annimmt. Aber zumindest bei Skype for Business sind diese Ports auch genau due Ports, mit denen der Client auch sendet.

Das hat den Vorteil, dass die UDP-Portrange immer gleich bleibt und QoS-Markierungen einfach anhand des lokalen Quellports gesetzt werden können und unabhängig von den Kandidaten der Gegenseite sind.

Ich würde mir wirklich wünschen, wenn der Port, den eine Probe eh zum Empfang der Pakete nutzt, auch gleichzeitig der Sendeport wäre und durch eine Vorgabe auch für QoS-Tagging seitens des Betriebssystems zur Verfügung stehen würde. Skype for Business kann es und selbst ich mit meinem Powershell weiter unten kann es.

PRTG Python Echo

Wenn man sich den Source Code anschaut und man vereinfacht die Filterungen und Parameter mit NAT etc. weg lässt, dann besteht der Kern aus folgenden Funktionen (Hinweis: Bei Python gibt es keine Blockklammern o.ä.. Die Einrückung bestimmt den Block)

while 1:
    d = s.recvfrom(4096)
    if d and not restrict_answer:
        data = d[0]
        reply = data
        s.sendto(reply, addr)

Das Skript reserviert einen 4096 Byte Puffer und wartet einfach auf Daten, um den Inhalt dann 1:1 wieder zum Absender zurück zu senden. Eigentlich kein Hexenwerk aber doch effektiv. Das ist sicher einfach für Unix-Administratoren, das Skript auf einem Unix-System einfach mitlaufen zu lassen. Das kann ja auch ein RaspberryPI oder anderer Minicomputer sein. Ein UDP-Mirror ist sehr einfach umgesetzt.

Echo mit PowerShell?

Es ist nicht wirklich schwer einen Python-Interpreter auf Unix oder Windows zu installieren, um das Skript von Paessler zu starten. Aber auf meinen Windows-Systemen habe ich doch die PowerShell und das .NET-Framework. Der Aufwand so einen UDP-Echo mit PowerShell zu schreiben ist auch nicht größer. Auf der Seite PS UDP beschreibe ich generell, wie ich per .NET und Powershell mit UDP-Paketen handhabe und am Ende habe ich auch ein PowerShell-Script, was genau das macht. Sie können ebenfalls die Source-IP einschränken und PRTG-typisch einen abweichenden Port für das Rückpaket angeben.

echo-udp.1.0.ps1

  • PS UDP
    Hier meine PowerShell Version eines UDP-Echo nach PRTG-Funktion

Achtung: Dieser Samplecode hat keine IP-Filterung. Das könnten sie aber sicher schnell addieren.

Windows "Simple TCP Dienste" als Echo ?

Bei meinen Kunden sind aber "Windows Systeme" und hier die Desktops etc. Natürlich omnipräsent. In kleinen Niederlassungen gibt es nicht immer einen Unix-Server oder Platz für einen kleinen Computer. Während der Arbeitszeit könnte ja ein Windows Client diese Funktion übernehmen. Schon viele Jahre gibt es von Microsoft ebenfalls die "Einfachen TCP/IP-Dienste, die Echo, CharGen, Daytime etc. vereinen und auch bei Windows 2012 immer noch über die Features installiert werden können:

Installiert wird dabei genau ein Dienst, der später auch automatisch gestartet wird.:

Wenn man aber genauer im Ressource Manager nachschaut, dann lauscht dieser Dienst auch auf den UDP-Ports. Interessant ist hier der Port 7 ECHO, der ziemlich genau unter Windows das tut, was die Probe brauchen könne.

Leider kann man dennoch nicht diesen Dienst auf einem Windows PC nutzen, da PRTG nur Port >1024 zulässt. Sollte PRTG auch einmal "UDP=7" zulassen, dann müssten Sie nur noch die Windows Firewall ggfls. öffnen um so viel mehr QoS-Sensoren in der Welt zu verteilen.

QoS UDP-Mirror mit anderen Devices

Es ist ja nun nicht so, dass man eine UDP-Echo Probe erst aufsetzen muss. Mit etwas Glück unterstützen ihre Router sogar diese Funktion.  Ich denke es gibt durchaus viel mehr Systeme, die einen UDP-Mirror für PRTG bereitstellen können, so dass Sie keinen Windows Server oder Service benötigen. Leider ist der Lync Client selbst kein UDP-Mirror und kann auch nicht dazu missbraucht werden. Ich versuche dennoch hier mal eine Liste der Geräte zu pflegen, die für PRTG als UDP-Mirror genutzt werden können:

Lesen Sie dazu auch die Seite Netzwerk SLA. Viele Netzwerkgeräte können sogar mehr als nur UDP-Mirror sein, sondern selbst aktive Tests durchführen

Es gibt sogar ein RFCs für solche Tests:

Als Lync und VoIP-Admin warte ich eigentlich nur noch darauf, dass auch VoIP-Gateways diese Funktion integriert haben, damit UDP-Tests als Dauertest genutzt werden können.

Schade aktuell, dass PRTG nur UDP-Ports >1024 unterstützt, denn damit entfällt die Nutzung des Standard UDP ECHO Dienstes (7/UDP). Aus Sicherheitsaspekten ist es natürlich besser diesen Port zu meiden und beim Echo-System auch eine Allowlist der Absender zu addieren.

Weitere Links