Aktueller Status WLAN: Arbeiten Juli/August

Fri Aug 7 02:07:06 CEST 2020

Hallo zusammen

Momentan beschaeftigt uns weiterhin fast ausschliesslich die aktuelle
WLAN Problematik rund um Video-Telefonie/MS-Teams und alle damit
verbundenen technischen und vorallem nicht-technischen Koordinations-
und Vermittlungsarbeiten mit/zwischen unserem externen Partner der das
Cisco Netzwerk betreibt.

In der ersten dieser zwei E-Mails moechten wir fuer die, die es
interessiert, ueber den Verlauf der Arbeiten seit dem letzten Status
Update informieren.

In der darauf folgenden zweiten E-Mail dann das Management-Summary mit
dem weiteren Vorgehen.

1. Was bisher geschah...
========================

vergl.
https://lists.bfh.science/pipermail/bfh-linux-announce/2020-July/000071.html:

  * seit dem 8. Juli ist das WLAN-Problem die erste, wichtigste und
    einzige Prioritaet als Auftrag an unseren externen Partner, der das
    Cisco Netzwerk betreut.

  * Falkenplatz 24 wurde als Standort ausgewaehlt, an dem das Problem
    ge-debuggt werden soll. Dazu wurde der Standort durch unseren
    externen Partner ausgemessen.

  * da nach der Ausmessung am 13. Juli kein weiterer Fortschritt
    absehbar war, war fuer den 21. Juli ein Eskalations-Meeting mit
    unserem externen Partner angesetzt.

...und nun die Fortsetzung.

2. Resultat Ausmessung Falkenplatz 24
=====================================

  * Urspruenglich wollten wir die Brueckenstrasse als Debug-Standort
    auswaehlen, dazu wurde dort ein Stockwerk durch unseren externen
    Partner ausgemessen.

    Nach 2 Arbeitstagen an der Brueckenstrasse haben wir aus
    organisatorischen Gruenden beschlossen, auf den Falkenplatz 24 zu
    wechseln (bei Services und Rektorat sind eher mehr Mitarbeitende
    waehrend der Vorlesungsfreien- und Ferien-Zeit vorort als an
    Departements-Standorten). Dabei wurde erst auf unsere explizite
    Nachfrage auch der Falkenplatz 24 durch unseren externen Partner
    nochmal neu ausgemessen (die zwei bisherigen Ausmessungen durch das
    vorherige Netzwerkteam stammen von 2016 resp. 2017 und sind aufgrund
    der in den Jahren danach erfolgten Umbauten nicht mehr
    aussagekraeftig).

  * Nach der Ausmessung am 13. Juli erhielten wir am 15. Juli die
    Auswertung auf total 37 Seiten, welche (neben Fotos von jedem
    einzelnen Accesspoint) lediglich zwei Parameter umfasste:

    - Signalstaerke (quantitativ; absoluter Wert "wie stark" das Signal
      unseres WLAN ist)

    - Signal-to-Noise Ratio (qualitativ; Verhaeltnis zwischen BFH WLAN
      Signalen und dem Umgebungsrauschen und "Echo"-Effekten im
      Gebaeude)

    Fuer beide Parameter sind wir laut Report vollstaendig im "gruenen"
    Bereich, d.h. es wurden keine Probleme aufgezeigt/erkannt.

    Als einzige (aber richtig und wichtige) Feststellung kam heraus,
    dass alle Accesspoints am Falkenplatz 24 falsch montiert wurden:
    es werden nur Modelle zur Deckenmontage (und damit
    Antennenpositionierung zur horizontalen Strahlung) eingesetzt
    die aber allesamt wandmontiert sind (d.h. die Antennen senden/
    empfangen vertikal).

  * Peter (sop2), seit Anfang Jahr in der BFH (Abteilung
    Projektmanagement) hat zufaelligerweise aus seinem vorherigen Job
    jahrelange Erfahrung im professionellen Ausmessen fuer WLAN mit
    der auch bei uns vorhandenen Software. Er hat mit den von unserem
    externen Partner erhobenen Messdaten mit der gleichen Software
    (Ekahau Pro) einen vollstaendigen Report (188 Seiten) generiert, der
    keine der von den externen gemessenen Parameter auslaesst. Dabei ist
    folgendes ohne weiteres Zutun direkt ersichtlich:

    - alle Accesspoints senden viel zu stark

      wenn zu viele Accesspoints zu dicht aufeinander mit zu starkem
      Signal senden, wird das Signal gestoert. Effekt: Signalstaerke und
      -anzeige am Geraet super ("drei von drei Balken"), trotzdem ist
      die Verbindung schlecht.

      Analogie: in einem Raum mit konstant schreienden Personen kann man
      eine andere in normaler Lautstaerke sprechende Person nicht
      verstehen.

    - alle Accesspoints senden auf dem gleichen Kanal

      Bei WLAN als Shared-Medium ist das zur verfuegungstehende
      Frequenzband in einzelne Kanaele aufgeteilt. So kann selbst wenn
      viele Accesspoints auf engem Raum vorhanden sind sichergestellt
      werden, dass es nicht zu Kollisionen kommt, weil sich die
      Accesspoints auf unterschiedliche, nicht ueberlappende Kanaele
      verteilen (in der Regel hats am Falkenplatz 24 mehr als
      3 Kanalueberlappungen an jedem Punkt im Raum, normal waere keine
      einzige Ueberlappung).

      Analogie: haetten unsere Autobahnen total nur eine einzige,
      gemeinsame Spur fuer beide Richtungen (statt normalerweise 2+2),
      gaebe es Dauerstau und man kaeme nicht vorwaerts.

    Die Konsequenz aus den beiden obigen Punkten ist dass das WLAN am
    gesamten Falkenplatz 24 fuer Video-Telefonie/MS-Teams komplett
    unbrauchbar ist.

    Ausserdem: Wegen der Falschmontage und daraus resultierenden
    falschen Strahlverhalten ist z.B. im 5. Stock der Accesspoint des
    Kellers(!) ersichtlich, nicht aber der Accesspoint im Nebenzimmer
    (was eigentlich ja toll ist und zeigt, wie gut die Accesspoints
    funktioneren fuer was sie gebaut wurden - leider werden sie bei uns
    nicht fuer das wofuer sie gebaut wurden eingesetzt).

    An dieser Stelle nochmal ein grosses Dankeschoen an Peter fuer seine
    Hilfe.

