PRTG QoS Sensor

Mit dem PRTG QoS-Sensor können Sie sehr einfach einen VoIP Test eines LAN machen. Wer Lync in einer Umgebung aufbaue und VoIP nutzt, für den sind Begriffe wie Call Admission Control und QoS relevant. Neben den technischen Einstellungen muss so eine Funktion aber auch überprüft werden. Natürlich kann der Lync Monitoring Server die Daten von kompatiblen Clients einsammeln und berichten aber er sieht eben nur Probleme, die während eines Gesprächs auftreten aber nicht in den anderen Zeiten. Auch können Sie erst dann auf diese Werte zurückgreifen, wenn sie Lync bereits installiert und in Produktion genommen haben.

Einsatzfähigkeit

Der PRTG-Sensor für QoS erlaubt es zwischen zwei Proben einen VoIP-Call zu simulieren. PRTG bietet dazu den Sensor als "OneWay" oder Two-Way-Konfiguration an:

Als Endpunkte müssen immer zwei PRTG-Probes genutzt werden. Eine Prüfung gegen ein Gateway, anderen Mirrorserver o.ä., ist leider nicht möglich. Die Simulation ist natürlich nicht perfekt, denn genau genommen werden nur UDP/TCP-Pakete mit einer definierten Länge und einem zeitlichen Abstand versendet. Dies ist in dem Sensor auch einzustellen. Hier habe ich absichtlich falsche Werte hinterlegt, dass Sie auch die Grenzen sehen können.

Sie können also mitnichten damit 10 Calls für eine Dauer von 1h simulieren. Es fehlt der komplette SIP-Anteil und auch die übertragenen Daten enthalten natürlich keine "Töne" oder "Bilder" und sind damit nicht zwingend repräsentativ. Wer auf dem WAN also mit Kompression oder WAN-Optimiereren arbeitet oder eine "Next Generation Firewall" die Daten inspiziert, kann so zu falschen Ergebnissen kommen. Auch kann die Probe nicht selbst entsprechende DSCP/QoS-Tags auf das Paket anwenden. Das müssen Sie per Windows Gruppenrichtlinie oder auf dem Switch/Router vornehmen.

Hinweis:
Der Sensor scheint nach ablauf des "Timeout (hier 60Sek) die Messung abzubrechen. Wenn der Versand der Pakete aber länger dauert, dann zählt er nicht mehr alle Pakete mit und meldet "Packet Loss". Achten Sie darauf, dass die Anzahl der Pakete und die Zeit zwischen den Paketen nicht zu groß wird. Wenn Sie nun 1000 Pakete mit 50ms Abstand senden sollen, dann kommen leider nicht 50Sek Laufzeit heraus. Der QoS-Sensor hält sich nicht genau an die 20ms Abstand, sondern macht nach jedem Versand wohl 20ms pause, so dass die Laufzeit insgesamt länger wird. Experimentieren Sie etwas mit ihren Werten, da es wohl auch von der Computergeschwindigkeit abhängt.
Ich habe eigentlich mit 1000 Paketen a 172 Bytes und 40-45ms Abstand keine Paketloss provoziert und dennoch eine ziemlich gute Abdeckung erreicht. Sie können ja mit Wireshark nachschauen, wie lange die Pakete effektiv gesendet werden.

Ein Blick auf die Leitung

Schaut man mit Wireshark oder NetMon 3 auf dem Ethernet nach, dann sind die UDP-Pakete sehr einfach zu erkennen. Es sind nackte UDP-Pakete die von jeder Probe zur anderen Probe gesendet werden. Der Ziel-Port ist dabei jeweils der hinterlegte Port, der auf beiden Seiten frei sein muss.

Die Payload ist ein String, von dem ich annehme, dass PRTG darin die GUID der Probe oder des Sensors und vielleicht einen Zeitstempel mit sendet, so dass die empfangende Seite die Daten zuordnen kann.

Ergebnisse

Dennoch sollten Sie nun nicht vorschnell aufhören sondern sich die Ergebnisse der Probe durchaus anschauen. Trotz der Einschränkungen ist der Sensor in den meisten Umgebungen durchaus wirkungsvoll, um kritische Strecken mit ausreichender Häufigkeit zu überwachen.

Die für VoIP wichtigen Werte wie Paket-Loss, Jitter und Laufzeit (RTT) sind enthalten und helfen schon einen ersten Eindruck zur Qualität der Leitung zu erhalten. ein genauerer Blick in die Live-Daten zeigt die Ergebnisse der letzten 2 Stunden:

Interessant sind hier die hellblaue (Paket Delay Variation) und die dunkelblaue (RTT Max) Linie, die quasi aufeinander liegen und zeigen, dass es hier bei einer Messung über 1000 Pakete immer mal die Laufzeit über den sonst um 50ms schwankenden Laufzeiten abweichen. Es ist also mindestens ein Paket dabei, welches sogar fast 250ms langsamer unterwegs war. Der gefüllte gelbliche Fläche unten gibt den "Jitter Max (msec)" wieder, der in diesen zwei Stunden aber 26msec nicht überschritten hat.

