9
Cisco SG350X und SG350X - Vlan Probleme und Grundsätzliches
Hallo zusammen,
ich bin ja seit ein paar Tagen dran, mich mit unseren neuen Cisco Switchen anzufreunden.
Anfangs klappte es ganz gut, aber es gibt es so ein paar Punkte an denen ich momentan scheitere und auch trotz Handbuch etc. nicht weiterkomme.
Insbesondere die VLANs wollen nicht so ganz wie ich.
Derzeit läuft ein Stack aus 2xSG350XG-24F und 2x SG350X-24P den ich zum Testen nutze.
Da ich momentan am Testen bin, ist die Konfiguration auch noch nicht so umfangreich.
Vlan 1: Clientsysteme
Static IP 10.101.1.254/24
DHCP Relay an 192.168.100.209
Untagged auf den meisten Ports, da Default.
Vlan 10: Management LAN
STatic IP 10.101.0.1/24
DHCP Relay an 192.168.100.209
Untagged auf Port 1-5 eines 24P Switches
VLAN99: Altes Netz sowie Weg ins Internet
IP DHCP 192.168.100.237
Untagged auf Port XG23 eines 350XG Switches am alten Netz.
Auf der Firewall im 192.168.100.0 Netz ist eine Route für beide 10.101xx. Netze eingetragen sodass ein Routing zwischen unserem Bestand-LAN und den Test-VLANs möglich ist.
Der DHCP auf 192.168.100.209 liefert fröhlich Adressen für die beiden Netze an Clients sofern diese am passenden Untagged Port hängen, die Rechner kommen an die Freigaben im LAN und das MGMT IP des Stacks in von allen beteiligten Netzen erreichbar.
Nun zu meinen Problemchen die ich trotz lesen und probieren nicht gelöst bekomme.
1.
Plan ist, dass die Switche später nur von bestimmten Rechner über ein Management VLAN erreichbar sind.
ACLs habe ich noch nicht eingerichtet sodass der Switch derzeit aus jedem Netz über die 10.101.0.1 erreichbar ist ->
Aber nur, wenn ein PC an einem Untagged Port ( Port 1-5) angeschlossen ist.
Ist dies nicht so, wechselt "VLAN Interface State" auf Disabled und die Route ist nicht mehr vorhanden.
Ist auf den ersten Blick erstmal "suboptimal" finde ich sodass ich skeptisch bin, wie ein Management-LAN am sinnvollsten umzusetzen ist.
2.
Der Stack soll als Core-Switch dienen und zwischen den Netzen und in Richtung Firewall zu Routen.
Einen weiteren 350X-24P Switch habe ich an einen 350XG-24F per LWL angebunden und schaffe es leider nicht, den Trunkport der Switche so zu konfigurieren, dass:
- Ich den Access-Switch über die feste IP 10.101.0.2 (VLAN 10 - MGMT) erreiche.
- DHCP Pakete des Access Switches über den Stack an den DHCP Server Relay Server zu leiten.
Ich bin davon ausgegangen, dass es ausreicht, den Port auf beiden Switchen auf Trunk-Modus umzustellen und den Port auf dem Access Switch auf Untagged VLAN 10 zu setzen.
Irgendwo muss ich nen Knoten haben..
3.
Für die Route zur Firewall würde ich ein eigenes Vlan auf dem Core-Switch einsetzen damit die FW nur noch den Internet-Traffic abbgekommt.
Sofern sich mit den ACL gut regeln lässt, dass z.b. nur RDP in Vlan X durchgelassen wird und VLAN X keinen Zugriff auf die anderen Netze bekommt.
4.
Gibt es die Möglichkeit, die per http durchgeführten Änderungen so mitzuschneiden/auszugeben, dass man hieraus die CLI Befehle ableiten kann?
5.
Bin ich für weitere Ratschläge dankbar!
Vielen Dank im voraus!
ich bin ja seit ein paar Tagen dran, mich mit unseren neuen Cisco Switchen anzufreunden.
Anfangs klappte es ganz gut, aber es gibt es so ein paar Punkte an denen ich momentan scheitere und auch trotz Handbuch etc. nicht weiterkomme.
Insbesondere die VLANs wollen nicht so ganz wie ich.
Derzeit läuft ein Stack aus 2xSG350XG-24F und 2x SG350X-24P den ich zum Testen nutze.
Da ich momentan am Testen bin, ist die Konfiguration auch noch nicht so umfangreich.
Vlan 1: Clientsysteme
Static IP 10.101.1.254/24
DHCP Relay an 192.168.100.209
Untagged auf den meisten Ports, da Default.
Vlan 10: Management LAN
STatic IP 10.101.0.1/24
DHCP Relay an 192.168.100.209
Untagged auf Port 1-5 eines 24P Switches
VLAN99: Altes Netz sowie Weg ins Internet
IP DHCP 192.168.100.237
Untagged auf Port XG23 eines 350XG Switches am alten Netz.
Auf der Firewall im 192.168.100.0 Netz ist eine Route für beide 10.101xx. Netze eingetragen sodass ein Routing zwischen unserem Bestand-LAN und den Test-VLANs möglich ist.
Der DHCP auf 192.168.100.209 liefert fröhlich Adressen für die beiden Netze an Clients sofern diese am passenden Untagged Port hängen, die Rechner kommen an die Freigaben im LAN und das MGMT IP des Stacks in von allen beteiligten Netzen erreichbar.
Nun zu meinen Problemchen die ich trotz lesen und probieren nicht gelöst bekomme.
1.
Plan ist, dass die Switche später nur von bestimmten Rechner über ein Management VLAN erreichbar sind.
ACLs habe ich noch nicht eingerichtet sodass der Switch derzeit aus jedem Netz über die 10.101.0.1 erreichbar ist ->
Aber nur, wenn ein PC an einem Untagged Port ( Port 1-5) angeschlossen ist.
Ist dies nicht so, wechselt "VLAN Interface State" auf Disabled und die Route ist nicht mehr vorhanden.
Ist auf den ersten Blick erstmal "suboptimal" finde ich sodass ich skeptisch bin, wie ein Management-LAN am sinnvollsten umzusetzen ist.
2.
Der Stack soll als Core-Switch dienen und zwischen den Netzen und in Richtung Firewall zu Routen.
Einen weiteren 350X-24P Switch habe ich an einen 350XG-24F per LWL angebunden und schaffe es leider nicht, den Trunkport der Switche so zu konfigurieren, dass:
- Ich den Access-Switch über die feste IP 10.101.0.2 (VLAN 10 - MGMT) erreiche.
- DHCP Pakete des Access Switches über den Stack an den DHCP Server Relay Server zu leiten.
Ich bin davon ausgegangen, dass es ausreicht, den Port auf beiden Switchen auf Trunk-Modus umzustellen und den Port auf dem Access Switch auf Untagged VLAN 10 zu setzen.
Irgendwo muss ich nen Knoten haben..
3.
Für die Route zur Firewall würde ich ein eigenes Vlan auf dem Core-Switch einsetzen damit die FW nur noch den Internet-Traffic abbgekommt.
Sofern sich mit den ACL gut regeln lässt, dass z.b. nur RDP in Vlan X durchgelassen wird und VLAN X keinen Zugriff auf die anderen Netze bekommt.
4.
Gibt es die Möglichkeit, die per http durchgeführten Änderungen so mitzuschneiden/auszugeben, dass man hieraus die CLI Befehle ableiten kann?
5.
Bin ich für weitere Ratschläge dankbar!
Vielen Dank im voraus!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 439462
Url: https://administrator.de/forum/cisco-sg350x-und-sg350x-vlan-probleme-und-grundsaetzliches-439462.html
Ausgedruckt am: 22.12.2024 um 02:12 Uhr
9 Kommentare
Neuester Kommentar
Soweit hört sich das ja schon mal ganz gut an bei dir. Kommen wir mal zu deinen Fragen.
1.)
Das ist auch normal. Solange kein aktiver Port in diesem VLAN ist nimmt der Switch ein evtl. Routing in diesem Segment auf down. Macht ja auch Sinn, denn solange es keinen aktiven Poret gibt ist das Netz unbenutzt und dann muss man da auch nix hin routen. Works as designed....
Das Default VLAN 1 ist allerdings immer besonders. Im IP Management kannst du ja sehen das das Management Interface auf VLAN 1 liegt. Solange das der Fall ist, ist also das VLAN 1 und die Routen dahin immer "up", denn das ist quasi so als ob du da einen aktiven Port dran hast. Da die PVID auch auf allen Tagged Ports 1 ist ist also das VLAN 1 immer aktiv solange nur ein Port aktiv ist.
Also auch das normales Verhalten. Ein Management VLAN solltest du aber immer besser in ein dediziertes anderes VLAN legen und das mit ACLs abschotten. Das macht Sinn denn ins VLAN 1 fallen alle unzugewiesenen Ports und die will man normal nicht in seinem Management VLAN haben.
Fazit: Es muss immer mindestens ein aktiver Port ob tagged oder untagged im VLAN sein damit es aktiv ist.
2.)
Das ist vermutlich ein Konfigurationsfehler deinerseits. Du hast vermutlich vergessen am Access Switch eine Default Route auf die 10.101.1.254, sprich den routenden Stack zu konfigurieren, kann das sein ?
Ohne diese Route kannst du den Access Switch dann logischerweise einzig nur im VLAN 1 erreichen.
Der Trunkport der Stack und Access verbindet muss natürlich an den Verbindungsports VLAN 1 als PVID konfiguriert haben und als Trunk Port definiert sein.
3.)
Das ist auch genau richtig so ! Der Internet Traffic sollte immer vom Produktivtraffic in den VLANs ferngehalten werden und dafür solltest du ein dediziertes Koppel VLAN vorsehen. Ist der richtige Weg.
Hier kannst du sehen wie es geht:
Verständnissproblem Routing mit SG300-28
4.)
Nein. Das kannst du nur im CLI mit "sh run" sehen. Bzw. nur im GUI. Was ein GUI Klick für ein CLI Command nach sich zieht kannst du nur im direkten Vergleich sehen. Bzw. CLI fitte Admins sehen das auch sofort. Bzw. die nutzen nur das CLI.
5.)
Bis dato hast du alles richtig gemacht !
1.)
Das ist auch normal. Solange kein aktiver Port in diesem VLAN ist nimmt der Switch ein evtl. Routing in diesem Segment auf down. Macht ja auch Sinn, denn solange es keinen aktiven Poret gibt ist das Netz unbenutzt und dann muss man da auch nix hin routen. Works as designed....
Das Default VLAN 1 ist allerdings immer besonders. Im IP Management kannst du ja sehen das das Management Interface auf VLAN 1 liegt. Solange das der Fall ist, ist also das VLAN 1 und die Routen dahin immer "up", denn das ist quasi so als ob du da einen aktiven Port dran hast. Da die PVID auch auf allen Tagged Ports 1 ist ist also das VLAN 1 immer aktiv solange nur ein Port aktiv ist.
Also auch das normales Verhalten. Ein Management VLAN solltest du aber immer besser in ein dediziertes anderes VLAN legen und das mit ACLs abschotten. Das macht Sinn denn ins VLAN 1 fallen alle unzugewiesenen Ports und die will man normal nicht in seinem Management VLAN haben.
Fazit: Es muss immer mindestens ein aktiver Port ob tagged oder untagged im VLAN sein damit es aktiv ist.
2.)
Das ist vermutlich ein Konfigurationsfehler deinerseits. Du hast vermutlich vergessen am Access Switch eine Default Route auf die 10.101.1.254, sprich den routenden Stack zu konfigurieren, kann das sein ?
Ohne diese Route kannst du den Access Switch dann logischerweise einzig nur im VLAN 1 erreichen.
Der Trunkport der Stack und Access verbindet muss natürlich an den Verbindungsports VLAN 1 als PVID konfiguriert haben und als Trunk Port definiert sein.
3.)
Das ist auch genau richtig so ! Der Internet Traffic sollte immer vom Produktivtraffic in den VLANs ferngehalten werden und dafür solltest du ein dediziertes Koppel VLAN vorsehen. Ist der richtige Weg.
Hier kannst du sehen wie es geht:
Verständnissproblem Routing mit SG300-28
4.)
Nein. Das kannst du nur im CLI mit "sh run" sehen. Bzw. nur im GUI. Was ein GUI Klick für ein CLI Command nach sich zieht kannst du nur im direkten Vergleich sehen. Bzw. CLI fitte Admins sehen das auch sofort. Bzw. die nutzen nur das CLI.
5.)
Bis dato hast du alles richtig gemacht !
Moin Moin,
Wir setzen hier die SG300er ein. Wenn ich mich recht entsinne kann man doch die Running Config als TXT Datei runterladen und sieht dort dann die CLI Befehle oder Irre ich mich da?
Gruß,
Tjelvar
Zitat von @aqui:
4.)
Nein. Das kannst du nur im CLI mit "sh run" sehen. Bzw. nur im GUI. Was ein GUI Klick für ein CLI Command nach sich zieht kannst du nur im direkten Vergleich sehen. Bzw. CLI fitte Admins sehen das auch sofort. Bzw. die nutzen nur das CLI.
4.)
Nein. Das kannst du nur im CLI mit "sh run" sehen. Bzw. nur im GUI. Was ein GUI Klick für ein CLI Command nach sich zieht kannst du nur im direkten Vergleich sehen. Bzw. CLI fitte Admins sehen das auch sofort. Bzw. die nutzen nur das CLI.
Wir setzen hier die SG300er ein. Wenn ich mich recht entsinne kann man doch die Running Config als TXT Datei runterladen und sieht dort dann die CLI Befehle oder Irre ich mich da?
Gruß,
Tjelvar
Nein, da irrst du nicht. So geht es natürlich auch. Das ist dann wie ein "show run" auf dem CLI.
Du siehst aber immer nur die gesamte Konfig. Der TO wollte aber, versteht man ihn richtig, sehen können wenn er einem Mausklick macht was das Äquivalent des CLI Kommandos ist in Echtzeit. Das geht aber leider nicht.
Real networkers do CLI !
Du siehst aber immer nur die gesamte Konfig. Der TO wollte aber, versteht man ihn richtig, sehen können wenn er einem Mausklick macht was das Äquivalent des CLI Kommandos ist in Echtzeit. Das geht aber leider nicht.
Real networkers do CLI !
Ah, dann hab ich das entweder überlesen oder falsch Verstanden. Wie gut dass ich kein "real networker" bin, sondern die eierlegende Wollmilchsau. Alles können aber nichts richtig.
Oder ich habe das falsch verstanden...ist ja auch möglich ?!
Hallo aqui und vielen Dank für die ausführliche Antwort!
Auf dem Access Switch habe ich den Uplink zum Stack nun auf Trunk mit Untagged VLAN1 gesetzt und der Switch bekommt nun auf eine VLAN 10 IP. Ergibt ja auch Sinn.. Der Switch hängt an den DHCP Request ja sein VLAN 10 Stempel und bekommt korrekterweise eine Adresse für selbiges.
Hab mich irgendwie am Untagged 10 festgebissen.
Hier werde ich aber wohl besser durchgehend feste VLAN10 Adressen an die Access Switche vergeben.
Nicht, dass der DHCP nach einem Stromausfall mal nicht zur Verfügung steht.. und dann muss ich natürlich auch eine Route auf die 10.101.0.1 setzen!
Eine Frage zum Routing habe ich allerdings noch.
Quasi Frage 6:
Die Access Switche bekommen nach jetzigem Stand nur eine IP aus dem MGMT Netz und keine aus jedem VLAN.
Sie überlassen dem Core-Switch das Routing zwischen den Netzen.
Wenn ich jetzt ein separates Drucker-Vlan einrichten würde, hätte ich ja denn Fall, dass Client und Drucker u.u. am selben Switch hängen und die Pakete aber über den Core-Switch geroutet würden. Da wir, sofern die OM2e Leitungen 10GB mitmachen, über 10GBIT Leitungen zum Core verfügen, dürfte sich der erhöhte Traffice auf dem Glas kaum bemerkbar machen. Alternativ dazu müsste ich auf den Access Switchen auch zwischen den Vlans Routen... da bin ich aber skeptisch ob das ganze nicht etwas unübersichtlich werden könnte.. was meinst Du?
Vielen Dank!
Zitat von @aqui:
Das ist auch normal. Solange kein aktiver Port in diesem VLAN ist nimmt der Switch ein evtl. Routing in diesem Segment auf down. Macht ja auch Sinn, denn solange es keinen aktiven Poret gibt ist das Netz unbenutzt und dann muss man da auch nix hin routen. Works as designed....
Ok, ergibt Sinn und so langsam komme ich auch dahinter.. siehe unten..Das ist auch normal. Solange kein aktiver Port in diesem VLAN ist nimmt der Switch ein evtl. Routing in diesem Segment auf down. Macht ja auch Sinn, denn solange es keinen aktiven Poret gibt ist das Netz unbenutzt und dann muss man da auch nix hin routen. Works as designed....
Das Default VLAN 1 ist allerdings immer besonders.
Dieses wird ja später für die allg. Clients sein.Im IP Management kannst du ja sehen das das Management Interface auf VLAN 1 liegt.
Hier kann ich Dir nicht ganz folgen.. im IP Management sehe ich die Vlans mit den zugehörigen IP-Adressen, aber kein spezielles Management Interface. Oder verstehe ich das falsch?Also auch das normales Verhalten. Ein Management VLAN solltest du aber immer besser in ein dediziertes anderes VLAN legen und das mit ACLs abschotten. Das macht Sinn denn ins VLAN 1 fallen alle unzugewiesenen Ports und die will man normal nicht in seinem Management VLAN haben.
Fazit: Es muss immer mindestens ein aktiver Port ob tagged oder untagged im VLAN sein damit es aktiv ist.
Ok, da die Access Switche ja später per LWL über Trunk-Ports am Stack angebunden sind, sollte hier also später immer ein Port Online sein sodass ich auf die 10.101.0.1 des Core komme. Wenn nicht, muss ich mal ein Notebook mit funktionierender RS232 Schnittstelle besorgen.Fazit: Es muss immer mindestens ein aktiver Port ob tagged oder untagged im VLAN sein damit es aktiv ist.
2.)
Das ist vermutlich ein Konfigurationsfehler deinerseits. Du hast vermutlich vergessen am Access Switch eine Default Route auf die 10.101.1.254, sprich den routenden Stack zu konfigurieren, kann das sein ?
Ohne diese Route kannst du den Access Switch dann logischerweise einzig nur im VLAN 1 erreichen.
Der Trunkport der Stack und Access verbindet muss natürlich an den Verbindungsports VLAN 1 als PVID konfiguriert haben und als Trunk Port definiert sein.
Ich glaube, hier hatte ich einen Knoten im Kopf.Das ist vermutlich ein Konfigurationsfehler deinerseits. Du hast vermutlich vergessen am Access Switch eine Default Route auf die 10.101.1.254, sprich den routenden Stack zu konfigurieren, kann das sein ?
Ohne diese Route kannst du den Access Switch dann logischerweise einzig nur im VLAN 1 erreichen.
Der Trunkport der Stack und Access verbindet muss natürlich an den Verbindungsports VLAN 1 als PVID konfiguriert haben und als Trunk Port definiert sein.
Auf dem Access Switch habe ich den Uplink zum Stack nun auf Trunk mit Untagged VLAN1 gesetzt und der Switch bekommt nun auf eine VLAN 10 IP. Ergibt ja auch Sinn.. Der Switch hängt an den DHCP Request ja sein VLAN 10 Stempel und bekommt korrekterweise eine Adresse für selbiges.
Hab mich irgendwie am Untagged 10 festgebissen.
Hier werde ich aber wohl besser durchgehend feste VLAN10 Adressen an die Access Switche vergeben.
Nicht, dass der DHCP nach einem Stromausfall mal nicht zur Verfügung steht.. und dann muss ich natürlich auch eine Route auf die 10.101.0.1 setzen!
3.)
Das ist auch genau richtig so ! Der Internet Traffic sollte immer vom Produktivtraffic in den VLANs ferngehalten werden und dafür solltest du ein dediziertes Koppel VLAN vorsehen. Ist der richtige Weg.
Hier kannst du sehen wie es geht:
Verständnissproblem Routing mit SG300-28
Die Zeichnung im Link ergibt Sinn und so schaut es bei mir ja auch aus.Das ist auch genau richtig so ! Der Internet Traffic sollte immer vom Produktivtraffic in den VLANs ferngehalten werden und dafür solltest du ein dediziertes Koppel VLAN vorsehen. Ist der richtige Weg.
Hier kannst du sehen wie es geht:
Verständnissproblem Routing mit SG300-28
4.)
Nein. Das kannst du nur im CLI mit "sh run" sehen. Bzw. nur im GUI. Was ein GUI Klick für ein CLI Command nach sich zieht kannst du nur im direkten Vergleich sehen. Bzw. CLI fitte Admins sehen das auch sofort. Bzw. die nutzen nur das CLI.
Na jut.. war nur so eine Idee.. M$ macht das ja beim Exchange Server gut vor.. da kann man sich die PS Befehle schön ansehen bevor man die aus der GUI abschickt.Nein. Das kannst du nur im CLI mit "sh run" sehen. Bzw. nur im GUI. Was ein GUI Klick für ein CLI Command nach sich zieht kannst du nur im direkten Vergleich sehen. Bzw. CLI fitte Admins sehen das auch sofort. Bzw. die nutzen nur das CLI.
5.)
Bis dato hast du alles richtig gemacht !
Vielen Dank, werde aber bestimmt noch einige weitere Fragen zu anderen Themen stellen müssen.Bis dato hast du alles richtig gemacht !
Eine Frage zum Routing habe ich allerdings noch.
Quasi Frage 6:
Die Access Switche bekommen nach jetzigem Stand nur eine IP aus dem MGMT Netz und keine aus jedem VLAN.
Sie überlassen dem Core-Switch das Routing zwischen den Netzen.
Wenn ich jetzt ein separates Drucker-Vlan einrichten würde, hätte ich ja denn Fall, dass Client und Drucker u.u. am selben Switch hängen und die Pakete aber über den Core-Switch geroutet würden. Da wir, sofern die OM2e Leitungen 10GB mitmachen, über 10GBIT Leitungen zum Core verfügen, dürfte sich der erhöhte Traffice auf dem Glas kaum bemerkbar machen. Alternativ dazu müsste ich auf den Access Switchen auch zwischen den Vlans Routen... da bin ich aber skeptisch ob das ganze nicht etwas unübersichtlich werden könnte.. was meinst Du?
Vielen Dank!
Zitat von @aqui:
Der TO wollte aber, versteht man ihn richtig, sehen können wenn er einem Mausklick macht was das Äquivalent des CLI Kommandos ist in Echtzeit. Das geht aber leider nicht.
Wäre halt praktischer um sich an die Arbeitsweise der CLI zu gewöhnen.Der TO wollte aber, versteht man ihn richtig, sehen können wenn er einem Mausklick macht was das Äquivalent des CLI Kommandos ist in Echtzeit. Das geht aber leider nicht.
Real networkers do CLI !
Ich bin auch eher die Wollmilchsau und das Problem ist mit jeder CLI, dass man die Befehle vergisst wenn man nicht häufig damit zu tun hat.Insofern ist die GUI schon praktisch. Die CLI ist natürlich flotter wenn man sich auskennt und Änderungen an vielen Ports gleichzeitig durchführen möchte/muss.
Hier kann ich Dir nicht ganz folgen.. im IP Management sehe ich die Vlans mit den zugehörigen IP-Adressen
Nein, denn wann du mal richtig hinsiehst, dann siehst du die Management IP Adresse und an welches VLAN diese Management IP Adresse angeflanscht ist:
sollte hier also später immer ein Port Online sein sodass ich auf die 10.101.0.1 des Core komme
Richtig. Aber da du ja immer einen Uplink Port aktiv hast später bei der Vernetzung der Switches hast du ja mindestens immer einen Port der aktiv ist Dein Mgmt VLAN sollte dort natürlich auch draufliegen (siehe oben).Auf dem Access Switch habe ich den Uplink zum Stack nun auf Trunk mit Untagged VLAN1 gesetzt
So sollte es ja natürlich auch sein, der klassische Standard !Ergibt ja auch Sinn..
Absolut ! Hab mich irgendwie am Untagged 10 festgebissen.
Niemals auf Tagged Uplinks natürlich ! Zieh dir nochmal die VLAN Schnellschulung rein die hilft Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
Hier werde ich aber wohl besser durchgehend feste VLAN10 Adressen an die Access Switche vergeben.
Ja, natürlich, wie es sich in der Regel gehört für alle Infrastruktur Komponenten, Server, Drucker usw.Alternativ machst du in deinem DHCP Server eine feste Reservierung über die Mac Adresse des Switches, geht auch als "feste" IP.
werde aber bestimmt noch einige weitere Fragen zu anderen Themen stellen müssen.
Immer her damit... Die Access Switche bekommen nach jetzigem Stand nur eine IP aus dem MGMT Netz und keine aus jedem VLAN.
So sollte es auch sein, denn dort machst du ja rein Layer 2 und kein Routing ! Alles richtig also.Sie überlassen dem Core-Switch das Routing zwischen den Netzen.
Genau so ist es !da bin ich aber skeptisch ob das ganze nicht etwas unübersichtlich werden könnte.. was meinst Du?
Du hast absolut Recht. Das kann man machen ist aber Unsinn. Der kleine "Umweg" der Daten über den Core juckt das Netzwerk nicht im Geringsten, gerade bei 10G Uplinks ist das irrelevant. Gerade bei Druckern, da ist das eh marginal vom Volumen. L3 machst du nur im Core anders kann das ein Management Albtraum werden den keiner will.
Ok, vielen Dank für die Erläuterungen!
Dann wäre der Part schonmal abgehakt.
Dann wäre der Part schonmal abgehakt.