3. Eskalationsmeeting mit externem Partner
==========================================

Nach einem ersten, kurzen Teil mit Klaerung von einigen
arbeitsmethodischen Differenzen und der gegenseitigen Erwartungshaltung,
haben wir unseren externen Partner erlaeutern lassen, was aus ihrer
Sicht das Problem ist und was sie als weiteres Vorgehen vorschlagen.

Als Antwort erhielten wir ein ernuechterndes "wir haben bis jetzt noch
keine Ahnung was das Problem sein koennte". Als weiteres Vorgehen wurde
ein "jetzt muessen wir alles (sic!) einmal anschauen" vorgeschlagen.

(NB: in der Vorwoche war die vermutete Ursache im Kreis wechselnd und
ohne weder positives noch negatives Resultat entweder Routing/Switching
des BFH-Netzes, MS-Teams als Applikation von Microsoft resp. das
BFH-Deployment davon, die BFH-Windows Systemkonfiguration, oder dann der
Netzwerkkarten-Treiber von Intel in einem bestimmten HP Notebook-Modell,
etc.)

Wir haben darauf hin nochmal die *Fakten* welche wir alle, auch unser
externer Partner, seit Ende Mai kennen, festgehalten. Wir wissen
empirisch dass das Problem..

  * nicht Betriebssystem-spezifisch ist (reproduzierbar mit Linux,
    Windows und macOS)

  * nicht BFH-spezifisch ist (reproduzierbar mit BFH und BYOD Setups)

  * nicht Hardware-spezifisch ist (reproduzierbar mit vielen alten und
    neuen Geraeten von HP, Lenovo, Apple und weiteren)

  * nicht Applikations-spezifisch ist (reproduzierbar mit MS-Teams,
    Nextcloud Talk und Zoom)

  * nicht Firewall-spezifisch ist (reproduzierbar egal ob via Checkpoint
    oder Linux-Firewall)

  * kein fundamentales Wireless-Medium-Problem ist (wenn man Handy
    Hotspot nutzt oder mit WLAN zu Hause geht es ja, d.h. es ist nicht
    so dass Video-Telefonie generell nicht per WLAN ginge)

  * kein Bandbreitenproblem ist (max. 1 bis 2Mbit/s pro Client fuer
    Video-Groupcalls fuer Teams in HD laut MS Empfehlungen)

