PRTG TL-SG1024DE

Für den Einsatz im privaten Bereich gibt es für wenig Geld durchaus interessante Switche wie z.B. den TLink TL-SG1024DE. 100€ für 24 Gigabit-Ports, FAN-Less, eingebautes Netzteil samt Mirroring und "Smart Management" per Web, QoS mit Bandbreitenlimitierung und VLAN ist als günstig zu bezeichnen. Allerdings fehlen hier natürlich PoE-Ports und leider ist auch SNMP nicht enthalten. Mit PRTG und einen Skript lässt sich der Switch aber dennoch überwachen. Seit dem Paessler PRTG als 100-Sensor-Lizenz (statt früher 10 oder 30) kostenfrei verteilt, kann man jeden Sensor auch eigens überwachen. Diese Seite beschreibt, wie man auch einen TP-Link Switch überwachen kann, der als "Easy Smart Managed" leider kein SNMP unterstützt.

TP-Link TL-SG1024DE Monitoring

Da SNMP nicht vorhanden ist, muss man per Browser die Daten abfragen. Das kann aber auch ein Skript machen, welches sich "wie ein Browser" anmeldet und dann die fragliche Seite abruft. Die Anmeldung erfolgt per "Formular", so dass man zuerst einen Post simulieren muss. Interessanterweise sind dann aber alle Folgezugriffe von dieser Client IP "erlaubt". Wenn ich mich also z.B. mit Chrome anmelde, kann ich parallel einen anderen Browser starten und weiter konfigurieren. Eine seltsame Sicherheitstechnik aber für einen SoHo-Switch vermutlich tolerierbar. SSL gibt es ja auch nicht. Nach der Anmeldung kann man dann auch direkt die Adresse http://<switch-adresse>/PortStatisticsPrm.htm ansprechen.

Aber ganz so einfach kann man die Zahlen dann doch nicht aus der Tabelle klauben, da die zurückgegebene Seite gerade zu von JavaScript strotzt. Fiddler zeigt hier die Details an. Zuerst die HTML-Konversation:

Der Request ist vollkommen unspektakulär. Der Abruf der Statistik per Browser fordert folgende Seite an.

Es gibt keine Cookies oder Authentication Header. Der Switch kann nicht unterscheiden, ob die vorherige Anmeldung vom gleichen Prozess gekommen ist. Und tatsächlich reicht es, wenn ein Prozess eine Anmeldung durchgeführt hat, dass dann alle Prozesse mit der gleichen Quell-IP-Adresse den Switch konfigurieren können. Sicher ist anders aber für einen SOHO-Gerät ist das tolerierbar.

Die Antwort enthält aber nicht die HTML-Tabelle zur Ansicht, sondern die Ergebnisse in der Variable "tmp_info", die durch das JavaScript im Browser erst zu der Tabelle aufbereitet wird.

 

Allerdings sind da nur die ersten 16 Ports enthalten. die Port 17-24 finden sich in der Variable "tmp_info2"

Ein Auswerteskript muss also gar nicht erst HTML-Code parsen, sondern kann einfach diesen Inhalt raus fischen, dessen Bedeutung sich im Vergleich mit der Tabelle schnell ergibt. Es sind immer sechs Felder pro Port mit folgender Bedeutung aneinander gehängt:

Feld Wert Bedeutung

1

1

Enabled
Disabled

2

0
1
2
3
4
5
6
7

Link Down
Auto
10HalfDuplex
10FullDuplex ?
100HalfDuplex ?
100FullDuplex
1000FullDuplex
?

Anzahl Integer 

TxGoodPkt

4

Anzahl Integer 

TxBadPkt

5

Anzahl Integer 

RxGoodPkt

6

Anzahl Integer 

RxBadPkt

Gut zu sehen ist aber auch, dass zumindest hier nur Pakete gezählt werden aber keine Bytes. Damit das aber funktioniert, muss die IP des Clients erst die Authentifizierungsmaske durchlaufen haben. Das ist dann wieder ein einfacher Formular POST:

