LX6400 dynamic VLAN per Radius

[Jaso]

Hallo zusammen,

ich stelle aktuell mehrere LN-630 Accespoint gegen die neuen LX-6400 um.
Problematisch hierbei ist, die VLAN zuweisung über den Radius Server, die an den LX Accespoint nicht klappt. Auf den LN Accespoint klappt die Zuweisung ohne Probleme.

Die Accespoints werden über einen 1781VA mit der WLC Option gesteuert. Die Firmwareversion ist die 10.50.0235RU1
Der Radius Server läuft auf einem 1793VAW, mit der Firmwareversion 10.42.0612RU5.

Der LN-630 Accespoint, auf dem die Zuweisung ohne Probleme funktioniert, hat die Version 10.50.0235RU1.
Der LX-6400 hat die Version 5.34.0027SU1. Nach meinem Verständniss, sollte die dynamische VLAN Zuweisung ab dem Firmwarestand 5.32 doch funktionieren. Tunnel kommen nicht zum Einsatz, die Daten werden lokal an den Accespoint ausgeleitet.

Habe ich eine Einstellunng im WLC übersehen, die vorgenommen werden muss, wenn die Accespoints getauscht werden?
Oder ist das noch eine Kinderkrankheit bei den neuen Accespoints?

Gruß
JASO

[Benutzername]

Moin Jaso,

ich habe das ganze Anfang August bereits durchgemacht. Einen wichtigen Punkt findet man in der Knowledgebase
https://support.lancom-systems.com/know ... d=71827828
Besonderheiten:
Exklusivität der Dynamic-VLAN ID:
Die per Dynamic-VLAN zugewiesene ID darf nicht bereits einer anderen SSID zugewiesen sein. Diese darf also nur exklusiv für die dynamische Zuweisung verwendet werden.

Ansonsten kann man im Webinterface Log direkt auf dem AP ganz gut erkennen was am AP ankommt und um er das für den Client umsetzt oder nicht.
Fallback VLANs hatte ich nicht definiert.

[hagicgn]

Hallo zusammen,

ich versuche gerade, einen LC 1302 durch einen LX-6400 zu ersetzen (LX-Ver 5.38.0084Rel)
Dabei verzweifele ich etwas an der dynamischen VlanID-Zuweisung per Radius-Server im LCOS (1781VA).
Bisher lief das problemlos, beim LX-6400 scheint das mit der bisherigen Konfig (im Radius-Server?) nicht zu passen.

Ich habe den Fehler gefunden. Die zugewiesene VlanID darf nicht nur in einem anderen Wlan angegeneb sein, sondern auch nicht die ID des Ehernetports sein.
Konkret: Der Ethernetport des LX-6400 hat die VlanID 1, die per Radius zugewiesene ID war auch 1.

Edit:
Korrektur der Vlan-ID

[Markus2022]

Hallo,

ich hänge schon 3 Wochen daran. Wir haben für eine Schule 40 x LX-6400 gekauft und hab bis heute keinen ans laufen gebracht. Die APs sind von einem Händer bezogen worden, der kein LANCom Zertifizierter Händler ist.

Ein Teil der Konfig wird übernommen, z. B. root Kennwort, WLAN 2.4 und 5 GHz Einstellungen, Kommentare, Standorte, aber ohne SSID's

Bei mir wird der LX-6400 noch als eigenständiger AP erkannt. Der WLC 1000 läuft auf 10.72.

Gruß Markus

[Dr.Einstein]

Hi Markus,