Fazit: in allen problematischen Permutationen ist das BFH WLAN (egal
welche SSID) der einzige gemeinsame Nenner.

Unser Bitten, dass doch jetzt, insbesondere gestuetzt auf unsere
vollstaendige Auswertung der Messdaten vom Falkenplatz 24, mit groesster
Wahrscheinlichkeit der RF-Layer (d.h. die "Funkschicht") angeschaut
werden muesse und nicht das "Debuggen" der Kabel-basierte BFH-Netzwerk-
infrastruktur weiterverfolgt wird, wurde mit "das kann schon sein, aber
wir koennen zu diesem Zeitpunkt noch nichts ausschliessen, wir muessen
weiterhin alles in Betracht ziehen" entgegnet.

Wir haben ausserdem ausdruecklich darauf hingewiesen, dass wir mit
grosser Sicherheit davon ausgehen, dass beim Wireless-Controller
saemtliche Funktionen zur automatischen Regulierung der Signalstaerke
und zur automatischen Kanalwahl und -verteilung abgeschaltet sind (was
wir spaeter noch verifizieren konnten, siehe weiter unten).

Wir haben als weiteres Vorgehen unseren externen Partner ueber folgendes
in Kenntnis gesetzt:

  * Falkenplatz 24 muss mit Deadline 31. Juli gefixt sein.

  * die von uns bis am Folgetag zu benennende Mehrheit der
    "Hauptstandorte" der BFH muessen bis zum 15. September gefixt sein.

  * unabhaengig davon werden wir eine Erst- und Zweitausmessung durch
    einen anderen externen Partner in Auftrag geben um u.a. ein un-
    abhaengiges Vorher/Nacher festhalten zu koennen und so den Effekt
    der jetzt folgenden Arbeiten am WLAN feststellen und beurteilen zu
    koennen.

4. Falkenplatz 24: Arbeiten bis zur Deadline
============================================

Seit dem 21. Juli arbeitet eine Person (ein Cisco WLAN Spezialist)
unseres externen Partners mit einem knapp 100% Pensum an der Loesung des
Problems am Falkenplatz 24 meistens vorort.

Dabei wurde primaer leider weiterhin versucht, das Problem reproduzieren
zu koennen und bis heute wurde den gemessenen und durch uns aufgezeigten
RF-Probleme (Signalstaerke und Kanalueberlappungen) trotz weiterhin
mehrmaligen Aufforderungen von uns keine Beachtung geschenkt.

Um besser Debuggen zu koennen und um globale WLAN Settings nur fuer den
Falkenplatz 24 vornehmen zu koennen ohne den Rest der BFH in (potentielle)
Mitleidenschaft zu ziehen wurde am 27. Juli ein weiterer Wireless-
Controller (Leihgabe externer Partner mit Kopie der Konfiguration der
BFH-Controller) durch unseren externen Partner aufgebaut.

In den Folgetagen wurden die Accesspoints vom Falkenplatz 24 auf den
neuen Wireless-Controller migriert. Danach wurden beim weiteren Debuggen
viele Burst von sogenannten RTS Frames entdeckt.

Bei RTS (Ready-to-Send) und CTS (Clear-to-Send) Frames handelt es sich
um ein aehnlich wie den Meisten bekannten SYN/ACK bei TCP um ein
Verfahren zur Signal resp. Empfangsbereitschaft. Anderst als bei TCP
wird RTS/CTS bei WLAN allerdings fuer Collison-Avoidance benutzt.

