24
Aruba instant on AP22, bei Funkzellwechsel keine Verbindung
Hallo
Das Netzwerk besteht aus einer Watchguard, Aruba instant on 1930 und AP22, alles Neuware. Die AP`s sind alle mit Kabel angeschlossen und bekommen per VLAN 4 W-LAN.
Bleibe ich in einer Funkzelle funktioniert alles. Wechsle ich zur nächsten Funkzelle kommt es öfter vor das sich mein Client scheinbar kurz verbindet um wenige Sekunden später ohne Verbindung zu sein. Ein Einbuchen des Clients von Hand ist dann auch nicht mehr möglich. Das Problem betrifft nicht alle der 4 W-LAN`s, mal geht noch eins, mal zwei. Das Problem ist auch abhängig von der Funkzelle aus der man kommt. Ich kann also von AP 1 problemlos zu AP 2 wechseln, aber nicht von AP 2 zu AP3 dort schlägt die Einbuchung fehl. Da von Hand einbuchen auch nicht geht, auch nicht wenn man auf dem Client alle W-LAN`s löscht, muss ich zu einem AP gehen wo das Einbuchen funktioniert, also zum AP1. Dort kann mein Client sich einbuchen ich kann dann zum AP 3 gehen und der Wechsel der Funkzelle gelingt. Die AP`s haben die gleiche Firmware, bekommen die selben V-LAN`s und sind auch sonst gleich konfiguriert, die sind auf Werkseinstellungen zurückgesetzt und neu ins Netz aufgenommen worden, ohne dass sich etwas verbessert hat.
Wenn ein Wechsel der Funkzelle fehlschlägt, meldet Android eine fehlende IP-Adresse, Windows behält die IP-Adresse aus der Funkzelle von der man kommt, hat aber keine Verbindung.
Das Netzwerk besteht aus einer Watchguard, Aruba instant on 1930 und AP22, alles Neuware. Die AP`s sind alle mit Kabel angeschlossen und bekommen per VLAN 4 W-LAN.
Bleibe ich in einer Funkzelle funktioniert alles. Wechsle ich zur nächsten Funkzelle kommt es öfter vor das sich mein Client scheinbar kurz verbindet um wenige Sekunden später ohne Verbindung zu sein. Ein Einbuchen des Clients von Hand ist dann auch nicht mehr möglich. Das Problem betrifft nicht alle der 4 W-LAN`s, mal geht noch eins, mal zwei. Das Problem ist auch abhängig von der Funkzelle aus der man kommt. Ich kann also von AP 1 problemlos zu AP 2 wechseln, aber nicht von AP 2 zu AP3 dort schlägt die Einbuchung fehl. Da von Hand einbuchen auch nicht geht, auch nicht wenn man auf dem Client alle W-LAN`s löscht, muss ich zu einem AP gehen wo das Einbuchen funktioniert, also zum AP1. Dort kann mein Client sich einbuchen ich kann dann zum AP 3 gehen und der Wechsel der Funkzelle gelingt. Die AP`s haben die gleiche Firmware, bekommen die selben V-LAN`s und sind auch sonst gleich konfiguriert, die sind auf Werkseinstellungen zurückgesetzt und neu ins Netz aufgenommen worden, ohne dass sich etwas verbessert hat.
Wenn ein Wechsel der Funkzelle fehlschlägt, meldet Android eine fehlende IP-Adresse, Windows behält die IP-Adresse aus der Funkzelle von der man kommt, hat aber keine Verbindung.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 21867368164
Url: https://administrator.de/contentid/21867368164
Printed on: May 2, 2024 at 18:05 o'clock
24 Comments
Latest comment
Wenn die WLAN Clients schon keine IP bekommen stimmt entweder...
Auch wenn du kein 802.11r und .11k in den WLANs aktiv hast (unterbrechungsfreies Roaming) muss dennoch immer ein Client basiertes Roaming passieren. Zwar mit Unterbrechungen aber Wechsel von Zelle zu Zelle. Voraussetzung ist natürlich eine saubere HF Kanalplanung im 2,5 und 5 GHz Band zu der du leider keinerlei Angaben machst. Siehe zu den grundlegenden WLAN ToDos auch hier.
Fragen:
- mit der VLAN Zuweisung am Switchport
- mit dem DHCP Server im jeweiligen MSSID VLAN
- oder mit der MSSID Zuweisung zur VLAN ID
Auch wenn du kein 802.11r und .11k in den WLANs aktiv hast (unterbrechungsfreies Roaming) muss dennoch immer ein Client basiertes Roaming passieren. Zwar mit Unterbrechungen aber Wechsel von Zelle zu Zelle. Voraussetzung ist natürlich eine saubere HF Kanalplanung im 2,5 und 5 GHz Band zu der du leider keinerlei Angaben machst. Siehe zu den grundlegenden WLAN ToDos auch hier.
Fragen:
- Sind das identisch konfigurierte standalone APs oder Controller basiert konfiguriert?
- Bekommen alle APs eine IP in einem gemeinsamen Management VLAN das nicht auf eins der MSSIDs gemappt ist?
- Sind die Management IPs der APs unterbrechungsfrei pingbar?
Danke für die Antwort. Einiges muss ich morgen noch prüfen.
Die Clients bekommen eine IP, nur das die manchmal nach dem Roaming verschwindet. Beim Roaming wird doch die IP nicht neu vergeben, oder?
Die Clients bekommen eine IP, nur das die manchmal nach dem Roaming verschwindet. Beim Roaming wird doch die IP nicht neu vergeben, oder?
Voraussetzung ist natürlich eine saubere HF Kanalplanung im 2,5 und 5 GHz Band zu der du leider keinerlei Angaben machst.
Die APs haben die Kanäle 1, 6 und 11. Im 5 GHz sind es die Kanäle 36, 52, 100.Fragen:
Mit dem Controller- Sind das identisch konfigurierte standalone APs oder Controller basiert konfiguriert?
* Bekommen alle APs eine IP in einem gemeinsamen Management VLAN das nicht auf eins der MSSIDs gemappt ist?
Ja.* Sind die Management IPs der APs unterbrechungsfrei pingbar?
Ja.
Am Switch sind Ports für AP`s reserviert, da darf nix anderes dran. Diesen Ports sind die tagged VLAN`s der W-LAN`s zugewiesen und das Management-VLAN untagged.
Der DHCP läuft auf der Watchguard, dort ist die Konfiguration der einzelnen VLANS sehr ähnlich, es unterscheidet sich die Security Zone. Die IP-Adressen passen zum VLAN. Der Gateway ist die Interface-IP. Es gibt Reservierungen für Drucker. IPv6 ist deaktiviert.
Der DHCP läuft auf der Watchguard, dort ist die Konfiguration der einzelnen VLANS sehr ähnlich, es unterscheidet sich die Security Zone. Die IP-Adressen passen zum VLAN. Der Gateway ist die Interface-IP. Es gibt Reservierungen für Drucker. IPv6 ist deaktiviert.
So vom Setup her was oben steht hast du alles richtig gemacht. Entspricht ja auch genau den Schritten die hier im Layer 2 VLAN Tutorial beschrieben sind.
Was du ggf. nochmal machen kannst ist dir abwechselnd Access Testports in den MSSID VLANs 102, 103, 106 und 106 auf dem Switch zu generieren und einmal mit einem Kupfer Client manuell zu "roamen". Sprich den Laptop also zwischen verschiedenen Ports einfach mal manuell umsteckst und so das Roaming Verhalten mehr oder minder auf Kupfer simulierst.
Sinn ist erstmal rauszubekommen ob die Switch und Firewall Infrastruktur der Troublemaker ist oder ob es die WLAN AP Infrastruktur ist. So kannst du das Suchfeld erstmal grob eingrenzen was sehr hilfreich wäre um die Baustellen einzugrenzen.
Das Verhalten ist in der Tat sehr ungewöhnlich und auch unüblich.
Hast du mehrere Switches im Einsatz? Ist auf dem/den Switches Spanning Tree aktiv?
Wenn Letzteres der Fall ist siehst du ggf. irgendwelche STP Topology Changes im Switchlog, besonders an den AP Ports?
Was du ggf. nochmal machen kannst ist dir abwechselnd Access Testports in den MSSID VLANs 102, 103, 106 und 106 auf dem Switch zu generieren und einmal mit einem Kupfer Client manuell zu "roamen". Sprich den Laptop also zwischen verschiedenen Ports einfach mal manuell umsteckst und so das Roaming Verhalten mehr oder minder auf Kupfer simulierst.
Sinn ist erstmal rauszubekommen ob die Switch und Firewall Infrastruktur der Troublemaker ist oder ob es die WLAN AP Infrastruktur ist. So kannst du das Suchfeld erstmal grob eingrenzen was sehr hilfreich wäre um die Baustellen einzugrenzen.
Das Verhalten ist in der Tat sehr ungewöhnlich und auch unüblich.
Hast du mehrere Switches im Einsatz? Ist auf dem/den Switches Spanning Tree aktiv?
Wenn Letzteres der Fall ist siehst du ggf. irgendwelche STP Topology Changes im Switchlog, besonders an den AP Ports?
Spanning Tree ist aktiv
Im log sehe ich den LLDP Status der sich ändert als ich die Ports zum obigen Test umkonfiguriert hatte.
Ich habe gerade die 4 VLAN´s untagged und einzeln auf jeweils einen Switchport gelegt und einen PC ohne W-LAN angeschlossen, dann mehrfach umgesteckt. Mit einem zweiten Switch gleicher Konfiguration simulierte ich den Wechsel zwischen den Switches. Der PC brauchte immer ca. 8 s um sich ins LAN einzubuchen und eine entsprechende IP zu bekommen.
Wir können nun davon ausgehen das der Fehler bei den AP`s liegt, oder?
Ich habe nun den betreffenden AP auf Werkseinstellungen zurückgesetzt.
Im betroffenen W-LAN:
Also nur noch 2,4 GHz und das Verbindungsproblem bleibt, aber Clients verbinden sich nach etlichen Minuten doch noch mit dem Netz.
Wenn ich also nun vom gut funktionierenden AP2 zum AP3 wechsle, sehe ich unter Windows, nach ein paar Sekunden, eine Verbindung ohne Internet.
zeigt mir die MAC von AP 3
Was nun, AP defekt?
Wenn ich Zeit finde werde ich die AP`s vertauschen um zu prüfen ob der Fehler mitwandert.
schöne Grüße
Im log sehe ich den LLDP Status der sich ändert als ich die Ports zum obigen Test umkonfiguriert hatte.
Ich habe gerade die 4 VLAN´s untagged und einzeln auf jeweils einen Switchport gelegt und einen PC ohne W-LAN angeschlossen, dann mehrfach umgesteckt. Mit einem zweiten Switch gleicher Konfiguration simulierte ich den Wechsel zwischen den Switches. Der PC brauchte immer ca. 8 s um sich ins LAN einzubuchen und eine entsprechende IP zu bekommen.
Wir können nun davon ausgehen das der Fehler bei den AP`s liegt, oder?
Ich habe nun den betreffenden AP auf Werkseinstellungen zurückgesetzt.
Im betroffenen W-LAN:
- WPA 3 deaktiviert.
- OFDMA deaktiviert
- WiFi 6 deaktiviert
- 5 GHz deaktiviert
Also nur noch 2,4 GHz und das Verbindungsproblem bleibt, aber Clients verbinden sich nach etlichen Minuten doch noch mit dem Netz.
Wenn ich also nun vom gut funktionierenden AP2 zum AP3 wechsle, sehe ich unter Windows, nach ein paar Sekunden, eine Verbindung ohne Internet.
netsh wl sh inWas nun, AP defekt?
Wenn ich Zeit finde werde ich die AP`s vertauschen um zu prüfen ob der Fehler mitwandert.
schöne Grüße
Im log sehe ich den LLDP Status der sich ändert als ich die Ports zum obigen Test umkonfiguriert hatte.
Das ist normal denn wenn du mit einmal einen anderen LLDP Neighbor hast weil z.B. das VLAN wechselt.Nach der Konfig Änderung MUSS das aber stabil bleiben und darf sich keinesfalls ändern! Also mal mit clear logg das Switch Log löschen und beobachten. Sich ändernde LLDP Neighbors deuten immer auf eine Topologie Änderung hin die normal NICHT passieren darf.
Wir können nun davon ausgehen das der Fehler bei den AP`s liegt, oder?
8 Sek. ist schon etwas lang aber sofern du kein STP Portfast an den Ports konfiguriert hast normal. Wichtig ist das diese Verbindung IP technisch stabil bleibt. Keine Ping Aussetzer usw.Ist das der Fall ist das Problem in der Tat eher auf WLAN Seite zu sehen.
Im betroffenen W-LAN:
- OFDMA deaktiviert = Ist falsch. Gerade OFDM sollte man nur ONLY definieren auf APs. Das schliesst den lahmen Uralt Standard 802.11b aus der 2,4 GHz WLANs immer in den Orkus reisst. Siehe auch Anmerkungen hier.
- 5 GHz deaktiviert = Warum? Willst du kein Dual Radio Support für deine Clients oder was ist der Grund?
AP`s vertauschen um zu prüfen ob der Fehler mitwandert.
Das wäre sehr sinnvoll.
Hallo aqui
Ich pinge den AP gerade an. Seit etlichen Minuten alles gut.
Seltsam ist das mir, beim Wechsel zum AP3, netsh nach wenigen Sekunden die MAC von AP 3 anzeigt, die Verbindung zum Netz aber erst etliche Minuten später realisiert wird. Wenn die Verbindung dann steht ist die nach wenigen Minuten wieder weg und netsh zeigt mir weiter die MAC vom AP3.
Ich habe nun AP2 gegen AP3 getauscht und der Fehler wandert nicht mit.
Zitat von @aqui:
Nach der Konfig Änderung MUSS das aber stabil bleiben und darf sich keinesfalls ändern!
Seit einer Stunde keine Meldungen mehr zu LLDP.Nach der Konfig Änderung MUSS das aber stabil bleiben und darf sich keinesfalls ändern!
Wir können nun davon ausgehen das der Fehler bei den AP`s liegt, oder?
Wichtig ist das diese Verbindung IP technisch stabil bleibt. Keine Ping Aussetzer usw.* OFDMA deaktiviert = Ist falsch.
Das war nur zum testen.- 5 GHz deaktiviert = Warum?
Seltsam ist das mir, beim Wechsel zum AP3, netsh nach wenigen Sekunden die MAC von AP 3 anzeigt, die Verbindung zum Netz aber erst etliche Minuten später realisiert wird. Wenn die Verbindung dann steht ist die nach wenigen Minuten wieder weg und netsh zeigt mir weiter die MAC vom AP3.
Ich habe nun AP2 gegen AP3 getauscht und der Fehler wandert nicht mit.
netsh nach wenigen Sekunden die MAC von AP 3 anzeigt
Mac Adresse in Bezug auf WAS? ARP Cache, BSSID mit welchem AP der Client assoziiert ist oder was meinst du damit? 🤔 Nicht Winblows Nutzer können damit nix anfangen. 
Auch wichtig: Die APs hast du auf die aktuellste Firmware geflasht??
mit welchem AP der Client assoziiert ist
Das letzte upgrade war vor 21 Tagen und das aktuelle 2.9.
Auch wichtig: Die APs hast du auf die aktuellste Firmware geflasht??
Aruba hostet einen Firmwareserver. Die AP`s und SW`s erhlten von dort die neueste Firmware. Ich kann nur sehen ob es Fehler gab, welche Version installiert ist und kann den Zeitpunkt des updates einstellen.Das letzte upgrade war vor 21 Tagen und das aktuelle 2.9.
Wenn es das denn nun war bitte nicht vergessen deinen Thread hier dann auch als gelöst zu markieren!
Leider gibt es noch keine Lösung.
Ich bin aber noch auf der Suche.
Wenn ich AP von unifi AC Pro einbinden gibt es zwischen Aruba und unifi keine Probleme beim Roaming.
Ich bin aber noch auf der Suche.
Wenn ich AP von unifi AC Pro einbinden gibt es zwischen Aruba und unifi keine Probleme beim Roaming.
AP von unifi AC Pro
Igitt. Miese Performance und Zwangscontroller (Vendor Lock). Von sowas sollte man die Finger lassen
Die Reichweite ist beim unifi AC Pro spürbar besser als beim Aruba AP22.
Ich vermute der Fehler liegt beim Switch Aruba 1930.
Zwangscontroller
Ja, den brauche ich zusätzlich zu Aruba Instan on um die unifi AC Pro einzurichten. Es war auch nie geplant Aruba und Unifi zusammen zu betreiben. Ich kann aber die Reichweite erhöhen bis mehr AP 22 angeschafft werden. Es war auch interessant das zwischen unifi AC Pro und Aruba 22 keine Probleme beim Roaming auftraten.Ich vermute der Fehler liegt beim Switch Aruba 1930.
Die Reichweite ist beim unifi AC Pro spürbar besser als beim Aruba AP22.
Dann hast du noch nie Ruckus APs oder Cisco 3702 betrieben sonst wüsstest du was wirkliche Reichweite ist! 
Cisco WLAN Access Points 1142N, 2702, 3702 für den Heimgebrauch umrüsten
Zitat von @aqui:
Ich kenne diese AP`s tatsächlich nicht.Die Reichweite ist beim unifi AC Pro spürbar besser als beim Aruba AP22.
Dann hast du noch nie Ruckus APs oder Cisco 3702 betrieben sonst wüsstest du was wirkliche Reichweite ist! Tolles Tutorial.
Grüße Uwe
Tolles Tutorial.
Vor allem Top Technik die keine Wünsche offen lässt für sehr kleines Geld.Danke für die 💐!
Hallo
Ich konnte nun auch den Switch am AP wechseln. Das Roaming Problem blieb erhalten. Zusammen mit dem Fakt das beim Wechsel des AP das Problem auch erhalten bleibt schlussfolgere ich das es an der Firewall liegt. Ich suche also weiter und hoffe noch diesem Jahr den Fehler zu beheben.
Ich konnte nun auch den Switch am AP wechseln. Das Roaming Problem blieb erhalten. Zusammen mit dem Fakt das beim Wechsel des AP das Problem auch erhalten bleibt schlussfolgere ich das es an der Firewall liegt. Ich suche also weiter und hoffe noch diesem Jahr den Fehler zu beheben.
Tja...HP eben. Die können besser Drucker und Laptops.
Wenn das neue Geräte sind und/oder du Wartung bzw. Garantie drauf hast solltest du in jedem Falle einen Case im HP TAC dafür aufmachen. Das Verhalten ist de facto nicht normal und vermutlich ein Bug.
Wenn das neue Geräte sind und/oder du Wartung bzw. Garantie drauf hast solltest du in jedem Falle einen Case im HP TAC dafür aufmachen. Das Verhalten ist de facto nicht normal und vermutlich ein Bug.
Danke für deine schnelle Antwort. Verstehe ich das richtig das du nicht an einen alleinigen Fehler in der Firwall glaubst?
Was hat eine Firewall mit WLAN Client Roaming zu tun?
Eine Firewall arbeitet in der Regel ja auf Layer 3 (IP) only und Roaming bzw. MSSIDs ist bekanntlich Layer 2 only. Zwei völlig verschiedene Baustellen also, die nichts miteinernader zu tun haben und sich auch gegenseiting nicht beeinflussen können. Dein Test mit alternativen APs bei gleichem Layer 2 Setup bestätigt diese Theorie ja eindeutig!
Fazit: Nein, eine Firewall ist hier ziemlich sicher nicht der Verursacher, denn wäre sie es wäre auch das Setup mit alternativen APs genauso gescheitert. Einfache Logik! 😉
Eine Firewall arbeitet in der Regel ja auf Layer 3 (IP) only und Roaming bzw. MSSIDs ist bekanntlich Layer 2 only. Zwei völlig verschiedene Baustellen also, die nichts miteinernader zu tun haben und sich auch gegenseiting nicht beeinflussen können. Dein Test mit alternativen APs bei gleichem Layer 2 Setup bestätigt diese Theorie ja eindeutig!
Fazit: Nein, eine Firewall ist hier ziemlich sicher nicht der Verursacher, denn wäre sie es wäre auch das Setup mit alternativen APs genauso gescheitert. Einfache Logik! 😉
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt markieren!
How can I mark a post as solved?
How can I mark a post as solved?
Ich hoffe es gibt noch ein Meeting mit dem Aruba-Support. Bisher hat das nicht geklappt, weil der Support andere Probleme hatte.
Auch andere AP von Aruba würde ich noch testen.
Ich würde gern eine klare Aussage zum Problem posten. Wenn nicht dieses dann im nächsten Jahr.
Auch andere AP von Aruba würde ich noch testen.
Ich würde gern eine klare Aussage zum Problem posten. Wenn nicht dieses dann im nächsten Jahr.
Nach dem Desaster wäre es ja nur vernünftig Aruba den Rücken zu kehren.
Dann warten wir mal gespannt wie die o.a. Story endet! 😉
Dann warten wir mal gespannt wie die o.a. Story endet! 😉
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
How can I mark a post as solved?
How can I mark a post as solved?
