TP-Link T2600G-28TS (TL-SG3424)

Dass SFLOW, SNMP, RMON LLDP und IPv6-Routing keine Merkmale von teuren "Enterprise-Switches" mehr sind, habe ich bei der Suche nach einem Ersatz für meinen "betagten" 24Port-Switch im Homeoffice Ende 2017 gemerkt. Für unter 160 Euro, also unter 6,60€/Port habe ich mir den T2600G-28TS (TL-SG3424) zugelegt, der alle das können soll. er hat den bisher genutzten TL-SG1024DE abgelöst, den ich "mühsam" per PRTG und Auslesen der Webseite überwacht habe. Mittlerweile reicht das aber nicht mehr, um bestimmte Situationen und Umgebungen nachzustellen.

Gerade die Funktion von 802.1x und LLDP für VoIP-Telefontests als auch IPv6 Funktionen waren mir wichtig. Ich was dann aber überrascht, welche Funktionen man heute in diesem Preissegment bekommen kann. Nur auf PoE habe ich verzichtet, da ich keine 24-Port brauche und der erhöhte Strombedarf und die dann auch erforderlichen Lüfter neben dem Aufpreis von ca. 200€ nicht erforderlich sind. Für PoE-Tests reicht mir eine passive Einspeisung oder ein kleiner Switch mit wenigen PoE-Ports wie z.B. den Netgear GS110 8 Port Switch in meinem Testfeld, den ich auch zum Port Mirroring einsetze. Es gibt natürlich auch von D-Link, Netgear u.a. Herstellern vergleichbare Switches in der Preisklasse.

Ich habe diese Seite unter dem Bereich PRTG eingehängt, auch wenn ich keine "eigenen Sensoren" dafür schreiben musste. Es ist dennoch ein einfaches Beispiel wie schnell per SNMP und vor allem sFlow selbst günstige Switches eingebunden werden können.

Einrichtung

Meine Umgebung, auch wenn es nur ein Homeoffice ist, ist schon etwas komplexer. So betreibe ich mehrere VLANs, um das Büro-Netzwerk von den IoT-Tests und einem Demo-Netzwerk zu trennen. Und natürlich sind auch verschiedene WLANs voneinander getrennt und durch einen EdgeRouterX (IoT Router) miteinander verbunden, der z.B. die IoT-Devices nicht ins Internet lässt. Dennoch war die Installation als Ersatz des bisherigen "webmanaged" Switch schnell erfolgt. Wie bei TP-Link Üblich hat der Switch im Werkszustand eine statische IP-Adresse (192.168.0.1). Ich musste also meinen Client erst mal eine feste Adresse im gleichen Subnetz geben, um mich mit den "admin/admin" anmelden zu können. Die Weboberfläche ist zweckmäßig.

Natürlich sind erst einmal die Grundeinstellungen vorzunehmen

  • Kennwort des Admin ändern
    Klar, dass ich hier nicht das Standard Kennwort nutze
  • Firmware Update
    Neue ist meist funktionsreicher und fehlerärmer. Bei mir war eine ca. 9 Monate alte Firmware drauf und die neuste Firmware war mit 3 Monaten vermutlich schon "ausgereift".
  • Systembeschreibung, Ort und Kontaktdaten
    Die Daten nutze ich später immer gerne für SNMP Tests.
  • Uhrzeit, Zeitzone und Sommer/Winterzeit
    Der Switch kann per NTP z.B. meinen DSL-Router oder DC fragen. Eine synchrone Zeit ist besonders beim Auswerten von Logs sehr hilfreich.
  • VLAN
    Ich nutze mehrere VLANs um Netzwerksegmente zu trennen. Die wollen also definiert und auf die Ports zugewiesen werden
    • Eintragen der VLAN Netzwerke.
    • Ändern der Trunkports von "ACCESS" auf "GENERAL".
    • Zuweisen der VLANs als "Tagged" zu den entsprechenden Ports
      Das sind Ports zu den WLAN-Accesspoints und die beiden Uplinks zu zwei weiteren Switches im Haus und natürlich zum EdgeRouterX (IoT Router).
  • Port Description
    Es ist nicht zwingend aber hilft bei der Zuordnung, wenn man auf den Ports eine Beschreibung pflegt.. So hat man gleich eine "Integrierte Dokumentation"
  • SNMP Konfiguration
    Ich verzichte hier auf allzu viele Eintragungen, auch wenn der Switch durchaus mit "Views" umgehen kann. Ich belasse es dabei eine Community mit "READONLY" einzutragen und die IP-Adresse des PRTG-Servers zuzulassen. Das reicht mir aus, denn ein Management per SNMP mache ich nicht
  • IP-Adresse anpassen
    Zuletzt habe ich die IP-Adresse auf die richte Adresse geändert. Die Änderung wird sofort aktiv und der PC verliert die Verbindung. Es ist wichtig, dass man dann den Switch nicht abschaltet, da die Konfiguration noch nicht gespeichert ist.
  • Konfiguration speichern
    Nachdem ich die anderen Anschlüsse umgesteckt und meinen PC auch wieder per DHCP mit einer IP-Adresse versehen habe, habe ich mich erneut angemeldet und die Konfiguration fest gespeichert.

