Bericht zum WLAN-Ausfall an der Brueckenstrasse am 15. und 16.11.

[Daniel Baumann]

Hallo zusammen

Kurzfassung
===========

  * am 15.11. Nachmittags (ca. 14 bis 16 Uhr) und am 16.11. Vormittags
    (ca. 9 bis 11 Uhr) waren in der Brueckenstrasse die Mehrheit der
    WLAN Accesspoints offline.

  * Grund fuer den Ausfall war das Volllaufen der DHCP Pools im AP
    Transport-Netz, wahrscheinlich ausgeloest durch Nacharbeiten im
    Rahmen des Core-Ersatzes Ende der Vorwoche.

  * wir haben die DHCP Pools fuer die Brueckenstrassem Mittwoch
    Abend/Nacht aufgeraeumt und verifiziert, dass das Problem nicht mehr
    auftreten kann.

  * alle anderen 15 Pools haben wir gestern und heute proaktiv
    ebenfalls bereinigt, so dass das gleiche Problem an keinem Standort
    auftreten kann.


Hintergrund
===========

1. DHCP
-------

  * WLAN APs ziehen per DHCP eine Adresse aus einem Pool in einem
    Subnet.

  * Auf den neuen DHCP Servern haben wir wie schon erwaehnt eine kurze
    Lease-time (10min), d.h. alle Geraete ziehen spaetestens alle 10min
    eine neue Adresse (oder verlaengern die die sie haben, ignorieren
    wir der Einfachheit halber):

    - Client verlangt eine Adresse
    - Server bietet eine freie Adresse an
    - Client bestaetigt die Annahme der vom Server genannten Adresse
    - Server merkt sich Adresse fuer Dauer der Lease-time als benutzt

  * In der speziellen Situation dass Traffic zum DHCP funktioniert,
    nicht aber der Rueckweg, tritt folgendes ein:

    - Clients verlangt eine Adresse
    - Server bietet eine freie Adresse an
    - Client bekommt keine Antwort vom Server
    - Server merkt sich die Adresse fuer eine "kurze" Dauer als benutzt

    - Client verlangt nochmals eine Adresse
    - Server bietet eine neue, freie Adresse an
    - [...]

  * Die "kuerzere" Dauer die eine nicht-bestaetigte Adresse als benutzt
    markiert ist, ist zwar viel kuerzer als die Lease-time, reicht aber
    bei uns aus um bestimmte DHCP Pools fuer WLAN APs volllaufen zu
    lassen, weil:

    - einige Transport-Netze fuer die WLAN APs sind historisch sehr
      knapp bemessen und sind nicht viel groesser als gerade die Anzahl
      der APs darin

    - da die meisten Geraete (und so auch die WLAN APs) mehrfach
      probieren eine Adresse zu erhalten, werden von einem Client
      kurzfristig mehrere Adressen "verbrannt", bis er eine kurze
      Pause einlegt und es wieder (mehrfach) versucht

    - die kurze Lease-time laesst die anderen WLAN APs sehr schnell
      eine neue Adresse holen. Wenn keine mehr frei sind fliegen auch
      sie aus dem Netz und beschleunigen den Ausfall in einer kleinen
      Kettenreaktion

  * Vorteil dafuer ist, dass das Problem schnell und isoliert entdeckt
    werden kann. Nach manuellem Freigeben der "blockierten" Adressen
    im DHCP Server erholen sich die WLAN APs innerhalb von ein paar
    Sekunden.

  * Ebenso einfach ist auch die "richtige" Loesung: alle WLAN APs mit
    fixer IP Adresse im DHCP reservieren, so kriegt jeder AP immer
    seine eigene Adresse exklusiv, so dass selbst ein Volllaufen des
    Pools keine Auswirkung hat.


2. Nacharbeiten Core-Ersatz
---------------------------

