16
Aufbau WLAN-Netzwerk - Wie Daten aus VLANs über Router leiten?
Hallo,
ich bin dabei ein WLAN-Netzwerk aufzubauen. Zum Einsatz kommen Access Points von HP (MSM460) und ein WLAN-Controller MSM760. WLAN soll in mehreren Gebäuden zur Verfügung stehen, die zum Teil durch Router verbunden sind. Der WLAN-Controller mit RADIUS-Authentifizierung usw. läuft bereits und auch einige Access Points im Gebäude 3 (siehe Zeichnung) sind bereits funktionsfähig. Die Access Points werden in einem eigenen VLAN und IP-Subnetz vom WLAN-Controller verwaltet. Die Daten der WLAN-Clients werden direkt am Access Point "entkoppelt" und in das Netzwerk geleitet. Soweit so gut.
Jetzt soll das Netzwerk auch auf andere Gebäude ausgeweitet werden, als Beispiel Gebäude 4. Das ist jetzt auch der Grund, warum ich hier nachfrage. Wie kann ich das Management VLAN für die Access Points bis in das Gebäude 4 ausweiten, immerhin sind 2 Router dazwischen? Sollte ich das Ganze über Subinterfaces auf den Routern machen mit verschiedenen Subnetzen und dann die Kommunikation per ACL steuern? Oder ist es besser einen Tunnel (GRE, L2TP o.ä.) aufzubauen, durch den das VLAN geleitet wird? Wäre es überhaupt sinnvoll das VLAN so weit auszudehnen, wegen größerer Broadcastdomäne usw.?
Der Core-Router, der Router in Gebäude 1 und einem weiteren Gebäude (nicht eingezeichnet) soll in den nächsten Monaten getauscht und zwischen diesen ein Dreieck/Ring aufgebaut werden. Außerdem soll pro Team ein VLAN eingerichtet werden, in das auch die WLAN-Daten der Teammitglieder eingeleitet werden. Als Krönung sollen sich dann etwa Mitglieder aus Team 3 auch im Gebäude 4 per WLAN verbinden können und in "ihrem" VLAN sein mit den entsprechenden Berechtigungen. Wie macht man das am Besten?
Ich bin für alle Antworten und Tipps dankbar.
Gruß
PSaR04
ich bin dabei ein WLAN-Netzwerk aufzubauen. Zum Einsatz kommen Access Points von HP (MSM460) und ein WLAN-Controller MSM760. WLAN soll in mehreren Gebäuden zur Verfügung stehen, die zum Teil durch Router verbunden sind. Der WLAN-Controller mit RADIUS-Authentifizierung usw. läuft bereits und auch einige Access Points im Gebäude 3 (siehe Zeichnung) sind bereits funktionsfähig. Die Access Points werden in einem eigenen VLAN und IP-Subnetz vom WLAN-Controller verwaltet. Die Daten der WLAN-Clients werden direkt am Access Point "entkoppelt" und in das Netzwerk geleitet. Soweit so gut.
Jetzt soll das Netzwerk auch auf andere Gebäude ausgeweitet werden, als Beispiel Gebäude 4. Das ist jetzt auch der Grund, warum ich hier nachfrage. Wie kann ich das Management VLAN für die Access Points bis in das Gebäude 4 ausweiten, immerhin sind 2 Router dazwischen? Sollte ich das Ganze über Subinterfaces auf den Routern machen mit verschiedenen Subnetzen und dann die Kommunikation per ACL steuern? Oder ist es besser einen Tunnel (GRE, L2TP o.ä.) aufzubauen, durch den das VLAN geleitet wird? Wäre es überhaupt sinnvoll das VLAN so weit auszudehnen, wegen größerer Broadcastdomäne usw.?
Der Core-Router, der Router in Gebäude 1 und einem weiteren Gebäude (nicht eingezeichnet) soll in den nächsten Monaten getauscht und zwischen diesen ein Dreieck/Ring aufgebaut werden. Außerdem soll pro Team ein VLAN eingerichtet werden, in das auch die WLAN-Daten der Teammitglieder eingeleitet werden. Als Krönung sollen sich dann etwa Mitglieder aus Team 3 auch im Gebäude 4 per WLAN verbinden können und in "ihrem" VLAN sein mit den entsprechenden Berechtigungen. Wie macht man das am Besten?
Ich bin für alle Antworten und Tipps dankbar.
Gruß
PSaR04
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 204162
Url: https://administrator.de/contentid/204162
Printed on: April 23, 2024 at 17:04 o'clock
16 Comments
Latest comment
Hallo,
das kommt im wesnetlichen auf die vorhandene HArdware an?
Was für Router setzt du den ein?
brammer
das kommt im wesnetlichen auf die vorhandene HArdware an?
Was für Router setzt du den ein?
brammer
Das sind leider nicht alles die gleichen Router, aber immerhin alles welche von Cisco. Ich kann leider gerade nicht nachgucken, wo welcher sitzt, sorry, einer von denen müsste aber ein ISR 2921 sein. Da die Router aber wie bereits geschrieben zum Teil getauscht werden sollen (Modell noch offen) wäre es mir erstmal wichtiger welche Lösung sich überhaupt anbieten würde um das Vorhaben zu realisieren.
Hallo,
wenn du eh alles in Cisco hast soltlest du auch dabei bleiben...
Und, dann bietet sich doch Trunking an.
du baust zwischen den einzelnen Gebäuden einfache Trunk Verbindungen auf.
Der Sinn eines Cisco Trunks ist ja, das die VLAN Informationen mitübertragen werden...
Wenn dein Switch im Core Bereich ein L3 Switch solltest du überlegen ob du dort auch das Gebäude 4 anbindest und nicht am Router, das umgeht eine Verbindung, ist aber eher Kosmetik.
brammer
wenn du eh alles in Cisco hast soltlest du auch dabei bleiben...
Und, dann bietet sich doch Trunking an.
du baust zwischen den einzelnen Gebäuden einfache Trunk Verbindungen auf.
Der Sinn eines Cisco Trunks ist ja, das die VLAN Informationen mitübertragen werden...
Wenn dein Switch im Core Bereich ein L3 Switch solltest du überlegen ob du dort auch das Gebäude 4 anbindest und nicht am Router, das umgeht eine Verbindung, ist aber eher Kosmetik.
brammer
Welche Router das sind ist auch eher unerheblich wenn die Gebäudeverbindiung rein auf Routing bzw. Layer 3 basiert, was ja auch ein gängiges und sinnvolles Design ist.
Leider war man ja beim WLAN nicht so konsequent und hat da ne HP Billiglösung akzeptiert, aber auch damit ist das Vorhaben problemlos umsetzbar.
Sind die unterschiedlichen SSIDs in den Gebäuden auf VLANs gemappt wie es hier beschrieben ist:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern __> Abschnitt Praxisbeispiel ?
Wenn dem so ist kannst du die VLANs transparent und logisch getrennt nur über einen tagged Uplink (802.1q) auf andere Switches im Netz übertragen.
Generell ist das kein Problem und auch das übliche Design bei dir dann nur pro Gebäude, da die Gebäude ja selber rein per Routing also L3 verbunden sind.
Mit Routing würdes du diese Netze alle zusammenführen und müsstest dann mit Firewall oder Accesslisten wieder eine nachträgliche Trennung vornehmen. Auf den ersten Blick ein hinderliches Design im WLAN Umfeld was es aber nicht ist mit dem richtigen WLAN Setup und Layer 3 Roaming mit dem du leben musst durch die L3 Trennung ! Kann man nur hoffen das Billigheimer HP L3 Roaming supportet ?! Deren WLAN Lösung ist ja auch nix eigenes sondern das haben die von Colubris gekauft.
http://www.crn.de/netzwerke-tk/artikel-5589.html
Nix eigenes also was bei HP ja auch mehr als verwunderlich wäre...
Interpretiert man aber dein Bild von oben hast du also ein rein geroutetes Design !
Dein großer Vorteil ist das du einen WLAN Controller betreibst, da ist eine Lösung Kinderleicht:
Du betreibst alle APs in den einzelnen Gebäuden im Tunnel Mode, tunnelst also den Traffic der einzelnen APs zentral zum WLAN Controller. Jeder WLAN Lösung supportet das.
Am Controller selber machst du dann wieder die Aufteilung in die separaten SSIDs zu VLANs (sofern du multiple SSIDs verwendest ?!) über einen tagged Link vom Controller gehst du dann wieder auf deine dortige Switch Infrastruktur und hast die einzelnen WLANs wieder getrennt vorliegen.
Das ist ein Allerweltsszenario was so gut wie alle WLAN Controller su umsetzen.
Einzieger Nachteil ist das das nicht besonders skaliert, da du ja jeglichen AP Traffic getunnelt zentral zum Controller bringen musst ! Besser wäre eine sog. "local Termination" am AP sofern deine WLAN Lösung sowas supportet.
Nachteil für dich ist dann aber das du das in jedem Gebäude dann auch wieder lokal routen müsstest mit den Nachteiel der Trennung Accesslisten, Firewall etc.
Vermutlich ist also eher das was du willst die Tunnellösung ?!
Die Zuweisung der Clients zu den entspechenden VLANs ist da eher banal. Das macht man mit dem Radius Server und 802.1x sowie dynamischer VLAN Zuweisung an den APs.
Das ist eher eine Banalität, die mit 3 Mausklicks im Controller aktiviert wird.
Grundlagen dazu erklären diese Tutorials:
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
und
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Leider war man ja beim WLAN nicht so konsequent und hat da ne HP Billiglösung akzeptiert, aber auch damit ist das Vorhaben problemlos umsetzbar.
Sind die unterschiedlichen SSIDs in den Gebäuden auf VLANs gemappt wie es hier beschrieben ist:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern __> Abschnitt Praxisbeispiel ?
Wenn dem so ist kannst du die VLANs transparent und logisch getrennt nur über einen tagged Uplink (802.1q) auf andere Switches im Netz übertragen.
Generell ist das kein Problem und auch das übliche Design bei dir dann nur pro Gebäude, da die Gebäude ja selber rein per Routing also L3 verbunden sind.
Mit Routing würdes du diese Netze alle zusammenführen und müsstest dann mit Firewall oder Accesslisten wieder eine nachträgliche Trennung vornehmen. Auf den ersten Blick ein hinderliches Design im WLAN Umfeld was es aber nicht ist mit dem richtigen WLAN Setup und Layer 3 Roaming mit dem du leben musst durch die L3 Trennung ! Kann man nur hoffen das Billigheimer HP L3 Roaming supportet ?! Deren WLAN Lösung ist ja auch nix eigenes sondern das haben die von Colubris gekauft.
http://www.crn.de/netzwerke-tk/artikel-5589.html
Nix eigenes also was bei HP ja auch mehr als verwunderlich wäre...
Interpretiert man aber dein Bild von oben hast du also ein rein geroutetes Design !
Dein großer Vorteil ist das du einen WLAN Controller betreibst, da ist eine Lösung Kinderleicht:
Du betreibst alle APs in den einzelnen Gebäuden im Tunnel Mode, tunnelst also den Traffic der einzelnen APs zentral zum WLAN Controller. Jeder WLAN Lösung supportet das.
Am Controller selber machst du dann wieder die Aufteilung in die separaten SSIDs zu VLANs (sofern du multiple SSIDs verwendest ?!) über einen tagged Link vom Controller gehst du dann wieder auf deine dortige Switch Infrastruktur und hast die einzelnen WLANs wieder getrennt vorliegen.
Das ist ein Allerweltsszenario was so gut wie alle WLAN Controller su umsetzen.
Einzieger Nachteil ist das das nicht besonders skaliert, da du ja jeglichen AP Traffic getunnelt zentral zum Controller bringen musst ! Besser wäre eine sog. "local Termination" am AP sofern deine WLAN Lösung sowas supportet.
Nachteil für dich ist dann aber das du das in jedem Gebäude dann auch wieder lokal routen müsstest mit den Nachteiel der Trennung Accesslisten, Firewall etc.
Vermutlich ist also eher das was du willst die Tunnellösung ?!
Die Zuweisung der Clients zu den entspechenden VLANs ist da eher banal. Das macht man mit dem Radius Server und 802.1x sowie dynamischer VLAN Zuweisung an den APs.
Das ist eher eine Banalität, die mit 3 Mausklicks im Controller aktiviert wird.
Grundlagen dazu erklären diese Tutorials:
Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch
und
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
@brammer: Was Cisco-Trunking ist, ist mir klar, aber das geht doch nicht so einfach zwische Routern, oder?
@aqui: Bisher gibt es nur in Gebäude 3 WLAN, dort gibt es eine SSID für Mitarbeiter (VLAN wird per Microsoft NPS zugewiesen) und eine Gast-SSID, die Gast-Daten werden zum Controller getunnelt (HP proprietär).
L3-Roaming wird auch von HP unterstützt. Es ist dort wie folgt vorgesehen: Wenn ein User sich per WLAN verbindet, dessen zugewiesenes VLAN/Subnetz nicht am Access Point verfügbar ist, werden die Daten zum Controller getunnelt und dort in das VLAN des Users geleitet (am Controller müssen also alle VLANs aller User verfügbar sein). Eine Weiterleitung der Daten an einen Access Point, der mit dem VLAN des entsprechenden Users verbunden ist, ist nicht möglich (das macht den Controller natürlich in gewissem Maße zum Flaschenhals, weshalb ich auch möglichst wenig über den Controller leiten möchte). Ist jemandem bekannt, ob das bei anderen Herstellern möglich ist bzw. weiß einer wie andere Hersteller das machen?
Nein, ich habe nicht ein komplett geroutetes Design, am Core-Switch hängen noch weitere Switche in anderen Gebäuden (das Größte mit ca. 200 Geräten im Netz). Ich hatte das nur weggelassen, da es mir auf die Verbindung der VLANs über die Router ankam.
Local Termination wird unterstützt und für die Mitarbeiter auch eingesetzt. Wie du aber erkannt hast sind die Daten dann z. B. in Gebäude 4 in VLAN6 (Team 6) oder etwa VLAN 3 (Team 3). Im Fall von VLAN 3 in Gebäude 4 müssten die Geräte in dem VLAN aber auch z. B. den Server in Gebäude 2 (ebenfalls VLAN 3) erreichen können. Und das war halt meine ursprüngliche Frage, wie man sowas am Besten macht (sorry, falls das nicht ganz klar geworden ist).
Meine Idee war entweder die Daten von Teammitgliedern, die nicht an ihrem Hauptarbeitsplatz sind (Team 3 = Gebäude 2, Team 6 = Gebäude 4) zum Controller zu tunneln und von dort aus weiterzuleiten. Beispiel für Gebäude 4: Die Daten von Mitgliedern aus Team 6 werden am Access Point terminiert, die Daten von Mitgliedern aus Team 3 werden zum Controller getunnelt und von dort aus weitergeleitet (was ist am Besten, Routing, GRE/L2TP-Tunnel zum Router in Gebäude 2?). Die Alternative, die mir einfiele, wäre auch die Daten des Teams 3 im Gebäude 4 lokal zu terminieren und dann weiterzuleiten. Also am Router (Richtung Switch) Subinterfaces einzurichten (siehe Zeichnung), das Routing zwischen den Netzen zu blocken und dann auf der anderen Seite (Richtung Core Router) auch Subinterfaces? Das wäre nur alles recht umständlich, da man dann ja für das VLAN 3 in Gebäude 4 und 2 und womöglich noch für die Router zu Router verbindungen verschiedene IP-Subnetze bräuchte und für jeden Bereich wieder einen DHCP-Relay usw. oder bin ich da auf dem Holzweg??
Einfacher wäre alles in einem rein geswitchten Netzwerk, die Router in den Gebäuden 1 und 2 ließen sich auch ohne größere Probleme gegen Switche austauschen, bei Gebäude 4 würde das allerdings schon schwieriger (hier müsste man gegebenenfalls tunneln). Aber würde das überhaupt Sinn machen die Router zu entfernen oder leidet dann die Performance zu sehr bei so großen Layer 2 Netzwerken (ca. 1800 Endgeräte)?
@aqui: Bisher gibt es nur in Gebäude 3 WLAN, dort gibt es eine SSID für Mitarbeiter (VLAN wird per Microsoft NPS zugewiesen) und eine Gast-SSID, die Gast-Daten werden zum Controller getunnelt (HP proprietär).
L3-Roaming wird auch von HP unterstützt. Es ist dort wie folgt vorgesehen: Wenn ein User sich per WLAN verbindet, dessen zugewiesenes VLAN/Subnetz nicht am Access Point verfügbar ist, werden die Daten zum Controller getunnelt und dort in das VLAN des Users geleitet (am Controller müssen also alle VLANs aller User verfügbar sein). Eine Weiterleitung der Daten an einen Access Point, der mit dem VLAN des entsprechenden Users verbunden ist, ist nicht möglich (das macht den Controller natürlich in gewissem Maße zum Flaschenhals, weshalb ich auch möglichst wenig über den Controller leiten möchte). Ist jemandem bekannt, ob das bei anderen Herstellern möglich ist bzw. weiß einer wie andere Hersteller das machen?
Nein, ich habe nicht ein komplett geroutetes Design, am Core-Switch hängen noch weitere Switche in anderen Gebäuden (das Größte mit ca. 200 Geräten im Netz). Ich hatte das nur weggelassen, da es mir auf die Verbindung der VLANs über die Router ankam.
Local Termination wird unterstützt und für die Mitarbeiter auch eingesetzt. Wie du aber erkannt hast sind die Daten dann z. B. in Gebäude 4 in VLAN6 (Team 6) oder etwa VLAN 3 (Team 3). Im Fall von VLAN 3 in Gebäude 4 müssten die Geräte in dem VLAN aber auch z. B. den Server in Gebäude 2 (ebenfalls VLAN 3) erreichen können. Und das war halt meine ursprüngliche Frage, wie man sowas am Besten macht (sorry, falls das nicht ganz klar geworden ist).
Meine Idee war entweder die Daten von Teammitgliedern, die nicht an ihrem Hauptarbeitsplatz sind (Team 3 = Gebäude 2, Team 6 = Gebäude 4) zum Controller zu tunneln und von dort aus weiterzuleiten. Beispiel für Gebäude 4: Die Daten von Mitgliedern aus Team 6 werden am Access Point terminiert, die Daten von Mitgliedern aus Team 3 werden zum Controller getunnelt und von dort aus weitergeleitet (was ist am Besten, Routing, GRE/L2TP-Tunnel zum Router in Gebäude 2?). Die Alternative, die mir einfiele, wäre auch die Daten des Teams 3 im Gebäude 4 lokal zu terminieren und dann weiterzuleiten. Also am Router (Richtung Switch) Subinterfaces einzurichten (siehe Zeichnung), das Routing zwischen den Netzen zu blocken und dann auf der anderen Seite (Richtung Core Router) auch Subinterfaces? Das wäre nur alles recht umständlich, da man dann ja für das VLAN 3 in Gebäude 4 und 2 und womöglich noch für die Router zu Router verbindungen verschiedene IP-Subnetze bräuchte und für jeden Bereich wieder einen DHCP-Relay usw. oder bin ich da auf dem Holzweg??
Einfacher wäre alles in einem rein geswitchten Netzwerk, die Router in den Gebäuden 1 und 2 ließen sich auch ohne größere Probleme gegen Switche austauschen, bei Gebäude 4 würde das allerdings schon schwieriger (hier müsste man gegebenenfalls tunneln). Aber würde das überhaupt Sinn machen die Router zu entfernen oder leidet dann die Performance zu sehr bei so großen Layer 2 Netzwerken (ca. 1800 Endgeräte)?
OK, wenn du das L3 Design nur aus Sicht des Core Switches dargestellt hast, dann hast du ja die Option das du die WLAN VLANs transparent über .1q Uplinks auch in alle Gebäude bringen kannst. Damit wäre dein Problem dann auf Schlag gelöst.
Dann kannst du local Termination machen an den APs und alles ist gut.
So wie hier:
sähe ja auch ein zentralisiertes L3 Netzwerk mit Routing auf mit HSRP oder VRRP geclusterten Core Switches. "Access" wäre hier bei dir ein Gebäude oder ein Gebäude Netzwerk aus mehreren Switches.
Deine Darstellung oben sah so aus als ob du Point to Point IP Netze zwischen den Gebäuden betreibst und da nativ routest, was ja auch ein gängiges Szenario ist um eine entsprechende Skalierbarkeit zu gewährleisten.
Wenn es aber so aussieht wie ein klassisches Core Design ziehst du eben einfach die WLAN VLANs überall dahin wo APs sind und gut ist. Damit ist dein Problem dann sofort gelöst.
Routest du doch wider Erwarten nativ zw. den Gebäuden hast du ja keinerlei Chance das so zu realisieren, da du L2 VLANs mit einen .1q Uplink natürlich niemals über Routergrenzen bekommst...logisch.
Dann bleiben dir also nur L3 Roaming.
D.h. du implementierst pro Gebäude auch diese einzelnen WLAN VLANs ebenso wie mit einer zentralisierten Lösung allerdings nun mit unterschiedlichen und eindeutiger IP Adressierung. Sprich die Teammitglieder haben zwar wieder ihre getrennten WLAN VLANs pro SSID aber mit unterschiedlicher IP Adressierung pro Gebäude. Klar, muss so sein, denn sonst wäre ein Routing nicht möglich.
DAS sind deine beiden Optionen die du hast...obwohl wenn du wirklich nativ routest hast du ja nur die letzte Option.
Das was du da oben mit dem Router aufgemalt hast ist Unsinn oder nur bedingt richtig.
Leider ist nicht wirklich klar wie dein Layer 3 Konzept aussieht...das macht einen zielführende Antwort so schwierig.
Wenn du kein L3 Switching in den Gebäuden machst, sprich da also alles flach und dumm hast und diese Netze nur rein routest auf den Core dann ja... dann macht das obige mit den Subinterfaces durchaus Sinn, denn damit terminierst du die WLAN VLANs ja auf dem Router und routest zwischen diesen und auch dem Core.
Das wäre dann absolut der richtige Weg um das WLAN Konzept im L3 Umfeld so zu realisieren...klar. Alternative ohne VLANs und Subinterfaces ist dann wieder tunneln auf den WLAN Controller !
Normalerweise hat man da aber ja keine Router sondern L3 Switches. Und die entweder im Gebäude selber um da lokal zu routen und den gerouteten Traffic auf den Core forzuwarden. Dann gilt obiges auch..klar !
Hier ist dann in den einzelnen Gebäuden auch local termination möglich. Willst du keine VLAN Aufteilung hier kannst du nur zentral tunneln zum Controller eine andere Option gibts dann nicht...auch klar.
Oder... zentrale L3 Switches im Core selber an denen die Gebäude per .1q Uplinks terminieren. Dann wäre obiges Unsinn, denn dann würde man nur die WLAN VLANs per .1q Uplink in die Gebäude bringen, arbeitet mit local Termination an den APs und gut.
Das sind die Rahmenbedingungen....
Dann kannst du local Termination machen an den APs und alles ist gut.
So wie hier:
Deine Darstellung oben sah so aus als ob du Point to Point IP Netze zwischen den Gebäuden betreibst und da nativ routest, was ja auch ein gängiges Szenario ist um eine entsprechende Skalierbarkeit zu gewährleisten.
Wenn es aber so aussieht wie ein klassisches Core Design ziehst du eben einfach die WLAN VLANs überall dahin wo APs sind und gut ist. Damit ist dein Problem dann sofort gelöst.
Routest du doch wider Erwarten nativ zw. den Gebäuden hast du ja keinerlei Chance das so zu realisieren, da du L2 VLANs mit einen .1q Uplink natürlich niemals über Routergrenzen bekommst...logisch.
Dann bleiben dir also nur L3 Roaming.
D.h. du implementierst pro Gebäude auch diese einzelnen WLAN VLANs ebenso wie mit einer zentralisierten Lösung allerdings nun mit unterschiedlichen und eindeutiger IP Adressierung. Sprich die Teammitglieder haben zwar wieder ihre getrennten WLAN VLANs pro SSID aber mit unterschiedlicher IP Adressierung pro Gebäude. Klar, muss so sein, denn sonst wäre ein Routing nicht möglich.
DAS sind deine beiden Optionen die du hast...obwohl wenn du wirklich nativ routest hast du ja nur die letzte Option.
Das was du da oben mit dem Router aufgemalt hast ist Unsinn oder nur bedingt richtig.
Leider ist nicht wirklich klar wie dein Layer 3 Konzept aussieht...das macht einen zielführende Antwort so schwierig.
Wenn du kein L3 Switching in den Gebäuden machst, sprich da also alles flach und dumm hast und diese Netze nur rein routest auf den Core dann ja... dann macht das obige mit den Subinterfaces durchaus Sinn, denn damit terminierst du die WLAN VLANs ja auf dem Router und routest zwischen diesen und auch dem Core.
Das wäre dann absolut der richtige Weg um das WLAN Konzept im L3 Umfeld so zu realisieren...klar. Alternative ohne VLANs und Subinterfaces ist dann wieder tunneln auf den WLAN Controller !
Normalerweise hat man da aber ja keine Router sondern L3 Switches. Und die entweder im Gebäude selber um da lokal zu routen und den gerouteten Traffic auf den Core forzuwarden. Dann gilt obiges auch..klar !
Hier ist dann in den einzelnen Gebäuden auch local termination möglich. Willst du keine VLAN Aufteilung hier kannst du nur zentral tunneln zum Controller eine andere Option gibts dann nicht...auch klar.
Oder... zentrale L3 Switches im Core selber an denen die Gebäude per .1q Uplinks terminieren. Dann wäre obiges Unsinn, denn dann würde man nur die WLAN VLANs per .1q Uplink in die Gebäude bringen, arbeitet mit local Termination an den APs und gut.
Das sind die Rahmenbedingungen....
1Zitat von @aqui:
OK, wenn du das L3 Design nur aus Sicht des Core Switches dargestellt hast, dann hast du ja die Option das du die WLAN VLANs
transparent über .1q Uplinks auch in alle Gebäude bringen kannst. Damit wäre dein Problem dann auf Schlag
gelöst.
Dann kannst du local Termination machen an den APs und alles ist gut.
So wie hier:
sähe ja auch ein zentralisiertes L3 Netzwerk mit Routing auf mit HSRP oder VRRP geclusterten Core Switches.
"Access" wäre hier bei dir ein Gebäude oder ein Gebäude Netzwerk aus mehreren Switches.
Deine Darstellung oben sah so aus als ob du Point to Point IP Netze zwischen den Gebäuden betreibst und da nativ routest,
was ja auch ein gängiges Szenario ist um eine entsprechende Skalierbarkeit zu gewährleisten.
Wenn es aber so aussieht wie ein klassisches Core Design ziehst du eben einfach die WLAN VLANs überall dahin wo APs sind und
gut ist. Damit ist dein Problem dann sofort gelöst.
Routest du doch wider Erwarten nativ zw. den Gebäuden hast du ja keinerlei Chance das so zu realisieren, da du L2 VLANs mit
einen .1q Uplink natürlich niemals über Routergrenzen bekommst...logisch.
Dann bleiben dir also nur L3 Roaming.
D.h. du implementierst pro Gebäude auch diese einzelnen WLAN VLANs ebenso wie mit einer zentralisierten Lösung
allerdings nun mit unterschiedlichen und eindeutiger IP Adressierung. Sprich die Teammitglieder haben zwar wieder ihre getrennten
WLAN VLANs pro SSID aber mit unterschiedlicher IP Adressierung pro Gebäude. Klar, muss so sein, denn sonst wäre ein
Routing nicht möglich.
DAS sind deine beiden Optionen die du hast...obwohl wenn du wirklich nativ routest hast du ja nur die letzte Option.
Das was du da oben mit dem Router aufgemalt hast ist Unsinn oder nur bedingt richtig.
Leider ist nicht wirklich klar wie dein Layer 3 Konzept aussieht...das macht einen zielführende Antwort so schwierig.
Wenn du kein L3 Switching in den Gebäuden machst, sprich da also alles flach und dumm hast und diese Netze nur rein routest
auf den Core dann ja... dann macht das obige mit den Subinterfaces durchaus Sinn, denn damit terminierst du die WLAN VLANs ja auf
dem Router und routest zwischen diesen und auch dem Core.
Das wäre dann absolut der richtige Weg um das WLAN Konzept im L3 Umfeld so zu realisieren...klar. Alternative ohne VLANs und
Subinterfaces ist dann wieder tunneln auf den WLAN Controller !
Normalerweise hat man da aber ja keine Router sondern L3 Switches. Und die entweder im Gebäude selber um da lokal zu routen
und den gerouteten Traffic auf den Core forzuwarden. Dann gilt obiges auch..klar !
Hier ist dann in den einzelnen Gebäuden auch local termination möglich. Willst du keine VLAN Aufteilung hier kannst du
nur zentral tunneln zum Controller eine andere Option gibts dann nicht...auch klar.
Oder... zentrale L3 Switches im Core selber an denen die Gebäude per .1q Uplinks terminieren. Dann wäre obiges Unsinn,
denn dann würde man nur die WLAN VLANs per .1q Uplink in die Gebäude bringen, arbeitet mit local Termination an den APs
und gut.
Das sind die Rahmenbedingungen....
OK, wenn du das L3 Design nur aus Sicht des Core Switches dargestellt hast, dann hast du ja die Option das du die WLAN VLANs
transparent über .1q Uplinks auch in alle Gebäude bringen kannst. Damit wäre dein Problem dann auf Schlag
gelöst.
Dann kannst du local Termination machen an den APs und alles ist gut.
So wie hier:
"Access" wäre hier bei dir ein Gebäude oder ein Gebäude Netzwerk aus mehreren Switches.
Deine Darstellung oben sah so aus als ob du Point to Point IP Netze zwischen den Gebäuden betreibst und da nativ routest,
was ja auch ein gängiges Szenario ist um eine entsprechende Skalierbarkeit zu gewährleisten.
Wenn es aber so aussieht wie ein klassisches Core Design ziehst du eben einfach die WLAN VLANs überall dahin wo APs sind und
gut ist. Damit ist dein Problem dann sofort gelöst.
Routest du doch wider Erwarten nativ zw. den Gebäuden hast du ja keinerlei Chance das so zu realisieren, da du L2 VLANs mit
einen .1q Uplink natürlich niemals über Routergrenzen bekommst...logisch.
Dann bleiben dir also nur L3 Roaming.
D.h. du implementierst pro Gebäude auch diese einzelnen WLAN VLANs ebenso wie mit einer zentralisierten Lösung
allerdings nun mit unterschiedlichen und eindeutiger IP Adressierung. Sprich die Teammitglieder haben zwar wieder ihre getrennten
WLAN VLANs pro SSID aber mit unterschiedlicher IP Adressierung pro Gebäude. Klar, muss so sein, denn sonst wäre ein
Routing nicht möglich.
DAS sind deine beiden Optionen die du hast...obwohl wenn du wirklich nativ routest hast du ja nur die letzte Option.
Das was du da oben mit dem Router aufgemalt hast ist Unsinn oder nur bedingt richtig.
Leider ist nicht wirklich klar wie dein Layer 3 Konzept aussieht...das macht einen zielführende Antwort so schwierig.
Wenn du kein L3 Switching in den Gebäuden machst, sprich da also alles flach und dumm hast und diese Netze nur rein routest
auf den Core dann ja... dann macht das obige mit den Subinterfaces durchaus Sinn, denn damit terminierst du die WLAN VLANs ja auf
dem Router und routest zwischen diesen und auch dem Core.
Das wäre dann absolut der richtige Weg um das WLAN Konzept im L3 Umfeld so zu realisieren...klar. Alternative ohne VLANs und
Subinterfaces ist dann wieder tunneln auf den WLAN Controller !
Normalerweise hat man da aber ja keine Router sondern L3 Switches. Und die entweder im Gebäude selber um da lokal zu routen
und den gerouteten Traffic auf den Core forzuwarden. Dann gilt obiges auch..klar !
Hier ist dann in den einzelnen Gebäuden auch local termination möglich. Willst du keine VLAN Aufteilung hier kannst du
nur zentral tunneln zum Controller eine andere Option gibts dann nicht...auch klar.
Oder... zentrale L3 Switches im Core selber an denen die Gebäude per .1q Uplinks terminieren. Dann wäre obiges Unsinn,
denn dann würde man nur die WLAN VLANs per .1q Uplink in die Gebäude bringen, arbeitet mit local Termination an den APs
und gut.
Das sind die Rahmenbedingungen....
Ok, das hat mir auf jeden Fall schon mal ein ganzes Stück weitergeholfen. Einige Gebäude (u. a. Gebäude 4) sind wirklich klassisch per Router angebunden, andere aber per L3-Switch. Für mich ist dann der Plan erstmal klar: Wo möglich local termination an den APs einsetzen und in Zukunft ausbauen (sprich Router gegen L3-Switche tauschen). Wo es jetzt noch nicht möglich ist (wegen den Routern) werde ich erstmal zum Controller tunneln.
Dann hätte ich aber doch noch eine Frage zum L3-Roaming. Ich habe mal aufgezeichnet, wie die Daten beim L3-Roaming von HP durchs Netzwerk wandern (siehe blaue Pfeile auf dem Bild). Die Daten werden also über den Controller geleitet, wo es eventuell mal zu einem Bandbreiten-Engpass kommen könnte. Ich habe mir dann gedacht, dass es doch Sinn machen könnte, wenn die Daten von einem "geroamten" Client nicht über den WLAN-Controller zum Zielnetz geleitet werden, sondern an einem Access Point, der sowieso schon im Netz ist sozusagen wieder lokal terminiert werden (rote Pfeile). Gibt es so eine Lösung bei irgendwelchen Herstellern?
"sprich Router gegen L3-Switche tauschen" das ist eigentlich die falsche Schlussfolgerung und muss nicht sein !
Generell ist dein Netzwerk dadurch ja perfekt segmentiert und das WLAN wird auch mit L3 Roaming sauber funktionieren (...obwohl man bei Billigheimer HP nie wirklich weiss ob das sauber klappt).
Du machst da auch einen Denkfehler beim L3 Roaming in sofern stimmt deine Zeichnung nicht.
Ist die Team SSID identisch wird den WLAN Clients nur eine neue lokale IP in dem Gebäude WLAN bzw. VLAN zugewiesen. Dadurch das du die VLANs auf den lokalen Routern mit Subinterfaces terminierst passiert das Routing der Clients vor Ort dort auf den Routern und eben NICHT über den Controller sofern du mit local Termination arbeitest am AP.
Deine L3 Wege sind also viel zu kompliziert gedacht....
Generell ist dein Netzwerk dadurch ja perfekt segmentiert und das WLAN wird auch mit L3 Roaming sauber funktionieren (...obwohl man bei Billigheimer HP nie wirklich weiss ob das sauber klappt).
Du machst da auch einen Denkfehler beim L3 Roaming in sofern stimmt deine Zeichnung nicht.
Ist die Team SSID identisch wird den WLAN Clients nur eine neue lokale IP in dem Gebäude WLAN bzw. VLAN zugewiesen. Dadurch das du die VLANs auf den lokalen Routern mit Subinterfaces terminierst passiert das Routing der Clients vor Ort dort auf den Routern und eben NICHT über den Controller sofern du mit local Termination arbeitest am AP.
Deine L3 Wege sind also viel zu kompliziert gedacht....
...mir wären andere Hersteller auch lieber, aber wenn es halt Leute gibt, die mehr auf den Preis als auf die Leistung und problemlose Funktion achten...
Mhh, ich glaube es ist immer noch nicht ganz klar geworden, wie ich mir das wünschen würde, also nächster Versuch:
- Es gibt für die Mitarbeiter (ganz egal ob Team 3, 6 oder sonst was) nur 1 SSID, das zu verwendende VLAN wird per RADIUS-Server festgelegt. Anders geht es nicht, da ich bestimmt auf 20 Teams komme, aber max. 16 SSIDs pro Accesss Point unterstützt werden.
- Alle Access Points sind im Management VLAN für die Accesss Points (VLAN 7). Darüber hinaus haben die Access Points Zugriff auf einige Team-VLANs (aber nicht auf alle an jedem Standort). In dem Bild hat der obere Access Point z. B. noch Zugriff auf das VLAN 3 und der untere auf das VLAN 6.
- Wenn sich jetzt ein Mitglied aus Team 3 mit dem oberen Access Point verbindet, wird dem Access Point vom RADIUS-Server mitgeteilt, dass die Daten ins VLAN 3 sollen. Da der Access Point direkten Zugriff auf das VLAN 3 hat, werden die Daten lokal terminiert und der Client bekommt eine IP aus dem VLAN 3 (DHCP-Reservierung).
- Roamt jetzt der Client rüber zum unteren Access Point soll er die IP-Adresse behalten (sonst kommen einige Programme nicht klar und müssten neu gestartet werden, außerdem ist es firewallseitig leichter Berechtigungen zu steuern) und weiterhin im VLAN 3 bleiben. Da der AP aber feststellt, dass er lokal keinen Zugriff auf das VLAN 3 hat müssen die Daten getunnelt werden.
Und hier wirds jetzt interessant: Wenn die Daten zum Controller getunnelt und dort ins VLAN 3 geleitet werden, müsste dieses VLAN ja einen anderen IP-Adressbereich als das obere VLAN 3 haben, da zwischen diesen noch ein Router sitzt --> also wäre es nicht möglich, dass der Client nach dem Roaming seine IP behält. Es sei denn, die Daten könnten vom unteren Access Point zum oberen getunnelt werden, der ja direkten Zugriff auf das VLAN 3 hat in dem der Client vorher gewesen ist. Alternative wäre erst zum Controller und von dort aus in das VLAN 3 per GRE/L2TP/... tunneln.
Klar, ich könnte auch generell alle Daten zum Controller tunneln und dort in die per RADIUS zugewiesenen VLANs leiten, bloß das würde den Controller zum Flaschenhals machen.
..."die mehr auf den Preis als auf die Leistung und problemlose Funktion achten..." Das weisst du selber als ITler das sich Preis und problemlose Funktion gegenseitig ausschliessen. Außerdem bist DU der IT Entscheider, sprich der Fachmann der die fachliche Entscheidung zu fällen hast. Nicht unwissende Kaufleute...aber egal..ist ja hier nicht das Thema !
OK, wenn das Team WLAN nur eine SSID ist dann ist das einfach. Dann richtest du in jedem Gebäude das gleiche VLAN ein mit der gleichen ID die dann vom Radius immer zugewiesen wird.
Das in jedem Gebaude VLAN dann eine andere IP vergeben wird interessiert die dynamische VLAN Zuweisung ja nicht.
Wenn genau DAS aber nicht geht und die IPs immer gleich bleiben sollen, dann hast du erstmal ein größeres Problem. Dann geht es in der Tat nur so das das der Traffic dann virtuell zum Controller getunnelt werden muss wie du es oben richtig beschreibst. Anders wäre es ja nicht möglich wenn das VLAN pro Gebäude ein anderes IP Netz hast was ja durch dein Routing Umfeld zwingend ist.
Dann aber solltest du das gesamte Konstrukt nochmal überdenken ob du es wirklich so umsetzen willst !! Schwer managebar, nicht performant, nicht skalierbar. Wenn deine IP Infrastruktur sich mal ändert musst du alles das wieder mühsam anpassen...willst du das ?
Wenn du so oder so tunneln musst um die IP Adressen und Connectivity konstant zu halten wäre es dann im Endeffekt sinnvoller diese SSID der Teams generell zentral auf den Controller zu tunneln !!
Fast alle Hersteller können pro SSID wahlweise local Termination machen oder tunneln im Setup, es also per SSID bestimmen wie der Traffic Flow ist. Kann man nur hoffen das die HP oder besser Colubris Lösung das auch kann ?!
Damit tunnelst du dann generell diese Team SSID auf den Controller und terminierst das VLAN zentral da während andere SSIDs dann mit local Termination am AP arbeiten.
Letztlich ist das die bessere und skalierbarere Lösung als die Fricklei mit Mobile IP wie oben. Das macht den Controller dann einzig nur für diese Team SSID zum Flaschenhals (die anderen wo's auf feste IPs nicht so ankommt arbeiten dann weiter mit loc.Term.) aber das ist sicherlich tolerierbar wenn du einen Gigabit Backbone Struktur hast und die meisten deiner User im 2,4 Ghz Bereich arbeiten wo du so oder so kein strukturiertes WLAN mit 40 Mhz Bandbreite betreiben kannst. Dort ist 20 Mhz Pflicht und damit sind die max. möglichen Datenraten pro AP tolerabel für sowas !
Darüber solltest du mal nachdenken...? Technisch besser und einfacher mangebar ist dann dieser Weg !
OK, wenn das Team WLAN nur eine SSID ist dann ist das einfach. Dann richtest du in jedem Gebäude das gleiche VLAN ein mit der gleichen ID die dann vom Radius immer zugewiesen wird.
Das in jedem Gebaude VLAN dann eine andere IP vergeben wird interessiert die dynamische VLAN Zuweisung ja nicht.
Wenn genau DAS aber nicht geht und die IPs immer gleich bleiben sollen, dann hast du erstmal ein größeres Problem. Dann geht es in der Tat nur so das das der Traffic dann virtuell zum Controller getunnelt werden muss wie du es oben richtig beschreibst. Anders wäre es ja nicht möglich wenn das VLAN pro Gebäude ein anderes IP Netz hast was ja durch dein Routing Umfeld zwingend ist.
Dann aber solltest du das gesamte Konstrukt nochmal überdenken ob du es wirklich so umsetzen willst !! Schwer managebar, nicht performant, nicht skalierbar. Wenn deine IP Infrastruktur sich mal ändert musst du alles das wieder mühsam anpassen...willst du das ?
Wenn du so oder so tunneln musst um die IP Adressen und Connectivity konstant zu halten wäre es dann im Endeffekt sinnvoller diese SSID der Teams generell zentral auf den Controller zu tunneln !!
Fast alle Hersteller können pro SSID wahlweise local Termination machen oder tunneln im Setup, es also per SSID bestimmen wie der Traffic Flow ist. Kann man nur hoffen das die HP oder besser Colubris Lösung das auch kann ?!
Damit tunnelst du dann generell diese Team SSID auf den Controller und terminierst das VLAN zentral da während andere SSIDs dann mit local Termination am AP arbeiten.
Letztlich ist das die bessere und skalierbarere Lösung als die Fricklei mit Mobile IP wie oben. Das macht den Controller dann einzig nur für diese Team SSID zum Flaschenhals (die anderen wo's auf feste IPs nicht so ankommt arbeiten dann weiter mit loc.Term.) aber das ist sicherlich tolerierbar wenn du einen Gigabit Backbone Struktur hast und die meisten deiner User im 2,4 Ghz Bereich arbeiten wo du so oder so kein strukturiertes WLAN mit 40 Mhz Bandbreite betreiben kannst. Dort ist 20 Mhz Pflicht und damit sind die max. möglichen Datenraten pro AP tolerabel für sowas !
Darüber solltest du mal nachdenken...? Technisch besser und einfacher mangebar ist dann dieser Weg !
.. "Außerdem bist DU der IT Entscheider, sprich der Fachmann der die fachliche Entscheidung zu fällen hast. Nicht unwissende Kaufleute..." Naja, in öffentlichen Einrichtungen ist das nicht immer so einfach, da gibt es halt bestimmte Budgets und das wars und in diesem Fall hatte ich mit der Kaufentscheidung nichts zu tun, ich muss das "bloß" einrichten. Eigentlich komme ich ja auch aus dem Cisco-Umfeld und vermisse einige Dinge, die dort für mich selbstverständlich waren, z. B. PVSTP oder die einfache VTP-Konfiguration, das ist mit GVRP schon was anderes...aber du hast Recht, das ist hier nicht Thema.
Wahlweise Tunnelung zum Controller ist möglich, es gibt die 3 Möglichkeiten immer, nie oder nur, wenn das entsprechende VLAN am Access Point nicht vorhanden ist.
Ich lasse mir das noch mal durch den Kopf gehen und spreche mit nem Kollegen darüber. Vielleicht ist Tunnelung doch besser, zumindest in den Bereichen wo ein Router dazwischen sitzt. Das was mich daran stört ist halt auch, dass dann z. B. aus Gebäude 4 (siehe allererste Zeichnung) die Daten erst komplett durchs Netz zum Controller gehen und dann noch mal zurück zum Server, der vor Ort steht (und ich hab noch gesagt lass mal besser den Controller mit den 10Gbit-Schnittstellen nehmen).
Dankeschön für die Tipps!
Grüße PSaR04
Wahlweise Tunnelung zum Controller ist möglich, es gibt die 3 Möglichkeiten immer, nie oder nur, wenn das entsprechende VLAN am Access Point nicht vorhanden ist.
Ich lasse mir das noch mal durch den Kopf gehen und spreche mit nem Kollegen darüber. Vielleicht ist Tunnelung doch besser, zumindest in den Bereichen wo ein Router dazwischen sitzt. Das was mich daran stört ist halt auch, dass dann z. B. aus Gebäude 4 (siehe allererste Zeichnung) die Daten erst komplett durchs Netz zum Controller gehen und dann noch mal zurück zum Server, der vor Ort steht (und ich hab noch gesagt lass mal besser den Controller mit den 10Gbit-Schnittstellen nehmen).
Dankeschön für die Tipps!
Grüße PSaR04
...und bitte nicht immer alles zitieren ! Wir können alle lesen hier im Forum...
Die Controller können auch alle Link Aggregation. Man kann dann mehrere 1 GiG Ports bündeln, 10 Gig ist nicht immer sinnvoll bei sowas und soooo viel Clients hast du ja nun auch nicht !
Wenn das denn war bitte dann auch
How can I mark a post as solved?
nicht vergessen !
Die Controller können auch alle Link Aggregation. Man kann dann mehrere 1 GiG Ports bündeln, 10 Gig ist nicht immer sinnvoll bei sowas und soooo viel Clients hast du ja nun auch nicht !
Wenn das denn war bitte dann auch
How can I mark a post as solved?
nicht vergessen !
Link-Aggregation geht bei den HP-Controllern eben nicht, zumindest ist mir noch kein Hinweis in irgendeiner Anleitung oder der Konfigurationsoberfläche entgegengekommen. Es gibt auch nur 2 Ports und der eine nimmt die Daten entgegen und der andere routet Richtung default Gateway. Das ist wohl auch so vorgesehen, zumindest haben die Ports auch die Bezeichnung "LAN" und "Internet".
Das wars dann aber auch.
PSaR04
Das wars dann aber auch.
PSaR04
Da zeigt sich dann wieder der Billigheimer.... Eigentlich kann das nicht sein denn das können auch Linksys, NetGear, D-Link und Co. heutzutage.
Vermutlich steht das im Handbuch unter "LACP" oder "LAG" oder "802.3ad". Wenn er es wirklich nicht kann wäre das mehr als ein schwaches Bild für die Hardware !!
Vermutlich steht das im Handbuch unter "LACP" oder "LAG" oder "802.3ad". Wenn er es wirklich nicht kann wäre das mehr als ein schwaches Bild für die Hardware !!
So ist das aber, ich habe mich gerade extra noch schlau gemacht: Der MSM720 (verwaltet max. 40 APs) unterstützt Trunks und hat auch 4 RJ45-Ports + 2 dual personality. Der von mir eingesetzte MSM760 Controller (bis 200 APs) kanns nicht und hat wie bereits geschrieben gerade mal 2 mickrige RJ45. Was das soll verstehe ich nicht, der Grund ist wohl noch bei Colubris zu suchen.
Ich hab übrigens noch eine nette Schote zu berichten: Anleitungen usw. hat HP alles schön mit dem eigenen Logo versehen und auch das Colubris Visitor Management Tool zum anlegen von Gastzugängen am PC in HP Guest Management Software umbenannt, wenn ich das Programm aber installiere wird dieses in der Systemsteuerung und Startmenü wieder als Colubris Visitor Management Tool angezeigt, das war HP wohl zu viel arbeit. Darüber hinaus steckt in den ganzen Radius-Attributen und DHCP-Optionen überall noch das Wort Colubris...
Ich hab übrigens noch eine nette Schote zu berichten: Anleitungen usw. hat HP alles schön mit dem eigenen Logo versehen und auch das Colubris Visitor Management Tool zum anlegen von Gastzugängen am PC in HP Guest Management Software umbenannt, wenn ich das Programm aber installiere wird dieses in der Systemsteuerung und Startmenü wieder als Colubris Visitor Management Tool angezeigt, das war HP wohl zu viel arbeit. Darüber hinaus steckt in den ganzen Radius-Attributen und DHCP-Optionen überall noch das Wort Colubris...
Was soll man da noch sagen.... HP eben 
Dank für das interessante Feedback !
Kann man mal sehen wie die ihre Zukäufe ins Unternehmen integrieren. Man kann wohl davon ausgehen das bei der Intergration der ProCurve Billigserie mit dem H3C/Huawei Kram es genauso kunterbunt zugeht...
Oder die sind noch dabei die Schnüffeltrojaner der Chinesen aus der Firmware zu entfernen
Na ja was solls wenns halt billich ist kauft die Schafherde ja immer kritiklos weil heute meist Einkäufer also Kaufleute entscheiden was die IT einsetzen darf.
Aber egal andere Baustelle....
Das sollte aber kein großer Hinderungsgrund sein für dich. Die Nettodatenrate ist im 2,4 Ghz Bereich eh gering und über Tagging kannst du das VLAN dieses Teams was du tunnelst ja auf einen separaten, einzelnen Gig Port geben.
Für die Performance reicht das allemal du hast ja nicht allzuviel User.
Der Rest ist ja eh lokal terminiert. Für das Mangement dieses WLANs ist das der einfachste Schritt.
Dank für das interessante Feedback !Kann man mal sehen wie die ihre Zukäufe ins Unternehmen integrieren. Man kann wohl davon ausgehen das bei der Intergration der ProCurve Billigserie mit dem H3C/Huawei Kram es genauso kunterbunt zugeht...
Oder die sind noch dabei die Schnüffeltrojaner der Chinesen aus der Firmware zu entfernen
Na ja was solls wenns halt billich ist kauft die Schafherde ja immer kritiklos weil heute meist Einkäufer also Kaufleute entscheiden was die IT einsetzen darf.
Aber egal andere Baustelle....
Das sollte aber kein großer Hinderungsgrund sein für dich. Die Nettodatenrate ist im 2,4 Ghz Bereich eh gering und über Tagging kannst du das VLAN dieses Teams was du tunnelst ja auf einen separaten, einzelnen Gig Port geben.
Für die Performance reicht das allemal du hast ja nicht allzuviel User.
Der Rest ist ja eh lokal terminiert. Für das Mangement dieses WLANs ist das der einfachste Schritt.