Ein direkter Zugriff auf die Statistik durch Übermittlung der Anmeldedaten als Teil der URL z.B. http://admin:admin@192.168.178.2/PortStatisticsRpm.htm, geht leider nicht. Die erfolgreiche Anmeldung erlaubt jedem Client hinter der IP-Adresse den Switch zu konfigurieren. IP-Spoofing ist mit TCP nicht ganz so einfach aber es gibt sicherere Verfahren eine Session zu verfolgen. Ein Logout am Ende ist zu empfehlen.

 

Mit diesem Handwerkszeug kann aber nun schon ein Skript gebaut werden, welches sich anmelden, die Statistik lädt und dann weiter verarbeitet. Ich habe parallel auch mal in die Firmware geschaut, ob es noch andere URLs oder CGI-Skripte gibt oder Spuren von SNMP aber bin nicht fündig geworden.

Skript-Basis

24 Ports mit sechs Werten sind mir zu viele Daten, um diese in einem Sensor zu erfassen. Mit der Erweiterung von Paessler auf 100 Sensoren kann ich nun jedem Port einen eigenen Sensor und damit eine eigene Grafik spendieren. Das Grundprinzip ist einfach:

  1. Anmelden am Switch
    Das geht über einen Form-Post in PowerShell recht einfach. Damit ist die IP-Adresse des PRTG-Servers dann für eine gewisse Zeit "authentifiziert"
  2. Abfrage der "PortStatisticsPrm.htm"
    In der Ausgabe hole ich mir nun natürlich direkt die Variable und Werte diese aus
  3. (optional) Abmelden
    Ich hab den "Abmelde-Code" aktuell auskommentiert, damit er nicht aktiv wird. Ich "brauche" ihn nicht wirklich und ein Abmelden würde auch einen Browser rauswerfen, der vom gleichen PC gerade den Switch konfiguriert.

Leider kann man in PRTG mit einem Skript nicht mehrere Sensoren direkt mit Daten füllen. Das gibt die PRTG-API leider nicht her, also muss PRTG für jeden Port das Skript getrennt ausführen. Um nun nicht auch noch 24-mal die Verbindung zum Switch aufbauen zu müssen, sollte das Skript die Ergebnisse einfach in eine Datei schreiben und beim nächsten Start die Datei lesen, wenn Sie noch nicht "zu alt" ist.

Write-Host "prtg-tplink:Login"
$postParams = @{username='admin';password='tppass06';logon='login'}
$loginresult=Invoke-WebRequest -Uri http://192.168.178.2/logon.cgi -Method POST -Body $postParams
if ($loginresult.StatusCode -ne 200) {
   write-host "Invalid Login"
}
else {
   Write-Host "prtg-tplink:Loading PortStatisticsRpm"
   $PortStatisticsPrm = Invoke-WebRequest -Uri 'http://192.168.178.2/PortStatisticsRpm.htm' -Method GET
   if ($loginresult.StatusCode -ne 200) {
      write-host "Invalid Content"
   }
   else {
      Write-Host "Matching Data Payload"
      if ($PortStatisticsPrm.RawContent -match 'var tmp_info = "(.*?)";')) {
         $data= $Matches[1].trim().split(" ")
         if (($data%6) -ne 0) {
            write-host "nicht durch 6 teilbar"
         }
         else { für ($i=0; $i -lt $data.count; $i=$i+6) {
               Write-Host "Port     :" ([int]($i/6) + 1)
               Write-Host "enabled  :" $data[[int]$i+1]
               Write-Host "Speed    :" $data[$i+2]
               Write-Host "TxGoodPkt:" $data[$i+3]
               Write-Host "TxBadPkt :" $data[$i+4]
               Write-Host "RxGoodPkt:" $data[$i+5]
               Write-Host "RxBadPkt :" $data[$i+6]
            }
         }
      }
      else {
         write-host "Unable to find data"
      }
   }
}

Das ganze muss nun natürlich in ein Skript verpackt, werden, welches PRTG-tauglich ist, d.h. mit Parametrisierung der IP-Adresse, des Kennworts und des Ports.

Die erste Version lief derart, dass nach der Angabe des Port die dazugehörigen Daten ermittelt und an PRTG übergeben wurde. So musste der Sensor 24-mal mit dem passenden Parameter aufgerufen werden. Ich habe darauf verzichtet,  Auf der anderen Seite eröffnet dies die Möglichkeit natürlich die Details dieses Ports in einer Grafik anzuzeigen. Allerdings hat die Auswertung eines Ports ca. 2-3 Sekunden gedauert. Wer damit alle 24 Ports abfragen wollte, also also ca. eine Minute damit verbracht.