Wir haben fast die gesamte letzte Woche mit Nacharbeiten vom Core-Ersatz
in der Vorwoche verbracht und mussten noch einige Spezialfaelle und
Spezialnetze nachkonfigurieren. Hoechstwahrscheinlich muss es dabei zu
kurzen Unterbruechen (1 bis max. 2min) gekommen sein in der
Erreichbarkeit der DHCP Server.

Diese waren fuer die normalen Clients nicht spuerbar weil jeweils
ausreichend grosse DHCP Pools vorhanden sind und Clients etwas
"toleranter" sind als WLAN APs und bei nicht-erreichen des DHCP Servers
einfach die vorherige IP (laenger) behalten und weitermachen.

Warum genau der DHCP kurzzeitig nicht erreichbar war, wissen wir nicht
und laesst sich im Nachhinein nicht mehr herausfinden:

  - die alten Netze der Standorte sind via temporaere Core-Router-Ersatz
    an die BFH.ch Firewall und den Border angeschlossen

  - via Border koennen die neuen Netze in Cage A (und Cage B) erreicht
    werden (das solange bis die Standorte neues Netz kriegen und damit
    Anschluss an die Transit-Fabric erhalten).

  - im alten Netz sind die Verbindungen innerhalb der Standorte
    geswitched, d.h. wir sehen vom AP bis zum Standort-Router nichts
    (erste Blackbox), sowie vom Standort-Router via Core bis zur
    Firewall sehen wir ebenso nichts (zweite Blackbox).

  - Am Mittwoch Vormittag haben wirs vergeblich zu debuggen versucht
    und konnten aufgrund beider Blackboxen nichts sehen, wo genau die
    Pakete verschluckt wurden.

Das neue Netz ist (u.a. deshalb, wie jedes moderen Netz) ein
vollstaendiges Layer3 Netz (d.h. Routing und nirgendwo Switching von
Traffic der ein Netzwerk-Geraet verlaesst), so dass in einem solchen
Fall die Nachvollziehbarkeit und Debuggung einfach gegeben ist weil
jeder einzelne Hopp "eine Spur im Netzwerk" hinterlaesst.


3. Monitoring
-------------

  * Bisher war aus historischen Gruenden das Setup so, dass die APs eine
    beliebige Adresse zugewiesen bekommen.

    Das hatte den Vorteil von wenig(er) Aufwand/Konfiguration, hat aber
    den Nachteil dass grundsaetzlich kein sinnvolles Monitoring moeglich
    ist:

    - im DNS sind nur die APs ersichtlich, die online sind und sich
      ihren Namen via DDNS eintragen konnten.

    - im Cisco Wireless Controller und Cisco Prime die nur sehr
      rudimentaeres Monitoring ermoeglichen, sind nur APs ersichtlich,
      die online sind und sich ensprechend mit dem Wireless Controller
      verbinden konnten.

    - im richtigen Montoring (bei uns Icinga) bringts nichts die APs
      einzutragen wenn sich die IP Adressen aendern (gibt dauernd
      False-positive Ausfaelle; DNS-Eintraege fuer Monitoring zu
      benutzen ist keine sinnvolle Loesung).

    Faellt also ein Accesspoint aus, bemerken wir das an der kleineren
    Nummer der APs die online sind im Controller, wissen aber nicht
    welcher fehlt oder wo er fehlt.

  * Da neu alle APs statisch eine Adresse und dazugehoerigen DNS Namen
    haben, koennen wir automatisch die (dynamische) Liste der APs in
    Icinga monitoren, d.h.:

    - faellt ein AP aus, wissen wir welcher und wo er fehlt

    - kommt ein neuer AP dazu, wird er vollautomatisch in Icinga
      hinzugefuegt

    - wird ein AP abgebaut und seine Reservation entfernt, wird er
      vollautomatisch in Incinga ausgetragen

    Das ist, meiner Meinung nach zumindest, die Betriebs-
    Grundvoraussetzung. Damit wir das machen konnten, mussten wir zuerst
    DHCP Migrieren (sonst haetten wir 800 APs von Hand "klicken"
    muessen). Schoen dass wir das jetzt haben :)

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