So gesehen hat mich die Einrichtung wenige Minuten gekostet. Auf all die anderen netten Features bin ich erst einmal nicht weiter eingegangen. Gesehen habe ich aber u.a.

  • MAC pro Port
    Hierüber kann gesteuert werden, wie viele MAC-Adressen an einem Port gelernt werden dürfen. Ein Wert von "1" verhindert relativ einfach, dass ein Anwender per Desktop-Switch weitere Geräte kaskadiert.
  • IP-Routing
    Obwohl es eigentlich ein Switch ist, kann ich mehrere Interfaces anlegen, die auf einen Port oder VLAN gebunden werden. Zwischen den Netzwerken ist ein Routing (IPv4 und IPv6) möglich. Das ist doch mal interessant für weitere Rests.
  • DHCP-Services
    Der Switch kann sogar selbst als DHCP-Server in den verschiedenen Netzwerken dienen und IP-Adressen vergeben. Allerdings sind die Optionen natürlich beschränkt. Optionen wie 443, 160 und Vendor-specific Options sind nicht möglich, soweit ich gesehen habe. Dafür kann er dann als DHCP-Relay arbeiten, um ein Subnetz über einen zentralen DHCP-Server zu bedienen.
  • ACLs
    Damit man eine Kontrolle über das Routing hat, können ACLs auf MAC, Protokoll, IP-Adressen, TCP/UDP-Port, DSCP-Flags, Zeiten u.a. definiert und zugewiesen werden. Der Switch ist damit natürlich keine "Deep Inspection Firewall" aber die Funktionen sind fast so gut, dass ich den Ubiquiti EdgeRouterX (IoT Router) ersetzten kann.

    Ich habe mein IoT-netzwerk (192.168.180.0/24) zwar erlaubt auf mein Hausnetz zuzugreifen (192.168.178.0/24) aber alles andere unterbunden. Ich habe eine ACL500 Liste angelegt. Eintrag 0 erlaubt und Eintrag 1 verbietet alles aus dem IoT-Netzwerk

    Diese ACL habe ich dann als "Inbound" auf das IoT-VLAN11 gebunden:

  • LLDP-MED
    Der Switch kann über dieses Protokoll z.B. an Endgeräte Inforationen über deren Standort verteile, die insbesondere kompatible VoIP-Geräte im Falle eines Notrufs mit senden können. Hier bin ich mal gespannt, wie man das im Skype for Business und Teams-Umfeld nutzen kann.

Soweit sieht das Setup und die Konfiguration schon einmal ganz gut aus. Sicher ist die Bedienung der Webseite etwas "altbacken" und wenn man die Beschreibung von 24 Ports individuell ändern will, muss man jeden Port einzeln anwählen, das Beschreibungsfeld füllen und "Apply" drücken und noch mal bestätigen. Da gibt es sicher schon modernere GUIs. Aber das mache ich ja eher selten. TP-Link entwickelt den Switch natürlich weiter. Daher gibt es immer mal wieder eine neue Firmware. Allerdings scheint auch die Hardware verändert zu werden und so gibt es den gleichen Switch in mehreren Versionen. Leider geht die Version bei den diversen Händlern nicht hervor und so habe ich eine Version 2 erhalten. Auf der US-Seite war dies auch aktuell. Auf der DE-Seite gab es aber schon eine Beschreibung zur Version 3 und auch Firmware für eine Version 1. Da besteht schon die Befürchtung, dass es dann keine Updates mehr gibt. Noch habe ich keine Fehler feststellen können aber es wäre schon interessant, was geändert wurde.

PRTG SNMP

Der neue Switch unterstützt natürlich SNMP und so war es klar, dass ich in PRTG die IP-Adresse des Switch mit meiner SNMP-ReadOnly-Community addiert habe. Schon der automatische "Basisscan" liefert alle Ports, die "gesteckt" sind. PRTG spart alleine die nicht belegten Ports aus. Allerdings addiert PRTG neben einem PING-Sensor auch noch verschiedene HTTP-Sensoren, die letztlich nur die Erreichbarkeit der Konfigurationswebseite testen. Die können dauerhaft Pausieren oder ganz löschen. Leider gibt es per Default keinen "SNMP-Device"-Sensor, der die essentiellen Daten des Geräts (CPU, Memory, Uptime, PING-Erreichbarkeit) in einem Sensor und mehreren Kanälen zusammenfasst. DAs kann ich aber über den "SNMP Custom Advanced"-Sensor manuell einrichten, der bis zu 10 OIDs sammelt. Ich muss mir vorab eben nur die OIDs zusammen sammeln.

