Neues Netzwerkdesign mit VLAN Routing und Subnetting

@brammer: danke für den Tip, den ich wärmstens ans Herz nehmen werde. Ich werde für die WLAN-Gäste ein eigenes Subnet nehmen, dass sich von unseren anderen unterscheidet. Das ist eine gute Idee. Und wegen den VLAN-Interfaces, oh Gott! Natürlich hast du Recht, ich hab mich da total vertan und verschrieben. Für die jeweiligen Interfaceverwende ich hinten die .254 im jeweiligen Subnet. Also hat das VLAN2 die 172.19.2.254, das VLAN100 die 172.19.100.254, das VLAN200 die 172.19.200.254, usw... Ich wollte sagen: die anderen jeweiligen Switche im gesamten Netzwerk erhalten jeweils eine einzige IP-Adresse, und zwar auf ihr VLAN254 im 172.19.254.0 /24 subnet. Das heißt der root switch hat unter anderem (neben all den anderen VLAN IPs) die 172.19.254.254, der switch "foo" erhält das VLAN254 interface mit IP 172.19.254.2, der switch "bar" erhält das VLAN254 interface mit IP 172.19.254.3, usw...

Wenn ich also irgendwo 172.19.254.* sehe, dann weiß ich das es sich um 'nen switch handelt. Und wenn ich hinten an einer IP-Adresse *.*.*.254 sehe, dann weiß ich sofort, dass es das jeweilige VLAN254 interface an einem Switch ist. So zumindest meine Überlegung, wenn das passt, dann hak ich das so ab.

@emeriks: nunja, ich wäre nicht abgeneigt davon, weniger VLANs zu verwenden. Daher frage ich ja um Vorschläge und Meinungen, die ihr mir ja bereits zur Geltung bringt und wofür ich dankbar bin. Wie würde es denn ausschauen, wenn ich (nur mal angenommen) 230 Workstations, 200 Drucker und 180 Server hätte ? In ein und demselben VLAN (z.B. VLAN555) könnte ich sie ja problemlos konfigurieren, das ist nicht das Problem. Aber ich bräuchte ja 610 IP-Adressen, wie würde man das dann sinnvoll auf L3 konfigurieren? Würde ich ja jeweils ein eigenes Subnet nehmen (wie ich ja auch bereits so in meinem Ursprungspost geplant hatte, also die Workstations z.B. in 172.19.20.0/24, die Server in 172.19.100.0/24, und die Drucker in 172.19.103.0/24) dann hab ich ja nix anderes erreicht, denn die Netze müssten auf L3-Ebene sowieso wieder miteinander verbunden werden müssen, oder nicht? Der Vorteil wäre, ich spar mir halt 2 VLANs dadurch, aber ein wirklicher Vorteil ist das doch gar nicht, oder? Wenn ich jedoch 3 VLANs verwenden würde, dann würden z.B. Broadcasts von Druckern nicht in die andere zwei VLANs überschlagen. Bitte korrigier mich falls ich falsch liegen sollte. Oder meintest du, dass wenn diese drei Bereiche in ein einzige VLAN gedrückt werden, ich eine andere subnet-Maske nutzen sollte z.B. 172.18.100.0 /22 (subnet mask: 255.255.252.0) und die 610 Hosts dann dort reinnehme (IP-Bereich 172.18.100.1 bis 172.18.103.254) ?

@aqui:

Also ich sehe das genauso, diese zwei Bereiche möchte ich auf jeden Fall getrennt voneinander haben (also in VLANs). Das Backup-VLAN mit dem Server-VLAN vereinen sehe ich als akzeptabel, da habt ihr Recht. Wie bereits ein paar Sätze weiter oben gefragt, mich würde interessieren inwieweit man diese einzelne Segmente in gemeinsame VLANs packen könnte, und damit auch die IP-Adresse da alle reinpassen.


Dafür hatte ich ja eigentlich das VLAN253 vorgesehen. Dort möchte ich BMC-Netzwerkkarten reinnehmen, Bladecenter-Module und dessen MGMT-Interfaces, unsere ganzen USVs, Klimaanlagensteuerung im Serverraum, Heizungscontroller, und solche Sachen. Ich hab für die Switche+Router ein extra VLAN254 ausgewählt gehabt in meinem Ursprungspost, warum? Weil wenn ich dieses VLAN253 so beschränke, dass nur die Admins (=VLAN200) darauf zugreifen können, so würde ich die Kommunikation für alle restlichen Hosts lahmlegen. Eine Workstation A könnte über einen Netzwerkswitch hinweg nicht den Server erreichen, wenn er nämlich über einen Netzwerkswitch seine Route sucht, denn der Switch würde ja für Workstations im VLAN253 nicht erreichbar sein. Das war eigentlich mein Gedanke, deswegen habe ich Switches+Router in ein extra VLAN gepackt (=VLAN254). Dort hatte ich dann vor, lediglich den Admin-Zugriff (also serial line 0 4) zu beschränken, damit nur Admins draufkommen per Telnet (bzw. SSH). Ist diese Idee falsch? Wie sollte ich das deiner Meinung nach bewerkstelligen?


Das habe ich jetzt nicht verstanden, sorry. Im VLAN2 (=WLAN-INTRA) werden Handscanner im Kommissionierbereich eingesetzt. Das sind so tragbare Minicomputer (Intermec cn70) mit Barcodescanner und WindowsMobile. Die loggen sich per WLAN an der ESSID "INTRA" an, und die müssen nur einen einzigen Server (172.19.100.199) erreichen können, sonst nix. Die brauchen kein DNS, kein Gateway, kein Internet ... nur dieser Server. Erklär mir bitte wie du das genau gemeint hast mit dieser subnetmask 255.255.255.128 da ich solche Masken bisher nie eingesetzt habe. Ich verstehe die subnet mask, aber ich verstehe nicht wieso du das VLAN254 (die 172.19.254.* Addressen) erwähnst wo meine Netzwerkswitche doch drinhängen ?? Worauf wolltest du mit diesem Satz heraus, bitte erklär mir das etwas genauer. Sorry fürs momentane Nicht-Verstehen


Oh ok, das wußte ich nicht. Ich hab da auch was verwechselt. Ich spiele in letzter Zeit mit einem C3550 in einer isolierten Testdomäne herum und im irc-Channel #cisco hatte ich nachgefragt wegen SSH-Zugang. Da hatten die mir erklärt, dass es auf mein image drauf ankommt. Ich kann mich jetzt nicht mehr genau erinnern, die meinten ob ich irgendeinen bestimmten Textstring in meinem image-Namen sehen würde (Keine Ahnung, war das irgendwas mit der Zahl '8' oder so?). Wie auch immer, ich hatte das auf jeden Fall nicht in dem Imagenamen, weswegen die meinten, dass der Switch somit kein SSH bieten kann. Auf dem C3560 (unser aktuell produktiver root switch) hab ich das noch nicht durchgelesen und auch das image nicht gecheckt gehabt. "show running-config" zeigt mir zumindest am Ende der Ausgabe an, dass "line con 0", "line vty 0 4" und "line vty 5 15" vorhanden wären. Was auch immer das genau bedeutet, oder ob man daraus überhaupt erkennen kann, ob SSH unterstützt wird oder nicht. Sein image-file lautet "flash:c3560-ipbase-mz.122-25.SEB1/c3560-ipbase-mz.122-25.SEB1.bin" Noch 'ne doofe Frage: Ist das überhaupt ein Catalyst??? Ich sag immer Catalyst dazu, weil mich das C3560 dazu verleitet. Aber kann es sein, dass das gar kein Catalyst, sondern einfach nur ein C3560 ? Nicht lachen, aber ich hab keinen Schimmer. Die genaue Modellbezeichnung lautet WS-C3560G-24TS, scheinnt 12MB RAM zu haben. SW-Version ist 12.2(25)SEB1. Aber gut, ich werde das im Hinterkopf behalten und wenn's soweit ist, die Kommandos checken und ggf. SSH aktivieren. Danke für die Erklärung.