Daher habe ich das Skript modifiziert, welches nur dann die Daten anfordert, wenn die Antworten in einer lokalen Cache-Datei puffert und liest. Damit wir deine echte Verbindung erst erforderlich, wenn der Cache noch leer oder älter als 60 Sekunden (Default) ist. Wenn die Sensoren also nacheinander ablaufen, was man natürlich sicherstellen sollte, dann holt der erste Sensor die Daten aller Ports und die weiteren Aufrufe lesen nur die Datei. Damit haben alle 24 Werte auch den gleichen Zeitpunkt erfasst. Wichtiger ist aber, dass der Abruf dann für die Daten aus dem Cache weniger 50ms pro Port dauert.

Integration in PRTG

Zuerst müssen Sie den Custom Sensor als PowerShell-Programm in das entsprechende EXEXML-Verzeichnis kopieren.

prtg/prtg-tplink.1.0.ps1
Bitte die Erweiterung ändern 

Den Switch gab es in PRTG sowieso schon als Device, welches bislang per ICMP (PING) und HTTP (Webkonsole) überwacht wurde. Hier habe ich nun 24x einen Custom Sensor angelegt, bei dem ich aber per Parameter den jeweiligen Port definiert habe. Zusätzlich wurde eine MUTEX gesetzt, damit immer nur einer der Sensoren gleichzeitig ausgeführt wird. Welcher dabei zuerst gestartet wird, ist aber egal.

 

Ich habe neben den Werten des Switches noch zwei synthetische Kanäle "TotalGoodPkt" und "TotalBadPkt" addiert, von denen TotalGoodPkt als primärer Kanal genutzt wird. Wenn Sie dies ändern wollen, dann sollten Sie den ersten Lauf mit Port1 abwarten, dann alles wie gewünscht konfigurieren. Die Port 2-24 lassen sich über die "Clone"-Funktion dann recht einfach erstellen

PRTG übernimmt dann alle Werte und Sie müssen nur noch den Namen des Sensors und die Portnummer anpassen. Wer weiß, welches Endgerät an welchem Port hängt, kann die im Namen mit hinterlegen. In der Übersicht ist dann jeder Port mit einer "Minigrafik" zu sehen

 

So ist sehr schnell erkennbar, auf welchen Ports Aktivitäten zu sehen sind. Leider enthält diese Tabelle als Status "UP" den SensorStatus und kann nicht den Portstatus (z.B. Link Speed) anzeigen.

Achtung:
Der Switch erlaubt immer nur eine einzelne HTTP-Sitzung von einer IP-Source-Adresse. Wenn Sie also per Browser von einem anderen Client den Switch verwalten, wird das Monitoring-Skript fehlschlagen oder ihre Sitzung rauswerfen. Am besten "Verwalten" sie den Switch gleich vom gleichen System, welches per PRTG die Überwachung ausführt oder sie pausieren die Überwachung.

Abtastrate und Scanintervall

Bei den ersten Messreihe habe ich die Standardwerte von "60 Sekunden" für das Gerät genommen, was zu einem sehr seltsamen Diagramm bei allen Sensoren geführt hat. Jede zweite Messung hat genau das gleiche Ergebnis wie die vorherige Messing geliefert. Anscheinend aktualisiert der Switch die Anzahl gesendete und empfangenen Pakete nicht "Realtime", sondern In Intervallen zwischen 60 und 120 Sekunden.

Da ich eine "Genauigkeit" von 60 Sekunden eh nicht brauche, habe ich die Sensoren auf 5 Minuten gestellt. Damit waren die Bilder dann auch "stimmig".

 

Hier sieht man ein System, welches ca. 5 Pakete/Sek (im Mittel über 5 Minuten) überträgt. Es ist aber auch zu sehen, dass die Geschwindigkeit von 2 (10 MBit/Halbduplex) auf 5 (=100MBit Full) hoch geht. Das Verhalten lässt sich durch Stromspar-Funktionen des "HP OfficeJet 8600 Plus" - Druckers im Ruhemodus erklären.

