 Ich werde heute die Vortrag halten, build yourself a SNMP replacement and make SSH pay for it. Und ja, so die grobe Gliederung allgemeines. Wer bin ich? Wie sieht das Umfeld aus, indem ich das ganze programmiert habe, gebastelt habe. Ganz kurze Ausflug zu SNMP Grundlagen und zu Enterprise WLAN. Dann, was habe ich benutzt? Die Hardware, die Software. Und dann kurz, dann was länger zur Umsetzung. Was für die Anfänge waren. Wie es jetzt momentan produktiv läuft, was für Probleme sind. Und was ich dazu gerne noch basteln möchte. Erstmal über mich. Ich bin Heiko Borchers. Ich mache momentan meine Ausbildung zum Fachinformatik-System Integration an der Uni Düsseldorf. Ich habe vorher versucht, Informatik zu studieren. Hat nicht ganz geklappt. Und während des Informatikstudiums habe ich noch an einem Institut an der Uni Bonn alles gemacht, was an viel an IT. Die Heinrich-Hahn-Universität selber ist eine relativ große Campus-Universität. Aktuell eingeschrieben sind ca. 30.000. Ich meine, es sind 35.000. Genaue Zahlen sind da immer schwierig. Im Schnitt haben wir 10.000 WLAN-Diversities am Tag. Und da war ein sehr, sehr bunten Zoo an WLAN-Hardware, die vom G-Standard mit 2,4 GHz bis zum aktuellen AC-Standard so einmal alles abdeckt. Und das Ganze sind 900 APs auf 1,3 Quadratkilometern. Die SNMP-Grundlagen, simple Network Management Protokoll, erlaubt eigentlich die Überwachung von allem, was irgendwie einen Ethernet-Anschluss hat oder teilweise auch ein WLAN hat. Die Vorteile sind, es ist wirklich ziemlich einfach zu konfigurieren auf Hardware-Seite. Es ist herstellerübergreifend und es ist so relativ strukturiert, wenn man irgendwas nachimplementieren möchte, was jetzt so nicht drinnen ist. Nachteile. Es ist langsam, sehr langsam teilweise bei uns, da komme ich gleich noch zu. Es ist teilweise fehlerbehaftet und Sicherheit und SNMP ist schwierig. Aber Trump hat etwas anderes zu sagen. Er hat dann zu den Grundlagen von Enterprise-WLAN. Es läuft ein bisschen anders als beim WLAN zu Hause, aber das ist ja auch kein Wunder. Man hat je nachdem mehrere Hundert Access Points, da hat kein Atmenlust, die alle per Anzug konfigurieren. Deswegen hat man normalerweise einen WLAN-Controller, der sich um die Steuerung der Access Points und die grobe Konfiguration kümmert. Dieser WLAN-Controller funktioniert entweder oder, wie in unserem Fall, funktioniert er eher nicht. Wie gesagt, 900 APs per Hand konfigurieren. Die verwendete Hardware. Ein wunderschönes Bild aus unserem Rechenzentrum. Das ist der HP Unified 870 Controller. Er hat auch gewisse Ähnlichkeiten zu Trump. Er ist teilweise langsam. Er ist teilweise nicht sonderlich intelligent. Er stürzt teilweise gerne mal ab, beziehungsweise ist es einfach nicht mehr erreichbar. Das könnte ich ihm noch beibringen. Der Access Point Wildwuchs, den wir bei uns haben, wäre ja schön, wenn wir nur einen APA-Typ hätte. Wir haben insgesamt fünf verschiedene Access Point-Typen, vom ältesten angefangen bis zu ja, das ist die aktuelle Generation. Die können dann auch WLAN-A10 mit 5 Gigahertz. Die hätten wir eigentlich ganz gerne überall, aber kosten halt auch Geld. Die verwendete Software für das ganze Projekt. Ich glaube, es versucht mit HP IMC. Ich habe es versucht mit Observium. Splank ist gerade das Experiment zusammen mit dem Partenscript, was ich geschrieben habe. So sieht das Standard HP IMC aus. Sieht eigentlich relativ schön aus. Gibt auch viele Infos. Man sieht hier in dem schönen grünen Kreis, das sollte eigentlich mir die WLAN-Clines nach MAC-Adressen und nach Herstellern aufschlüsseln. Das funktioniert mal, mal funktioniert es nicht. Meistens nach einem F5 funktioniert es wieder. Aber HP sagt selber, WLAN im IMC ist noch beta und funktioniert auch nicht so ganz. Dann haben wir Observium im Einsatz. Das liefert eigentlich auch schöne Daten. Hier die Kurve sieht man die Anzahl an WLAN-Clines, die zu dem gewissen Zeitpunkt online waren. Man erkennt sehr schön, wann Wochenende war. In der Jahresübersicht erkennt man auch sehr schön, wann Semesterferien sind und kann dementsprechend teilweise auch planen. Da muss ich sagen, ob Observium funktioniert gut. Wenn es dann mit den SNMP-Daten vom Controller klar kommt, wird es mal der Controller nicht aufgibt. Das Neuste, was wir jetzt einsetzen, ist Splunk, ein kommerzielles Tool, mit dem man große Datenmengen verarbeiten kann und sehr gute Auswertungen machen kann. Mit Splunk habe ich auch meine Monitoring-Ansätze mit zusammengebastelt programmiert. Der Produktiveinsatz. Weil SNMP nicht so ganz funktioniert, grab them by the SSH. Meine Anfänge waren, dass ich ein Skript regelmäßig Befehle an den Controller abschicken lassen. In dem Skript waren einfach nur drei SSH-Befähle. Mit welchem Access-Point ist die MAC-Adresse gerade verbunden? Wie ist die Signalstärke? Und wie sind die Datenraten? Und das dann in einem wählbaren Intervall. Da habe ich dann einfach mal geguckt, wie sieht das eigentlich aus, wenn ich mich einen Tag über den Campus bewege und mein Handy dabei habe. Die Erweiterung, die jetzt auch im Produktiveinsatz ist, ist ein Skript, was mir automatisch alle Access-Point erfasst, von allen Access-Points eine Spektrumanalyse macht. In der habe ich dann, wie viele Störsender sind auf dem jeweiligen Kanal, auf dem wir Access-Point fungen. Wie ist die minimale Signalstärke und wie ist die durchschnittliche Signalstärke in der letzten Minute gewesen? Und es gibt mir die Info zu allen Kleins, die gerade verbunden sind, einmal pro Stunde. Das ist noch relativ fein, dass man theoretisch alle Nutzer der Uni verfolgen könnte. Aber die Anonymisierung ist auch schon drinne, die macht es blank später automatisiert. Das ist ein kleiner Ausschnitt aus dem Code. Das Ganze funktioniert so, wenn ich es versuchen würde, per SNMP abzufragen, laufe ich in Timeouts von teilweise, läuft der Controller eine halbe Stunde, teilweise eine Dreiviertelstunde, um alle SNMP-Daten abzugeben. Per SSH braucht das Ganze fünf Minuten. Und das auch nur, weil der Controller das Ganze in menschenlesbarer Zeit versucht, auf dem Bildschirm auszugeben. Wenn er das Ganze einfach direkt ausgeben würde, was er im Speicher hat, würde das Ganze in wenigen Millisekunden laufen. Per SNMP haben wir teilweise eine CPU-Load auf dem Controller von 50% bis 100%. Per SSH liegt die CPU-Load bei 5%. Das sind die Daten, die der Controller mir ausliefert. Das ist wirklich nur einmal die absoluten Basics. Name, Status, welcher Access Point es ist vom Modell her. Und die Seriennummer. Und dann in einem separaten SSH Befehl und in einer separaten Tabelle steht dann der AP-Name, die RadioID 1 für 5 Gigahertz, 2 für 2,4 Gigahertz, Channel und die Air-Colities. Und aus diesen Tabellen wird dann in dem Script, die werden zusammengefasst und es wird ein JSON-Objekt generiert, was sich dann an die verschiedenen Monitoring-Systeme weiter schicken kann. Das ist standardkonformes. JSON frisst eigentlich ziemlich alles. Ja, die Probleme, eben schon kurz angesprochen, der Datenschutz. Momentan, zum Anfang des Skrips wäre es möglich gewesen, jeden einzelnen Studenten zu tracken, weil jede MAC-Adresse aufgezeichnet wird und die Informationen von jedem Access Point. Das wird jetzt direkt beim beim Lauf des Skrips werden die MAC-Adressen nur noch auf die WenderID beschränkt und die Device-IDs vom Gerät werden ausgeext, sodass es dazu keine Identifizierbarkeit kommt. Ich sehe nur noch, auf dem Access Point sind fünf Apple-Devices und drei Geräte von anderen Herstellern. Die Dauer des Skrips hatte ich eben angesprochen. Es läuft momentan fünf Minuten ungefähr, weil der Controller mir das textbasiert ausgibt und den Text nicht als einen Blog gibt, sondern immer in 5.000 bytes am Stück. Ein Problem ist auch noch die Zuverlässigkeit der Controller. Das passiert teilweise gerne mal, wenn der Controller versucht, per SSH zu erreichen und er einfach sagt, nichts. Man kriegt dann einfach nur ein Connection Refused oder IP Address Unknown. Meine Ideen für die Zukunft sind, das vielleicht auch für OpenWRT umzusetzen, dass man sich relativ einfach ein schönes WLAN der Sport zu Hause basteln kann, dann die Daten der Access Points mit der Auslastung via Splank schön auf eine Karte des Campuses zu packen, das wir hat man es jederzeit wissen, welcher Access Point ist gerade viel belastet, welcher als wenig belastet und eventuell noch ein bisschen mehr Schutz für die Privatsphäre. Wenn Leute ihren WLAN Zugang falsch konfiguriert haben in Adiorome und als anonyme Identität auch ihren Nutzanahmen verwendet haben, steht halt der Nutzanahme bei uns teilweise noch in den Logs mit drin. Ja, es geht bei Windows auch anders. Ja, dann vielen Dank für eure Aufmerksamkeit. Wenn Fragen sind, stellt Fragen. Die Frage war, ob es eventuell noch schneller geht, wenn ich die Daten anders vom Controller zurückgeben lasse. Das habe ich mir auch schon überlegt, eine mögliche Implementierung ist, ich könnte mir das vom Controller auch als TFTP über TFTP ausgeben lassen, dann kriege ich eine TFTP-Datei zugeschickt, dann habe ich aber wieder das Security-Problem. TFTP ist unverschlüsselt, genauso wie SNMP. Deswegen habe ich das noch nicht implementiert, das wäre jetzt noch eine Option. Was war denn das Ziel, was ihr da folgt, da wollte ich dir einfach nochmal so ganz generell eine Statistärm, also wie viele Kleinen sie zu welcher Zeit oder gab es einen Grund dafür, da irgendwie tiefer statistisch einzusteigen? Also das Ziel des Ganzen war wirklich du hattest nach dem Ziel des Ganzen gefragt, ob wir jetzt nur die Basisinformationen haben wollten oder tiefer einstellen wollten. Das Ziel war wirklich, wir könnten diese Daten per SNMP bekommen, dann müssen wir aber eine halbe Stunde warten und das Ganze zu beschleunigen, weil wir das WLN wirklich an der Uni besser machen wollen und dafür brauchen wir teilweise auch diese tiefen Auswertung mit welchen Signaltstärken arbeiten die Kleins, welche Datenübertragungsraten bekommt jeder Klein noch, wie sieht die A-Time aus? Und wenn wir das per SNMP abfragen wollten, würde der Controller das nicht mitmachen. Dann habe ich hier noch meine Quellen, die Slides werde ich auch später noch online stellen, genauso wenn das Skript so zuverlässig läuft, dass man das veröffentlichen kann, würde es auch auf GitHub stehen. Das werde ich dann auch noch in den Slides ergänzen, wo es auf GitHub steht, wenn man es sich angucken will oder selber debacken will. Später ist es, wenn ich die Implementierung für OpenWAT drinnen habe, wird es auf jeden Fall Open Source sein.