WLC-1000 und LX-6400 Instabilität

[ua]

geht wieder....
Nutzt Du ggf. eine Bridge-Gruppe für mehrere Tunnel?
https://support.lancom-systems.com/know ... +und+SSIDs

Zum Thema LEPS-U über CAPWAP und VLAN habe ich nichts gefunden.
LEPS-U nutze ich sehr viel mit Zuweisung eines VLAN (sowenig SSID wie möglich).
Habe es aber nicht CAPWAP und VLAN-Zuweisung ("hinter dem WLC") noch nicht zum fliegen bekommen.

[AndreasL]

Bei mir läuft es mit 3x 6400 und 1x LW600 (alle 5.34.0027 SU19) und 1906VA (10.50.0235RU1) als WLC zur Zeit recht gut.

Das soll vermutlich 5.34.0027SU1 heißen und die 9 hat sich beim Versuch der schließenden ) eingeschmuggelt, richtig?

[ua]

jau, Tippfehler
Wage zu bezweifeln, das es je eine SU19 geben wird (egal für welches Produkt)

[tstimper]

Nutzt Du ggf. eine Bridge-Gruppe für mehrere Tunnel?

Nein, der WLC läuft im Router Modus, Bridge-Gruppen nehme ich garnicht.

Zum Thema LEPS-U über CAPWAP und VLAN habe ich nichts gefunden.

So wie es aussieht, scheint LEPS-U das nicht von CAPWAP abzuhängen.

LEPS-U nutze ich sehr viel mit Zuweisung eines VLAN (sowenig SSID wie möglich)

Das klingt interessant, muss ich mir anschauen, inwieweit wir das sogar in unser eigenes Deployment Tool einbauen können.

Zur ursprünglichen Frage WLC-1000 und LX-6400 Instabilität:
Lancom hat mittels unserer Traces und Wireshark Mittschnitte zwei Fehler gefunden und arbeitet an dem Fix für die LX-6400 Firmware.
Sobald ich die habe, teste ich und berichte.

Viele Grüße

ts

[tstimper]

Hi,

ein Update zu diesem Fall:

Wir testen eine neue Firmware für den LX-6400.

Beim Updaten ist folgendes aufgefallen, was mit den LX APs sicher gar nichts zu tun hat.

Nach einiger Zeit, so ca, 6 - 48 Stunden, nimmt der WLC keine APs mehr an,
die nicht unmittelbar vorher verbunden waren.

LX-6400 APs, die zwar konfiguriert waren, sich aber nicht mehr mit dem WLC verbinden konnten,
können sich auch nach einem Reboot nicht verbinden.

Konfigurierte LX APs, die verbunden waren können sich nach einem Reboot wieder neu verbinden.

Konfigurierte LN APs, die eine Weile ( z.mehr als 8 Stunden) aus waren, können sich wieder zum WLC verbinden.

Resettete und aus der WLC Konfig gelöschte LN APs werden nicht neu angenommen.

Das Verhalten kennen wir, hatten es bisher auf die LX APs geschoben und Abhilfe durch nächtliches Reboot des WLC geschaffen.

Jetzt haben wir folgendes im Syslog beobachten können:

Der WLC setzt die Zeit neu, die er von eime LC-1906VA bekommt. Das macht er alle 3.600 Sekunden.

Code: Alles auswählen

Local time set to 2021-10-08 12:30:37(UTC) received by 10.xxx.xxx.xx

Kurz dannach kommen die fehlenden APs wieder online, auch die resetteten/gelöschten LX und LN APs kommen online.

Im Bootlog des WLC sehen wir:

Code: Alles auswählen

10/08/2021 11:30:10  LCOS-Watchdog

Task name = CAPWAP-Worker  Type=PPC: DSI (protection error on store access @0x0)

Code=0x00000002 Thread=00000001e1c600b8 Task=00000001e1c60098 Nest=0x00000000

registers follow, m_p_area = 0000000107d32040