Wichtig: Man kann nur bei der Anlage die Anzahl der OID (1..10) aktivieren.

1 - ISO assigned OIDs
1.3 - ISO Identified Organization
1.3.6 - US Department of Defense
1.3.6.1 - OID assignments from 1.3.6.1 - Internet
1.3.6.1.2 - IETF Management
1.3.6.1.2.1.1 - SNMP MIB-2 System
1.3.6.1.4.1 - IANA-registered Private Enterprises
1.3.6.1.4.1.11863.6 TP-Link.tplinkMgmt
ChannelName OID Sensor Channel Unit

system.sysUpTime.0

1.3.6.1.2.1.1.3.0

TimeResponse

tpSysInfoUpTime

1.3.6.1.4.1.11863.6.1.1.9

TimeResponse

tpSysMonitorCpu1Minutes

1.3.6.1.4.1.11863.6.4.1.1.1.1.3.1

CPU

tpSysMonitorMemoryUtilization

1.3.6.1.4.1.11863.6.4.1.2.1.1.2.1

BytesMemory

Ich habe in den MIBs leider keine Quelle für die Temperatur gefunden. Einen Lüfter kann man natürlich ebenfalls nicht abfragen, wenn er nicht verbaut ist.

Aber auch einfach mit den Standardsensoren funktioniert der Switch mit PRTG auf Anhieb. Für jeden Port sammelt PRTG das Datenvolumen.

Allerdings hat er bei mir wirklich nur "Traffic In/Out" erfasst. Über die Einstellungen konnte ich aber auch noch Counter für andere Werte per Checkbox aktivieren. Zumindest auf den "Trunks" möchte ich schon gerne die Error-Rate sehen.

Soweit ist die Integration allein mit den Standard-MIBs gelungen.

PRTG sFlow

Besonders neugierig war ich aber über die SFLOW-Funktion, die der Switch ebenfalls hat. Normal kenne ich diese Funktion primär von Routern, die auf Layer 3/4 (IP/UDP/TCP) die Verbindungen erfassen und über NetFlow/SFlow melden. Bei einem reinen Switch ist diese Funktion eigentlich nicht zu erwarten. Allerdings ist der TP-Link T2600-28TS nun kein reiner Switch sondern kann sogar IP-Router sein. PRTG kann mit SFLOW/NetFlow umgehen und so habe ich umgehend auch diese Funktion auf dem Switch aktiviert. Auch das ist sehr einfach

Zuerst muss ich den "Collector" definieren, d.h. welches System die sFlow empfangen soll. Der Switch unterstützt bis zu vier Systeme, die mit IP-Adresse und Port spezifiziert werden. Vergessen Sie nicht den Radio-Button "Enabled" auch einzuschalten.

Nach mindestens ein Collector definiert ist, muss ich nun pro Port festlegen, an welchen Collector die Statistiken für diesen Port gesendet werden. Ich kann pro Port nur genau einen Collector angeben. Aber die Unterscheidung ist durchaus interessant, da ich so eben bis zu vier Collectoren zur Auswahl habe.

Ich sende in der ersten Version erst einmal alles an den gleichen Collector. Da Sie in PRTG aber mehrere Netflow/SFlow-Sensoren anlegen können, ist es durchaus interessant, z.B.: besondere Ports zu einem eigenen Sensor zu leiten und die Datenverbindungen schon zu separieren. So könnte der Link zum Exchange Server oder auch ein Uplink zu einem WAN-Port auf einem eigenen Sensor landen.

Auch hier kann ich schreiben, dass die Einrichtung auf dem Switch und die Konfiguration des SFLOW-Sensors auf PRTG auf Anhieb funktioniert haben und nach wenigen Stunden die Bilder Gestalt angenommen haben:

Allerdings sehen Sie schon hier, dass sehr viel Verkehr unter "Various" zu finden ist. Da muss ich doch noch mal nachschauen und ein paar Definitionen anpassen.

In der Detail-Ansicht sind dann auch die "Partnerschaften" zu sehen:

Leider scheint PRTG selbst die Daten anzunehmen und dann die TOP-Listen zusammen zu fassen. Die Rohdaten aber sind wohl nicht aufgezeichnet worden. Man kann Sie von PRTG daher nicht für weitere Analysen extrahieren.

Allerdings gibt es doch Wege, wie ich auf den beiden folgenden Links beschrieben habe.

Weitere Links