Ihr Überwachungstool meldet Ihnen, dass etwas ausgefallen ist. Und dann? In den meisten Organisationen lautet die Antwort: Ein Engineer klappt das Notebook auf, verbindet sich per SSH mit einem Switch und beginnt, Befehle abzusetzen. Wenn es 2 Uhr nachts ist, macht dieser Engineer das halb verschlafen vom Bett aus. Genau diese Lücke schliesst Closed-Loop Remediation.
Das Problem: Die Überwachung sagt Ihnen das Was, nicht das Warum
Jedes Netzwerkteam hat eine Überwachung im Einsatz. PRTG, Zabbix, LibreNMS oder etwas anderes. Diese Tools sind hervorragend darin, Probleme zu erkennen. Ein Access Point geht offline. Ein Switch-Port beginnt zu flappen. Ein Gerät wird unerreichbar. Sie erhalten einen Alarm.
Doch der Alarm sagt Ihnen nur, dass etwas nicht stimmt. Er sagt Ihnen nicht, warum. Und genau das Finden des «Warum» verschlingt die meiste Zeit. Ein Engineer muss sich auf dem Switch anmelden, den Port-Status prüfen, Fehlerzähler ansehen, eine Kabeldiagnose durchführen, PoE verifizieren, den WLC prüfen und zusammensetzen, was passiert ist. Für ein einzelnes AP-Problem kann das 20 bis 45 Minuten manueller Arbeit bedeuten.
Multiplizieren Sie das über ein grosses Campus-Netzwerk mit Hunderten von Access Points, und Sie haben ein Team, das mehr Zeit mit Fehlersuche verbringt als mit der Verbesserung des Netzwerks.
So sieht Closed-Loop Remediation aus
Das Konzept ist einfach: Ihr Überwachungstool erkennt ein Problem und löst automatisch einen Diagnose-Workflow aus. Der Workflow verbindet sich mit den relevanten Netzwerkgeräten, führt eine strukturierte Abfolge von Prüfungen durch und liefert Ihrem Team einen Root-Cause-Bericht. Niemand muss eine CLI anfassen.
So sieht das in der Praxis aus, wenn ein Access Point offline geht:
Phase 1: Erkennen und Lokalisieren
Ihre Überwachungsplattform sendet in dem Moment einen Webhook an NetGUI, in dem sie feststellt, dass der AP unerreichbar ist. NetGUI schlägt den AP in seinem Inventar nach, identifiziert, mit welchem Switch er verbunden ist, und auf welchem genauen Port er sitzt. Das dauert Sekunden.
Phase 2: Diagnostizieren
NetGUI verbindet sich mit dem vorgelagerten Switch und führt eine strukturierte Diagnose-Abfolge durch. Es ist dieselbe Abfolge, die ein erfahrener Network Engineer befolgen würde, aber sie läuft automatisch und jedes Mal konsistent ab:
- Port-Status - Ist der Port up oder down? Wann hat er zuletzt seinen Zustand gewechselt? Gibt es Fehlerzähler oder CRC-Fehler?
- TDR-Kabeltest - Wenn der Port down ist, prüft ein Time-Domain-Reflectometry-Test das Kabel auf Defekte, Unterbrechungen oder Kurzschlüsse und meldet die genaue Distanz zur Fehlerstelle in Metern.
- PoE-Validierung - Erhält der AP Strom? Ist genügend Budget auf dem Switch vorhanden? Hat sich die Leistungszuteilung verändert?
- CDP/LLDP-Nachbarn - Sieht der Switch den AP noch? Ist die MAC-Adresse in der Tabelle?
- IP und DHCP - Hat der AP eine IP-Adresse erhalten? Was zeigt die ARP-Tabelle? Gibt es DHCP-Snooping-Einträge?
- WLC-Registrierung - Hat sich der AP beim Wireless Controller angemeldet? In welchem Zustand befindet er sich? Gibt es Join-Fehler?
- Client-Auswirkungen - Waren vor dem Ausfall Clients verbunden? Gab es Authentifizierungsfehler?
Phase 3: Berichten
Alle Ergebnisse werden zu einem strukturierten Bericht zusammengefasst und Ihrem Pikettteam über Microsoft Teams, Slack oder E-Mail zugestellt. Der Bericht enthält die Ursache, die betroffene Infrastruktur und empfohlene nächste Schritte. Jeder ausgeführte Befehl und jedes empfangene Ergebnis wird für die Compliance mit Zeitstempel protokolliert.
PRTG erkennt um 02:00 Uhr, dass ein Access Point in Gebäude 3 offline ist, und sendet einen Webhook an NetGUI. Bis 02:03 Uhr hat sich NetGUI mit dem vorgelagerten Switch verbunden, die vollständige Diagnose-Abfolge ausgeführt, eine Kabelunterbrechung bei 12 Metern auf Port Gi1/0/24 (Adernpaare C und D) identifiziert und den Root-Cause-Bericht über Microsoft Teams an das Pikettteam geliefert. Das Facility-Team wird am frühen Morgen aufgeboten, um das Kabel zu ersetzen. Gesamteinsatz des Engineers: null.
Warum das für Ihr Team wichtig ist
Der Mehrwert liegt nicht nur in der Geschwindigkeit. Er liegt in Konsistenz und Abdeckung.
Wenn ein Mensch um 2 Uhr nachts Fehler sucht, überspringt er womöglich Schritte. Vielleicht vergisst er, PoE zu prüfen. Vielleicht führt er keinen TDR-Test durch. Vielleicht protokolliert er nicht, was er getan hat. Ein automatisierter Workflow führt jedes einzelne Mal dieselben Prüfungen durch, dokumentiert alles und wird nie müde.
Für Organisationen mit Compliance-Anforderungen ist der automatische Audit-Trail von Bedeutung. Jeder Befehl, jede Antwort, jeder Zeitstempel wird erfasst. Wenn ein Auditor fragt, was während eines Vorfalls passiert ist, haben Sie eine vollständige Aufzeichnung, ohne sich auf das Gedächtnis eines Engineers verlassen zu müssen.
Was Sie für den Start brauchen
Closed-Loop Remediation mit NetGUI erfordert drei Dinge:
- Eine Überwachungsplattform, die Webhooks oder SNMP-Traps unterstützt. PRTG, Zabbix und LibreNMS unterstützen dies alle von Haus aus. Wenn Ihr Überwachungstool beim Auslösen eines Alarms ein HTTP POST senden kann, funktioniert es.
- NetGUI mit Zugriff auf Ihre Switches. NetGUI benötigt SSH- oder API-Zugriff auf die Switches, an denen Ihre APs angeschlossen sind. Derselbe Zugriff, den Ihre Engineers heute schon nutzen.
- Einen Benachrichtigungskanal. Microsoft Teams, Slack oder E-Mail. Hierhin werden die Diagnoseberichte zugestellt.
Die Einrichtung ist unkompliziert. Sie konfigurieren Ihre Überwachungsplattform so, dass sie Alarme an den Webhook-Endpunkt von NetGUI sendet. Sie ordnen Ihr AP-Inventar den Switch-Ports zu. Den Rest übernimmt NetGUI.
Tipp: Beginnen Sie mit einem einzelnen Gebäude oder einer einzelnen Etage. Lassen Sie die automatisierte Diagnose ein paar Wochen lang parallel zu Ihrem bestehenden manuellen Prozess laufen. Vergleichen Sie die Ergebnisse. Sobald Sie der Ausgabe vertrauen, erweitern Sie auf den gesamten Campus.
Über Access Points hinaus
Auch wenn die AP-Fehlersuche der häufigste Anwendungsfall ist, funktioniert derselbe Ansatz für jedes Gerät, das an einem verwalteten Switch-Port angeschlossen ist. IP-Telefone, Kameras, IoT-Sensoren. Wenn es an einem Switch-Port hängt und Ihre Überwachung erkennen kann, wann es offline geht, kann NetGUI diagnostizieren, warum.
Die Diagnoseprüfungen passen sich dem Gerätetyp an. Eine Untersuchung eines IP-Telefons könnte sich auf die VLAN-Zuweisung und Voice-QoS konzentrieren. Bei einer Kamera könnte der Schwerpunkt auf der PoE-Leistungsaufnahme und der Bandbreitenauslastung liegen. Der Workflow ist flexibel, doch das Prinzip bleibt dasselbe: erkennen, lokalisieren, diagnostizieren, berichten.
Das Fazit
Die meisten Netzwerkteams haben stark in die Überwachung investiert. Sie wissen, wann etwas kaputtgeht. Was ihnen fehlt, ist die automatisierte Reaktionsebene, die diese Alarme in Antworten verwandelt. Closed-Loop Remediation schliesst diese Lücke. Ihre Überwachung erkennt es. NetGUI behebt es. Ihre Engineers konzentrieren sich auf Projekte, die das Netzwerk voranbringen, statt um 2 Uhr nachts Brände zu löschen.