usw. Ich weis nicht was da alles drin steht, deshalb poste ich das hier nicht.
Wer helfen kann und das Bootlog braucht, bitte PN:

Merkwürdig ist der Zeitunterschied.

Der Event war:

14:30 Uhr CEST - also unsere aktuelle Sommerzeit
12:30 Uhr UTC - sagt Syslog
11:30 - sagt das WLC Bootlog

Jetzt ist es 15:30 Uhr und der WLC sagt, seine Betriebszeit wäre 4 h, also das passt aus der Sicht des WLC, seit 11:30 sind 4 h vergangen.

Der Event war aber 14:30 Uhr und seit dem ist eine Stunde vergangen.

Als der WLC in diesem "Ich gebe langsam auf" Modus war, funktionierten auch keine neuen Public Spot Logins mehr.

Viele Grüße

ts

[tstimper]

Hi,

ein Update zu diesem Fall:

Folgendes hat der Lancom Support gefunden:

Die Remote Router hatten alle im VCM abgehend PMTU Reduzierung auf 576 eingestellt.
Das ist im Wizard Standard. Das führte dazu, das im Falle eines Anrufes die PMTU reduziert wurde.
Allerdings nur abgehend. Das führte dazu, das die LX-APs dann manchmal die Verbindung um WLC verloren.
Die LCOS APs liefen stabil durch.
Weiterhin besteht noch das Problem, das ein LX-AP, der einmal die Verbindung zum WLC verloren hat,
nach einer Weile keinen Neuverbindungsversuch macht. Er ist aber noch per GUI und CLI erreichbar und kann rebootet werden.
Dann läuft er wieder bis zum nächsten Abbruch.
Lancom arbeitet an einem Fix.

Die Test Firmware, die wir haben, ist schon um Größenordnungen stabiler.

Viele Grüße

ts

[DerFreistaat]

Ich habe seit gestern Nacht ein ähnliches Problem. Hier ist ein vRouter von 10.42.0473RU3 auf 10.50.0235RU1 [..]
öfters einen Reboot gemacht hat (alle 30-45 Minuten). Das würde zu dem gemeldeten Lastproblem passen.
System boot after LCOS-Watchdog
Jetzt läuft der Controller nach einem Rollback wieder mit 10.42.0473RU3 / 13.04.2021 stabil

danke!!! und ich dachte schon ich werd Irre.
Hier das gleiche Phänomen, mit der 10.50.x startet mein vRouter regelmäßig neu, mit der LC-vRouter-10.42.0740-RU6 läuft zumindest der vRouter stabil. Nur meine WLC Tunnel brechen regelmäßig zusammen.

Immerhin bin ich nicht der einzige mit dem Problem. Ich werde mal die Tipps hier beherzigen und bei uns Testen.

Danke,
Tanke

[tstimper]

Hier das gleiche Phänomen, mit der 10.50.x startet mein vRouter regelmäßig neu, mit der LC-vRouter-10.42.0740-RU6 läuft zumindest der vRouter stabil.

Hat jemand diese WLC Reboots auch auf einem physischen WLC?
Wir hatten das auf dem WLC-1000 auch gesehen, als wir noch die ersten Releases der LX Firmware auf den APs hatten.
Mittlerweise fahren wir die 10. Test Firmware für die LX-APs und reporten fast täglich an Lancom.

Die LC-LX-6400-5.34.0058 vom 05.11.2021, die der Support bei Problemen rausgibt, ist schon recht stabil.
Vereinzelt sehen wir im Syslog / Trace des WLC bzw. AP noch DTLS Errors, meist an langsameren Leitungen.

Unter anderen diese DTLS Errors scheinen erhebliche Last auf dem WLC zu erzeugen und dann läuft auch der RAM des WLC voll.

Lässt sich da der vRouter WLC ggf mit mehr RAM konfigurieren? Mit den vRoutern habe ich noch nicht gearbeitet.

Und wir würden gern einen virtuellen Admin Roundtable mit Nutzern der LX-APs am WLC machen,
um Erfahrungen auszutauschen. Wer hätte Interesse, teilzunehmen?

