Wir haben die Zeit zwischen den Tagen damit genutzt, bei einem Kunden neue WLAN Controller einzurichten. In der üblichen Vorgehensweise: also aktuelle Firmware und Konfiguration aufbringen, Einbau im Rack, Anbindung an die Switching-Infrastruktur, Access Points migrieren, verschiedene Funktionstests. Und zuletzt der obligatorische Redundanztest: Netzstecker ziehen und beobachten, was passiert.
Bekanntlich gibt es verschiedene Varianten dafür, wie sich Access Points mit einem redundanten WLAN Controller verbinden. Eine Variante basiert auf einem Controller Cluster. Hierbei erscheinen beide WLAN Controller als ein virtueller. Mit anderen Worten: Access Points verbinden sich immer mit derselben IP-Adresse, egal welcher Controller gerade ausfällt. Bei der anderen Variante bleiben die WLAN Controller unabhängig und die Access Points kennen deren IP-Adressen. Wird die primäre Adresse nicht erreicht, verbinden sie sich mit der sekundären. Und diese Variante (übrigens mein Favorit) setzt der Kunde ein.
Bei unserem Test fiel auf, dass nach dem Wiedereinschalten des primären WLAN Controllers zwei Access Points auf dem sekundären verblieben. O.k., manchmal dauert es eben etwas länger. Also beide Access Points zurückgesetzt, dann sollten sie umschwenken. Nicht so in diesem Fall. Beide verbanden sich wieder mit dem sekundären Controller.
Irgendetwas musste „faul“ sein an den Access Points. Ich habe sie dann erst einmal in den Auslieferungszustand zurückgesetzt –
ohne Erfolg. Dann dafür gesorgt, dass die Firmware erneut vom WLAN Controller heruntergeladen wurde – erfolglos. Was ich auch probiert habe, das ungewöhnliche Verhalten der Access Points veränderte sich um nichts in der Welt. Zuletzt habe ich den Access Points sogar noch mit Hilfe des DHCP Servers neue IP-Adressen verpasst, um sicherzustellen, dass alle für die Konfiguration benötigten DHCP-Optionen erneut geladen wurden.
Danach war einer der Access Points gar nicht mehr zu erreichen. Hoppla, wie kommt das denn? Im Log des DHCP Servers konnte ich erkennen, dass beide korrekt konfiguriert worden waren. Und die neuen IP-Adressen fanden sich in der ARP Table des Default Gateways. Von dort ließen sich beide Access Points auch „anpingen“, nicht jedoch von meiner Arbeitsstation. Sollte es sich etwa um ein Routing-Problem handeln?
Ich habe dann die Konfiguration des Default Gateway untersucht. Wie üblich handelt es sich um ein Paar Distribution Switches, die sich aus Sicht der Access Netze eine virtuelle IP-Adresse teilen (VRRP). In Richtung des Backbone werden die IP-Adressen der angeschlossenen Access-Netze per dynamischem Routing (OSPF) propagiert. Um die Gesamtzahl der Routen im Backbone zu begrenzen, hatte man Route Summarization konfiguriert, also die Adressen aller Access Netze unter einem Supernet zusammengefasst.
Access Points samt Access Switch waren erst kürzlich installiert worden. Aus irgendeinem Grunde war der Switch nur einbeinig angebunden; wahrscheinlich fehlte noch die Glasfaser zum zweiten Verteilerraum. Das entsprechende Access VLAN existierte dementsprechend auch nur auf einem Distribution Switch. Und genau das war das Problem. Die Route Summarization führt nämlich dazu, dass dennoch implizit beide Distribution Switches das betroffenen Access Netz in den Backbone propagieren. Landeten die IP-Pakete an die Access Points dann auf dem „falschen“ Distribution Switch, wurden sie kurzerhand verworfen.
Auf Grund dieses Fehlers konnten die Access Points letztlich den primären WLAN Controller nicht erreichen. Sie haben sich – entgegen meiner ursprünglichen „Fixen Idee“ – vollkommen korrekt verhalten. Hätte ich einfach nachgefragt, was es mit diesen speziellen Access Points auf sich hatte, wäre ich wahrscheinlich eher auf die Idee gekommen, die Konfiguration des sie umgebenden LANs zu untersuchen…
Teile diesen Eintrag