In einem Update zielt Aruba auf ein einzelnes, schwerwiegendes Problem mit Bezug auf Roaming (Fast BSS Transition / 802.11r). Das Problem betrifft AP’s fast aller ArubaOS und InstantOS Generationen.
Auch wesentlich ältere Release-Trains bekommen das Update. Die Versionen 4.2.4.20 (nur InstantOS), 6.5.4.22, 8.3.0.18 (nur ArubaOS), 8.6.0.16, 8.7.1.8, 8.8.0.3 und 8.9.0.2 sind jetzt jeweils im Aruba Support Portal (Link) verfügbar.
Was ist passiert?
Wer sich wundert, dass er zum Teil APs mit keinem einzigen Client (STA) neben APs mit STA-Zahlen am Limit, ungewöhnlich viele Sticky-Clients hat oder Roaming in Zonen fehlschlägt, an jenen eigentlich sofort zu Nachbar-AP’s geroamt werden könnte, kann vom Problem betroffen sein: Die STA-Association eines AP’s funktioniert nicht mehr.
Aruba hat gleich eine ganze Reihe von Meldungen
AOS-229972, AOS-229991, AOS-230192, AOS-230290, AOS-230416, AOS-230554, AOS-230604, AOS-230721, AOS-230725 & AOS-230871einem einzelnen Bug zugeordnet:
Clients were unable to connect to SSIDs that had the 802.11r option enabled. During this period, commands run in the CLI of the affected AP returned the following error message: Module AP STM Low Priority is busy. Please try later. The fix ensures that SSIDs configured with 802.11r option service the client as expected. This issue was observed in APs running Aruba Instant 8.3.0.0 or later versions.Ursächlich wird bei der Reassociation ein vom Anwendergerät (STA) erwartetes Feld in einem Frame nicht geliefert. Das STM-Modul des AP’s fällt in diesem Fall in eine Schleife. Alle weiteren Anmeldungen an dem jeweiligen AP sind deshalb nicht mehr möglich. Der AP fällt auf 0 STA zurück, ist jedoch in allen Verwaltungstools weiterhin normal sichtbar. Eine Fehlermeldung wird nicht generiert.
Übersetzt bedeutet dies, dass ein einzelner Anwender, mit einem einzelnen, fehlerhaften Endgerät, sämtliche Accesspoints, zu denen er roamt, komplett schlafen legen kann. Auf einem Campusgelände mit mehreren, tausenden Clients, und bei AP’s, welche sich in Zonen mit hoher Fluktuation befinden, ist die Wahrscheinlichkeit relativ hoch, dass ein Anwender in der Nähe so ein Gerät besitzt und in Folge dessen dieses Problem auftritt.
Workaround
Vom Support wurde empfohlen, 802.11r zu deaktivieren. Zu diesem Zeitpunkt war noch kein Bugfix von Aruba verfügbar. 802.11r wird in den Sicherheitseinstellungen, jeweils pro SSID konfiguriert. Das abgestürzte STM-Modul lässt sich allerdings nur durch einen Neustart des jeweiligen AP’s wiederbeleben. Der Workaround funktionierte – Die AP’s waren dauerhaft nutzbar.
Feststellung
Ob man vom Problem am jeweiligen AP betroffen ist, lässt sich einfach feststellen. Das STM/BSS-Modul wirft bei der Frage
sh ap association
sh ap bss-tabledie Meldung es sei „beschäftigt“ aus, anstatt – wie erwartet – die vollständige Tabelle anzuzeigen.
Das ganze kollidierte mit einem weiteren Bug, weil z.B. zuvor die von mir an hochfrequentierten Bereichen oder für Veranstaltungen häufig verwendete Aruba AP340er-Serie mit einem ähnlichen Problem – durch Fast BSS-Transition verursacht – sich ebenfalls komplett schlafen legten (AOS-222157, AOS222841).
Auch wenn es in den meisten Szenarien absolut „unangenehm“ ist, empfehle ich 802.11r zunächst zu deaktivieren und die passenden Releases – mit intensivem Studium der known issues – zu testen. AP’s, deren STA-Association-Module abgeschmiert ist, sind noch schlechter, als fehlendes 802.11r.
Beitragsbildquelle: John Lose