End2End-HWProbe

Diese Beschreibung gibt meine aktuellen Überlegungen und Planungen wieder. Die Lösung gibt es aber noch nicht.

Wenn die Gegenstelle aber ein TURN-Server ist, was z.B.: bei vielen VoIP-Gateway möglich ist, dann kann ich dir schon heute mit End2End-UDP3478 ansprechen. Auch Router und Switches habt oft entsprechende Dienste wie z.B. Cisco IPSLA (Siehe auch PRTG QoS mit UDP-Mirror)

 

Auf der Seite Ende zu Ende Monitoring habe ich beschrieben, dass auch eine Überwachung mit Performance Counter, Eventlog und SNMP nicht immer jede Performanceschwäche finden kann. Denn die meisten Überwachungen betrachten nur als Stichprobe (z.B. alle 5 Minuten) einen bestimmten Counter, was kürzere Spitzen einfach nicht erwischen kann. Auch ein Counter kann nur dann "hoch" sein, wenn viel Last anliegt und zugleich der Performanceengpass anliegt. Viele Administratoren wissen aber gar nicht, welche "Grundlast" ein System im Tagesbetrieb hat.

Der Trick besteht auch darin, die Funktionen mit einer kleinen aber permanenten Grundlast zu beaufschlagen und die Performance, bzw. Antwortzeit zu überwachen. Natürlich eignet sich das nicht so gut für OWA, POP3, IMAP4 oder SMTP, da hier ein Test ja nicht permanent mit eine kontinuierlichen Rate Mails senden und empfangen kann, bzw. könnte schon aber zum Preis vieler Transaktionsprotokolle, Messagetracking etc.

Aber die Basisdienste eines Servers sind immer noch Disk-IO und Netzwerk-IO und genau diese beiden Funktionen habe ich nun als Windows Dienst umgesetzt. Die Dateiüberwachung hat mit schon oft geholfen (Siehe End2End-File) und die Netzwerküberwachung brauche ich, um etwas bessere Aussagen zur Qualität von Netzwerken und deren Komponenten zu machen. Das ist hinsichtlich Lync besonders interessant.

Diese Probe ist kein ideales Mittel zur Qualifizierung von Netzwerken bezüglich der VoIP Tauglichkeit. Aber sie ist hilfreich, wenn es darum geht, eine bekannte Strecke mit etwas kontinuierlicher Last zu beaufschlagen.

Funktionsweise

Die namhaften Hersteller und Dienstleister im Bereich VoIP-Überprüfungen setzen natürlich sehr leistungsfähige Proben ein, die vergleichbar zu einem Netzwerkschnüffler (NETMON, WireShark) die Pakete mitschneiden, analysieren, Fehlersituationen speichern und später auswerten lassen.

So eine Funktion kann meine "kleine Probe" nicht leisten. Aber VoIP betrifft nicht nur die XXL-Firmen, sondern wird vermutlich bald bei allen Firmen Einzug halten, Egal ob nun Lync oder andere Produkte zum Einsatz kommen. Eine Überwachung ist da also schon "ratsam".

Version 1

Die einfachste Version der Probe ist einfach ein UDP-Mirror, der jedes Paket, was an ihn gesendet wird an die angeblich Absenderadresse zurück sendet. Das ist trivial und ressourcenschonend und ich hoffe, dass so ein Mirror nicht nur auf Windows laufen kann, sondern auch auf kleinen Probe-Devices, wie weiter unten aufgeführt.

Diese trivial-Lösung ist natürlich weder sicher noch einfach konfigurierbar noch werter die die empfangenen Daten aus. Die Auswertung der Roundtrip-Pakete bleibt bei dem Initialtor der Verbindung, der zugleich auch wieder Empfänger ist.

Aber es ist besser als nichts und eine Lastsimulation ist damit auch schon einfach möglich.

Version 2

Mit ein wenig Aufwand kann man so eine Probe aber etwas schlauer machen.

  • Es gibt genau einen Controller der auch per DNS "veröffentlicht wird"
  • Die "verteilten" Probe-Geräte nutzen DNS um dem Controller ein Paket mit einer Zufallszahl zu senden
  • Der Controller kann die Proben per "Befehl" steuern
  • Die Proben senden und Empfangen Pakete, die einem VoIP RTP-Strom ähnlich sind.
  • Die Proben senden ihre "Ergebnisse" an den Controller.

Technisch funktioniert eine Probe wie folgt:

  • Einschalten
  • Hole eine IP-Adresse per DHCP
  • Hole die Liste der Master per DNS (A-Records im DNS)
  • Sende sekündlich einen "Status" an den Master mit folgenden Zweck
    • "Kennwort"
    • Information über das Gerät selbst (MAC, Gateway, Starttime)
      So können die "Controller" erkennen, welche Probes im Feld bereit sind
    • Information über die zuletzt empfangenen Pakete.
  • Empfange Pakete per UDP auf einem vordefinierten Port (z.B.: 50.000)
    Werte die Ergebnisse aus und sendet Sie mit dem Statuspaket an den Master
  • Empfange "Steuerbefehle" von dem Master um z.B. selbst Pakete an andere Proben zu senden
  • Sende UDP-Datenströme gemäß den Befehlen.
    Bleiben "update Befehle" des Master aus, dann stelle den Versand nach 10 Sek wieder ein.

