16
Cisco SG350X-48 AdminIP in anderes VLAN
Hallo zusammen,
ich habe ein Problem mir einem Cisco SG350X-48
bei der Erstinstallation wurde eine IP 192.168.0.254 (Default VLAN 1) festgelegt. Es sind mehrere VLANs konfiguriert. Der Switch soll nun über eine IP 192.168.90.2 in VLAN 90 erreichbar sein. Der Switch soll nicht Routern, das tut ein separater Router.
Ich habe die neue IP unter IP Configuration mit zugehörigem VLAN hinterlegt.
Mgmt Access Method / ACCESS Profile steht auf none
IPv4 Routing ist deaktiviert.
Ping auf die alte und neue IP funktioniert.
Die Administrative Oberfläche ist über HTTP auf 192.168.0.254 erreichbar, nicht aber auf 192.168.90.2
Wireshark sieht so aus:
Ich gehe daher davon dass das Routing (PC->Router:VLAN90->Switch) und auch zurück funktioniert. In der Dokumentation zum Switch habe keinen Hinweis gefunden. Der Switch gibt diesbezüglich keine Fehlermeldungen aus.
Ich habe jetzt noch die Idee, die alte IP kurzerhand zu entfernen, glaube aber nicht, dass das das Problem löst, und irgendwie habe ich keine Lust den Stecker zu ziehen.
Hat jemand eine Idee?
Grüße
lcer
ich habe ein Problem mir einem Cisco SG350X-48
bei der Erstinstallation wurde eine IP 192.168.0.254 (Default VLAN 1) festgelegt. Es sind mehrere VLANs konfiguriert. Der Switch soll nun über eine IP 192.168.90.2 in VLAN 90 erreichbar sein. Der Switch soll nicht Routern, das tut ein separater Router.
Ich habe die neue IP unter IP Configuration mit zugehörigem VLAN hinterlegt.
Mgmt Access Method / ACCESS Profile steht auf none
IPv4 Routing ist deaktiviert.
Ping auf die alte und neue IP funktioniert.
Die Administrative Oberfläche ist über HTTP auf 192.168.0.254 erreichbar, nicht aber auf 192.168.90.2
Wireshark sieht so aus:
Ich gehe daher davon dass das Routing (PC->Router:VLAN90->Switch) und auch zurück funktioniert. In der Dokumentation zum Switch habe keinen Hinweis gefunden. Der Switch gibt diesbezüglich keine Fehlermeldungen aus.
Ich habe jetzt noch die Idee, die alte IP kurzerhand zu entfernen, glaube aber nicht, dass das das Problem löst, und irgendwie habe ich keine Lust den Stecker zu ziehen.
Hat jemand eine Idee?
Grüße
lcer
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 365695
Url: https://administrator.de/forum/cisco-sg350x-48-adminip-in-anderes-vlan-365695.html
Ausgedruckt am: 09.04.2025 um 16:04 Uhr
16 Kommentare
Neuester Kommentar
Der Switch soll nicht Routern,
Fragt sich dann warum du dann einen 350er gekauft hast, dann hätte es ein preiswerter SG200 auch getan...aber egal !Normal musst du nur eine zusätzliche IP Adresse in VLAN 90 eintragen und danach dann die IP Adresse aus dem VLAN 1 austragen bzw. entfernen.
Fertig.
Ich habe jetzt noch die Idee, die alte IP kurzerhand zu entfernen,
Das MUSST du machen, denn ansonsten ist der Switch auch über die alte IP im VLAN 1 noch weiter erreichbar !!
Der Switch soll nicht Routern,
Fragt sich dann warum du dann einen 350er gekauft hast, dann hätte es ein preiswerter SG200 auch getan...aber egal !Normal musst du nur eine zusätzliche IP Adresse in VLAN 90 eintragen und danach dann die IP Adresse aus dem VLAN 1 austragen bzw. entfernen.
Dachte ich ja auch, habe ich auch so gemacht.Das MUSST du machen, denn ansonsten ist der Switch auch über die alte IP im VLAN 1 noch weiter erreichbar !!
Das ist klar, ich dachte halt, dass der Switch während der Umkonfiguration über beide Adressen erreichbar sein sollte.Kann es sein, dass der Switch nur die Administrative Verbindung zu einer einzelnen IP zulässt? Das finde ich aber nirgendwo dokumentiert. Egal, ich werde es mal probieren - sobald ich vor Ort bin
.Grüße
lcer
So - ich war mutig!
das löschen der alten führte zu folgendem Verhalten:
- Die Seite hat nicht gleich reagiert.
- nach kurzer Zeit hat der Switch eine DHCP Adresse für das VLAN 1 akzeptiert, und eingetragen
- Danach war die Seite sofort wieder erreichbar.
die andere eingetragene IP funktioniert weiter nicht.
rätzelig!
Grüße
lcer
das löschen der alten führte zu folgendem Verhalten:
- Die Seite hat nicht gleich reagiert.
- nach kurzer Zeit hat der Switch eine DHCP Adresse für das VLAN 1 akzeptiert, und eingetragen
- Danach war die Seite sofort wieder erreichbar.
die andere eingetragene IP funktioniert weiter nicht.
rätzelig!
Grüße
lcer
Moin,
rennt der Switch im L2 oder L3 Modus?
Gruß
em-pie
€dit: Kann nur L3 sein, da du sonst keine zweite IP ehättest eintragen können....
rennt der Switch im L2 oder L3 Modus?
Gruß
em-pie
€dit: Kann nur L3 sein, da du sonst keine zweite IP ehättest eintragen können....
Hallo,
Tja, das ist wohl anders als ich es von den SG300 kenne. Da konnte man umschalten zwischen Layer2 und 3
Jetzt scheint das Portbasiert zu sein: Unter VLAN/Interfaces sieht das so aus:
und unter IP Configuration / IPv4 Interfaces so:
Da hat cisco wohl die Oberfläche geändert. Dummerweise kenne ich mich mit der Konfiguration über ein Terminal nicht aus. SSH funktioniert aber - allerdings auch nur auf die erste IP
Das der DHCP-Client ist im Default-VLAN=VLAN1 laut Handbuch immer aktiviert. Deshalb hat dieses VLAN immer eine IP (Auto-192.168.1.254, DHCP oder statisch).
Grüße
lcer
rennt der Switch im L2 oder L3 Modus?
Tja, das ist wohl anders als ich es von den SG300 kenne. Da konnte man umschalten zwischen Layer2 und 3
Jetzt scheint das Portbasiert zu sein: Unter VLAN/Interfaces sieht das so aus:
und unter IP Configuration / IPv4 Interfaces so:
Da hat cisco wohl die Oberfläche geändert. Dummerweise kenne ich mich mit der Konfiguration über ein Terminal nicht aus. SSH funktioniert aber - allerdings auch nur auf die erste IP
Das der DHCP-Client ist im Default-VLAN=VLAN1 laut Handbuch immer aktiviert. Deshalb hat dieses VLAN immer eine IP (Auto-192.168.1.254, DHCP oder statisch).
Grüße
lcer
Sieht beim SG500X genau so aus, wie bei deinem SG350X
am SG300 habe ich das bei der Inbetriebnahme direkt angepasst, ob L3 oder L2 (für uns L2 aktuell ausreichend)...
Mal ne andere Frage:
Ist das VLAN 90 neu?
Nutzt ihr einen Proxy?
Hast du eine AUsnahme für den das VLAN 90 in den Proxy-Settings definiert/ mal den Proxy am PC deaktiviert?
am SG300 habe ich das bei der Inbetriebnahme direkt angepasst, ob L3 oder L2 (für uns L2 aktuell ausreichend)...
Mal ne andere Frage:
Ist das VLAN 90 neu?
Nutzt ihr einen Proxy?
Hast du eine AUsnahme für den das VLAN 90 in den Proxy-Settings definiert/ mal den Proxy am PC deaktiviert?
Hallo,
Der Switch musst kurzfristig ersetzt werden, und da wurden alle Kabel einfach reingesteckt -> VLAN1
Das VLAN90 ist neu, es soll Verwaltungsnetzwerk werden.
Einen Proxy nutzen wir nicht.
Es geht auch an Rechnern ohne Endpointsecurity-Lösung und mit deaktivierter Firewall nicht.
bin ratlos.
Grüße
lcer
Der Switch musst kurzfristig ersetzt werden, und da wurden alle Kabel einfach reingesteckt
-> VLAN1Das VLAN90 ist neu, es soll Verwaltungsnetzwerk werden.
Einen Proxy nutzen wir nicht.
Es geht auch an Rechnern ohne Endpointsecurity-Lösung und mit deaktivierter Firewall nicht.
bin ratlos.
Grüße
lcer
Habs hier gerade mal an einem SG250 L3 Switch nachgestellt und das funktioniert fehlerlos !
Dein Fehler ist das du das VLAN 1 Interface nicht entfernt hast
Es sollte natürlich auch klar sein das auf dem Switch mindestens 1 Port im VLAN 90 ist oder der Switch mit einem Tagged Uplink irgendwo am VLAN 90 hängt. Andernfalls kann man natürlich NICHT auf den Switch zugreifen wenn die L3 Funktion dort deaktiviert ist !!
Dein Fehler ist das du das VLAN 1 Interface nicht entfernt hast
Es sollte natürlich auch klar sein das auf dem Switch mindestens 1 Port im VLAN 90 ist oder der Switch mit einem Tagged Uplink irgendwo am VLAN 90 hängt. Andernfalls kann man natürlich NICHT auf den Switch zugreifen wenn die L3 Funktion dort deaktiviert ist !!
Kommst du via SSH denn an den Switch dran?
Wenn ja, dann lässt der zumindest mal darüber den Zugriff zu, wodurch ich dann mal vorsichtig der Annahme bin, dass es nicht am Switch liegt.
andere Frage: hast du es via http oder https versucht?
Habe hier nämlich an einem der hiesigen SGs (300er Serie) das Problem, dass wenn ich den via http am IE aufrufe, sich nichts tut, via https indes schon (kann auch umgekehrt gewesen sein). So ganz bin ich aber noch nicht dahinter gekommen, ggf. ne Buggy FW, die ich mal auf Aktualität prüfen müsste....
Teste einfach mal die beiden PRotokolle nebst verschiedener Browser...
Wenn ja, dann lässt der zumindest mal darüber den Zugriff zu, wodurch ich dann mal vorsichtig der Annahme bin, dass es nicht am Switch liegt.
andere Frage: hast du es via http oder https versucht?
Habe hier nämlich an einem der hiesigen SGs (300er Serie) das Problem, dass wenn ich den via http am IE aufrufe, sich nichts tut, via https indes schon (kann auch umgekehrt gewesen sein). So ganz bin ich aber noch nicht dahinter gekommen, ggf. ne Buggy FW, die ich mal auf Aktualität prüfen müsste....
Teste einfach mal die beiden PRotokolle nebst verschiedener Browser...
Update:
habe zuerst die statische IP von VLAN1 gelöscht. Danach war unmittelbar eine DHCP-IP für VLAN1 eingestellt. Dann habe ich diese gelöscht. Da kam eine Warnung, die zuvor nicht kam - und komme seitdem nicht mehr auf den Switch. weder über die eine noch die andere IP.
Jetzt muss ich den einmal vom Strom nehmen, was gerade nicht geht.
Grüße
lcer
habe zuerst die statische IP von VLAN1 gelöscht. Danach war unmittelbar eine DHCP-IP für VLAN1 eingestellt. Dann habe ich diese gelöscht. Da kam eine Warnung, die zuvor nicht kam - und komme seitdem nicht mehr auf den Switch. weder über die eine noch die andere IP.
Jetzt muss ich den einmal vom Strom nehmen, was gerade nicht geht.
Grüße
lcer
Kommst du via SSH denn an den Switch dran?
nur über die VLAN1 - IPandere Frage: hast du es via http oder https versucht?
Ja - geht nur über VLAN1-IPTeste einfach mal die beiden PRotokolle nebst verschiedener Browser...
Teste ich , wenn das wieder aufrufbar ist. s.o.Im cisco Forum wird darauf hingewiesen, dass man mit dem selben VLAN verbunden seien soll, wie die IP, die man aufrufen will. Das kann ich gerade mangels mit Laptop-Vor-Ort-Sein nicht testen. Kann es daran liegen? Allerdings kann ich auf die VLAN1-IP auf über ein entferntes geroutetes Netz zugreifen....
Grüße
lcer
OK.
wie ja? auf eine Oder-Frage kann man nicht mit Ja oder Nein antworten! Denn es geht nicht hervor, ob sich das "Ja" auf das http, https oder gar beides bezieht 
Was ja keinen Sinn für den Test ergibt... Wenn es mit dem FF auch nicht klappt (http sowie https), ist dein TEst dahingehend erfolgreich, dass es auch damit nicht klappt...
andere Frage: hast du es via http oder https versucht?
Ja - geht nur über VLAN1-IPTeste einfach mal die beiden PRotokolle nebst verschiedener Browser...
Teste ich , wenn das wieder aufrufbar ist. s.o.Im cisco Forum wird darauf hingewiesen, dass man mit dem selben VLAN verbunden seien soll, wie die IP, die man aufrufen will.
Das ist "quatsch". Ich greife auch aus anderen VLANs heraus auf das Management-VLAN des SGs zu. bei HP ist das wiederum so. Wurde das Management VLAN von VLAN 1 auf ein anderen verschoben, musst du dich auch in diesem VLAN befinden.Das kann ich gerade mangels mit Laptop-Vor-Ort-Sein nicht testen. Kann es daran liegen? Allerdings kann ich auf die VLAN1-IP auf über ein entferntes geroutetes Netz zugreifen....
Ich ging davon aus, du sitzt vor Ort. Wenn du via VPN versuchst zu agieren, wäre es denkbar, das ICMP zugelassen ist, andere PRotokolle aber nicht. Gibt es schon andere GEräte im VLAN 90, auf die du zum TEsten mal zugreifen könntest?andere Frage: hast du es via http oder https versucht?
Ja - geht nur über VLAN1-IPVLAN1 x HTTPS OK
VLAN90 x HTTP geht nicht
VLAN90 x HTTPS geht nicht
alles jeweils EDGEDas kann ich gerade mangels mit Laptop-Vor-Ort-Sein nicht testen. Kann es daran liegen? Allerdings kann ich auf die VLAN1-IP auf über ein entferntes geroutetes Netz zugreifen....
Ich ging davon aus, du sitzt vor Ort. Wenn du via VPN versuchst zu agieren, wäre es denkbar, das ICMP zugelassen ist, andere PRotokolle aber nicht. Gibt es schon andere Geräte im VLAN 90, auf die du zum Testen mal zugreifen könntest?Bin per VPN auf einem Rechner Vor Ort, der ist direkt am VLAN1 dran und erreicht VLAN90 via Router. ICPM funktioniert. Aufgrund des Wireshark-Protokolls Zeilen 1-3 bin ich erst mal davon ausgegangen, dass das Routing für TCP funktioniert und auch keine Firewall blockt (wobei, vielleicht denkt die mit und falsch
) Ich könnte eine VM umbasteln aber bin auch morgen wieder vor Ort, daher warte ich das mal ab.Grüße
lcer
Im cisco Forum wird darauf hingewiesen, dass man mit dem selben VLAN verbunden seien soll, wie die IP, die man aufrufen will.
Das ist ja logisch ! Deshalb oben auch nochmals der wichtige Hinweis das mindestens ein Port des Swiotches im VLAN 90 sein muss, sei es tagged oder untagged.Da VLANs immer 2 physisch völlig getrennte Collision Domains sind auf einem Switch wäre es technisch unmöglich aus einem Port der Member in VLAN 1 auf einen VLAN 90 Port zu kommen.
Wie gesagt, hier auf einem SG250 neues Firmware der einen Tagged Uplink auf einen Catalyst 3550 hat (VLAN 10) funktioniert die obige Konfig fehlerlos.
- VLAN 10 ist durchgehende auf Cat 3550 und SG250 vorhanden. Beide Switches sind mit einem Tagged Uplink verbunden für alle VLANs
- VLAN 10 IP im SG250 erstellt
- Von einem PC der am Cat 3550 in einem untagged Memberport des VLAN 10 steckt die VLAN 10 IP des SG250 gepingt, geht.
- VLAN 1 IP am SG-250 entfernt
- Wieder vom VLAN 10 Client die VLAN 10 Mgmt IP am SG250 gepingt, geht
- Client umgesteckt aufs VLAN 1 (3550 routet)
- Ping vom VLAN 1 Client die VLAN 10 Mgmt IP am SG250 gepingt, geht
Ohne Gateway sonst logischerweise kein Zugang, da die Rückroute dann nicht geht.
Fazit: Works as designed
Hallo,
kurze Zwischenmeldung, nachdem jetzt 2 Tage gar nichts mehr ging:
- Weboberfläche des switches war nicht zu reichen, lediglich der Loginbildschirm kam mal sporadisch
- der Router (bintec be.ip) war gar über nicht mehr erreichbar über die LAN-Anschlüsse,
- die Oberfläche des NAS (QNAP TS863U) war auch nicht benutzbar (kam über den Login nicht hinaus)
Der Router war lustig:
- Bei Zugriff über WLAN oder VPN funktionierte alles, nur die LAN-Ports nicht, auch nicht, wenn man den Router von allem anderem trennte und nur einen PC mit passender IP dran ließ
Habe folgendes gemacht:
- Routereinstellungen gesichert, auf Werkseinstellungen zurückgesetzt und Routereinstellungen zurückgesichert
- danach war der Router schon mal wieder erreichbar vom einzelPC
- am QNAP auf dass lustigerweise der SMB Zugriff noch lief - die Ordner der drauf laufenden VMs umbenannt
- alle PCs & sonstigen Geräte vom Switch getrennt
- den Switch auf Firmwareeinstellungen zurückgesetzt
- ein paar Neustarts später kam ich wieder auf die Oberfläche des NAS und habe sicherheitshalber alle VMs deaktiviert und die Containerstation (Docker) deinstalliert sowie alle virtuellen Switches entfernt.
Meine Idee ist, dass entweder eine doppelte IP vorhanden war oder die STP-Implementierungen versagt haben.
bintec: kein STP in Einstellungen zu finden
qnap: da steht was von STP, ist aber nur ein- und ausschaltbar, nicht konfigurierbar
Hat jemand noch einen anderen üblichen Verdächtigen für dieses Szenario?
Grüße
lcer
kurze Zwischenmeldung, nachdem jetzt 2 Tage gar nichts mehr ging:
- Weboberfläche des switches war nicht zu reichen, lediglich der Loginbildschirm kam mal sporadisch
- der Router (bintec be.ip) war gar über nicht mehr erreichbar über die LAN-Anschlüsse,
- die Oberfläche des NAS (QNAP TS863U) war auch nicht benutzbar (kam über den Login nicht hinaus)
Der Router war lustig:
- Bei Zugriff über WLAN oder VPN funktionierte alles, nur die LAN-Ports nicht, auch nicht, wenn man den Router von allem anderem trennte und nur einen PC mit passender IP dran ließ
Habe folgendes gemacht:
- Routereinstellungen gesichert, auf Werkseinstellungen zurückgesetzt und Routereinstellungen zurückgesichert
- danach war der Router schon mal wieder erreichbar vom einzelPC
- am QNAP auf dass lustigerweise der SMB Zugriff noch lief - die Ordner der drauf laufenden VMs umbenannt
- alle PCs & sonstigen Geräte vom Switch getrennt
- den Switch auf Firmwareeinstellungen zurückgesetzt
- ein paar Neustarts später kam ich wieder auf die Oberfläche des NAS und habe sicherheitshalber alle VMs deaktiviert und die Containerstation (Docker) deinstalliert sowie alle virtuellen Switches entfernt.
Meine Idee ist, dass entweder eine doppelte IP vorhanden war oder die STP-Implementierungen versagt haben.
bintec: kein STP in Einstellungen zu finden
qnap: da steht was von STP, ist aber nur ein- und ausschaltbar, nicht konfigurierbar
Hat jemand noch einen anderen üblichen Verdächtigen für dieses Szenario?
Grüße
lcer
Das riecht sehr stark nach einem STP Problem ! Den Symptomen nach zu urteilen sieht das nach einem STP Loop aus. Doppelte IPs kann man ausschliessen, denn das würde dann einzig nur diese IP betreffen aber niemals das gesamte Netz wie bei dir.
Sieht so aus als ob einer der virtuellen Switches oder der QNAP da geloopt hat. Vieles spricht dafür.
Du solltest in einem komplexeren Netz IMMER das Spanning Tree aktivieren damit sowas nicht passiert.
Am besten immer die RSTP Variante (Rapid STP). Diese ist auch rückwärts kompatibel zu Standard STP.
Der zentrale Switch sollte dann immer die höchste STP Priority bekommen. (Werden modulo 4096 vergeben)
Also wenn das der Cisco ist dann immer so: (Kleinere Werte = größere Prio)
Anhand der Designated Root Angaben kannst du dann auch immer die STP Topologie erkennen und ob die schlüssig ist in deinem Netz !
Wenn du ganz sicher gehen willst aktivierst du auch noch den "Loopback" Guard oben im Setup, der verhindert das z.B. am gleiche Port Loops das Netzwerk stören. Das kann z.B. sein wenn an einem Switchport ein ungemanageter Switch steckt und jemand dort einen Loop steckt oder auslöst. Das deckt Standard RSTP nicht ab.
Mit der Loop Detection aber auch das.
Sieht so aus als ob einer der virtuellen Switches oder der QNAP da geloopt hat. Vieles spricht dafür.
Du solltest in einem komplexeren Netz IMMER das Spanning Tree aktivieren damit sowas nicht passiert.
Am besten immer die RSTP Variante (Rapid STP). Diese ist auch rückwärts kompatibel zu Standard STP.
Der zentrale Switch sollte dann immer die höchste STP Priority bekommen. (Werden modulo 4096 vergeben)
Also wenn das der Cisco ist dann immer so: (Kleinere Werte = größere Prio)
Anhand der Designated Root Angaben kannst du dann auch immer die STP Topologie erkennen und ob die schlüssig ist in deinem Netz !
Wenn du ganz sicher gehen willst aktivierst du auch noch den "Loopback" Guard oben im Setup, der verhindert das z.B. am gleiche Port Loops das Netzwerk stören. Das kann z.B. sein wenn an einem Switchport ein ungemanageter Switch steckt und jemand dort einen Loop steckt oder auslöst. Das deckt Standard RSTP nicht ab.
Mit der Loop Detection aber auch das.