D.h. konkret: bei schlechter WLAN Qualitaet kann durch gesteuertes
Senden/Empfangen und kontrolliertes "Stillhalten" der/aller Netzwerk-
teilnehmenden, via RTS/CTS, wenigsten "etwas Netzwerk" sichergestellt
werden (die genaue Erklaerung sprengt hier den Rahmen und kann im
Internet nachgelesen werden).

Offenbar gibt es in diesem Zusammenhang aktuell einen Software-Bug
(CSCvu61194) der nur mit den etwas aelteren Cisco 2800/3800 Accesspoints
auftritt, wo dies dann nicht richtig funktioniert. Murphy's Law folgend
werden natuerlich am Falkenplatz hautpsaechlich 2800er Accesspoints
eingesetzt :)

Unser externer Partner hat dies korrekt entdeckt und, da dies von Cisco
in den letzten Wochen mit einem Vorab-Release gefixt wurde, fuer den
Falkenplatz 24 via den zusaetzlichen Wireless-Controller behoben.

Unserer Meinung nach ist damit das Symptom mit abbrechender Video-
Telefonie zwar etwas gemildert (= die Collison-Avoidance funktioniert
jetzt wieder), die Ursache (= schlechtes WLAN-RF das die Collisions
hervorruft) aber nicht behoben. Laut der ueberwiegenden Mehrheit der
Rueckmeldungen der Mitarbeitenden vom Falkenplatz 24 funktioniert
MS-Teams jetzt besser als vorher.

5. Falkenplatz 24: Arbeiten nach der Deadline
=============================================

Wir gehen mit unserem externen Partner einig dass die WLAN Probleme am
Falkenplatz trotz Verstreichen der Deadline noch nicht geloest sind.
Diese Woche haben sie sich jetzt mit QoS (Quality of Service)
auseinandergesetzt.

QoS ist ein Mechanismus bei welchem bei einem 100% ausgelasteten
Netzwerk (idR Kabel) bestimmt werden kann, welche Pakete ein
Netzwerkgeraet (idR Switches und Router) zugunsten von welchen anderen
Paketen verwerfen darf.

An der BFH machen wir konzeptionell kein QoS, sondern machen Over
Provisioning. D.h. anstatt die "Buechse der Pandora" (loest 1 Problem,
dafuer hat man 10 neue Probleme) von QoS aufzumachen und fuer jegliche
Applikationen aufwendig/fehleranfaellig auf allen Geraeten QoS zu
konfigurieren, stellen wir einfach sicher, dass es nie zu einer 100%
Auslastung der Netzwerk-Infrastruktur kommt, konkret: wenn die Leitung
zu schmal ist, gibts ein dickeres Kabel und gut ist. Dies ist ein seit
mind. der Zentralisierung der IT-Services ab 2011 gueltiger,
fundamentaler (und richtiger) Grundsatz, der das Netz mit gleichen oder
nur minimalen hoeheren Gesamtkosten fuer alle signifikant viel
effektiver und effizienter macht.

Da wir bereits wissen dass es sich generell nicht um ein Bandbreiten-
Problem handelt (es wurden bei allen Messungen des externen Partners
auch keine Bandbreiten-Probleme gefunden), und konkret beim Falkenplatz
24 es sich auch gar nicht um eines handeln kann (es sind noch lange nicht
alle Mitarbeitenden wieder gleichzeitig vorort am Arbeiten wie vor
Corona; die Probleme treten auch auf wenn die betroffenen Personen
alleine am Standort sind; auch bei Vollbelegung sind nicht mehr Personen
vorort als vor Corona, und da gab es nie Bandbreitenprobleme), kommt QoS
selbst wenn es konfiguriert waere nie zum Einsatz weil es nie einen Link
mit 100% Auslastung hat und ist somit nutzlos.

