Von Jörg Wiebusch

Nach dem ersten Blogeintrag habe ich mir gedacht, wie kann es weitergehen? Welche interessanten Themen könnte man als nächstes angehen?

Der Beitrag hinsichtlich der Performance im WLAN war natürlich auch von unserem letzten Firmenevent beeinflusst oder besser gesagt „inspiriert“. Gerade die Punkte Performance und Motorsport waren natürlich eine sehr gute Verbindung. Daher würde ich gerne auch jetzt wieder eine Verbindung schaffen und möchte an das Thema Performance anknüpfen. Performance im WLAN war das Ziel im letzten Beitrag. Was Performance ist und wie man sie erreichen kann.

Jetzt möchte ich jedoch zeigen, dass es nicht nur wichtig ist, die Performance im WLAN zu erreichen, sondern diese auch zu erhalten, zu überwachen und im Zweifelsfall auch Probleme oder Beeinträchtigungen schnellstmöglich zu erkennen und natürlich danach zu beseitigen. Denn was nützt es, die neuesten Komponenten einzusetzen oder auch eine perfekte Planung zu haben, wenn dies nur als Momentaufnahme gesehen wird und nicht auf Dauer genutzt werden kann? Teile dessen oder beides sind eine sehr gute Grundlage für ein wirklich performantes WLAN System.

All das habe ich versucht auf eine hoffentlich nicht ganz unlustige Art und Weise zu erklären. Jetzt wollen wir doch mal schauen, ob mir das mit diesem Thema ebenfalls gelingt. Allerdings möchte ich dafür erst ein wenig ausholen, denn das Thema ist zwar nicht hochkomplex oder technisch, aber ich würde gerne kurz meine Sicht auf das Thema Monitoring, Management und auch Fehlersuche und Analyse aufzeigen. Denn eine super Planung und auch ein Spitzendesign sind zwar eine hervorragende Grundlage, aber…

Kein Gizmo in Sicht

Da kommt das gute, alte „Aber“ um die Ecke. Es gibt immer mal wieder ein Hindernis oder Problem. Ein sporadisch auftretendes Ereignis oder eine Störquelle. Die Piloten im zweiten Weltkrieg hatten einen Begriff dafür: „Gremlin“. Der Name wurde vom britischen Schriftsteller Ronald Dahl geprägt.

Nein, bevor die Frage kommt… kein Gizmo, kein Wasser und nach Mitternacht wird auch nicht gefüttert. Diese „wirklichen“, fiesen Gremlins tauchen immer mal wieder auf und sorgen für merkwürdige Phänomene in technischen Systemen. Aber warum komme ich auf Gremlins? In Fall von WLAN-Infrastrukturen würde ich der Definition sogar zustimmen. Gremlins sind kleine unsichtbare Kobolde, die Spaß daran haben, technische Systeme zu sabotieren. Passt zum WLAN. Nicht sichtbar, nicht greifbar, nicht verständlich und vor allem sehr schwer auffindbar.

So! Ich stelle also erst einmal fest, dass es Gremlins in jedem WLAN-System geben kann. Aber was machen, wenn diese kleinen Gremlins zuschlagen? Halten wir fest, wir haben ein sauber geplantes WLAN, neueste Komponenten, ein gutes Design und eine korrekte Konfiguration der Systeme. Abgerundet mit einem vernünftigen Management-System, WLAN-Controller oder ähnlichem. Die Systeme können mir zeigen, dass ich einen Ausfall eines Access Points habe, ein Client einen falschen Key verwendet oder generell kritische Systeme ausgefallen sind. Das ist schon wirklich nicht schlecht und eigentlich heutzutage unumgänglich für die meisten Unternehmen. Die wenigsten Administratoren haben heutzutage die Zeit oder die technischen Möglichkeiten, jedem möglichem oder sporadischen Fehler auf den Grund zu gehen. Und selbst, wenn eine hochmoderne Wi-Fi 6 WLAN Infrastruktur mit zentralisiertem Management und Monitoring existiert, kommn unter Umständen noch die Faktoren Zeit und Entfernung hinzu. Was passiert, wenn man ein internationales Netzwerk verwaltet oder etwas kleiner, ein deutschlandweites Netzwerk implementiert hat? Die Firmenzentrale liegt vielleicht in München, Berlin oder Flensburg,…

