Große Probleme L-321agn-R2

[tbc233]

Ich hab wollt mal wieder einen WLC-4006+ mit Erweiterungsoption und 10 L-321 APs in Betrieb nehmen. Eigentlich eine Standardsache, die ich in der Größenordnung schon öfter gemacht habe und eigentlich nicht mit Problemen rechnete.

Nun steh ich aber mit einem Haufen Problemen da. Ich hab den Support schon angeschrieben, wollte mich in der Zwischenzeit aber auch hier austauschen. Konkret ist das WLAN *extrem* langsam, bei einem Dauerping gehen um die 10% verloren. Zudem fliegen bei jeder kleinsten Config Änderung die Clients raus und brauchen ewig bis sie sich wieder verbinden können.
Die Accesspoints sind alle per Ethernet mit dem Hauptswitch verbunden. Verbinde ich mich zum Beispiel per ssh auf einen Accesspoint und pinge einen der Server, gibt es keinen Paketverlust. Alles stabil. Pinge ich den selben Server vom WLAN aus, hab ich hohe Paketverluste (sitze aber mit dem Notebook direkt neben dem AP). Die ping Zeiten sind sehr hoch.

Um Probleme mit dem WLC auszuschließen, habe ich auch schon einen Accesspoint "einfach so" alleine ohne Controller betrieben. Die Probleme sind die selben.

LCOS ist 9.0.4 - bei den Geräten ist mir das "R2" aufgefallen. Gibt es da bekannte Probleme? Ich weiß im Moment noch gar nicht wo ich zu suchen beginnen soll.

[Dr.Einstein]

Hm, hatte persönlich vielleicht 5-10 WLCs mit den neuen R2 eingerichtet, dabei unabhängig ob 320/321/322. Kein Aufbau hatte die von dir geschilderten Probleme :-/ Vielleicht doch was standortbezogenes? Mal einen AP einzelnd ohne LAN hingestellt, bzw. am LAN nur ein Laptop? Den AP mal wo ganz anders hingestellt (statt beim Kunden im Büro) ?

Gruß Dr.Einstein

[alf29]

Moin,

udem fliegen bei jeder kleinsten Config Änderung die Clients raus und brauchen ewig bis sie sich wieder verbinden können.

Also zumindest daß Clients bei einer Konfig-Änderung im WLAN rausfliegen, ist normal - wenn sich auf einer SSID etwas ändert, werden alle Clients auf dieser SSID zwangsweise vom AP rausgeworfen. Es ist sonst nicht garantiert, daß die Clients die Änderungen im Betrieb auf dieser SSID mitbekommen. Ob sich Clients nach so einem Rauswurf sofort wieder verbinden oder für eine Weile in die Schmollecke zurückziehen, ist Client-abhängig...

Gruß Alfred

[tbc233]

Also zumindest daß Clients bei einer Konfig-Änderung im WLAN rausfliegen, ist normal - wenn sich auf einer SSID etwas ändert, werden alle Clients auf dieser SSID zwangsweise vom AP rausgeworfen. Es ist sonst nicht garantiert, daß die Clients die Änderungen im Betrieb auf dieser SSID mitbekommen. Ob sich Clients nach so einem Rauswurf sofort wieder verbinden oder für eine Weile in die Schmollecke zurückziehen, ist Client-abhängig...

Ja, aber ich spreche hier von 15 Minuten und mehr, und das bei einem Notebook das sonst an anderen Standorten nicht zickig ist.

Auffallend ist auch dass die ohnehin schlechte Performance immer noch schlechter wird, wenn sich nur ein zweiter oder gar dritter Client auf den Accesspoint verbindet.

CPU Auslastung auf dem AP ist in Ordnung.

[stefanbunzel]

Hallo tbc233,

Nun steh ich aber mit einem Haufen Problemen da.

Bitte gib uns mal noch mehr Informationen: Frequenzband? Kanallast? IAPP? Stationsüberwachung? MAC-Filter? Verschlüsselung? sonst. WLAN-Einstellungen?
Was sagt das WLAN-Log?

Ich habe tlw. schlechte Erfahrungen mit der SSID-Broadcast-Unterdrückung, wodurch manche Clients ewig brauchen, um sich dann doch mal mit dem AP zu verbinden... Das sind aber i.d.R. keine 15 Minuten sondern eher Dauern bis max 1 oder 2 Minuten.

Ich würde dir ja empfehlen, anfangs so wenig wie nur möglich von Default abweichende Einstellungen zu verwenden.

Viele Grüße und viel Erfolg,
Stefan

[tbc233]

Danke für eure Antworten.

