WLAN Netzwerkwechsel in anderes Subnetz bei gleichen WLAN Netz (SSID usw.)
Hallo zusammen,
ich suche Tipps/Lösungen für folgendes Szenario.
Wir habe ein Firmennetz das in 2 VLANs unterteilt ist. Die Kommunikation funktioniert tadellos nur haben wir Probleme wenn ein Mitarbeiter mit seinem Notebook aus dem ein VLAN1 in das andere VLAN2 geht oder andersrum. In beiden VLANs sind WLAN Access Points verbaut welche genau identische SSIDs und Kennwörter haben. Die WLANs werden auch sauber verbunden, allerdings bekommt der WLAN Adapter des Notebooks dann keine neue IP Adresse, eben aus dem anderen VLAN1 vom DHCP Server zugewiesen und hat dann mit der „alten“ IP Adresse natürlich keinen Netzwerkzugriff. Deaktiviere ich den WLAN Adapter kurz und aktiviere ihn wieder bekommt der Client eine IP Adresse aus dem VLAN2 Bereich und alles funktioniert nur suche ich nach einer Lösung die mir das erspart.
Hier nochmal die Daten
VLAN 1 : 192.168.10.X 255.255.255.0
VLAN 2 : 192.168.11.X 255.255.255.0
DHCP Server: Windows Server 2012 mit 2 Adressbereichen für die beiden VLANs
Im VLAN2 werden DHCP Anfragen per Relay an den Windows Server weitergegeben.
ich suche Tipps/Lösungen für folgendes Szenario.
Wir habe ein Firmennetz das in 2 VLANs unterteilt ist. Die Kommunikation funktioniert tadellos nur haben wir Probleme wenn ein Mitarbeiter mit seinem Notebook aus dem ein VLAN1 in das andere VLAN2 geht oder andersrum. In beiden VLANs sind WLAN Access Points verbaut welche genau identische SSIDs und Kennwörter haben. Die WLANs werden auch sauber verbunden, allerdings bekommt der WLAN Adapter des Notebooks dann keine neue IP Adresse, eben aus dem anderen VLAN1 vom DHCP Server zugewiesen und hat dann mit der „alten“ IP Adresse natürlich keinen Netzwerkzugriff. Deaktiviere ich den WLAN Adapter kurz und aktiviere ihn wieder bekommt der Client eine IP Adresse aus dem VLAN2 Bereich und alles funktioniert nur suche ich nach einer Lösung die mir das erspart.
Hier nochmal die Daten
VLAN 1 : 192.168.10.X 255.255.255.0
VLAN 2 : 192.168.11.X 255.255.255.0
DHCP Server: Windows Server 2012 mit 2 Adressbereichen für die beiden VLANs
Im VLAN2 werden DHCP Anfragen per Relay an den Windows Server weitergegeben.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 286889
Url: https://administrator.de/contentid/286889
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Das wird auch so bleiben.
a) LAN:
Solange der Netzwerk-Adapter von DHCP-Server einen Release-Stamp erhalten hat, ist es egal, was da netzseitig ankommt: Der Rechner ist mit einem Netzwerk verbunden und wird sich nicht vollautomatisch mit einem anderen Netzwerk verbinden.
b)WLAN
Das Netzwerk wird anhand der SSID erkannt, und da sich die beim Wechsel von VLAN1 nach VLAN2 oder umgekehrt nichts ändert, bleibt die einmal eingerichtete Verbindung analog zu a) bestehen.
Alternativ kannst Du noch ein /release /renew per ipconfig losschicken, wenn der Wechsel von VLAN1 nach VLAN2 geschieht, aber ohne Unterbrechung/Deaktivierung des Netzwerk-Adapters wird sich in der gegebenen Konstellation nichts ändern.
Gruß J chem
Es bleibt die alte bestehen bis ich den Adapter einmal deaktiviere.
Das wird auch so bleiben.
a) LAN:
Solange der Netzwerk-Adapter von DHCP-Server einen Release-Stamp erhalten hat, ist es egal, was da netzseitig ankommt: Der Rechner ist mit einem Netzwerk verbunden und wird sich nicht vollautomatisch mit einem anderen Netzwerk verbinden.
b)WLAN
Das Netzwerk wird anhand der SSID erkannt, und da sich die beim Wechsel von VLAN1 nach VLAN2 oder umgekehrt nichts ändert, bleibt die einmal eingerichtete Verbindung analog zu a) bestehen.
Alternativ kannst Du noch ein /release /renew per ipconfig losschicken, wenn der Wechsel von VLAN1 nach VLAN2 geschieht, aber ohne Unterbrechung/Deaktivierung des Netzwerk-Adapters wird sich in der gegebenen Konstellation nichts ändern.
Gruß J chem
Grundsätzlich ist dein Design nicht falsch und kann man so machen.
Es so das wenn ein Roaming passiert die WLAN Verbindung am Client kurz unterbrochen wir und mit dem neuen AP auf den geroamed wird die Verbindung neu negotiated wird.
Diese kurzzeitige Unterbrechung erzwingt dann auch einen DHCP Request, denn der Client muss sich vergewissern das seine IP Adresse noch stimmt.
Letztlich ist das genau das was du machst wenn du den Adapter deaktivierst und wieder aktivierst !
Leider schreibst du mit keinem Wort ob deine WLAN Lösung Controller basierend ist
Vermutlich ist sie das aber nicht, was den großen Nachteil hat das dann das Roaming allein nur durch den Client bestimmt und ausgelöst wird. Sog. Client basiertes Roaming.
In der Regel funktioniert das aber sehr sehr schlecht, da sehr oft schlampig in den Treibern implementiert. Besonders bei Billigchipsätzen.
Was hier dann passiert ist das der Client quasi so lange an seinem einmal assoziierten AP "klebt" bist die Funkfeldstärke zu diesem dedizierten AP komplett abbricht. Er bleibt auch dann weiter "kleben" wenn um ihn herum weitere APs mit erheblich besserer Feldstärke und gleicher SSID liegen.
Das liegt daran das die Assoziierung mit dem AP nicht auf Basis der SSID passiert sondern auf der sog. BSSID !
Die BSSID ist immer die dedizierte Mac Adresse des APs.
Was bei dir also vermutlich passiert ist das die Feldstärken der APs des einen Gebäudes noch teilweise gerade so eben ausreichen im anderen Gebäude so das es zu keinem Roaming Event an den Clients kommt.
Folglich dann auch nicht zum Negotiaten eines neuen APs und damit einer neuen IP Adresse (DHCP).
Das kannst du mit einem WLAN Sniffer (Nirsoft, inSSIDer etc.) einmal ganz genau messen:
InSSIDer nicht mehr kostenlos
Die generelle Frage ist auch ob du ein sauberes Funkkanal Design gemacht hast innerhalb der Gebäude mit dem entsprechenden 4 kanaligen Abstand der Zellen ? Auch das kann sowas auslösen wenn das nicht richtig konfiguriert ist. Siehe hier:
Seit WLAN Umstellung von Cisco WAP 200 auf Zyxel NWA3560-N schlechtere Verbindung
Oft hilft es die WLAN Treiber auf die aktuellen Treiber des Chipsatz Herstellers wie z.B. Realtek, Intel etc. upzudaten und NICHT die Default Treiber von Windows usw. zu verwenden. In vielen Fällen mildert das das Problem so das ein Arbeiten möglich ist.
Die Grundursache ist ein Client basiertes Roaming.
Deshalb wird es auch gar nichts nützen wenn du die SSID umstellst wie oben unsinnigerweise geraten. Allein eine intelligente Frequenzplanung und ein Minimieren der Sendeleistung der APs die ggf. ins andere Gebäude senden können kann hier helfen.
Oder natürlich indem du dein WLAN auf ein Controller basiertes WLAN umstellst.
Viele moderne APs (Ubiquity, Lancom, Motorola, Ruckus, Meru etc.) können auch innerhalb eines WLANs eine Controller Funktion übernehmen. Ggf. hast du auch solche APs die diese Option haben. Das würde auch helfen.
Leider kommt zur verwendeten HW ja auch hier keinerlei Infos deinerseits
Es so das wenn ein Roaming passiert die WLAN Verbindung am Client kurz unterbrochen wir und mit dem neuen AP auf den geroamed wird die Verbindung neu negotiated wird.
Diese kurzzeitige Unterbrechung erzwingt dann auch einen DHCP Request, denn der Client muss sich vergewissern das seine IP Adresse noch stimmt.
Letztlich ist das genau das was du machst wenn du den Adapter deaktivierst und wieder aktivierst !
Leider schreibst du mit keinem Wort ob deine WLAN Lösung Controller basierend ist
Vermutlich ist sie das aber nicht, was den großen Nachteil hat das dann das Roaming allein nur durch den Client bestimmt und ausgelöst wird. Sog. Client basiertes Roaming.
In der Regel funktioniert das aber sehr sehr schlecht, da sehr oft schlampig in den Treibern implementiert. Besonders bei Billigchipsätzen.
Was hier dann passiert ist das der Client quasi so lange an seinem einmal assoziierten AP "klebt" bist die Funkfeldstärke zu diesem dedizierten AP komplett abbricht. Er bleibt auch dann weiter "kleben" wenn um ihn herum weitere APs mit erheblich besserer Feldstärke und gleicher SSID liegen.
Das liegt daran das die Assoziierung mit dem AP nicht auf Basis der SSID passiert sondern auf der sog. BSSID !
Die BSSID ist immer die dedizierte Mac Adresse des APs.
Was bei dir also vermutlich passiert ist das die Feldstärken der APs des einen Gebäudes noch teilweise gerade so eben ausreichen im anderen Gebäude so das es zu keinem Roaming Event an den Clients kommt.
Folglich dann auch nicht zum Negotiaten eines neuen APs und damit einer neuen IP Adresse (DHCP).
Das kannst du mit einem WLAN Sniffer (Nirsoft, inSSIDer etc.) einmal ganz genau messen:
InSSIDer nicht mehr kostenlos
Die generelle Frage ist auch ob du ein sauberes Funkkanal Design gemacht hast innerhalb der Gebäude mit dem entsprechenden 4 kanaligen Abstand der Zellen ? Auch das kann sowas auslösen wenn das nicht richtig konfiguriert ist. Siehe hier:
Seit WLAN Umstellung von Cisco WAP 200 auf Zyxel NWA3560-N schlechtere Verbindung
Oft hilft es die WLAN Treiber auf die aktuellen Treiber des Chipsatz Herstellers wie z.B. Realtek, Intel etc. upzudaten und NICHT die Default Treiber von Windows usw. zu verwenden. In vielen Fällen mildert das das Problem so das ein Arbeiten möglich ist.
Die Grundursache ist ein Client basiertes Roaming.
Deshalb wird es auch gar nichts nützen wenn du die SSID umstellst wie oben unsinnigerweise geraten. Allein eine intelligente Frequenzplanung und ein Minimieren der Sendeleistung der APs die ggf. ins andere Gebäude senden können kann hier helfen.
Oder natürlich indem du dein WLAN auf ein Controller basiertes WLAN umstellst.
Viele moderne APs (Ubiquity, Lancom, Motorola, Ruckus, Meru etc.) können auch innerhalb eines WLANs eine Controller Funktion übernehmen. Ggf. hast du auch solche APs die diese Option haben. Das würde auch helfen.
Leider kommt zur verwendeten HW ja auch hier keinerlei Infos deinerseits
OK, sagt aber nichts aus über die Kanalverteilung, Leistungsregelung und ALLEM anderen was im o.g. Beitrag angesprochen wurde.
TP-Link ist natürlich billigster China Schrott. Klar das die keinerlei Controller basiertes Roaming supporten.
Dir bleiben dann nur die oben angesprochenen ToDos:
Das sollte dann reichen damit du wenigsten das Problem gefixt bekommst und erträglich arbeiten kannst. Mit den Billigstkomponenten wirst du das problem aber niemals komplett gelöst bekommen, das sollte dir hoffentlich klar sein.
Weisst du aber vermutlich auch selber..?!
TP-Link ist natürlich billigster China Schrott. Klar das die keinerlei Controller basiertes Roaming supporten.
Dir bleiben dann nur die oben angesprochenen ToDos:
- Firmware der APs auf den aktuellsten Stand bringen
- Aktuellste Treiber der WLAN Chipsatz Hersteller verwenden auf den Clients.
- Saubere Kanalplanung der AP Zellen UND Ausleuchtungs Check mit einem der o.g. WLAN Sniffer (Feldstärke) und ggf. Leistungsreduzierung im AP an den Gebäudegrenzen.
Das sollte dann reichen damit du wenigsten das Problem gefixt bekommst und erträglich arbeiten kannst. Mit den Billigstkomponenten wirst du das problem aber niemals komplett gelöst bekommen, das sollte dir hoffentlich klar sein.
Weisst du aber vermutlich auch selber..?!