Summensensor

Nachdem ich nun für jede Port einen Sensor nutzen kann, habe ich mir mir überlegt, dass ein Summensensor durchaus interessant sein könnte, um den Switch als gesamtes zu erfassen, z.B.: mit den folgenden Werten:

  • Anzahl aktivierter und deaktivierter Ports
  • Anzahl der Ports mit Link und der Verteilung der Link-Geschwindigkeiten
  • Gesamtsumme aller empfangenen und gesendeten Pakete
  • Gesamtsumme der fehlerhaften Pakete

Die Werte sind eine gute Übersicht aber eignen sich auch gut zur Alarmierung, z.B. wenn die Fehlerrate ansteigt. Diese Funktion ist nun erreichbar, wenn Sie den Port 0 (Parameter "-portnumber:0") angeben.

Hinweis: Da die Summer durch Addition der Ports erfolgt, gibt es Differenzen. Die Summe der "empfangenen Pakete" ist ein Maß für die Gesamtpakete. Die Summer der gesendeten Pakete is aber immer höher, da z.B. ein Broadcast nur auf einem Port empfangen aber auf allen Ports gesendet wird.

Nebeneffekte

Monitoring kostet Ressourcen. Durch den umstieg mit einer Cache-Datei hat sich die CPU-Las des PRTG-Servers nicht signifikant reduziert. Aber die Laufzeit der Skripte wurde natürlich deutlich verkürzt. Interessanterweise hat sich die Ladezeit der Webseite, gemessen mit dem HTTP-Monitor, eher noch verkürzt.

Einen negativen Effekt gibt es aber auch noch zu berichten: Der Zugriff auf die Webseite ist immer nur von einer "Source-IP" möglich. Solange aber PRTG regelmäßig die Daten abruft, kann ich den Switch nicht mehr von einem anderen Client aus konfigurieren.

Für die Konfiguration muss ich also dann eben vom PRTG-Server selbst einen Browser starten.

Wünsche

Dank der Flexibilität PRTG Custom Sensors kombiniert mit PowerShell konnte ich sogar meinen "Smart Managed"-Switch von TP-Link in die Überwachung aufnehmen. Wenn ich aber Wünsche äußern dürfte, dann hätte ich zwei vordringliche Verbesserungen

  • TP-Link: Bessere API: SNMP oder REST
    Warum bedeutet "Smart Managed" eigentlich immer nur "Browser Managed" ?. Es sollte doch komplett problemlos sein, auch noch einen kleinen SNMP-Prozess zu integrieren, der zumindest ReadOnly den Zugriff erlaubt. Wenn schon nicht SNMP, dann wäre eine REST-API auf den WebServer interessant, die eine XML-Struktur zurück gibt. Aber bitte nicht nur eine Webseite mit halbherziger Authentifizierung, die zudem immer ein "200 OK" zurück gibt und auch im Body keinen direkten Hinweis auf den Fehler.
  • TP-Link: Byte Counter
    Noch wichtiger als die Anzahl der Pakete wäre mir aber die Anzahl der Bytes, die übertragen wurden. Am besten natürlich Beides. Eigentlich müssen die Werte auch schon erhoben werden, da der Switch QoS mit Bandbreiten-Beschränkungen unterstützt.
  • PRTG: Feedback an mehrere Sensoren
    Sollte mein Sensor der erste sein, bei dem ein Skript Daten erhebt, die mehreren anderen Sensoren zugute kommen könnten ?. Ich würde mir hier wünschen, dass der PRTG-Core nicht nur Daten selbst anruft, sondern man ihm diese auch zusenden kann. Gerne mit einer Beschränkung auf "localhost" als Absender oder mit einer Authentifizierung. Ein Empfang von SYSLOG-Messages und SNMP-Traps ist ja auch möglich
  • Skript
    Aktuell definiert das Skript noch keine "Fehler" oder Grenzwerte

Aber auch ohne diese Verbesserungen kann ich so zumindest sehen, welche Geräte wann Daten senden und Empfangen und welche Fehlerraten anliegen. Aber vielleicht gibt es ja

Weitere Links