Wir sind mit den Einstellungen eigentlich komplett standardmäßig unterwegs. SSID ist nicht unterdrückt. An den anderen Einstellungen wurde kaum etwas verändert - Verschlüsselung 802.11i WPA-PSK, Frequenzband 2,4/5GHz, Mac Prüfung ist nicht aktiviert. Automatische Kanalwahl. Antennengewinn ist Default auf 3. An IAAP wurde nichts gedreht, Client Überwachung ist kein Haken drin.

Als einzige Ursache (hatte ich in meinem Eingangspost vergessen zu erwähnen) würde mir noch einfallen, dass das WLAN welches wir dort ablösen möchten, noch aktiv ist. Ich kann es derzeit noch nicht abdrehen, weil sonst dort die Hölle los ist. Es besteht aus zwei Linksys mit dd-wrt, vermutlich Radio Leistung erheblich aufgedreht (ich habe leider keinen Zugriff auf die Geräte). Sie verwenden eine andere SSID. Da auf unserer Seite aber der Kanal automatisch gewählt wird, und es dort sonst keine WLANs gibt die das Funkfeld noch weiter verschmutzen könnten (abgelegenes Gebäude), habe ich das bisher nicht als Störungsursache in Betracht gezogen. Es wird aber als nächstes getestet, wie das Verhalten ist, wenn wir die Linksys abdrehen.

[stefanbunzel]

Na, dann bin ich ja mal auf die Kanallast vor und nach der Abschaltung gespannt!
Zur "automatischen Kanalwahl" bei 2,4 GHz: Irgendwie habe ich da schlechte Erinnerungen an deren effektive Funktion, da diese (meines Wissens) nur beim ersten Einschalten des Gerätes genutzt wird? Bei 5 GHz wäre noch interessant, welche Unterbänder verwendet werden.
Treten deine Probleme sowohl bei 2,4 GHz als auch 5 GHz auf?
Bitte teste auch mal unbedingt den Unterschied mit / ohne "Adaptive Noise Immunity".
Bei 10 AP's, die sich ja sicherlich gegenseitig überlappen, würde ich aber unbedingt IAPP aktivieren.

Viele Grüße,
Stefan

[tbc233]

Um das Problem weiter einzugrenzen, haben wir mittlerweile nur mehr einen einzigen Accesspoint in Betrieb (und den WLAN Controller). Überlappungen unsererseits kann ich also ausschließen. Wir haben bereits den reinen 2,4GHz Betrieb getestet, keine Verbesserung. Unterbänder bei 5GHz sind 1+2 (Standard IMHO) Adaptive Noise Immunity werde ich testen, kann ich mich jetzt nicht mehr erinnern ob wir damit auch schon experimintiert haben.

[tbc233]

Ich bin noch nicht 100% sicher, aber es zeichnet sich gerade eine massive Verbesserung ab, seit wir das Client Steering auf "AP-basiert..." und das bevorzugte Frequenzband des Client Steerings auf 2,4 GHz festgelegt haben. Auch wenn ich dafür keine Erklärung habe, warum genau das die Situation verbessert.

[tbc233]

Wie sich rausgestellt hat, war es das leider doch nicht. Auch testweises deaktivieren des Steerings und der Adaptive Noise Geschichte hat nichts geholfen.

[tbc233]

Eine neue Erkenntnis gibt es: In den Geräteaktivitäten tauch dutzendfach die Meldung auf "Wireless LAN: Karte hängt". Und zwar taucht die Meldung immer dann auf, wenn die Performance in die Knie geht bis zum Totalausfall.

Hinweis auf Hardwaredefekt?

[tbc233]

Mittlerweile einen der Accesspoints an einen (völlig) anderen Standort getestet. Die selben Probleme... Unglaublich. Wie realistisch ist eine Lieferung von 10 out-of-the-box defekten Geräten?

[Dr.Einstein]

Wurden alle via PoE versorgt (wenn ja, alle am selben / baugleichen Switch)? Hatte mir zumindest auch 6x ne R Serie zerschossen dadurch. Waren aber die ETH Ports, die alle tot waren. Nur so als Idee

Gruß Dr.Einstein

[tbc233]

Nein, kein PoE. Wie gesagt, es ist ein reines WLAN Problem. Verbinde ich mich mit ssh auf den Lancom und pinge ins per ETH angeschlossene Netz, ist alles bestens, keine Paketverluste. Die Probleme sind ausschließlich vom WLAN ins LAN und (mittlerweile auch gestetet) ebenfalls zwischen WLAN Clients untereinander.

[martinw]

Hatte mir zumindest auch 6x ne R Serie zerschossen dadurch. Waren aber die ETH Ports, die alle tot waren.

Autsch Wie genau?