Aktueller Stand zur "WLAN Problematik"

Mon Jul 20 06:57:08 CEST 2020

Hallo zusammen

Auch in den letzten Wochen beschaeftigt uns WLAN weiter. Hier der
aktuelle Stand zu den aktuellen Problemen im Zusammenhang mit
Video-Telefonie/MS-Teams und WLAN.

1. Ausgangslage
===============

Wir haben am 1. Mai die Verantwortung fuer das Gesamtnetzwerk
uebernommen. Dabei speziell ist, dass wir das Cisco-basierte Netzwerk
(im Gegensatz zur Arista-basierten Science DMZ) nicht selber betreiben,
sondern dies ein externer Partner uebernommen hat. D.h. wir sind hier
untypisch fuer uns nur in der administrativen Vermittler- und
Koordinationsrolle und koennen keine technischen Arbeiten selbst
durchfuehren.

2. keine generellen WLAN Probleme mehr
======================================

Durch die Optimierungen der WLAN Parameter durch unseren externen
Partner am 12. Mai hatten wir *generelle* Verbindungsabbrueche/schlechte
WLAN Signalqualitaet, d.h. dies hat *alle* Standorte und *alle*
Anwendungen betroffen.

Wir haben diese WLAN Parameter-Aenderungen schrittweise und kontrolliert
rueckgaengig machen lassen, so dass ab 16. Juni *keine generellen* WLAN
Probleme mehr vorliegen. Die aktuellen WLAN-Parameter sind nun wieder
die selben seit mind. Ende 2018, d.h. das Wireless-Netz ist wieder
genauso stabil/im gleichen Zustand wie vor dem 12. Mai.

Zum Hintergrund dazu, siehe:

https://lists.bfh.science/pipermail/bfh-linux-announce/2020-June/000067.html

3. neue Problem-Meldungen mit MS-Teams
======================================

Nach dem Revert der WLAN-"Optimierungen" haben wir fuer eine Woche keine
WLAN Problem-Meldungen mehr erhalten. Seit dem 22. Juni, von zuerst
wenigen, einzelnen Nutzenden erhalten wir Meldungen ueber
Verbindungsabbruecke oder schlechte Verbindungsqualitaet bei
Video-Telefonie mit MS-Teams.

Ungluecklicherweise muss jede einzelne Problem-Meldung auch einzeln
angeschaut werden da die Gruende sehr individuell sind. Diese reichen
ueber Fehlbedienung der Nutzenden, andere Client-Probleme,
WLAN-Abdeckungsprobleme und schliesslich WLAN-Infrastruktur-Probleme.

Auch im optimalen Fall braucht das Zeit. Aufgrund der nur partiellen
Anwesenheit der Nutzenden und zusammen mit dem Fakt dass wir das WLAN
nicht selber betreiben und der externe Partner rund 60% (d.h.
grundsaetzlich immer nur Vormittags) da ist, sind die Feedback-Loops
zusaetzlich verlangsamt.

Die aktuellen Probleme lassen sich auf die folgenden zwei Typen
einteilen/unterscheiden.

3.1 WLAN Abdeckung/Signalqualitaet
----------------------------------

Durch die gesteigerte Nutzung von MS-Teams und Video-Telefonie im
Allgemeinen sind die Anforderungen an die WLAN-Abdeckung und die
Signalqualitaet deutlich hoeher als dies frueher der Fall war. D.h. in
Randzonen um Accesspoints wo die aktuelle Verbindungsqualitaet
problemlos normale Office- und Internet-Arbeiten ermoeglicht, reicht
diese fuer Video-Telefonie nicht mehr aus.

Unabhaengig davon wird durch die verteiltere Arbeitsweise auch ganz
ausserhalb des bisherigen WLAN-Erschliessungsbereiches eine Verbindung
durch unsere Nutzenden erwuenscht. In diesen Faellen muss nicht wie oben
eine Verbesserung, sondern eine "Ersterschliessung" mit WLAN gemacht
werden. Diese zeigt sich durch allgemeine nicht-Verfuegbarkeit von WLAN
(d.h. generell schlechte Verbindung unterhalb 60db womit auch fuer
normalen Office- und Internet-Traffic nicht sinnvoll gearbeitet werden
kann).

Wir haben einige dieser Probleme gefunden und haben/werden weiter
zusaetzliche Accesspoints montieren lassen. Das ist eine
Standard-Aktion, kann zeitnah gemacht werden und ist grundsaetzlich
unproblematisch.

3.2 Spezifische Video-Telefonie Probleme
----------------------------------------

Seit dem 1. Juli erhalten wir auch Problem-Meldungen mit MS-Teams von
Nutzenden die "direkt neben einem Accesspoint" arbeiten. D.h. dort
handelt es sich nicht um Abdeckungsprobleme sondern um ein *neues* Problem.

3.2.1 Brueckenstrasse
~~~~~~~~~~~~~~~~~~~~~

Da wir in der Woche vor dem 1. Juli an der Brueckenstrasse einen
zusaetzlichen Accesspoint haben montieren lassen und genau von dort
trotzdem weiterhin Probleme gemeldet wurden, haben wir uns zuerst auf
die Brueckenstrasse als Standort zum weiteren Debuggen fokusiert.