Und der Gremlin? Der schlägt in Köln, Siegen oder Traben-Trabach zu. Was dann? Bis ein Techniker vor Ort ist und eventuell Messungen und Tests vornehmen kann, vergehen auf jeden Fall Stunden. Selbst, wenn ein Administrator sofort losfahren würde oder sogar fliegen könnte, ist die Zeitdifferenz doch recht groß zwischen Auftreten des Fehlers und der ersten Analyse vor Ort.

Jetzt kann man sagen, dass man ja mit dem zentralen Management und Monitoring schon viele Analysemöglichkeiten hat. Man kann diese Technologien natürlich nutzen, um Fehlerlogs der Access Points auszulesen oder auch im gewissen Rahmen sogar Signalstärken zu ermitteln und vielleicht sogar Paket- oder Frameanalysen vorzunehmen. Das Ganze vielleicht sogar mit einer gewissen Forensik – also rückwirkend – zumeist mit Cloudsystemen, die einen relativ unbegrenzten Speicher dafür liefern (im Vergleich zu lokalen Systemen).

Die Nadel im Heuhaufen

All das sind wirklich gute Möglichkeiten zur Fehlereingrenzung. Weit mehr als noch vor wenigen Jahren. Der Grad der Automatisierung, der Analysefunktionen und der Detailgrad der Daten, die diese hochentwickelten Controller und Cloudsysteme liefern, ist inzwischen sehr hoch. Jedoch führt diese Komplexität auch zu einer neuen Situation. Zu Beginn des „WLAN Zeitalters“, in einer Galaxis… äh, Anfang der 2000er Jahre, war WLAN ein Thema für HF-Ingenieure, Professoren usw. Bereits kurze Zeit später waren die ersten Geräte auf dem Markt, die eine relative einfache Konfiguration ermöglichten: „WEP-Key, Channel, SSID, fertig – o.k. noch IP-Adressen usw.“ Aber, diese Konfiguration wurde sehr schnell auch „sehr einfach“ (zumindest in den Augen vieler). Zu diesen Zeiten waren auch die Analysemöglichkeiten begrenzt. Oft wurde bei Fehlern einfach ein neuer oder zusätzlicher Access Point verbaut. Das Endgerät getauscht oder der Fehler mit Inkompatibilität erklärt. Höre ich da grad… Gremlin?

Mittlerweile sind die Analysemöglichkeiten in den aktuellen Systemen sehr weit entwickelt. Die Systeme geben vereinfachte Meldungen oder direkte Handlungsempfehlungen aus. Für Experten mit tiefergehendem Wissen bieten diese Systeme den tiefergehenden Blick in die WLAN Protokollebene. Somit sind wir wieder an dem Punkt angekommen, dass Spezialisten notwendig sind, um diese doch durchaus komplexen System bei der Integration oder bei Fehleranalysen zu beherrschen. Doch warum diese Ausführungen? Ist doch genau das, was man will. Systeme, die Fehler selbstständig analysieren können, Empfehlungen aussprechen können und somit das Leben eines Administrators und auch des WLAN Experten einfacher zu machen. Aber…. Sagte ich schon, komische Fehler, sporadische Fehler, Gremlin…?

Die andere Seite der Medaille

Jedoch all diese Möglichkeiten berücksichtigen leider nicht einige, kleine, wichtige Punkte. Jedes dieser Systeme ist meistens nicht in der Lage, die „andere Seite“ zu sehen. Kaum eines dieser Systeme überwacht das WLAN aus Sicht des Clients. Es gibt bei einigen dieser Systeme zwar die Möglichkeit eines „AP Tests“. Damit soll der Infrastruktur die Möglichkeit gegeben werden, im Fehlerfall, zum Zweck des Troubleshootings, einen Access Point in einen Client zu „verwandeln“ und die Infrastruktur zu testen. Diese Methode hat allerdings auch Nachteile. Der „testende“ Access Point kann zu dieser Zeit keinen „normalen“ Client bedienen, da er ja selbst „Client“ ist. Systeme, die in dieser Art und Weise arbeiten nennt man daher auch „integrated Monitoring/Sensoring/WIPS System“, da die Funktion in die Infrastrukturkomponenten integriert ist. Die Access Points nehmen den WLAN Traffic, den sie bearbeiten und weiterleiten, auf und analysieren diesen. Diese Systeme haben jedoch auch den Nachteil, dass die Access Points nicht dauerhaft das WLAN überwachen können. Die Hauptfunktion dieser Geräte ist und bleibt, Daten vom drahtlosen Client ins Netzwerk und andersherum zu transportieren. Somit können solche integrierten Systeme nur dann auf Fehler aufmerksam werden, wenn diese während des Daten-Transports geschehen oder in den sogenannten Off-Channel-Scans (in den kurzen Ruhephasen – während das WLAN nicht „arbeitet“).

