12
Aufbau controllerbasiertes WLAN, Controller und Access Points in eigenes VLAN
Hallo,
ich habe eine Frage zur Einrichtung eines controllerbasierten WLAN-Netzwerks und würde gerne mal eure Meinung dazu hören: Ist es sinnvoll oder bringt es irgendwelche Vorteile bzw. Nachteile die WLAN-Hardware, also Controller, Access Points und evtl. Radius-Server in ein eigenes VLAN zu setzten? Über dieses VLAN soll dann nur die Kommunikation zwischen der WLAN-Infrastruktur-Hardware stattfinden, also etwa Synchronisierung der Konfiguration usw., die Nutzerdaten gehen durch separate VLANs.
ich habe eine Frage zur Einrichtung eines controllerbasierten WLAN-Netzwerks und würde gerne mal eure Meinung dazu hören: Ist es sinnvoll oder bringt es irgendwelche Vorteile bzw. Nachteile die WLAN-Hardware, also Controller, Access Points und evtl. Radius-Server in ein eigenes VLAN zu setzten? Über dieses VLAN soll dann nur die Kommunikation zwischen der WLAN-Infrastruktur-Hardware stattfinden, also etwa Synchronisierung der Konfiguration usw., die Nutzerdaten gehen durch separate VLANs.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 192825
Url: https://administrator.de/forum/aufbau-controllerbasiertes-wlan-controller-und-access-points-in-eigenes-vlan-192825.html
Ausgedruckt am: 23.12.2024 um 07:12 Uhr
12 Kommentare
Neuester Kommentar
Das ist nicht nur sinnvoll das MUSST du sogar so machen und ist eine gängige Vorgehensweise. Andernfalls würde sich das management VLAN für das WLAN bzw. die Komponeten in einem Produktiv VLAN befinden, was ein absolutes NoGo ist allein schon aus Sicherheitsgründen.
Dieses Design setzt man immer so egal ob die Accesspoints im Tunnelmode oder mit Local Termination betrieben werden.
Das management VLAN benötigst du immer !
Dieses Design setzt man immer so egal ob die Accesspoints im Tunnelmode oder mit Local Termination betrieben werden.
Das management VLAN benötigst du immer !
nimm nur nicht zu viele SSIDs, da jede für sich eine Grundlast in einem gesharten Medium erzeugt.
Hallo,danke für die Antwort. Dann kommt bei mir aber noch eine Frage auf: Wie gehe ich am Besten vor, wenn das Management-VLAN über einen Router hinweg ausgedehnt werden muss (2. Gebäude, 1 Gbit LWL-Anbindung)? Es soll dann local Termination eingesetzt werden, ich habe aber im Handbuch des Controllers gelesen, dass automatisch ein Tunnel für die Nutzerdaten verwendet wird, wenn zwischen WLAN-Controller und Access Point ein Router sitzt. Das ganze müsste also so sein, dass der Router in dem Mgmt-VLAN gar nicht wahrgenommen wird. Ich hatte als erstes an Subinterfaces auf dem Router gedacht, aber dann bekommt man von dem Router ja immer noch was mit.
Das ist eine Frage des Designs und der Praktikabilität.
Man kann es auch recht kompliziert aufziehen wenn einem danach ist - besser wirds dadurch nicht, eher fehleranfälliger.
So genannte "NoGos aus sicherheitsgründen" sind auch recht dehnbar, jede Firma wird das ein bisschen anders sehen, was als "sicher genug" oder als "unsicher" anzusehen ist. Hier muss jeder selber entscheiden, welche potentiellen Risiken in seiner Umgebung existieren oder nicht existieren und welche Massnahmen man im spezifischen Fall für "ausreichend sicher" oder "eher vernachlässigbar" ansehen möchte. Wichtig ist lediglich, die IT Verantwortlichen verständlich über potentielle Risiken zu informieren (die meistens eher akademischer Natur sind), hier nicht übervorsichtig zu sein (Anfängerfehler..) und vor lauter Sicherheits-Panik den Dienst quasi unbrauchbar zu machen. Manche Dinge wie "völlig offenes WLAN" dagegen sind NoGos, da hilft gelegentlich der gesunde Menschenverstand, Fachwissen und Erfahrung, ein gesundes Verhältnis zwischen Wirtschaftlichkeit, Sicherheit und Handhabbarkeit zu ermitteln.
Wenn ich beispielsweise in Marseilles Urlaub machen will würde ich das Auto wohl in eine überwachte Tiefgarage stellen und nicht auf offener Strasse.
In Hintertupfing kann ich das Auto jedoch auch unabgeschlossen vor dem Haus abstellen, die Chance dass einer nachts ins Auto kackt ist recht gering.
So ist halt alles "relativ" und man passt seine Paranoia der Umgebung und der Realität an. Wer das anders handhaben will kann dies gerne tun - wir sind ein freies Land!
In meiner Umgebung ist es so dass es völlig unerheblich ist, in welchem VLAN der Access Point hängt.
Er hängt im ganz normalen User-LAN und ist so sehr flexibel einsetzbar ohne viele Umstände (Switchport umkonfigurieren entfällt wenn man einen der mobilen APs mal wo anders betreiben will).
Der AP tunnelt den relevanten WLAN Traffic eh zum WLAN Controller, der in einem anderen Netz steht.
DHCP kann vom WLC via DHCP Relay angesprochen werden und den WLAN Clients IP verpassen.
An externen Standorten laufen die APs im HREAP Modus und die Clients erhalten dort die IP vom lokalen DHCP.
Man kann es auch recht kompliziert aufziehen wenn einem danach ist - besser wirds dadurch nicht, eher fehleranfälliger.
So genannte "NoGos aus sicherheitsgründen" sind auch recht dehnbar, jede Firma wird das ein bisschen anders sehen, was als "sicher genug" oder als "unsicher" anzusehen ist. Hier muss jeder selber entscheiden, welche potentiellen Risiken in seiner Umgebung existieren oder nicht existieren und welche Massnahmen man im spezifischen Fall für "ausreichend sicher" oder "eher vernachlässigbar" ansehen möchte. Wichtig ist lediglich, die IT Verantwortlichen verständlich über potentielle Risiken zu informieren (die meistens eher akademischer Natur sind), hier nicht übervorsichtig zu sein (Anfängerfehler..) und vor lauter Sicherheits-Panik den Dienst quasi unbrauchbar zu machen. Manche Dinge wie "völlig offenes WLAN" dagegen sind NoGos, da hilft gelegentlich der gesunde Menschenverstand, Fachwissen und Erfahrung, ein gesundes Verhältnis zwischen Wirtschaftlichkeit, Sicherheit und Handhabbarkeit zu ermitteln.
Wenn ich beispielsweise in Marseilles Urlaub machen will würde ich das Auto wohl in eine überwachte Tiefgarage stellen und nicht auf offener Strasse.
In Hintertupfing kann ich das Auto jedoch auch unabgeschlossen vor dem Haus abstellen, die Chance dass einer nachts ins Auto kackt ist recht gering.
So ist halt alles "relativ" und man passt seine Paranoia der Umgebung und der Realität an. Wer das anders handhaben will kann dies gerne tun - wir sind ein freies Land!
In meiner Umgebung ist es so dass es völlig unerheblich ist, in welchem VLAN der Access Point hängt.
Er hängt im ganz normalen User-LAN und ist so sehr flexibel einsetzbar ohne viele Umstände (Switchport umkonfigurieren entfällt wenn man einen der mobilen APs mal wo anders betreiben will).
Der AP tunnelt den relevanten WLAN Traffic eh zum WLAN Controller, der in einem anderen Netz steht.
DHCP kann vom WLC via DHCP Relay angesprochen werden und den WLAN Clients IP verpassen.
An externen Standorten laufen die APs im HREAP Modus und die Clients erhalten dort die IP vom lokalen DHCP.
Zitat von @PSaR04:
Tunnel für die Nutzerdaten verwendet wird, wenn zwischen WLAN-Controller und Access Point ein Router sitzt.
Aber, wenn das VLAN der Verbindung im Wege steht, dann klappt das mit den Routen nicht.Tunnel für die Nutzerdaten verwendet wird, wenn zwischen WLAN-Controller und Access Point ein Router sitzt.
Ja, gute Controller können über den Layer 3 hinweg die APs managen. Das ist auch logisch, da die Kommunikation nicht mehr zwischen den APs sondern via den Controller läuft. Hier ist nicht die Nutzlast sondern das Management gemeint (Login, Handover, Lastverteilung, upgrades, ...).
Das geht sogar so weit, dass man über größere Infrastrukturen die selben Zugangsdaten aber getrennte Broadcastdomänen nutzen kann.
Gruß
Netman
Zitat von @MrNetman:
> Zitat von @PSaR04:
> Tunnel für die Nutzerdaten verwendet wird, wenn zwischen WLAN-Controller und Access Point ein Router sitzt.
Aber, wenn das VLAN der Verbindung im Wege steht, dann klappt das mit den Routen nicht.
Ja, gute Controller können über den Layer 3 hinweg die APs managen. Das ist auch logisch, da die Kommunikation nicht
mehr zwischen den APs sondern via den Controller läuft. Hier ist nicht die Nutzlast sondern das Management gemeint (Login,
Handover, Lastverteilung, upgrades, ...).
Das geht sogar so weit, dass man über größere Infrastrukturen die selben Zugangsdaten aber getrennte
Broadcastdomänen nutzen kann.
Gruß
Netman
> Zitat von @PSaR04:
> Tunnel für die Nutzerdaten verwendet wird, wenn zwischen WLAN-Controller und Access Point ein Router sitzt.
Aber, wenn das VLAN der Verbindung im Wege steht, dann klappt das mit den Routen nicht.
Ja, gute Controller können über den Layer 3 hinweg die APs managen. Das ist auch logisch, da die Kommunikation nicht
mehr zwischen den APs sondern via den Controller läuft. Hier ist nicht die Nutzlast sondern das Management gemeint (Login,
Handover, Lastverteilung, upgrades, ...).
Das geht sogar so weit, dass man über größere Infrastrukturen die selben Zugangsdaten aber getrennte
Broadcastdomänen nutzen kann.
Gruß
Netman
Ich habe aber in der Anleitung des HP MSM760 folgendes gelesen (Seite 106, http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c0352263 ..):
When a VSC is access-controlled, client traffic that is sent between the AP and controller can
be carried in the client data tunnel. This provides the following benefits:
• User traffic is segregated from the backbone network and can only travel to the controller.
• Underlying network topology is abstracted enabling full support for L2-connected users
across routed networks.
The client data tunnel is always used when the connection between a controlled AP and its
controller traverses at least one router. The client data tunnel supports NAT traversal, so it can
cross routers that implement NAT.
Sehe jetzt keine Widerspruch zu den vorherigen Ausführungen.
Can be carried in the client data tunnel. Wird also bei Bedarf vom Rest getrennt.
Der normale L2 Betrieb wird abstrahiert um die Roomingfähigkeit, also den typischen WLAN-Aufbau trotz L3 Netz zu gewährleisten. Bei L3 Infrastrukturen muss immer ein Tunnel bestehen. Ob der aber die Benutzerdaten transportieren soll, ist Designsache.
Abhängig von der Größe des Netzwerks kann man eben verschiedene Szenarien wählen.
Can be carried in the client data tunnel. Wird also bei Bedarf vom Rest getrennt.
Der normale L2 Betrieb wird abstrahiert um die Roomingfähigkeit, also den typischen WLAN-Aufbau trotz L3 Netz zu gewährleisten. Bei L3 Infrastrukturen muss immer ein Tunnel bestehen. Ob der aber die Benutzerdaten transportieren soll, ist Designsache.
Abhängig von der Größe des Netzwerks kann man eben verschiedene Szenarien wählen.
Richtig... Bestätigt ja damit die Aussage von oben das der Tunneltraffic auch über Layer 3 Grenzen laufen kann !!
Das ist so oder so gängiger Standard bei Controller basierten WLANs. Wäre ja auch Blödsinn wenn man das nur L2 basierend machen könnte, damit wären dann für so ein Produkt L3 segmentierte Netze tabu.
Kein Hersteller würde so einen Unsinn machen logischerweise.
Ansonsten gilt das was Kollege spacyfreak schon absolut korrekt ausgeführt hat oben zu diesem Thema.
Das ist so oder so gängiger Standard bei Controller basierten WLANs. Wäre ja auch Blödsinn wenn man das nur L2 basierend machen könnte, damit wären dann für so ein Produkt L3 segmentierte Netze tabu.
Kein Hersteller würde so einen Unsinn machen logischerweise.
Ansonsten gilt das was Kollege spacyfreak schon absolut korrekt ausgeführt hat oben zu diesem Thema.
Ich glaube, ich sollte das mal einfach ausprobieren. Mich hatte nur folgendes stutzig gemacht: "The client data tunnel is always used when the connection between a controlled AP and its controller traverses at least one router." und vor allem im Zusammenhang mit "This [der Client-Data-Tunnel] provides the following benefits: User traffic is segregated from the backbone".
Hört sich für mich ehrlich gesagt immer noch ein bisschen nach folgendem an: Der Tunnel wird immer benutzt, wenn ein Router zwischen AP und Controller ist und der Tunnel dient dazu die Benutzerdaten zum Controller zu tunneln - unabhängig davon, ob man ein VLAN für die local Termination angegeben hat oder nicht.
Hört sich für mich ehrlich gesagt immer noch ein bisschen nach folgendem an: Der Tunnel wird immer benutzt, wenn ein Router zwischen AP und Controller ist und der Tunnel dient dazu die Benutzerdaten zum Controller zu tunneln - unabhängig davon, ob man ein VLAN für die local Termination angegeben hat oder nicht.
Ja, klar.
Hinter dem Router ist ja kein Layer 2 mehr, also muss er einen anderen Weg wählen.
Das VLAN separiert ja nur bis zum Router.
Hinter dem Router ist ja kein Layer 2 mehr, also muss er einen anderen Weg wählen.
Das VLAN separiert ja nur bis zum Router.
Wenn nur die Authentifizierung über den Tunnel stattfindet wäre das ja in Ordnung, wenn aber auch die Nutzerdaten bis zum Controller getunnelt werden nicht, da die Daten dann 2x über den Router laufen (1x zum Controller hin und dann zurück zum Ziel, das sich vielleicht im selben Netz wie der AP befindet).
Nachtrag:
Wenn man über VoIP over WLAN nachdenkt, dann ist es zwingend notwendig, dass der komplette Verkehr über den Controller gesteuert und geleitet wird. Sonst hat man keine Chance die kurzen Unterbrechungszeiten zu realisieren. Hier geht es um doppelten Verkehr, um Pufferung und viele Parameter, die in den Herstellerprospekten dann als Vorhersage / prediction erwähnt werden.
Bei normaler WLAN Nutzung wäre das nicht notwendig, wenngleich es das Design des WLAN vereinfacht.
Aber - und diese Sorge kann ich verstehen, man benötigt richtig dicke Uplinks, da der Verkehr mehrfach durchgeleitet wird.
Gruß
Netman
Wenn man über VoIP over WLAN nachdenkt, dann ist es zwingend notwendig, dass der komplette Verkehr über den Controller gesteuert und geleitet wird. Sonst hat man keine Chance die kurzen Unterbrechungszeiten zu realisieren. Hier geht es um doppelten Verkehr, um Pufferung und viele Parameter, die in den Herstellerprospekten dann als Vorhersage / prediction erwähnt werden.
Bei normaler WLAN Nutzung wäre das nicht notwendig, wenngleich es das Design des WLAN vereinfacht.
Aber - und diese Sorge kann ich verstehen, man benötigt richtig dicke Uplinks, da der Verkehr mehrfach durchgeleitet wird.
Gruß
Netman