dem AP gefällt höchstwahrscheinlich ein WLAN-Parameter aus dem Profil nicht. Dieser müsste eigentlich identifizierbar sein, wenn du auf dem AP einen Trace startest. (trace # CAPWAP-CTRL). Habe leider gerade keinen LX-AP vor mir, bin mir also unsicher, ob der Tracebefehl für WLC zwischen LCOS und LX abweicht. Ansonsten einfach mal 'trace' eingeben und schauen, was aufgelistet wird (oder den LanTracer verwenden).

Nach ein paar Paketen hin und her müsstest du eigentlich die Ursache im Klartext sehen. Filter lieber noch auf die DHCP Adresse des LX APs.

Gruß Dr.Einstein

[tstimper]

Habe leider gerade keinen LX-AP vor mir, bin mir also unsicher, ob der Tracebefehl für WLC zwischen LCOS und LX abweicht. Ansonsten einfach mal 'trace' eingeben und schauen, was aufgelistet wird (oder den LanTracer verwenden).

Gruß Dr.Einstein

auf einem LX AP gibt es nur tr # capwap

Gruß

ts

[Markus2022]

Anbei das LOG, hier erkenne ich leider nix
Das ganze wiederholt sich dann.

[Syslog] 2022/12/15 12:31:43,475 : capwap[1633]: From 10.xxx.xx.10:1027 to 10.xxx.xx.43 with size -1
[Syslog] 2022/12/15 12:31:43,475 : capwap[1633]: WTP got data: r: -1
[Syslog] 2022/12/15 12:31:43,475 : capwap[1633]: Try again...
[Syslog] 2022/12/15 12:31:43,475 : capwap[1633]: Leave capwap control
[Syslog] 2022/12/15 12:32:10,481 : capwap[1633]: Check possibility to send Echo Request
[Syslog] 2022/12/15 12:32:10,481 : capwap[1633]: Send echo request incremented sequence number [63]
[Syslog] 2022/12/15 12:32:10,481 : capwap[1633]: Send echo request thread id 1633 localseqnumber 63 self 548034350672
[Syslog] 2022/12/15 12:32:10,481 : capwap[1633]: Send Echo request
[Syslog] 2022/12/15 12:32:10,481 : capwap[1633]: Send echo case [2] mtu [1452] allowed length [1404]
[Syslog] 2022/12/15 12:32:10,482 : capwap[1633]: Sent packet to 10.xxx.xx.10:1027 with result 149
[Syslog] 2022/12/15 12:32:10,482 : capwap[1633]: Now wait for a response
[Syslog] 2022/12/15 12:32:10,482 : capwap[1633]: Restart retransmission timer
[Syslog] 2022/12/15 12:32:10,482 : capwap[1633]: Restart retransmission timer
[Syslog] 2022/12/15 12:32:10,483 : capwap[1633]: Receive CAPWAP Control Channel message
[Syslog] 2022/12/15 12:32:10,483 : capwap[1633]: Receive packet from 10.xxx.xx.10:1027 to 10.xxx.xx.43 with size 85
[Syslog] 2022/12/15 12:32:10,483 : capwap[1633]: From 10.xxx.xx.10:1027 to 10.xxx.xx.43 with size 85
[Syslog] 2022/12/15 12:32:10,483 : capwap[1633]: WTP got data: r: 85
[Syslog] 2022/12/15 12:32:10,484 : capwap[1633]: CAPWAP process packet
[Syslog] 2022/12/15 12:32:10,484 : capwap[1633]: CAPWAP decrypt packet
[Syslog] 2022/12/15 12:32:10,484 : capwap[1633]: Check message type [10]
[Syslog] 2022/12/15 12:32:10,484 : capwap[1633]: Update AP WLAN status table [10.xxx.xx.10] res [0] state [100]
[Syslog] 2022/12/15 12:32:10,498 : capwap[1633]: Got capwap response
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: Stop Keep alive dead timer
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: Stop Keep alive timer
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: Stop echo timer
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: Receive Echo Response
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: Receive WTP Echo Response
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: Handle any left association event [1]
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: Receive CAPWAP Control Channel message
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: From 10.xxx.xx.10:1027 to 10.xxx.xx.43 with size -1
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: WTP got data: r: -1
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: Try again...
[Syslog] 2022/12/15 12:32:10,499 : capwap[1633]: Leave capwap control

[Dr.Einstein]

Mach mal

Code: Alles auswählen

trace # CAPWAP-CTRL @ 1.2.3.4

auf dem WLC, wobei 1.2.3.4 ersetzt durch die IP des APs. Vllt sieht man dort etwas.

[tstimper]

Mach mal

Code: Alles auswählen

trace # CAPWAP-CTRL @ 1.2.3.4

auf dem WLC, wobei 1.2.3.4 ersetzt durch die IP des APs. Vllt sieht man dort etwas.

Irgendwie habe ich auch das Gefühl, es könnten noch mit der mit einer alten Firmware auf dem WLC erstellten CA zusammenhängen ...

Der gepostete Trace sagt mir dazu nichts.

Viele Grüße

ts

[Aushilfsinformatiker]

Hallo, hat sich das Problem mit der dynamischen VLAN-Zuordnung mit den AP's gelöst? Am kommenden Mittwoch richte ich einen WLC 2000 mit 35 Accesspoints in unserem Internat ein. Alles komplett neu verkabelt, 4 Gebäude mit LWL-Brücken..... Geplant ist ein PublicSpot über VLAN für Klasse 5-10, die 11/12er sollten über einen RADIUS sich anmelden. Testumgebung zu Hause funktioniert, aber mit LN860.
Da brauch ich bei der Benutzererstellung im RADIUS nur die VLAN-ID und das Routing-Tag anpassen, schon hoppst der Client in das entsprechende VLAN.

Wenn das mit den neuen AP*s nicht funktioniert, wäre echt ein Problem. Falls sich ein Schüler mit einem PublicSpot angemeldet hat, kommt er dann mit dem selben Gerät nicht mehr am RADIUS ab Klasse 11 angemeldet. Gibt es eine Möglichkeit, die ID des Clienten zurückzusetzen, oder reicht es vielleicht, wenn er einen neuen Benutzernamen erhält? Wenn der WLC aber die VLAN-Zuweisung an der MAC-Adresse festmacht, habe ich ein Problem.

Viele Grüße

[tstimper]

Hallo, hat sich das Problem mit der dynamischen VLAN-Zuordnung mit den AP's gelöst? Am kommenden Mittwoch richte ich einen WLC 2000 mit 35 Accesspoints in unserem Internat ein. Alles komplett neu verkabelt, 4 Gebäude mit LWL-Brücken..... Geplant ist ein PublicSpot über VLAN für Klasse 5-10, die 11/12er sollten über einen RADIUS sich anmelden. Testumgebung zu Hause funktioniert, aber mit LN860.
Da brauch ich bei der Benutzererstellung im RADIUS nur die VLAN-ID und das Routing-Tag anpassen, schon hoppst der Client in das entsprechende VLAN.

Wenn das mit den neuen AP*s nicht funktioniert, wäre echt ein Problem. Falls sich ein Schüler mit einem PublicSpot angemeldet hat, kommt er dann mit dem selben Gerät nicht mehr am RADIUS ab Klasse 11 angemeldet. Gibt es eine Möglichkeit, die ID des Clienten zurückzusetzen, oder reicht es vielleicht, wenn er einen neuen Benutzernamen erhält? Wenn der WLC aber die VLAN-Zuweisung an der MAC-Adresse festmacht, habe ich ein Problem.

Viele Grüße

Kannst Du keinen Case bei LANCOM aufmachen?

Viele Grüße

ts

[sebsch134]

Siehe Release Notes. Und siehe

https://knowledgebase.lancom-systems.de ... w/71827828

Das funktioniert mit Beachtung dieser Regel schon länger.
Sollte jetzt aber weggefallen sein mit 6.20

Und wenn die Geräte vorhanden sind kann man so etwas vor einer Umstellung schnell einmal durchtesten ob alles klappt oder nimmt erstmal einen AP in das Szenario, testet und stellt dann den Rest um.

[Aushilfsinformatiker]

Vielen Dank für die Rückmeldung. Wenn ich am Mittwoch den WLC eingerichtet habe, probiere ich mit privaten Geräten, ob ich mit veränderter Benutzer-ID das VLAN mit einem Gerät wechseln kann. Ich gebe hier auch eine Rückmeldung.

Viele Grüße

[Aushilfsinformatiker]

Hallo, hier eine kleine Rückmeldung. Zu Beginn hat der WLC 2000 das Profil nicht auf den Test-AP ausgerollt. Nach einer Stunde fummeln war es nur die Firmware des AP.
Die Zuweisung der VLAN-ID's per Nutzernamen gehen problemlos. Ich habe ein privates iPad zuerst am RADIUS angemeldet, dann später am PublicSpot und bin zum Radius wieder zurück. Alles kein Problem.
Also habe ich jetzt für alle Netzwerke nur eine SSID und für Gäste einen PublicSpot (nicht über WLC-Tunnel). Nächste Woche rolle ich das Profil auf alle AP's aus, welche noch an die Wand müssen.
Ich bin fast am überlegen den PublicSpot still zulegen und dann lieber ein Gäste-VLAN einzurichten mit automatisch ablaufenden Benutzern. Das Problem ist nur, wenn der Benutzer sich irgendwann mit einem neuen Zugang einwählen will, wird die Verbindung verweigert. Das Netzwerk muss auf den Clienten "vergessen" werden. Beim PublicSpot ist das kein Problem.

Viele Grüße