Viele Grüße

ts

[DerFreistaat]

Hat jemand diese WLC Reboots auch auf einem physischen WLC?

mein physischer WLC war nur bis 10.4x im Einsatz und wurde dann eben durch den vRouter ersetzt.
Gefühlt war der psysische WLC aber um ein vielfaches stabiler.

Mein vRouter Reboot Problem ist zumindest temporär behoben... immer wenn der vRouter eine Email verschicken wollte (Emailbenachrichtigung vom WLC) ist der Watchdog angesprungen und das das Gerät neu gestartet. -> SMTP deaktiviert -> keine Reboots mehr! Was auch immer da grade schiefläuft...

Ich hab jetzt mal den ersten LX-6400 angebunden und werde berichten. (alle anderen ~90 AP's sind noch LN,L oder OAPs)

Gruß
Tanke

[tstimper]

Ein Update,

nach vielen Monaten Arbeit mit Traces, Syslogs, Updates und gigabyteweise Daten mit dem Lancom Support tauschen sind die LX-6400 jetzt recht stabil.
Released wurde die v5.34.0072 als v5.34.0072-RU2.
Vielen Dank dem Lancom Support Team und dem Management. Es war seit Start des Projektes die 18. LC-6400 Firmware, mit der wir getestet und debugged haben.

Insbesondere die CAPWAP DTLS Errors sind fast weg.
Auch das automatische Firmware Update vom WLC aus soll jetzt gelingen, das werden wir aber erst bei nächsten Update sehen.

"Kleinigkeiten" wie fehlendes NTP und DNS Setzen der AP auf den WLC und disablen von IPv6 werden wir hoffentlich auch noch bekommen.
Und Scripting nicht vergessen natürlich

Wenn Ihr Probleme mit den LX-6400 am WLC hattet, würde es mich interessieren, ob die v5.34.0072-RU2 bei Euch auch die Situation verbessert hat.

Unser WLC-1000 läuft immernoch auf der v10.42.0740-ru6. Den Schritt auf die v10.50.0434-ru3 werden wir erst auf einem Testsystem wagen.

Viele Grüße

ts

[AndreasL]

Ich bedanke mich ganz herzlich für euren Einsatz Mir ist das leider so nicht möglich. Ich werde die Firmware auf einen lw-600 und einen lx-6402 loslassen. Mal sehen, was passiert.

Ich wünsche geruhsame Feiertage

[tstimper]

Hi,

ein Update:

wir sehen im CAPWAP-Data Trace, das der WLC Antworten auf DNS Anfragen von Clients nicht nur an den AP schickt,
an dem der betreffende Client hängt, sondern jeweils einzeln nacheinander an ALLE APs,

Aufgefallen ist und das grad bei einem iPhone, das eine locally-adm MAC Adresse gesetzt hat.

Da reichen dann eine wenige Clients, um das WLAN mit DNS Reply's flooden zu lassen...

Hat das so schon jemand gesehen?

WLC-1000 mit Firmware v10.42.0740-ru6
LX-6400 mit Firmware v5.34.0072-ru2

SSIDs über WLC Tunnel und teilweise Publik Spot

Vielen Dank

ts

[tstimper]

Hi ,

noch ein Update:

Wir haben gestern nochmal weiter analysiert, das ist ein sowas von heftiger BUG in der WLC Implementation.
Aufgrund der Menge der Daten im CAPWAP DATA Trace ist und erstmal nur aufgefallen, das Clients, die in einer Public Spot SSID angemeldet sind,
ALLE APs mit DNS replies flooden lassen können.

Ausschitte aus CAPWAP DATA trace, IPs und Mac-Adressen verändert

Code: Alles auswählen

UdpConn: L:10.10.10.10:1027  R:10.55.1.91:57284 (LAN-1, INTRANET)
Dest                : 32:33:92:55:55:6d (locally-adm.)
Source              : 00:a0:57:11:22:33 (LANCOM 11:22:33)
Src Address         : 10.80.80.10
Dest Address        : 10.90.90.228
Src Port            : DNS
Dest Port           : 59834

UdpConn: L:10.10.10.10:1027  R:10.55.1.95:43102 (LAN-1, INTRANET)
Dest                : 32:33:92:55:55:6d (locally-adm.)
Source              : 00:a0:57:11:22:33 (LANCOM 11:22:33)
Src Address         : 10.80.80.10
Dest Address        : 10.90.90.228
Src Port            : DNS
Dest Port           : 59834

UdpConn: L:10.10.10.10:1027  R:10.55.1.99:54733 (LAN-1, INTRANET)
Dest                : 32:33:92:55:55:6d (locally-adm.)
Source              : 00:a0:57:11:22:33 (LANCOM 11:22:33)
Src Address         : 10.80.80.10
Dest Address        : 10.90.90.228
Src Port            : DNS
Dest Port           : 59834

Wir sehen also genau:

Client 10.90.90.228 mit Mac Adresse 32:33:92:55:55:6d hat offensichtlich eine DNS Anfrage mit dem QuellPort 59834 gestellt.

Der WLC mit IP 10.10.10.10 und MAC Adresse 00:a0:57:11:22:33 schick dann Replies an ALLE APs an den Destiniation Port 59834.
Und zwar EINZELN an jeden AP in einer separaten Session, aber mit demselbem Destination Port.

Senden darf er diesen Reply AUSSCHLIESSLICH an den AP, mit dem der betreffenden Client verbinden ist!!!!

Falls von LANCOM jemand mit liest, gebt das mal bitte weiter, das Verhalten tötet die WLANs.

Wir wissen noch nicht genau, ob das nur Public Spot SSIDs betrifft, es sieht aber fast so aus..


Viele Grüße

ts

[tstimper]

Update:

Der Lancom Support sagte uns das wir folgendes ändern müssen:

Schnittstellen > LAN-Bridge > Port-Tabelle > WLC-TUNNEL-1 auswählen > Bridge-Gruppe auf bspw. BRG-1 ändern
IPv4 > Allgemein > IP-Netzwerke > Netzwerk WLAN-NETZ-NAME- auswählen > Schnittstellen-Zuordnung auf BRG-1 ändern

Dann noch die Lan Bridge in den Standard Mode

Schnittstellen > LAN > LAN-Bridge > Standard Mode

Jetzt sieht es wesentlich ruhiger aus..

Viele Grüße

ts

[AndreasL]

Schnittstellen > LAN-Bridge > Port-Tabelle > WLC-TUNNEL-1 auswählen > Bridge-Gruppe auf bspw. BRG-1 ändern
IPv4 > Allgemein > IP-Netzwerke > Netzwerk WLAN-NETZ-NAME- auswählen > Schnittstellen-Zuordnung auf BRG-1 ändern
Dann noch die Lan Bridge in den Standard Mode
Schnittstellen > LAN > LAN-Bridge > Standard Mode

Ist das eine Grundsätzliche Sache oder liegt da eine Spezielle Konfiguration zu Grunde, die nur bei euch Zutrifft?
Ich habe mal in den von uns betreuten vRouter rein gesehen:
Erster Eintrag unter Schnittstellen steht bei der Bridge-Gruppe 'keine'

Für den 2. Eintrag existiert nur das Intranet, kein eigenes Wlan Netz. Hier steht der Netzwerktyp auf 'Intranet'
Der 3. Punkt mit der Standard LAN-Bridge ist so eingestellt.

Besteht Handlungsbedarf? Wir hatten letztes Jahr auch ein Problem, wo Teile des Netzwerks, die über Router angebunden sind, nach ein Firmwareupdate nicht mehr ansprechbar waren weil alles geflutet wurde. Das Problem al solches konnten wir nicht einkreisen und nach einem Rollback war alles wieder ok. Deswegen fahren wir überall noch die 10.34.x