Die betroffenen Bueros wurden am 8. Juli durch unseren externen Partner
WLAN-technisch ausgemessen, was leider keine weiteren Erkenntnisse
gebracht hat. Da die Brueckenstrasse generell wenig besucht wird, haben
wir am 10. Juli den Fokus auf den Falkenplatz 24 verschoben (das
Verwaltungs- und Administrationspersonal ist aktuell tendenziell eher
anwesend), mit der Absicht die Problemloesung beschleunigen zu koennen.

3.2.2 Falkenplatz 24
~~~~~~~~~~~~~~~~~~~~

Der Falkenplatz 24 wurde durch unseren externen Partner daraufhin am
13.7. vollstaendig ausgemessen. Dabei wurde entdeckt, dass im 2. OG
keiner der beiden Accesspoints lief (beide APs waren seit dem letzten
Firmware-Update Anfang Jahr haengen geblieben). Sensibilisiert fuer
dieses Problem hat unser externer Partner mind. 8 weitere Accesspoints
an anderen Standorten in diesem Status entdeckt, die teilweise seit 6
Monaten nicht mehr liefen (der Status ist auf dem WLAN-Controller
ersichtlich).

Ab jetzt wird unser externer Partner woechentlich manuell pruefen, dass
es keine "haengenden" Accesspoints gibt (Tipp fuer den Vorort-Support:
"haengende" Accesspoints erkennt man an den in allen Farben abwechselnd
blinkenden LEDs; einmal Power-Cycle fixt das Problem).

Seit der Ausmessung des Falkenplatz 24 gehts jetzt leider irgendwie
nicht wirklich weiter - morgen Dienstag gibts dazu ein
Eskalations-Meeting mit unserem externen Partner.

4. Was wir bisher wissen
========================

Das neue Problem ist insofern neu, als dass es nichts mit den
WLAN-Parametern vom 12. Mai zu tun hat und das es, in einigen Faellen
zumindest, nicht ein Abdeckungsproblem alleine ist. Diese Unterscheidung
ist wichtig fuer die Eingrenzung des Problems.

Das Problem ist auch so nicht neu, da es aufgrund des
Konfigurationsstands des Cisco-Setups schon immer bestehen muss, aber
erst aufgrund der grossflaechigen Nutzung *Vorort* von MS-Teams fuer
Video-Telefonie jetzt zum Vorschein kommt (waehrend des Lockdowns haben
zwar auch alle grossflaechig MS-Teams verwendet, aber nicht uebers BFH
WLAN sondern von zu Hause aus im Home-Office).

Was wir bisher empirisch wissen:

  * Das Problem ist platformunabhaengig, wir koennen es mit MS-Teams
    unter Windows und Linux gleichermassen reproduzieren.

  * Das Problem ist nicht BFH spezifisch, wir koennen es mit BFH-Clients
    und Bring-your-own gleichermassen reproduzieren.

  * Das Problem ist nicht MS-Teams spezifisch, wir koennen es mit
    Nextcloud Talk gleichermassen reproduzieren.

  * Das Problem ist nicht abhaengig von der Linux- oder Checkpoint-
    Firewall, sobald Kabel eingesteckt wird funktioniert die Verbindung
    problemlos[*].

  * Das Problem ist nicht fundamental Wireless-spezifisch, sobald ein
    Handy-Hotspot oder eine andere WLAN-Infrastruktur benutzt wird,
    funktionieren die Verbindungen problemlos.

Der einzige gemeinsame Nenner aller problematischen Permutationen ist
das BFH-WLAN.

Irgendetwas beim BFH-WLAN ist also offenbar "anderst" als bei allen
anderen WLANs, ob zu Hause oder bei anderen Grossinstallationen. Die
Loesung muss sein, dass wir diesen Unterschied finden, das BFH-WLAN
"ent-BFH-isieren" und "gleich(er)" machen wie sonst ueberall. Was genau
"anderst" ist, wissen wir noch nicht.

Wir bitten um Nachsicht fuer die untechnische Formulierung - das
Cisco-Setup ist fuer uns eine vollstaendige Blackbox.

5. Weiteres Vorgehen
====================

Seit dem 8. Juli ist das WLAN-Problem die erste, wichtigste und einzige
Prioritaet als Auftrag an unseren externen Partner.

Sobald es neue Erkenntnisse gibt, werden wir informieren und hoffen auf
eine zeitnahe Loesung des Problems.

Besten Dank fuers Verstaendnis.

Gruesse,
Daniel

[*] Wir haben in einzelnen Faellen gehoert dass die Probleme auch nach
    Einstecken des Kabels weiterhin bestanden haetten. Da wir es selbst
    reproduzierbar durch Kabeleinstecken beheben koennen, gehen wir
    davon aus, dass a) in den 2 so gemeldeten Faellen (von insgesamt ca.
    50 Tickets) entwender Software-technisch nicht korrekt aufs Kabel
    gewechselt wird, ein lokales Problem besteht (Client, Dockingstation
    oder Netzwerk-Infrastruktur/Verkabelung). Diese 2 so gemeldeten
    Faelle gehen wir separat an.

-- 
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