Eine Alternative sind sogenannte „übergeordnete“ Systeme (Overlay). Diese Systeme arbeiten mit eigenständigen Sensoren, die keine direkte Verbindung zur eigentlichen Infrastruktur haben. Auch hier gibt es Vor- und Nachteile mit diesen Systemen. Der Vorteil ist, dass diese Systeme das Medium WLAN dauerhaft überwachen können. Jedoch können sie nicht den Datenverkehr „sehen“ und analysieren, der in der Infrastruktur übertragen wird. Zum einen kann ich somit 100 % der Zeit überwachen, aber nur einen sehr geringen Anteil des Datenverkehrs. Während die integrierten Systeme zumeist 100 % des Datenverkehrs analysieren können, aber dafür nur einen geringen Teil des Frequenzbandes. Einen Punkt kann man auf jeden Fall beiden Varianten bescheinigen. Beide Systeme sind äußerst hilfreich bei der Suche und Analyse von Fehlern. Und aus meiner Sicht gerade bei distribuierten Systemen eigentlich unverzichtbar, wenn man kein Personal vor Ort hat.

Die neue Gremlin-Falle

Aber ich möchte natürlich nicht nur einfach altbekanntes wiedergeben und noch mal anpreisen oder erklären. Es geht mir auch darum, neues zu betrachten und vielleicht damit neue Möglichkeiten aufzuzeigen. Uns wurde vor kurzem die Möglichkeit geboten, eine neue Variante eines Overla- Systems zu testen. Der Hersteller hat uns Komponenten seiner neuen Lösung zur Verfügung gestellt, um diese einem eingehenden Test zu unterziehen.

Im ersten Moment könnte man jetzt sagen, warum ist das etwas Besonderes und warum sollte man darüber extra sooo viel schreiben? Generell handelt es sich bei den Sensoren und den Funktionen um ein Cloud-basiertes System. Wie bereits vorweg festgestellt, sind Cloud-gestützte Systeme sehr gut geeignet, da die Analysefunktionen dank (Achtung Buzzwords) Big Data und AI-Funktionen in allen Cloudsystemen den großen Vorteil versprechen.

Aber was macht das Ding jetzt besonders gegenüber anderen Systemen? Warum lohnt es sich einen genaueren Blick auf dieses System zu werfen?

Ich möchte gleich vorweg geben, auch dieses System „kocht“ nur mit Wasser und ist kein „Gremlin-Detektor“. Jedoch gibt es nach diesem eingehenden Test einige Punkte, die mich durchaus beeindruckt haben und diesen Artikel entstehen ließen. Es schafft eine durchaus neue Transparenz für die wirkliche Performance und die Abläufe innerhalb der zu überwachenden oder zu analysierenden Infrastruktur. Ich habe bereits integrierte und „übergestülpte“ Systeme dargestellt. Bei diesen Sensoren handelt es sich prinzipiell ebenfalls um ein solches Overlay-System. Der Nachteil eines solchen Systems liegt normalerweise darin, dass es nicht in den Datenstrom „blicken“ kann. Und hier liegt der Unterschied zu den Systemen anderer Hersteller. Es kann prinzipiell eigentlich alles, was ein „normales“ Monitoring-System so tut. Die Sensoren überwachen das Frequenzband auf Störungen und Anomalien. Es meldet, sobald Probleme auftreten und natürlich sind Reporting und Forensik dank Cloud auch integriert. Allerdings gibt es bei diesem speziellen System einen kleinen Unterschied. Die Sensoren fungieren quasi auch als Client. Es ist möglich, sie mit den entsprechenden Credentials oder Pre-Shared-Keys zu versehen, um sich als Client aktiv im WLAN anzumelden. Damit kommt der eigentliche Unterschied zu herkömmlichen Monitoring-Systemen zum Tragen. Der Sensor sieht das WLAN aus Client-Sicht. Ich kann Performance-Messungen definieren, die mir Latenzen und Verfügbarkeit von kritischen Diensten und Services darstellen, messen und im Fehlerfall melden.