Die Konfiguration der "Steuerungsmaster" per DNS ermöglicht quasi einen konfigurationsfreien Betrieb der Proben. Die von den Proben an den Master gesendeten Statuspakete enthalten einem zufälligen "Schlüssel". Der Master muss seine "Befehle" mit diesem Schlüssel versehen. Da alle Kommunikation per UDP erfolgt, stellt dies einen einfachen aber meist ausreichenden Schutz gegen "Fremdbestimmung" dar.

Die Aufgabe des Masters ist es demnach, die aktiven Probes "einzusammeln", ihnen Steuerbefehle zu senden und die Ergebnisse wieder einzusammeln.

Hardware

Aktuell entwickle ich die Probe basieren auf Windows und PowerShell. Wenn man auf umfangreiche Bildschirmausgaben verzichtet, dann ist dies auch sehr schnell. Mittelfristig wäre natürlich eine kleine Hardware als Probe interessant, die man einfach irgendwo ins LAN anstecken kann. Es gibt sogar einige sehr interessante Geräte:

Hinweis: Viele Router und Firewalls haben ähnliche Funktionen eingebaut. Siehe auch Netzwerk SLA und PRTG QoS mit UDP-Mirror

Gerätetyp Preisklasse Beschreibung

OpenWRT-Systeme

ab 20€

Es gibt einige sehr günstige und kleine WIFI-Router, die mit eine quelloffenen OpenWRT-Firmware arbeiten. Hier könnte es einfach möglich sein die Logik zu addieren.

Es gibt sehr viele interessante und günstige fertige Geräte, die als Probe nutzbar sein könnten.

RaspberryPI

ab 35€

Im Jahr 2012 kam der Raspberry PI auf den Markt, welcher mit Linux(ARM) betrieben wird. Er braucht sehr wenig Strom und unterstützt ebenfalls Ethernet. Es sollte also einfach sein, hier eine UDP-Probe zu realisieren.

Seit dem die PowerShell Core auch auf RasPi 2/3/4 läuft, ist diese Plattform durchaus für Probes interessant, da auch Windows Admins ihre Skripte nun darauf laufen lassen können.

Netduino

50€ ohne Gehäuse

Die Netduino-Plattform ist ein Entwicklungsboard und Gehäuse und Strom muss noch dazu gerechnet werden. Dafür kann man mit C# und dem .NET Microframework elegant entwicklen.

Ardunio

50€ ohne Gehäuse

Nicht viel günstiger ist das vergleichbare Arduino. Dies gibt es für 50€ aber auch schon mit PoE Modul

Microsoft .NET Gadgeteer

 

Das Gadgeteer ist sicher eher die Luxusversion (und teuerer). Neben dem Mainboard muss man aber noch das Ethernet-Modul addiert werden

Ferrari Gateway

Es könnte sein, dass Ferrari Electronic einen solchen Agenten in ihre Gateway implementiert um so ein Gateway für ein Monitoring nutzen zu können. Das ist sicher weniger interessant als Vorabprüfung aber sicher gut für eine ÜberwachungsMöglichkeit im Regelbetrieb.

PRTG

 

Das Monitoringtool PRTG enthält QoS Prüfprogramme, die z.B. 1000 Pakete mit 172 Byte und 20ms Abstand an eine "Remote Probe" senden und auswerten.

Ich weiß noch nicht genau, wie diese Probe funktioniert. Aber es wäre auch denkbar diese PC-Lösung für eigene Dauertests zu verwenden.

Diese Sensoren werden aber immer nur zyklisch aufgerufen und sind keine "Dauerüberwachung" oder Lastsimulation.

RIPE Atlas

(free)

Das RIPE betreibt unter dem Namen "Atlas" ein weltweise Netzwerk von Probes, meist basierend auf einem WLAN-Router, dessen Firmware durch die Probe-Software ersetze wird und zyklisch entsprechende Test gegen andere Probes und Endpunkte startet

Ich selbst werde mich bei Gelegenheit am Netduino versuchen. Vielleicht findet sich noch jemand, der mit OpenWRT ein passendes Modul baut.

Umsetzung

Wie ich am Anfang schon geschrieben habe, bin ich noch nicht dazu gekommen diese Ideen und Überlegungen auch umzusetzen. Ich habe bislang mich auf die reine Software-Lösungen auf Basis von PowerShell konzentriert, welche einfach auf jedem beliebigen Windows-PC eingerichtet werden können.

Vielleicht findet sich ja ein Leser oder ein Azubi, Student o.ä., der diese Denkabstöße zum Anlass nimmt und die Lösung baut.

Weitere Links