Per Default sendet PRTG 1000 Pakete mit 20ms Abstand und 172 Bytes, was damit einem einzelnen VoIP-RTP-Datenstrom über eine Dauer von 20 Sekunden. Bei dem Standard-Wiederholungsintervall von 60 Sek müssen Sie als 1/3 der Zeit die Netzwerkqualität. Sie haben damit zwar keine lückenlose Überwachung aber immer noch mehr als andere Tools mit Stichproben alle 5 Minuten erreichen.

Gegenstelle ohne PRTG Probe, Python und Powershell

Sie können den QoS Roundtrip-Sensor auch mit anderen Gegenstellen nutzen, wenn diese aber auf die Besonderheiten von PRTG Rücksicht nehmen. Siehe dazu

Last-Test mit etwas Hilfe

Sie haben bei den Einschränkungen aber schon gesehen, dass mit dem Sensor nur bedingt auch eine Last simuliert werden kann. Sicher können Sie Paketgröße von 172 Byte auf bis zu 4500 Byte anheben aber das ist kein Ersatz für die 26-fache Anzahl an kleinen Paketen. Auch die Wartezeit zwischen zwei Paketen (Default 20ms) können sie nur auf 10ms drücken. Um also echt eine Last auf einer Leitung zu untersuchen, muss man andere Hilfsmitteln nutzen. Damit meine ich nicht zwingend ein anderes Programm.

Stellen Sie sich vor, sie überwachen mit PRTG so eine Leitung und sie wollen sehen, wie diese Leitung sich unter höherer VoIP-Last verhält. Es hindert sich ja niemand daran, mit einem anderen Programm eine gewisse "Last" auf das Netzwerk zu legen. Solche Lastgeneratoren sind schnell erstellt und selbst wenn diese nicht selbst "messen", so kann der PRTG-Sensor im Pulk der andere Pakete mitschwimmen und seine eigene Messung machen. Wenn alle Pakete der gleichen Klasse auch gleich befördert werden, dann werden die Pakete auch vergleichbar gedroppt, verzögert o.ä. Und sind damit durchaus messbar.

Ich hoffe bald ein kleines Framework zum Generieren einer solchen Grundlast bereit stellen zu können. Bis dahin können sie aber z.B. mit IPerf3 solche Lasten erzeugen

NetFlow/cFlow/IP SLA

PRTG kann in der lizenzierten Version auch NetFlow-Pakete von kompatiblen Routern einsammeln und damit die Funktion, die über die Funktion "Paket Sniffing" eigentlich nur "lokal" für einen PC/Server verfügbar ist, auf alle Systeme im LAN ausdehnen. Es gibt sogar entsprechende Module, damit ein Windows Server solche Verkehrsdaten per NETFLOW versenden kann:

Diese Daten "sollte" dann auch PRTG einsammeln und verstehen können. Gerade wenn ein Windows Server als "Router" agiert (z.B. ISA/TMG oder VPN-Knoten), ist die eine nette Funktion.

Ähnliche Sensoren

PRTG enthält noch zwei weitere Sensoren, die in die ähnliche Richtung gehen:

  • IP-SLA
    Hierbei wird die IP SLA-Funktion in Cisco-Routern genutzt, die zwischen Cisco-Routern solche VoIP-Tests fahren und von PRTG nur noch abgelesen werden. Siehe auch http://www.de.paessler.com/ip_sla_monitoring
  • PING Jitter
    Ein schwächerer aber im Notfall nutzbarer Sensor sendet einfache PINGs und ermittelt dabei die Laufzeit und die Variant. Das sind dann natürlich keine 50 ICMP-Pakete pro Sekunde mit 172 Bytes aber wenn ihre Firewall noch kein UDP passieren lässt oder sie keine Gegenstelle haben, kann die Laufzeit und dren Varianz eines einfachen ICMP manchmal auch schon interessant sein.

Wunschliste

Es wäre zwar schön., wenn es zusätzlich zum einfachen QoS-Sensor noch einen echten VoIP-Sensors gäbe, der nicht nur einfache UDP/TCP-Pakete sendet, sondern auch ein bisschen SIP zur Steuerung nutze und einen echten RTP-Datenstrom simuliert. Aber wie schon weiter oben beschrieben muss das gar nicht der Fall sein.

Interessant wäre aber, wenn der QoS-Sensor nicht nur gegen andere PRTG-Proben sondern gegen fremde Systeme arbeiten könnte. Natürlich kann dies dann nur funktionieren, wenn die andere andere Seite z.B. als UDP-Mirror mithilft und die empfangenen Pakete umgehend wieder an den Absender zurück sendet. Solche ECHO"-Server sind aber in vielen Routern schon enthalten und wären z.B. auch mit einem RaspberryPI einfach bereit zu stellen. So könnte man ein ganzen VoIP-Testnetz aufbauen. Es gibt sogar einige Beispiele dafür und viele Lync Gateways, SBCs etc. basieren auf Unix oder Windows.

Allerdings sollten die Proben natürlich nicht von jedem UDP-Pakete annehmen und vielleicht nicht auf dem Standard Echoe Port 7/UDP lauschen, damit DoS-Angriffe nicht so einfach möglich sind. Auf der anderen Seite werden PCs natürlich auch immer billiger und kleine Boxen mit Windows 8.1 und einer PRTG-Probe drauf sind auch nicht wirklich mehr ein Kostenfaktor, wenn man eine größere VoIP-Umgebung im Rahmen eines "Readyness-Tests" für wenige Tage ausmessen möchte.

Weitere Links