Ich will wissen ob ein Teams-Call zuverlässig möglich ist? Funktioniert DNS einwandfrei? Wie ist es mit Roaming oder Spektral-Analyse? Diese Tests sind dank der „Client-Sicht“ möglich. Und selbst der Paket-Trace (Header-Analyse) ist durch die Verbindung (auf drahtloser Ebene) mit der Infrastruktur als Troubleshooting und Analysefunktion verfügbar. Somit habe ich mit der Lösung zwar ein Overlay-System, aber trotzdem die Funktionen, die ich normalerweise nur innerhalb einer integrierten Lösung vorfinde. Durch diese Sichtweise des Systems (von der Client-Seite) hat es nach den vorgenommenen Tests einen entscheidenden Vorteil gegenüber den meisten auf dem Markt vorhandenen Systemen. Die meisten Hersteller-Systeme können entweder als Overlay-System das Spektrum überwachen oder als integrierte Lösung in den Datenstrom schauen. Letzteres geht jedoch nur mit den Komponenten des gleichen Herstellers und funktioniert nicht mit Fremdsystemen.

Das ist der entscheidende Vorteil dieser Lösung. Durch die Integration in die WLAN-Infrastruktur als Client, ist sie herstellerunabhängig und flexibel integrierbar. Genau dieser herstellerunabhängige Ansatz ist interessant. Vielleicht oder gerade, weil wir als Wireless.Consulting ebenfalls diesen herstellerunabhängigen Lösungsansatz darstellen wollen. Mit einer derartigen Sensorik und Monitoring-Funktion ist nach den ersten Tests auf jeden Fall ein sehr umfangreicher Blick in jede WLAN Infrastruktur möglich. Ob allein, oder vielleicht sogar noch gepaart mit einem guten Management (zentraler Controller oder Cloud-Lösung) ist die Jagd nach den kleinen Gremlins auf jeden Fall einfacher oder zumindest wesentlich effektiver. Diese Lösung kann permanent oder temporär genutzt werden. Entweder als dauerhafte zusätzliche Überwachung oder als temporäre Lösung bei sporadisch vorbeischauenden kleinen Technik-Monsterchen. Das lässt sich perfekt mit einer überwachten remote Fehleranalyse verbinden. Ein Techniker, der in definierten Zeiträumen einen oder mehrere Sensoren in einem problembehafteten Bereich überwacht und den Fehler damit eingrenzt. Damit sind unsere Kollegen wesentlich besser in der Lage eine Remote-Fehleranalyse durchzuführen. Es kann nicht absolut verhindern, dass ein Termin vor Ort notwendig wird, aber es hilft gerade bei diesen sporadischen Fehlern, die sonst über Wochen gesucht werden müssen. Somit kann ich den Kreis schließen zwischen dem performanten WLAN und dem Erhalt der Performance. Mit diesen Mitteln wird einem professionellen WLAN-Techniker professionelles Werkzeug an die Hand gegeben, um die Fehleranalyse oder Überwachung von Infrastrukturen zu verbessern. Es schafft eine größere Transparenz der Vorgänge “vor Ort” und innerhalb der überwachten Infrastruktur.

Autonome Access Points, alte Gerätegenerationen von WLAN-Komponenten oder auch hochmoderne Systeme können davon profitieren. Egal welcher Art Ihre Infrastruktur auch sein mag… solch ein Overlay-Monitoring-System ist immer integrierbar. Aber dieses verbindet die Sicht der Infrastruktur mit der des Clients und hat damit aus meiner Sicht aktuell ein Alleinstellungsmerkmal, da mir kein weiteres System bekannt ist, vor allem in Simplizität der Anbindung. Was vielleicht als zusätzlicher Faktor wichtig ist, gerade für temporäre Installationen und Fehleranalysen, dieses System ist autark und nicht mit der Infrastruktur des Unternehmens verbunden. Jedenfalls nicht so, dass es in Netze/VLANs mit weitergehenden Berechtigungen eingebunden sein muss. Es ist nicht in die Management-Ebene der Netzwerkinfrastruktur eingebettet und somit besteht keine Gefahr, dass unternehmenseigene Komponenten angegriffen oder gehackt werden können. All das hilft uns, Ihnen die kleinen Gremlins vom Hals zu schaffen. Sprechen Sie uns an,…

*Komisch, warum habe ich ein Bild mit drei Typen und ‚nem alten Krankenwagen im Kopf …* 😊