Interessant. Ich hab nicht gewußt was ein transparenter Proxy ist und wie der arbeitet. Laut der Wikipedia-Erklärung Transparenter Proxy scheint es ja eigentlich genau DAS zu sein, wonach ich gesucht hatte und womit das Problem gelöst wäre. (Übrigens: auf dem C3560 habe ich nach dem Kommando "wccp" vergebens gesucht, das gibt's wohl nicht?). Seh ich das richtig, dass ich quasi in meiner squid.conf den Eintrag hier einfach um das Wort "transparent" erweitern müßte? http_port 3128 transparent. Dann muss ich noch die iptable hier verwenden, richtig? iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 3128 Aber auf welchem Host??? Wenn ich diese rule auf dem squid Host ausführe, dann müssten die Clients ja die IP des squid-hosts als Gateway eingeben, das wiederum wäre ja blöd, weil die als default gateway eigentlich den 172.19.254.254 erhalten sollten. Wenn ich also auf meinem 172.19.254.254 das einrichten könnte, dass sämtliche Anfragen auf Port 80 an den Squid-Host (=172.19.100.101) weitergeschickt werden könnten, dann würde das ja passen, richtig?

Ich möchte jetzt nicht die einzelne Squid-Konfiguration vorgelegt bekommen, danach werde ich sicherlich noch googeln. Aber kannst du mir das Grundprinzip erläutern, wie das funktionieren soll? Laut Wikipedia muss am Client KEIN Proxy eingetragen werden. Wie findet denn also der Client den Weg zum Proxy? Muss man im Client statt dem Gateway (172.19.254.254) die IP-Adresse vom SquidProxy eintragen (das wäre dann die 172.19.100.101)?


Das wäre meine nächste Frage gewesen, ich hatte sie bewußt noch zurückgehalten, weil hier wieder mehr Details einfließen. Aber da du das ja bereits angesprochen hast ... Nunja, es sieht so aus: wir haben ca. 20 UbiQuiti Unifi AccessPoints im Einsatz mit der Software-Controller Version 3.1.9. Der software-controller kann auch das von dir angesprochene vouchet-basierte Hotspotzeugs liefern. Dazu kann man folgende Funktionen konfigurieren:

... jetzt muss ich mal nach der Möglichkeit suchen, Bilder hier einzufügen... irgendwie fehlt mir oben der Button, den ich erwarten würde.... meld mich gleich, werde gleich weiterschreiben...
EDIT:also vorab sorry, aber ich finde DEFINITIV keinen Link bei mir, wo ich Bilder hochladen könnte in meinem Beitrag. Die Hilfe-Seite habe ich natürlich bemüht, und auch eine Anleitung gefunden, die erklärt, wie man Bilder hochlädt. Bei mir sieht das jedoch ganz anders aus und von diesem Button weit und breit keine Spur daher poste ich jetzt mal die zwei Pics einfach so rein, damit ich den Beitrag fertig kriege...


Ich könnte hier also eintragen und konfigurieren, dass sämtliche WLAN-Clients, die sich unter der ESSID namens "FOOBAR-GUESTS" anmelden, automatisch dem VLAN 30 zugeordnet werden.

Aber die oben gezeigten Settings behalte ich doch bei, oder nicht? Sonst gelangen die Gäste ja nicht ins VLAN30 wie gewünscht? Auf meinem root switch (der via L3 alle VLANs wieder zusammenverbindet) muss ich dann halt die besagte ACL definieren, so daß VLAN30 exklusiv ins Internet gelangen darf. Am besten halt durch diesen transparenten Proxy, aber dazu muss ich mich noch schlauer machen wie das funktionieren würde (siehe Fragen oben)

Als Firewall setze ich IPFIRE ein, ich denke da kann man noch nach gusto weiter zudrehen, bzw. feinjustieren.

Ich dachte mir, dass ich über den cisco Switch die Basics via ACL definieren, also grad solche Sachen, dass die WLAN_Gäste nur ins INternet dürfen sollen und sonst nirgendswo, usw... alle weiteren Feinjustierungen würde ich dann über die IPFIRE regeln können, so denke ich hast du das gemeint, oder?

Jup Mit dem Zusatzfeauture, dass man die ACEs nachträglich verarbeiten kann, ohne die gesamte ACL löschen zu müssen. Zumindest hab ich das noch so in Erinerung aus den letzten Tagen beim zig Seiten lesen.

Das Prinzip habe ich jetzt begriffen, danke.


Du sagst quasi Verbiete Pakete mit der Quelle=ALLE und die als Ziel=172.19.0.0/16 haben. Diese ACL wendest du dann anschließend als IN auf dem Interface VLAN30 an, also so?

?

Macht das denn Sinn? Ich verstehe zwar den Hintergedanke, aber bei einem cisco-switch würde man ja keine Ausfälle erwarten oder Fehlfunktionen. Bringt mir also diese Aktion (außer den drastischen Mehraufwand, da ich in jedem anderen VLAN explizit VLAN30 blocke) wirklich Vorteile? Bitte mit Erklärung, damit ich das richtig verstehe.

HIer steig ich nicht richtig durch. Welche Firewall Hotspotlösung meinst du denn nun? Also meine Hotspot-Lösung hat keine Firewall, ich nutze eine extra Firewall in meinem Netzwerk.

Ich glaub ich verstehe was du meinst, aber ich verstehe noch nicht um welche Hotspot-Lösung es sich handelt Ich hab nämlich kein extra Gerät (=Hotspot) mit Firewallfunktion, denn meine Hotspot-Funktionalität würde der Software-Controller (=Software, keine Hardware!) von Ubiquiti übernehmen. Bitte klär mich diesbezüglich auf.

EIN DICKES DANKESCHÖN

@emeriks: danke für diese Info, werde ich beherzigen.

@all:

"sh ru" meines root switches zeigt mir:


Wenn ich die cisco-Seite nach diesem Model durchsuche, dann gibt es folgende Downloads. Macht es Sinn meinen Switch upzugraden? Mich verwirren all diese vielen Images und Bezeichnungen

http://abload.de/img/clipboard011bkjd.jpg

Es wird mir 12.2.55-SE9(ED) vorgeschlagen. Das müßte schonmal aktueller sein wie mein jetziges 12.2.(25)SEB1 nehme ich an. Aber was bedeutet denn SE9, ED, bzw. SEB1 bei meinem aktuellen image? Und was wenn ich die "latest" version = 15.0.2-SE6(ED) downloaden und installieren würde, geht das oder ist das inkompatibel?

EDIT: Ahja. Ich hab etwas weiter recherchiert. Und laut diesem Tool müßte mein derzeit eingesetztes Image demnach OHNE Crypto sein, denn der Dateiname des Images wäre exakt derselbe wie bei mir auch aktuell im Einsatz. Heißt das also, ohne Crypto doch kein SSH möglich?

http://abload.de/img/clipboard0296uii.jpg

Ich hab hier mal mein aktuelles image (=linke Seite) und das von Cisco-Download empfohlene image (=rechte Seite) als Vergleich darstellen lassen. Da gibt's halt doch viele Punkte, die sich unterscheiden. Die unique-Ausgabe zeigt quasi die Leistungen an, die das jeweilige Image beinhalten. Weiter unten stehen dann alle "gemeinsamen" Funktionen, die von beiden images geleistet werden.

http://abload.de/img/clipboard027br73.jpg
http://abload.de/img/clipboard034up02.jpg

Ah, du hast schon geantwortet, während ich meinen Beitrag editierte Also hab ich momentan kein Crypto und demnach kein SSH, richtig? Mit dem 12.2.55-SE9 (ED) hätte ich dann also crypto und kann SSH verwenden.

EDIT: Lese gerade. Wenn im image filename K9 auftaucht, dann heißt es dass es crypto unterstützt. Wenn nicht, dann eben wird kein crypto und ergo SSH geboten.

Werde ich mit diesem neueren image dann irgendwas vermissen? Was passiert eigentlich mit der Konfiguration bei solch einem update? Ich muss das halt schon planen, da es sich um einen produktiven root switch handelt. Wenn da irgendwas schief läuft hätte ich ein massives Problem und Zeitdruck. Kann ich notfalls zurück auf das alte image gehen, falls irgendwas schief läuft?

Hallo brammer,

danke für's feedback. Ich hatte leider früher Feierabend gemacht und vergessen, das zu posten. Ich hab das Image-Update an meinem Testswitch, dem C3550 durchgeführt. Dabei bin ich genauso vorgegangen, bis auf den Unterschied, dass ich eben /overwrite nehmen mußte, weil nicht genug Platz da war. Den "boot ..." Befehl mußte ich auch nicht machen, das hat der Upgradeprozess automatisch durchgeführt, ich hab mich mit "show boot" vergewissert. Nach einem reboot war das neue image aktiv, und meine ganzen Settings waren genauso wie vorher. Also alles bestens, war zufriedne mit der Aktion. Und das ging echt schnell.

@aqui: danke für den Hinweis. Ich werd leider die IPFire nicht abschaffen können und durch eine neue Lösung ersetzen können. Trotzdem werd ich mir das zu Gemüte führen und bei einem passenden Zeitpunkt in Erwägung ziehen und planen. Ich denke daher, momentan muss ich mit den Gegebenheiten klarkommen.


Ich versteh nicht worauf das jetz bezogen ist. Ich hab meinen eigenen Beitrag wieder durchgelesen, aber worum geht's denn überhaupt? Du sagst, ich hab VLAN2 und VLAN100 auf ein gemeinsames IP-Netz verteilt. Wo? Seh ich grad den Wald vor lauter Bäumen nicht? Zu VLAN2<-->VLAN100 Thematik hatte ich eigentlich in meiner Tabelle erwähnt, dass VLAN2 diese WLAN-INTRA Handscanner reinkommen sollen. Die wiederum sollen nur Kontakt zu einem einzigen Server aus VLAN100 haben. Also alle WLAN-Clients aus dem 192.168.2.0/24 Netzwerk dürfen lediglich den Server 192.168.100.199 erreichen dürfen und sonst gar nix. Daher war doch meine Idee, dies einfach durch eine extended ACL zu bewerkstelligen. Lieg ich damit komplett falsch? Wieso hast du mir hier vorgeschlagen ein IP-Netz zu splitten durch eine 25er Maske, ich versteh das nicht. Bitte erklär mir das genauer.

Ich würde gerne mal testweise anfangen ein VLAN in dem produktiv Netzwerk zu implementieren. Dazu würde ich gerne das WLAN-GUEST Netz aufbauen und hab hier und dort noch meine Hürden. Folgendes Szenario dazu:

WLAN-Clients (=smartphones, Tablets, Besucher, usw...) loggen sich auf das offene Netzwerk mit der ESSID "GUESTS" ein. Dazu müssen Sie einen Voucher-Einmalcode verwenden, den Sie von uns Admins ausgehändigt bekommen. Der gilt dann für 8h beispielsweise. Das ganze wird im software-Controller Ubiquiti geregelt (Ubiquiti UniFi UAP sind unsere AccessPoints). Dieses WLAN-Gastnetz hat die VLAN-ID 30 und läuft also unter VLAN30. Da weder der Ubiquiti-Softwarecontroller, noch die UAPs selbst DHCP-Leases verteilen können, brauche ich einen DHCP-Server für die WLAN-Gäste. Ich würde gerne meinen vorhandenen DHCP-Cluster nutzen, der auf zwei Debian-Hosts arbeitet und momentan Leases verteilt. Ich möchte diesen DHCP-Server um einen Poolbereich erweitern, und zwar für Leasevergabe im Bereich 192.168.30.10-250. Ich hatte mir überlegt auf dem Debian-Host einfach ein zusätzliches virtuelles Interface eth0.30 zu erstellen und diesem das VLAN30 zuzuordnen. So gesehen würde ich durch diesen Schritt eine Verbindung auf L2-Ebene zwischen den sozusagen authentisierten WLAN-Gästen und dem DHCP-Server erreichen, oder nicht? der WLAN-Gast sollte dann hoffentlich eine IP aus dem 192.168.30.10-250 Bereich erhalten. Allerdings ist mein DHCP-Server eine VM, die auf einem Blade (innerhalb eines Bladecenters H) werkelt. Müsste ich dazu die Network I/O Module entsprechend auch mit VLAN konfigurieren oder ist das nicht erforderlich, da ich ja lediglich dem virtuellen interface eth0.30 auf meinem Debian-Host (=DHCP-Server) das VLAN30 zuordne? Würde das genügen und ich kann mir Konfiguration auf Bladecenter-Ebene ersparen?

Hi aqui,

das mit dem VLAN2=172.19.254.2, VLAN100=172.19.254.100, .... war mein Ursprungspost und damit wollte ich eigentlich sagne, dass meine VLAN-Interfaces am C3560 diese IPs erhalten. Das war aber falsch geschrieben, wie brammer schon richtigerweise kritisiert hat. Die VLAN-interfaces am C3560 sollen erhalten:

VLAN2 interface kriegt die 172.19.2.254
VLAN30 interface kriegt die 172.19.30.254
VLAN100 interface kriegt die 172.19.100.254

..usw..

das von dir angesprochene Szenario mit dem IP Helper (das ist quasi ein DHCP-relay, und heißt auf Cisco-Ebene einfach IP Helper nehme ich an?) wäre natürlich klasse! dann kann ich mir das VLAN-Gefummle auf Serverseite echt sparen. Enthält solch ein DHCP-request Paket, welches von einem DHCP-client versendet wird, auch alle notwendigen Informationen, und werde diese auch exakt bis zu meinem DHCP-Server auf die Serverlandschaft durchgeschleift, so daß der DHCP-Server die Info entnimmt, dass Client XYZ eine DHCP-Lease angefordert hat, und dass es von VLAN30 kommt? Das wäre echt gut wenn das so easy wäre und würde echt viel Arbeit ersparen. Ich wende mich daher mal fürs Erste an dieses Cisco DHCP Dokument hier

Grob gesagt: müßte ich quasi auf meinem c3560 mit "conf t" und dann "int vlan30" den Befehl "ip helper-address 172.16.1.22" absetzen? Die IP 172.16.1.22/16 ist mein derzeitiger DHCP-Server (der master), den ich noch eben mit dem zusätzlichen Scope erweitern müsste. Kann ich denn irgendwie auch meinen slave (=172.16.1.23/16) hier ins Spiel mit reinbringen? Denn wenn ja der master ausfallen sollte, dann würde der c3560 versuchen die dhcp-request an 172.16.1.22 vergeblich weiterzuleiten was ja nicht klappen kann. Gibt's also eine Art Befehl auf dem cisco, dass ich auch ein Backup-Relay angeben könnte (in dem Fall 172.16.1.23/16) ?

Danke dir. Hört sich gut an... natürlich werd ich mich da weiter durchlesen.

Allerdings frage ich mich gerade, wie es der WLAN-GAST über das VLAN30 bis ins Internet dann schafft. Bis zu diesem Punkt hätte nun der WLAN-Gast eine Lease erhalten im DHCP-Bereich 172.19.30.10-250 /24. Mein Internetrouter (=Linksys WRT54GL mit OpenWRT, derzeit im produktiven Netz mit der IP 172.16.110.5/16) ist für das Internet zum Surfen verantwortlich. Die Workstations gehen nicht direkt über diesen ins Internet, sondern haben den 172.16.101.254/16 (=mein squid) als Proxy eingetragen und surfen quasi über den squid hindurch ins Internet. Nur der squid darf über 172.16.110.5 /16 ins Internet raus. Als default Gateway haben meine derzeitigen Workstations die IP-adresse des c3560 eingetragen. Der wiederum hat keine default route (0.0.0.0), sondern nur seine statischen routes, da zeigt aber keine zum Linksys WRT54GL (172.16.110.5/16).

Den produktiven Squid auf 172.16.101.254/16 kann ich ja schlecht auf "transparent" umbiegen, denn dann würden all meine aktuellen Workstations nicht mehr ins Internet gelangen, weil die haben ja überall diesen squid als Proxy in den Einstellungen eingetragen. Leider hab ich (noch) keine Möglichkeit über eine GPO das für alle Workstations gezielt abzuschalten (hab noch kein AD). Ich bin daher vorsichtig, an dem derzeitigen squid rumzudrehen. Stattdessen bin ich in diesem Zuge aber bereit einen neuen Host zu installieren mit einem neuen Squid. Der alte ist vom Vorbesitzer und sowas von verbogen und mit einem uralt Versionsstand. Ich möcht da nicht viel rumdrehen, ich wollt eh einen vollständig neuen Squid aufsetzen. Dann könnte ich ja parallel einfach 'nen neuen squid installieren und dem gleich VLAN100 (=serverLandschaft) und die IP 172.19.100.101 /24 verpassen. In dessen Konfiguration müsste ich dann eintragen, dass als Internetgateway mein OpenWRT Router genutzt werden soll. Der hat aber momentan nur die 172.16.110.5/16. Muss ich dem OpenWRT dann also noch zusätzlich das VLAN30 beibringen und eine 172.19.30.101 /24 verpassen damit das klappt?

Dieser neue zukünftige squid wird eine VM wird auf dem Blade innerhalb des Bladecenters werden. Müßte ich direkt am I/O-Ethernet-Modul des Bladecenters (das sind Nortel Layer2-3 GbE Switch Module(Copper), AlteonOS) ebenfalls ein VLAN30 definieren? Diese Switche haben Interfaces mit der Bezeichnung INT1 bis INT14, MGT1 und MGT2, und EXT1 bis EXT6. Denn wenn ich das nicht mache, und auf dieser Debian-VM einfach das dpkg-Paket "vlan" installiere und mein eth0 interface mit einem VLAN-interface namens "eth0.30" ausstatte, würde das doch nicht einfach klappen? Denn das ist ja nirgends ein 802.1q trunk aufgebaut, der alle VLAN-Pakete einschleusen würde.

Wie sähe hier die richtige Vorgehensweise aus?

Für paar VPN-Strecken, hat mit dieser Thematik nix zu tun, ist was gesondertes.

Es geht ja grad darum, dass ich diese VLAN30 Thematik in mein produktives Netz miteinbaue, parallel dazu. An der bestehenden Infrastruktur (dem popeligen 16er-Masken-Netz) kann ich auf die Schnelle nichts ändern. Ich möchte jetzt erstmal (auch zum Ausprobieren der VLAN-Thematik) die WLAN-GAST Funktion miteinbauen, parallel zum aktuellen Stand.

Ich hab zwar noch 'n altes images auf dem produktiven c3560g-24ts = 12.2(25)SEB1 laufen, aber selbst wenn ich das aktuell empfohlene 12.2(55)SE9 ED nehmen würde, dann kann es laut Dem Cisco Software Feauture Comparison Tool kein WCCP, zumindest finde ich keine Angaben über WCCP oder WebCache Services in der feauture list.



Du meinst also, den Verkehr der VLAN30 WLAN-Gäste auch über meinen aktuell produktiven squid abzuwickeln (=172.16.101.254/16) ? Dann müsste ich aber den WLAN-Gästen den Proxy miteintragen, denn mein aktueller Squid ist ja nicht transparent konfiguriert. Und transparent konfigurieren will ich ja nicht, weil dann all meine anderen "normalen" Workstations im produktiven Firmennetz nicht mehr im Internet surfen könnten, denn die haben bei sich ja im Browser überall den Proxy eingetragen (=172.16.101.254/16). Daher war ja meine Überlegung einen zweiten Squid (ein neuer Proxy) als "transparent" zu installieren, der in Zukunft auch für meine derzeitigen workstations gelten soll, wenn ich später das gesamte Netz auf VLANs umgestellt habe. Wäre das verkehrt, hab ich hier 'nen Denkfehler? Ich möchte ja momentan erstmal "parallel" aufbauen und den aktuellen Stand nicht verändern müssen.

Bypassen wohin? Wenn ich keinen Proxy für die WLAN-Gäste verwende, dann müssten ja die WLAN-Gäste direkt über meinen Internetrouter ins Internet gelangen können (was ja auch nicht so dolle ist, aber zu verschmerzen wäre, zumindest für den Zeitabschnitt, bis ich alles komplett umgestellt habe). Den WLAN-Gästen auf VLAN30 könnte ich ja dann durch die DHCP-Optionen als default gw meinen LinksysWRT54GL Internetrouter geben. Der aber hat momentan nur die 172.16.110.5/16. Das würde nicht funktionieren, denn diese IP kann ein WLAN-Gast auf VLAN30 mit 'ner IP 172.19.30.10-250 nicht erreichen. Daher war meine Frage, ob ich am OpenWRT Internetrouter ein extra Interface einrichten könnten, das eben VLAN30 spricht, mit der IP z.B. 172.19.30.5/24. Und diese IP 172.19.30.5 übergebe ich meinen WLAN-Gästen als default gw. Würde das gehen? Falls ja, ist es kompliziert auf dem OpenWRT ein solches zusätzliches Interface einzufügen? Ich frage deshalb, weil ja bei dem LinksysWRT54GL (OpenWRT) die 6 Ports intern irgendwie verschaltet sind und eine bridge genutzt wird.

sorry, muss ich passen, hab ich nicht verstanden. Oder meintest du damit, was ich im letzten Absatz meinte? Also dass die WLAN-Gäste direkt über den Internetrouter OpenWRT ins Internet gelangen?

==> EDIT: Das IPSERVICES image von 12.2(55)SE9 ED könnte WCCP v2, das könnte also was werden. Wobei ich noch nicht sicher bin, welcher Weg der "richtige" wäre.

Klingt einleuchtend das Ganze, ja. Wobei eine Frage noch ungeklärt blieb: muss ich auf dem OpenWRT Router nicht auch ein VLAN30 mit 'nem VLAN30 interface und 'ner IP einrichten (z.B. 172.19.30.5/24), und diese IP dann meinen WLAN-Gästen (per DHCP-options) als default gateway übermitteln? Soweit ich HIER gelesen habe, gibt's defaultmäßig das VLAN0 und VLAN1 auf dem OpenWRT WhiteRussian (=ältere OpenWRT Version).

eth0 ist gebridget mit

• VLAN0 ist den externen Ports 1-4 zugewiesen (intern heißen die port0-3)
• VLAN1 ist dem externen Port WAN zugewiesen

WiFi Interface ist eth1 zugewiesen

der interne Port 5 (CPU) ist ein Trunkport mit 802.1q worüber alle VLAN-IDs getragen werden.
siehe auch ==> hier die Skizze

Demnach dachte ich mir, dass ich einfach VLAN30 auf diesem OpenWRT Router einrichte, indem ich das VLAN30 hinzufüge mit den zwei NVRAM Variablen:

nvram set vlan30ports="5"
nvram set vlan30hwname=et0

Müsste dann nur noch schauen, wie ich gnaz einfach diesem VLAN30 dann auch eine IP-adresse zuweise (=172.19.30.5/24).

Oder brauch ich das alles gar nicht und ich übergebe den WLAN-Gästen, die eine Lease aus dem Bereich 172.19.30.10-250 erhalten werden, einfach die IP meines c3560 switch/routers (=172.19.30.254/24) als default gw, der dann wiederum mittels wwcp die Anfragen der WLAN-Gästen auf port 21,80,443 an die 172.16.110.5/16 weiterschickt? (wwcp sollte dann nur für VLAN30 aktiv sein auf dem c3560 switch, ich hoffe das geht?)

Mist!!! Ich kann IPSERVICES nicht downloaden, dafür wird ein Supportvertrag mit Cisco vorausgesetzt und jetzt rate mal: den haben wir natürlich nicht *grrr*. Ich kann das normale IPBASE Image vom 12.2(55) SE9 ED downloaden, dann kann ich aber kein WCCP einsetzen hmpf


Wenn ich das richtig verstanden habe: ich setze eine statische Route auf meinem Catalyst für 0.0.0.0 mit Ziel 172.16.110.5/16 (mein OpenWRT Internetrouter). Dann erstell ich folgende ACL, damit NUR VLAN30 direkt auf den Internetrouter 172.16.110.5/16 kommen darf.


und wie folgt zuordnen:

In dem Beispiel bin ich von einem imaginären VLAN16 ausgegangen, welches momentan noch gar nicht auf meinem catalyst vorhanden ist. Denn der Catalyst hat momentan die IP 172.16.254.1 /16 aus der Horror-16er-Maske, und der Internetrouter hat 172.16.110.5 /16. Demnach brauch ich ja auf dem catalyst doch eigentlich nix blockieren, denn ein Client XY 172.16.*.* /16 gelangt ja auf direktem Wege auf den Internetrouter 172.16.110.5 /16, ohne durch den catalyst geroutet werden zu müssen. Auf dem Internetrouter ist dann per iptables alles gedroppt, nur dem Squid-Proxy (=172.16.101.254/16) wird erlaubt, den Internetrouter und somit das Internet zu nutzen. Ergo auch kein VLAN16 vorhanden auf dem catalyst.

Kann ich mir also die ACL-Zugriffsbeschränkung wie soeben erklärt einfach sparen? Dann müsste ich ja noch nur eine iptables Regel am Internetrouter erstellen, und Pakete erlauben die von 172.19.30.0 /24 aus kommen und ins Internet wollen.


Wie macht man das denn ? In meiner Ubiquiti UniFi WebGUI kann ich ja lediglich wählen, dass sämtliche WLAN-Gäste automatisch ins VLAN30 gewürfelt (getagged) werden. Das macht der Softwarecontroller von Ubiquiti, der auf einer Windows-VM werkelt als Windowsdienst. Würde ich jetzt eine direkte Verbindung zum Internetrouter aufstellen wollen (um den Catalyst zu umgehen wie von dir beschrieben), so müßte ich jetzt wohl von dieser VM ausgehend über trunks oder anderen Switch bis zum Internetrouter gelangen und dort in einen Port einstöpseln (bzw. via VLAN30-interface und dem default trunk-Kanal, der ja mit eth interface gebridget ist). Außerdem hätte ich durch diese Umgehungsmaßnahme auch das weitere Problem, dass kein DHCP-Server (mittels relay/IP helper) mehr Leases an die WLAN-Gäste verteilen könnte so wie ursprünglich geplant. Ich könnte dann aber auf dem OpenWRT-Router DHCP-Server laufen lassen, und die VLAN30-Gäste versorgen, oder nicht?

Nunja, das ist wohl was internes und Unsinn in dem Sinne ist es ja nicht, denn das hab ich nicht frei vom Kopf erfunden. Die zwei geposteten Links in meinem letzten Beitrag (1 und 2 erklären das ja genau.

Aqui, nur um das mal zusammenzufassen ... (bitte korrigier mich entsprechend):

Ich hab folgende Möglichkeiten:

(Methode 1)

• ich installiere die aktuelle image-Version auf meinen Catalyst c3560g-24ts und zwar IPBASE with web+crypto (IPSERVICES geht leider nicht!) und hätte dadurch leider keine Möglichkeit auf proxy zwangs redirects durch die wccp Funktion.
• die WLAN-Gäste erhalten durch mein CP automatisch VLAN30 zugewiesen.
• ich nutze meinen vorhandenen DHCP-Server /Cluster (Debian VM) (derzeit 172.16.0.0/16) indem ich ein weiteres scope hinzufüge für die geplanten WLAN-Gäste. Das mache ich indem ich meiner VM ein 'echtes' VLAN30-Interface (=eth1) spendiere und dieses neue zusätzliche WLAN-GAST Scope nur für dieses neue eth1-interface gültig mache. Damit erhalten die WLAN-Gäste eine Lease aus beispielsweise 172.19.30.0/24. Dazu müsste ich wohl auf Debian das Paket "isc-dhcp-relay" installieren, damit ich dem explizit sagen kann, für scope1/subnet1 soll er eth0 verwenden, und für scope2/subnet2 soll er eth1 verwenden?? Oder wie sonst soll mein DHCP-Server wissen, dass er Anfragen, die aus eth1 kommen, mit scope2 bearbeitet werden sollen und Anfragen aus eth0 mit scope1?
• Dann aktiviere ich auf meinem Catalyst ip helper und leite BOOTP-Anfragen die aus VLAN30 kommen zu meinem DHCP-Server.
• Der WLAN-Gast erhält somit seine Lease im VLAN30-Segment aus dem Bereich 172.19.30.0/24. Als default gateway bekommt er die 172.16.101.254 /16, die momentane IP des Catalyst C3560.
• Auf dem Catalyst trage ich die Route 0.0.0.0 mit Ziel 172.16.110.5 /16 (=Internetrouter/OpenWRT) ein
• Auf dem Catalyst erlaube ich durch die oben gezeigte extended ACL den Zugriff auf 172.16.110.5 /16, nur für Hosts aus 172.19.30.0 /24
• Auf dem Internetrouter 172.16.110.5 /16 erlaube ich durch iptables den Zugriff aufs Internet für Hosts aus 172.19.30.0 /24

(Methode 2)
--> wie Methode 1, jedoch mit folgenden Unterschieden

• auf dem Internetrouter/OpenWRT erstelle ich ein VLAN-Interface VLAN30 und weise diesem die IP 172.19.30.5 /24 zu.
• ich erstelle irgendwie einen DHCP-Server auf dem OpenWRT Internetrouter 172.16.110.5 /16 und verteile IPs im Bereich 172.19.30.0 /24, nur gültig für VLAN30 = 172.19.30.5 /24 (muss ich mich schlau machen, wie ich das auf dem OpenWRT umsetze)
• dieser auf dem OpenWRT/Internetrouter arbeitende DHCP-Server vergibt Leases an die WLAN-Gäste mit default gateway = 172.19.30.5 /24
• die WLAN-Gäste kommen daher auf direktem Wege bis zum Internetrouter und somit ins Internet

Hab ich das richtig verstanden?

Hallo nochmal. Beim erneuten Durchlesen dieses Threads ist mir aufgefallen, dass ich eine ganz wichtige Information vergass, aufzulisten:

ich nutze nämlich zwei Internetleitungen. Die eine Internetleitung hat 10MBit/s down und 5MBit/s up, und die andere hat 100MBit/s down und 2,5MBit/s up. Erstere ist für unseren WWW, FTP, Mailverkehr, EDI, usw... gebraucht, während die zweite Internetleitung mit der höheren Downstream-Bandbreite (100MBit/s) exklusiv NUR für's Internetsurfen gedacht ist. Die IPfire und DMZ, die ich in meinem Beitrag erwähnte, und worauf du dich immer bezogen hattest, die ist nur im Internet1 Strang vorhanden. Fürs Internet-Surfen wird das schnellere Internet2 genutzt. Und zwar ist dort auf dem OpenWRT Router per iptables geregelt, dass NUR der Squid-Proxy rausdarf ins Internet. Und die Workstations im Netz nutzen den squid, um im Internet surfen zu können, das ist der Stand aktuell. Ich hab mal schnell per Hand 'ne Skizze gemacht, die das hoffentlich verdeutlicht:


Es geht mir jetzt ja hauptsächlich um die WLAN-Gäste und VLAN30, welches ich parallel zum produktiven Betrieb aufbauen möchte. Die WLAN-Gäste erhalten von den Ubiquiti UAPs automatisch VLAN id 30 zugewiesen. Wäre es denn verkehrt, wenn ich die WLAN-Gäste direkt über den LinksysWRT54GL ins Internet2 schicke? Dann müsste ich doch lediglich am OpenWRT-Router ein zusätzliches VLAN30 Interface erstellen mit z.B. 192.168.111.5/24 und auf dem OpenWRT-Router selbst auch mittels dnsmasq einen DHCP-Server betreiben, der nur auf VLAN30 reagiert/lauscht. Somit müssten ja dann die WLAN-Gäste, die sich authentifiziert haben und in VLAN30 utnerwegs sind, vom DHCP-Server des OpenWRT Routers eine IP erhalten. Und diese DHCP-Lease übergibt denen das Gateway 192.168.111.5 womit sie direkt ins Internet rauskönnten. Und per iptables auf dem OpenWRT könnte ich ja dann Zugriff beschränken und definieren, dass alles aus dieser DHCP-verteilenden Range (z.B. 192.168.111.10-250) nur Port 21, 80, 443 im Internet kontaktieren dürfen.

Was wäre denn falsch daran, bzw. wo sind meine Denkfehler? Worin lägen die Vor-/Nachteile dieser Variante, und der von dir beschriebenen, alles mittels dem internen Proxy und internem DHCP-Server abzuwickeln?

Freue mich auf feedback und sag schonmal danke im Voraus.

Du hast mich ja bereits schon einmal darauf hingewiesen, die interne Bildupload-Funktion zu verwenden. Ich hatte daraufhin wie ein Verrückter gesucht und auch die HIlfe durchlesen. Aber ich hatte diesen Bereich einfach nicht finden wollen. Du hast mir jetzt durch deinen letzten Kommentar endlich verständlich gemacht, wie das funktioniert. Um ehrlich zu sein finde ich das aber schon sehr unüblich wie man hier Bilder hochladen tut. Ich bin Mitglied in sehr vielen andren Foren, und da ist das deutlich einfacher, aber was solls...will ja nicht rummeckern bin froh dass es das Forum überhaupt gibt. An dieser Stelle danke für den Hinweis ==> "den gesamten "Inhalt" in der "Meine Inhalte"-Seite bearbeiten zu müssen, damit man überhaupt auch Bilder hochladen kann. Durch Editieren des Beitrags an sich, ist das nämlich nicht möglich, deswegen fand ich das bei meinem letzten Versuch nicht. Ich hab jetzt die entsprechenden Links in den Beiträgen angepasst und somit ersetzt, hoffe das passt so. :p

Back to Topic:

Freut mich das zu hören, ich denke ich hab das dann richtig verstanden. Ich werde wohl aus Gründen der "wasserdichten" Trennung die OpenWRT-Variante ausprobieren. So haben die WLAN-Gäste absolut nix im restlichen Netzwerk zu suchen, und können auch durch "falsch-geratene" oder "vergessene/fehlerhafte" ACL-Konfigurationen keine Schlupflöcher ausnutzen. Natürlich muss ich auf dem OpenWRT-Router die iptables genauso mit Sorgfalt anpassen. Jetzt müsste ich mich nur mal schlau machen, wie ich das komfortabel alles auf dem OpenWRT Router managen kann. Soweit so gut, ich meld mich wieder wenn's irgendwo klemmt

VIELEN HERZLICHEN DANK soweit.

Grüße,
Pangu

Hallo aqui (und Rest),

zwischenzeitlich war ich noch mit einigen anderen wichtigen Arbeiten beschäftigt, deshalb hab ich mich länger nicht mehr gemeldet. Ich habe jedoch schon einige Fortschritte erzielen können, habe dennoch noch einen weiten Weg vor mir und hoffe weiterhin auf deine/eure Hilfestellung. Hier mal der aktuelle Stand des VLAN30, also wie ich die WLAN-Gäste abwickle:

Der WLAN-Gast (durch sein Notebook, Smartphone, Tablet, ...) verbindet sich im ersten Schritt mit der ausgestrahlten ESSID names "WLAN-GUESTS". Da es sich um ein offenes Netzwerk handelt, muss er kein Passwort eingeben. Nach erfolgreicher Verbindung wird er durch das CaptivePortal ins VLAN15 zugewiesen (VLAN30 wollte ich ja ursprünglich für die Gäste nutzen, musste aber VLAN15 nehmen, weil OpenWRT nur bis ID 15 unterstützt). Auf dem OpenWRT-Internetrouter habe ich ein VLAN15-Interface hinzugefügt mit der IP 192.168.15.254 (/24). Nur auf diesem Interface läuft ein DHCP-Server, der somit leases von 192.168.15.11-249 /24 im VLAN15 verteilt. Somit erhält jeder WLAN-Gast eine IP aus diesem Adressbereich zugeteilt. Damit er aber auch Zugriff ins Internet erhält, muss er erstmal einen gültigen Voucher-Code eingeben, sich also am CP authentifizieren. Erst nach erfoglreicher Auth erlangt er somit Zugriff auf das offene Internet, direkt durch diesen OpenWRT-Internetrouter. Hier eine kleine Skizze:


Meine ganzen Ubiquiti UAP-LR Accesspoints haben außerdem ebenfalls und automatisch eine DHCP-Lease vom im VLAN15 dienenden DHCP-Server erhalten, das sieht dann im CLI bei denen ungefähr so aus:


Funktioniert bisher alles erste Sahne und genauso wie ich's mir erhofft hatte. Durch diese Konfiguration schleife ich quasi WLAN-Gäste vollständig am bestehenden Firmennetzwerk vorbei und leite sie direkt auf den Internetrouter, der nur 192.168.15.0/24 Hosts direkt ins Internet erlaubt.

==> So, nun möchte ich zum nächsten Schritt übergehen, und meine neuen firmenbezogene VLANs erstellen. Meinen core switch habe ich soweit mit dem empfohlenen aktuellen image (ipservices) ausgestattet und rebootet, so dass das neue image auch aktiv ist. Die ganzen bestehenden configs blieben dabei unverändert und somit aktiv.

Mein Plan sieht dabei so aus:

- das bestehende Netz in der Horrormaske /16 muss ja erstmal unangetastet bestehen bleiben, da es sich um das Produktivnetz handelt. Hier steckt ja einfach alles mit drin, sprich: "Server", "Clients", "Drucker", usw... damit muss man tag täglich arbeiten, und die kann ich unmöglich in einer Nacht-und-Nebel Aktion komplett umbiegen. Deshalb plane ich eine Art übergangsweise "Migrations-VLAN" namens VLAN16 auf meinen gesamten Switches im Netzwerk zu erstellen, und mittels trunk auch dafür zu sorgen, dass VLAN16 eben überall durchgeschleift wird (tagged via 802.1q). Dann erstelle ich auf meinem core switch (=Catalyst C3560G-24TS) auch ein Interface für dieses VLAN16 und verpasse ihm die IP 172.19.16.254.

- jetzt erstelle ich als nächstes auf diesem core switch auch ein VLAN100 und das Interface dazu 172.19.100.254. Das VLAN100 soll mein zukünftiges VLAN100 werden. Ich könnt jetzt z.B. hergehen und auf meiner Xenserver-Farm einen neuen Server erstellen mit der IP 172.19.100.123 /24.

Dadurch, daß auf dem core switch "ip routing" aktiviert ist, müsse demnach ein alter Client aus der bestehenden 16er-Maske (z.B. 172.16.200.11 /16) den neuen Server im VLAN19 erreichen können (172.19.100.123 /24), oder nicht? Wenn mein Gedankenansatz richtig wäre, könnte ich nämlich nun Schritt-für-Schritt und mit den Tagen/Wochen anfangen, die ganzen Hosts umzubiegen. Als Beispiel: Ich ändere die Netzwerkkonfiguration eines Servers um (natürlich ggf. Serverdienste checken und configs anpassen):

von alt:
IP: 172.16.103.50
Subnet: 255.255.0.0
Gateway: 172.16.254.1 (=das ist das vlan1 interfaces des core switch WS-C3560G-24TS)

auf neu:
IP: 172.19.100.222
Subnet: 255.255.255.0
Gateway: 172.19.100.254

Müsste hierzu aber noch eine "ip route ..." gesetzt werden, oder wird automatisch durch das globale "ip routing" Kommando geroutet und ich muss nur die ACLs anpassen, um den Gürtel enger zu schnallen?

Dann würd ich noch gerne wissen, wie das Best-Practice aussieht für die Absicherung der Management-Interfaces diverse Geräte. Aqui schrieb dazu:


Wie genau sollte ich das anstreben? Die Workstations/Clients + Drucker sollen ja im VLAN200 sein und somit im subnet 172.19.200.0 /24. Die Server sind VLAN100 und subnet 172.19.100.0 /24. Und meine USVs, Bladecenter-IO-Module, Klimagerätsteuerung, BMC-Adapter diverse IBM-Server, usw... sprich die ganzen Managementinterface sollen ins VLAN253 und subnet 172.19.254.0 /24. So hatte ich das zumindest verstanden. Damit dieses Modell funktioniert, müssten die Admins (Kollegen+Ich) in ein getrenntes VLAN und somit subnet rein, damit eine Unterscheidung zwischen "Normalen Clients" und "Admins" erfolgen kann? Also die Admins dem VLAN222 und 172.19.222.0 /24 zuordnen und dann eben per ACL festlegen, dass nur die Admins auf die Managementinterfaces drauf dürfen?

in der Tat. Diesbezüglich habe ich bereits eine Anfrage im support-Forum Ubiquiti gestellt. Ein anderer User steht momentan vor derselben Frage. Ich vermute, dass ich entgegenwirkend per internen Firewall-Regeln den Zugriff darauf verbieten könnte, aber ich warte erstmal auf Antwort ab. Das beste wäre natürlich, dass Management lediglich auf dem default interface stattfinden kann, und sonst nirgends. Danke für den Hinweis.

Verstanden.

Ich habe mir erstmal die running-config meines core switches angezeigt, um alle Einträge aufzulisten, die mit meinem Horrornetz 172.16.0.0/16 in Verbindung stehen. Der Output des Befehls "sh ru | i 172.16" gibt u.a. folgendes aus:





Ich habe ein VLAN 16 erstellt mit Bezeichnung "Old_network", das VLAN 16 ist nun also vorhanden. Aber ich frage mich, ob es nicht "problematisch" werden könnte, wenn ich an diesem Punkt ausführen würde: "conf t" --> "int vlan 16" --> "ip address 172.16.16.16 255.255.0.0" und meinem vlan16 interface quasi die IP 172.16.16.16 /16 verpasse. Oder ist das genau der richtige Ansatz ?

ich denke da an einen anderen Migrationsweg... Beispiel: ich möchte Hosts aus meinem aktuellen flachen /16 old_network in die neu erstellten VLANs migrieren. Ich möchte z.B. Hosts aus meinem 172.16.0.0/16 subnet hinüber in die neuen VLANS ==> VLAN10 (172.19.10.0/24), VLAN20 (172.19.20.0/24), VLAN30(172.19.30.0/24), VLAN100 (172.19.100.0/24) und VLAN200 (172.19.200.0/24) migrieren.

Mein core switch hat aktuell lediglich ein VLAN1 interface mit der Addresse "172.16.254.1/16". Nun erstelle ich mit diesen Befehlen zusätzliche (sogenannten secondary's) auf diesem VLAN1 interface:


Durch diese übergangsweise Konfiguration könnte ich somit meine Hosts in die neuen subnets rüberziehen, so daß eine Kommunikation untereinander stattfinden kann. Wenn ich beispielsweise alle Hosts aus dem bestehenden flachen old_network in einem VLAN-Segment rübermigriert habe und somit fertig bin mit diesem jeweiligen VLAN (nehmen wir als Beispiel an, ich habe alle Hosts in VLAN20 und bin damit fertig), so gehe ich nun her und lösche diese secondary ip address vom vlan1 interface und erstelle nun mit

conf t
int vlan20
ip address 172.19.20.1 255.255.255.0

das endgültige VLAN interface für dieses jeweilige VLAN.

Sollte doch eigentlich so funktionieren, was denkt ihr?

oh, ich vergass hierzu Stellung zu nehmen. Das Problem ist gelöst mit Hilfe von Ubiquiti. Leider kann ich nicht explizit Mgmt-Interfaces auswählen, aber es gibt eine Lösung hierzu. Dazu wird für meine Guest-WLAN ESSID einfach folgendes genutzt:

Restricted Subnets = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Allowed Subnets = 192.168.2.250/32, 192.168.15.254/32

wobei 192.168.2.250 erreicht werden muss, weil es der Ubiquiti Softwraecontroller ist und für ein funktionierendes CP erreichbar sein muss, und...
die 192.168.15.254 ist das VLAN15 interface auf dem Internetrouter, worüber die WLAN-guest direkt raus in die weite Welt dürfen

So haben die WLAN-Gäste nirgends Zugriff, keine Pings, kein gar nix, außer eben auf diese zwei genannten Hosts. Passt soweit

Was genau heißt "aktiv genutzt" ? Meine Clients und 99% all meiner andren Hosts (Server, ...) haben ja die 172.16.254.1 als Default-Gateway stehen, das heißt sie müssen diese IP-adresse ja erreichen können, sonst kommen sie auf die anderen gerouteten Netze nicht mehr rüber, die auf diesem core switch geroutet werden (VPN-Strecken).

achso, verstehe... du meinst also, die IP vom VLAN1 interface entfernen, und stattdessen auf das VLAN16 interface legen? Das wiederum würde aber wieder voraussetzen, dass all meine vorhandenen Hosts aus dem flachen 172.16.0.0/16 subnet ins VLAN16 bewegt werden müssen damit sie Verbindung zu 172.16.254.1 /16 haben könnten, oder nicht? Oder kann ich die einfach unverändert so bestehen lassen, wie sie grad sind (=kein VLAN zugewiesen, und somit im default VLAN1 unterwegs) ?

Die Variante mit den secondary IPs habe ich deswegen angesprochen und vorgeschlagen, weil ich in diversen Cisco-Dokumenten darübre gelesen habe. Anscheinend ist dies der richtige Ansatz für Migrationszwecke, so wie ich sie plane. Das ist natürlich nur temporär, bis eben alles umgestellt wurde. Danach muss ich die secondary IPs entfernen, und sie dem tatsächlichen VLAN zuordnen (siehe auch dazu meinen letzten Beitrag, wie ich das erklärt hatte).

Nun? Was meinst du?

Das klingt interessant, könntest du das ein wenig detailliert beschreiben? Ich bin mir nicht sicher, ob ich das richtig verstanden habe. Ich achte also darauf, dass all meine ausgestrahlten ESSIDs einem VLAN !=0 zugeordnet werden? z.B. FOOBAR ist VLAN2 zugeordnet, JOHNDOE dem VLAN3 und SOMETHING dem VLAN4? Wie leg ich denn jetzt aber fest, auf welchem VLAN das Mgmt-Interface gelegt wird?

Das kann ich dir nicht genau beantworten. Das was ich aber weiß ist, dass der Software-Controller für den eigentlich WLAN-Betrieb nicht notwendig ist und nicht kontaktiert werden muss. Der Software-Controller ist nur für das Management erforderlich ,und auch für das CP damit die Hotspot/Voucher-Geschichte funktionieren kann, und sich Gäste authentifizieren können.

Wegen dem Gateway, ja du hattest Recht. Hab mich verwurstelt Zum Glück hab ich da aber keine voreiligen Entscheidungen getroffen gehabt, sondern nochmal drüber nachgedacht. Ich hab am Freitag das Ganze bereits schon umgesetzt, oder besser ausgedrückt "ausprobiert". Dazu habe ich meinem VLAN1 interface wie gesagt eine secondary ip 172.19.100.1/24 verpasst und einen Test-Server ins VLAN100 gesetzt mit der IP 172.19.100.123/24. Ich kann dadurch vom alten und produktiven Horrornetz 172.16.0.0/16 diesen Testserver erreichen, der im VLAN100 steckt. Somit steht eine Migration nichts mehr im Wege würde ich sagen. Wenn ich mit einem VLAN komplett fertig bin, dann erst entferne ich diese secondary ip vom VLAN1 interface, und erstelle dann ein VLAN100 interface mit dieser IP 172.19.100.1/24

Hi aqui,

etwas länger her, aber zu dem angesprochenen Punkt von dir... wenn ich das richtig verstanden habe, dann mache ich also folgendes:

(als Beispiel, ich habe die User auf VLAN10 und die Gäste auf VLAN20 und das management soll auf 254 stattfinden)

- ich definiere auf meinen APs die ESSID "MGMT" und weise diesem keine VLAN id zu
- dann noch eine weitere ESSID namens "User" und weise diesem die VLAN id 10 zu
- dann noch eine weitere ESSID namens "Guests" und weise diesem die VLAN id 20 zu

Die zwanzig APs sind an Switch-Ports verbunden, die als 802.1q trunk mit "allowed vlans=10,20,254" sind und zusätzlich "trunk native vlan 254" konfiguriert sind. Die gesamten APs hängen verteilt an 5 verschiedenen Switches die ebenfalls mittels einem 802.1q trunk port miteinander verbunden sind und in dessen "allowed vlans" Liste "10,20,254" stehen haben und auch hier mit "native vlan 254" konfiguriert sind.

Damit sollte das doch eigentlich funktionieren, oder?