Wir konnten im Meeting heute Vormittag unseren externen Partner davon
ueberzeugen, QoS mindestens fuer erste mal nicht mehr weiterverfolgen
zu wollen. Anstatt dessen wird jetzt die Abdeckung mal als naechstes
angeschaut...

6. Wireless Controller Konfiguration bzgl. Automatismen
=======================================================

Im Gegensatz zum einzelnen WLAN Accesspoint den man von zu Hause kennt,
werden in der Regel WLAN Accesspoints im Business-Umfeld durch einen
zentralen Controller gesteuert.

Dies darum weil in grossen, zusammenhaengenden WLAN-Installationen ganz
andere Anforderungen bestehen, hier ein Beispiel zur dynamischen
Kanalwahl:

  * Gegeben sei ein BFH Gebaeude das mit WLAN erschlossen ist. Ein neuer
    Nachbar zieht ein und sein Accesspoint sendet "ploetzlich" auf dem
    gleichen Kanal wie einer unserer eigenen Accesspoints.

  * Im Consumer-Bereich wird ein "traditioneller" Accesspoint wegen
    Kollisionen jetzt nicht mehr sinnvoll funktionieren (oder nur noch
    in unmittelbarer Naehe). Abhilfe gibts nur durch manuelle
    Umkonfiguration des Accespoints auf einen anderen, freien Kanal.

    Alle eigenen Accesspoints nebendran muessen ggf. ebenfalls
    umkonfiguriert werden, falls diese durch die Aenderung des ersten
    Accesspoints nun selbst in eine Ueberlappung zu diesem gekommen
    sind.

    Alternativ koennte man auch versuchen, den Nachbar zu ueberzeugen
    dass er seinen Accesspoint auf einen anderen Kanal wechselt. In
    jedem Fall gibts ueber eine nicht unerhebliche Zeit Einbussen in der
    WLAN Verfuegbarkeit.

  * Im Business-Bereich ueberwacht ein Stueck Software (= ueblicherweise
    in der Form eines Servers resp. Wireless Controller genannte
    Appliance) staendig moegliche Kanalueberlappungen und wird unseren
    Accesspoint selbststaendig auf einen freien Kanal umkonfigurieren.

    Alle anderen eigenen Accesspoints werden, sofern noetig, ebenfalls
    automatisch umkonfiguriert so dass ueber alle Accesspoints als
    ganzes keine Kanalueberlappungen vorhanden sind.

    Die Implikationen eines nicht vorhandenen Automatismus in diesem
    Beispiel liegen auf der Hand, insbesondere dann wenn es sich nur um
    temporaere "Nachbaren" (= Stoerquellen) handelt (was zum Beispiel,
    wenn der Nachbar nur immer eine Stunde am Tag seinen Accesspoint
    einschaltet und auf einem immer anderen Kanal wechselt - da waere
    ohne WLAN Controller der Aufwand gigantisch und das Ausmass der
    Service-Einschraenkung vor, waehrend und nach den
    Konfigurationsarbeiten erheblich).

Oder anderst: WLAN ist nicht wie das frueher mal war, eine "statische"
Installation die man einmal ins Gebaeude einpassen kann und fertig.
Eine WLAN-Infrastruktur ist staendig der "Umwelt" ausgesetzt und muss
sich dieser konfigurativ automatisch, flexibel, selbststaendig und
unmittelbar anpassen.

Die beiden Cisco Controller welche fuer die Verwaltung/Steuerung der
Accesspoints an der BFH verwendet werden, stellen viele solcher
Automatismen zur Verfuegung und standartmaessig wuerde man diese auch
immer eingeschaltet lassen. Wie wir festellen mussten sind diese
automatischen Stoerungsbehebungsfunktionen und Stoerungsmilderung/
umgehungsstechniken auf den BFH WLAN Controllern abgeschaltet worden -
die WLAN Parameter wurden vom vorherigen Netzwerkteam offenbar fuer alle
Standorte und Accesspoints von Hand gemacht/gepflegt.

Wir vermuten, dass wenn man diese Automatismen einschaltet, wohl
viele/die meisten der WLAN Probleme automatisch verschwinden werden.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science