Cisco SG220 VLAN Konfiguration
Hallo
Wir haben einige alte 100Mbit Cisco Switche im Einsatz, die gegen SG220-26 getauscht werden sollen.
In dem Zuge würde ich gerne die Konfiguration etwas verändern und 2 VLAN konfigurieren. Aktuell ist alles auf dem default VLAN1 konfiguriert.
Ich möchte gerne ein VLAN1 beibehalten und zusätzlich ein VLAN 50 anlegen, das nur für WLAN genutzt wird, mit eigenem DHCP und Router dazwischen, der die Netze inkl. Firewall verbindet. Der Router Teil ist schon ok.
Dieses VLAN muss ja auch auf allen Switchen/Trunks (LWL via GBIC Module) dann konfiguriert sein, damit es auch überall funktioniert, auch wenn die Switche nur Verbindungsteile sind via Trunk.
Dafür mache ich doch ausgehend von der default config nur folgendes:
1. VLAN Management - Create VLAN - VLAN 50 anlegen
2. VLAN Management - Port to VLAN - Uplink Port 25+26 sowohl für VLAN ID1 auf "tagged" stellen als auch für VLAN ID 50 auf "tagged" stellen
Jetzt die Fragen:
Es ist an sich nicht so gut, dass überall das VLAN 1 als default konfiguriert ist oder? Oder wie schmeiße ich einen Port aus dem VLAN 1 raus? Excluded kann ich nicht wählen für das default VLAN.
Unter VLAN Management - Interface Settings stelle ich alle Trunk Ports auf VLAN Mode Trunk, alle anderen mit Endgeräten auf Access. Wofür ist "General" da als Auswahl?
Den Trunk Ports weise ich beide VLAN parallel zu, damit die das auch beide Netzsegmente weitergeben, richtig?
Wieso stehen da eigentlich alle Ports per default auf "Trunk"?
Wir haben einige alte 100Mbit Cisco Switche im Einsatz, die gegen SG220-26 getauscht werden sollen.
In dem Zuge würde ich gerne die Konfiguration etwas verändern und 2 VLAN konfigurieren. Aktuell ist alles auf dem default VLAN1 konfiguriert.
Ich möchte gerne ein VLAN1 beibehalten und zusätzlich ein VLAN 50 anlegen, das nur für WLAN genutzt wird, mit eigenem DHCP und Router dazwischen, der die Netze inkl. Firewall verbindet. Der Router Teil ist schon ok.
Dieses VLAN muss ja auch auf allen Switchen/Trunks (LWL via GBIC Module) dann konfiguriert sein, damit es auch überall funktioniert, auch wenn die Switche nur Verbindungsteile sind via Trunk.
Dafür mache ich doch ausgehend von der default config nur folgendes:
1. VLAN Management - Create VLAN - VLAN 50 anlegen
2. VLAN Management - Port to VLAN - Uplink Port 25+26 sowohl für VLAN ID1 auf "tagged" stellen als auch für VLAN ID 50 auf "tagged" stellen
Jetzt die Fragen:
Es ist an sich nicht so gut, dass überall das VLAN 1 als default konfiguriert ist oder? Oder wie schmeiße ich einen Port aus dem VLAN 1 raus? Excluded kann ich nicht wählen für das default VLAN.
Unter VLAN Management - Interface Settings stelle ich alle Trunk Ports auf VLAN Mode Trunk, alle anderen mit Endgeräten auf Access. Wofür ist "General" da als Auswahl?
Den Trunk Ports weise ich beide VLAN parallel zu, damit die das auch beide Netzsegmente weitergeben, richtig?
Wieso stehen da eigentlich alle Ports per default auf "Trunk"?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1283912375
Url: https://administrator.de/contentid/1283912375
Ausgedruckt am: 19.11.2024 um 11:11 Uhr
31 Kommentare
Neuester Kommentar
Nein, das VLAN 1 zu taggen ist falsch !
Das VLAN 1 ist das Native (Default) VLAN und wird an Trunk Ports immer untagged übertragen. Die Trunk Ports bei dir sollten folgendermaßen eingestellt sein:
Alle Endgeräte Porst setzt du global in den Access Mode.
So ist es dann richtig.
Genau dehalb richtet ein kundiger Netzwerker auch immer ein dediziertes Management VLAN ein. In dieses VLAN bringst du dann den Management Port des Switches und auch alle anderen Geräte wie die Out of Band Ports der Server usw. So sind alle diese wichtigen Infrastruktur Management Zugänge sauber getrennt von den Clients und so gesichtert vom Zugang her.
Wie gesagt, Endgeräte Ports immer fest in den Access Mode setzen !
Das VLAN 1 ist das Native (Default) VLAN und wird an Trunk Ports immer untagged übertragen. Die Trunk Ports bei dir sollten folgendermaßen eingestellt sein:
- Port Mode : Trunk
- Tagged : VLAN 50
- VLAN 1 belassen wie es ist
Alle Endgeräte Porst setzt du global in den Access Mode.
So ist es dann richtig.
Es ist an sich nicht so gut, dass überall das VLAN 1 als default konfiguriert ist oder?
Das ist richtig !Genau dehalb richtet ein kundiger Netzwerker auch immer ein dediziertes Management VLAN ein. In dieses VLAN bringst du dann den Management Port des Switches und auch alle anderen Geräte wie die Out of Band Ports der Server usw. So sind alle diese wichtigen Infrastruktur Management Zugänge sauber getrennt von den Clients und so gesichtert vom Zugang her.
Oder wie schmeiße ich einen Port aus dem VLAN 1 raus?
Indem du ihn ganz einfach UNtagged in ein andewres VLAN legst ! Er geht dann automatisch auf Excluded. Wie gesagt, Endgeräte Ports immer fest in den Access Mode setzen !
und transportiere über den Trunk sowohl untagged VLAN1 als auch tagged VLAN 50
So wäre es der übliche Standard und kann man auch belassen.Problem ist nur das im Default das Management Interface auch im Default VLAN 1 liegt.
Steckt also jemand irgendwas an einen nicht zugewiesenen Port liegt dieses Endgerät im VLAN 1 mit Zugriff aufs Management.
Deshalb legt ein verantwortungsvoller Netzwerker das management in ein dediziertes VLAN.
Manche Ports für Endgeräte kriegen dann untagged einfach z.B. VLAN 99
Richtig ! Das geht aber natürlich nur wenn du auch das VLAN 99 vorher angelegt hast ! Endgeräte Ports sollten wie oben schon gesagt immer im Access Mode konfiguriert sein. Geht über die Port Konfig im VLAN Menü.
Das wäre doch auch dann eine Möglichkeit oder?
Jupp, das ginge auch so. Einfacher und sehr viel eleganter ist es aber wenn du das Management in einem dedizierten VLAN isolierst, dann musst du nicht alle Ports so frickelhaft und umständlich mit dem 99er VLAN "umbiegen". @NixVerstehen
Nein, das ist nicht ganz richtig. Trusted DHCP Ports sind nur die Ports an denen der DHCP Server erreicht wird sproch von wo aus der Switch aktiven DHCP Traffic erlaubt (DHCP Replies). Da die APs aber niemals selber DHCP Server sind ist das falsch und auch kontraproduktiv das so einzustellen.
@aqui: Danke für die Info. Da lasse ich mich gerne eines Besseren belehren. So habe ich das bei mir auch, das einzig der Windows Server, der DHCP für alle Netze abfackelt, an seinem Switchport „trusted“ ist. Allerdings mit einer Ausnahme: Meine Cisco WAP-150 hängen ebenfalls an Switchports, die DHCP trusted Ports sind. Sonst bekommen die WLAN-Clients keine Adresse. Da hab ich vermutlich woanders einen laienhaften Fehler?
Gruß NV
Gruß NV
das einzig der Windows Server, der DHCP für alle Netze abfackelt, an seinem Switchport „trusted“ ist.
Das ist auch genau richtig so.Meine Cisco WAP-150 hängen ebenfalls an Switchports, die DHCP trusted Ports sind.
Das wäre falsch und auch unlogisch wenn sie nur DHCP Clients sind. Ansonsten müsste diese Regel analog ja auch für alle anderen DHCP Clients wie Winblows PCs usw. gelten.Das denke ich auch ! Da hast du dann ein paar Löcher für rogue DHCP Angriffe. Und das dann ausgerechnet auf den WLAN Ports...nicht gut !
Besser also nochmal nachlesen was das genau ist und wie es funktioniert...
https://de.wikipedia.org/wiki/DHCP-snooping
(Man achte auf den "Trusted Port" !!)
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2 ...
https://community.fs.com/blog/what-is-dhcp-snooping-and-how-it-works.htm ...
Zitat von @aqui:
Das denke ich auch ! Da hast du dann ein paar Löcher für rogue DHCP Angriffe. Und das dann ausgerechnet auf den WLAN Ports...nicht gut !
Besser also nochmal nachlesen was das genau ist und wie es funktioniert...
https://de.wikipedia.org/wiki/DHCP-snooping
(Man achte auf den "Trusted Port" !!)
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2 ...
https://community.fs.com/blog/what-is-dhcp-snooping-and-how-it-works.htm ...
das einzig der Windows Server, der DHCP für alle Netze abfackelt, an seinem Switchport „trusted“ ist.
Das ist auch genau richtig so.Meine Cisco WAP-150 hängen ebenfalls an Switchports, die DHCP trusted Ports sind.
Das wäre falsch und auch unlogisch wenn sie nur DHCP Clients sind. Ansonsten müsste diese Regel analog ja auch für alle anderen DHCP Clients wie Winblows PCs usw. gelten.Das denke ich auch ! Da hast du dann ein paar Löcher für rogue DHCP Angriffe. Und das dann ausgerechnet auf den WLAN Ports...nicht gut !
Besser also nochmal nachlesen was das genau ist und wie es funktioniert...
https://de.wikipedia.org/wiki/DHCP-snooping
(Man achte auf den "Trusted Port" !!)
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2 ...
https://community.fs.com/blog/what-is-dhcp-snooping-and-how-it-works.htm ...
@aqui: Moin. Gerade mal geprüft. Ich rede natürlich Quatsch und du hast recht. Die APs hängen mit dem GUI im VLAN 1 untagged und für's WLAN in VLAN 60 tagged. Die Switchports für die APs sind nun "DHCP untrusted ports" und es funktioniert natürlich. Nur der Windows DHCP-Server hängt an einem Switchport, der "DHCP trusted" ist.
@NixVerstehen: So ist DHCP Snooping dann bilderbuchmässig eingerichtet !
@hausrocker:
Wenn man es richtig macht müssten...
Ports 25 und 26 sind korrekt eingestellt.
Ein Access Port ist eben ein Access Port der NUR ein einziges VLAN UNtagged supportet. Willst du zusätzlich noch Taggen darüber ist das doch immer ein Trunk. Das weiss auch der Azubi schon...
Du solltest dir besser nochmal die VLAN Schnellschulung reinziehen um das besser zu verstehen und zu verinnerlichen !
@hausrocker:
Port 19-24 sind für WLAN (also VLAN 50 tagged) aber nicht VLAN1 untagged. Darum da die 99 zusätzlich untagged.
Da ist dann oben aber etwas gehörig schiefgelaufen, denn der Screenshot zeigt ja bei 19-24 rein nur Access Ports im VLAN 99 an mit denen dein Vorhaben dann gründlich in die Hose geht !! Das siehst du doch auch selber in der VLAN Port Übersicht das dort ein "50T" irgendwo fehlt !!Wenn man es richtig macht müssten...
- 19-24 in den Trunk Mode gesetzt werden
- VLAN 99 auf UNtagged stellen
- VLAN 50 auf Tagged setzen
- In der Port Übersicht sollte dann dort stehen 99P, 50T
Ports 25 und 26 sind korrekt eingestellt.
und ich kann auch tagged nicht auswählen?
Logisch wenn du die Ports 19 bis 24 taggen willst, sie aber im falschen Port Mode betreibst !! Ein Access Port ist eben ein Access Port der NUR ein einziges VLAN UNtagged supportet. Willst du zusätzlich noch Taggen darüber ist das doch immer ein Trunk. Das weiss auch der Azubi schon...
Würde das so funktionieren? Oder ist da irgendwo noch ein Fehler drin?
Nein, würde so natürlich NICHT funktionieren, denn deine Ports 19 bis 24 sind wegen der Port Mode Fehlkonfiguration einzig nur UNtagged in VLAN 99 haben aber keinerlei Connectivity ins VLAN 50 wie gefordert. Siehst du ja auch selber mit dem 99P in der Port Übersicht !Von Management VLAN sind wir aktuell noch weit weg.
Warum ?? Es sind 10 Sekunden im Setup mit einem Mausklick das schon vorzubereiten und mit anzulegen. Unverständlich...also auch noch unnötig großes Subnetz mit jeder Menge Broadcast Traffic an alle.
Weise Worte !! Du solltest dir besser nochmal die VLAN Schnellschulung reinziehen um das besser zu verstehen und zu verinnerlichen !
Ja, aber nur wenn du "dumme" WLAN APs verwendest die kein MSSID (mehrere virtuelle SSIDs pro VLAN ID) können.
Die kann man untagged über einen simplen nur Access Port anschliessen.
Wenn du aber einen MSSID AP anschliesst kann man das zwar auch machen sollte es aber niemals, denn das Management liegt an solchen APs immer untagged an und man hätte so das Management des APs immer auch gleich parallel im aktiven WLAN liegen.
Bei prvaten und gesicherten Netz ggf. grad noch tolerabel wenn man damit leben kann. Bei Gastnetzen ist das aber natürlich nicht so besonders dolle wie du dir selber denken kannst, würde aber letztlich auch laufen.
Es hängt also immer von der Art und Weise deiner WLAN AP Hardware ab und WIE du diese APs anschliesst bzw. dein WLAN designed hast. Dazu hast du leider nix gesagt bis dato so das wir nur frei raten können.
Wie das mit MSSID APs geht zeigt dir dieses_Tutorial an eimem Praxisbeispiel.
Wenn du "dumme" APs hast ist das natürlich obsolet...
Wenn du ihm das richtig beibringst kann der auch mit VLAN Tags umgehen. Guckst du hier:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Lesen und verstehen...!
Ein Access Port überträgt immer nur den UNgetaggten Traffic aus dem VLAN das ihm als Port über das Setup zugewiesen ist. Wenn du keinerlei Zuweisung machst befinden sich solche Ports immer im Default VLAN 1. Wenn du ihnen über das Setup z.B. den Port 50 zuweist befinden sie sich in dem VLAN das du ihm zuweist (und nur in dem).
Ganz einfache Logik !
Man darf aber nie vergessen dass an den Trunk Ports dann immer sämtlicher Allerweltstraffic anliegt und Endgeräte belastet.
Besser also man macht es gleich richtig !
Die kann man untagged über einen simplen nur Access Port anschliessen.
Wenn du aber einen MSSID AP anschliesst kann man das zwar auch machen sollte es aber niemals, denn das Management liegt an solchen APs immer untagged an und man hätte so das Management des APs immer auch gleich parallel im aktiven WLAN liegen.
Bei prvaten und gesicherten Netz ggf. grad noch tolerabel wenn man damit leben kann. Bei Gastnetzen ist das aber natürlich nicht so besonders dolle wie du dir selber denken kannst, würde aber letztlich auch laufen.
Es hängt also immer von der Art und Weise deiner WLAN AP Hardware ab und WIE du diese APs anschliesst bzw. dein WLAN designed hast. Dazu hast du leider nix gesagt bis dato so das wir nur frei raten können.
Wie das mit MSSID APs geht zeigt dir dieses_Tutorial an eimem Praxisbeispiel.
Wenn du "dumme" APs hast ist das natürlich obsolet...
kriegen einfach sowohl 1UP und 50T, damit sie beides übertragen.
Das ist auch perfectly OK und richtig !Aber mein PC kann ja gar nichts mit diesem VLAN Tag in den Paketen anfangen dachte ich?
Nicht denken sondern nachdenken !!! Wenn du ihm das richtig beibringst kann der auch mit VLAN Tags umgehen. Guckst du hier:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Lesen und verstehen...!
Oder wie kann ein PC in 2 VLAN drin sein?
Sogar in 20 und theoretisch sogar in 4096 ! Welchen Grund hat man denn Ports auf Access zu setzen?
Das die Accessports nicht mit überflüssigem Traffic (Broad- Multicast) aus allen anderen VLANs belastet werden.Ein Access Port überträgt immer nur den UNgetaggten Traffic aus dem VLAN das ihm als Port über das Setup zugewiesen ist. Wenn du keinerlei Zuweisung machst befinden sich solche Ports immer im Default VLAN 1. Wenn du ihnen über das Setup z.B. den Port 50 zuweist befinden sie sich in dem VLAN das du ihm zuweist (und nur in dem).
Ganz einfache Logik !
dass da alle Ports auf Trunk einfach stehen...
Ja das ist leider Default und sollte man dringent ändern wenn man in Produktion geht. Das machen viele Hersteller so um auch DAUs und Laien abzuholen bzw. sicherzustellen das die eine VLAN Konfig hinbekommen. Die meisten verstehen leider den Unterschied zw. Access Ports und Trunk Ports nicht so das Hersteller schrotschussartig alles auf Trunk setzen. Trunks übertragen ha auch immer ungetaggten Traffic und so geht man zu 99% sicher das die Konfig klappt. Ob solche Konfig dann sinnvoll und sicher ist spielt bei solchen Admins eher eine untergeordnete Rolle. Leider... Für den Hersteller kosten aber Support Calls bei billigen Massenprodukten einfach nur Geld die die Margen dieser Produkte nicht hergeben. Einfaches Prinzip...Man darf aber nie vergessen dass an den Trunk Ports dann immer sämtlicher Allerweltstraffic anliegt und Endgeräte belastet.
Besser also man macht es gleich richtig !
TO: Wenn's das denn nun war bitte dann nicht vergessen diesen Thread zu schliessen:
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Ist das so richtig mit den Buchstaben und VLAN Zahlen?
Jupp, alles richtig. Die Buchstaben bedeuten T=tagged, U=Untagged, I=Inactive einfach und logisch ! Dieses Default VLAN 1 soll am besten einfach nicht mehr funktionieren/benutzt werden.
Das kann man so machen wenn man möchte ist aber nicht zwingend. Einen goldenen Rat kann es da nicht geben, denn das hängt immer von deiner lokalen Policy ab wie DU sowas handhaben willst !VLAN 101 konfiguriere ich auf den Trunks und zusätzlich auf den Ports, wo meine Rechner hängen auf denen ich die Webinterfaces von den Switchen öffnen können will, richtig?
Nein, das ist grundfalsch jedenfalls was die Ports anbetrifft.Die Switches hängst du mit ihrer Management IP dann in das VLAN 101 wie du es hier am Beispiel von VLAN 11 siehst:
Analog dann mit dem 220er. Aller anderen Geräte die am Switch hängen und im Management VLAN hängen sollen bekommen einen Port der nur UNtagged im VLAN 101 ist oder wenn sie z.B. wie MSSID WLAN Accesspoints mit einem Trunk verbunden sind dann das 101 als native VLAN (PVID) gesetzt. So ist immer sichergestellt das alles diese Geräte eine Management IP im VLAN 101 haben.
Entscheidend für den Zugriff ist dann WIE das Routing zw. den VLANs gelöst ist ??
Dazu hast du leider keinerlei Angabe gemacht.
Der 350X ist ein Layer 3 Switch und du könntest damit ein klassisches Layer 3 Konzept umsetzen:
Sprich der Switch routet dann zwischen den VLANs.
Mit Hilfe von IP Accesslisten (ACL) auf den VLAN IP Interfaces des Switches kontrollierst du dann WER mit WAS wohin darf. Natürlich nur wenn du eine Einschränkung des VLAN übergreifenden Traffics vornehmen willst. Mindestens aber eine ACL auf das 101 Management VLAN die den Zugriff dort nur einigen Geräten oder dem Admin und sein Segment erlaubt.
Die andere Option ist ein Layer 2 Konzept mit einem externen Router oder Firewall die das VLAN Routing übernimmt.
Hier steuert dann der Router oder die Firewall mit einem entsprechenden Regelwerk den VLAN Traffic.
Es ist also essentiell wichtig welches Konzept du umsetzt !!! Eins geht nur und du musst dich entscheiden.
...auf dem Switch und stelle für 100 um auf "excluded" und 50 um auf "untagged", fertig. Richtig?
Das ist genau richtig so !dann muss ich danach ja zu jedem Sub-Switch hin und da die Konfiguration anpassen
Jein....Dein VLAN 101 in der neuen Infrastruktur entspricht vermutlich dem bestehenden VLAN 1 bei den alten Access Switches, richtig ?
Wenn du diese zusammen betreiben willst, dann stellst du auf den Koppelports zu den alten Switches das VLAN 101 als native VLAN ein (PVID 101, 101UP). Der empfangende, alte Switch wird dann diese ungetaggten VLAN 101 Pakete in sein Default VLAN 1 forwarden auf dem Trunk. So kannst du immer einen hybriden Übergang gestallten wenn du die alten Switches parallel betreiben musst und sie sukzessive austauschen willst.
Aktuell und bisher ohne den SX350 war der Plan den Draytek Router routen zu lassen.
OK, dann klassisches L2 Konzept mit dem Draytek.Der SX350 kann das sicher schneller vom Durchsatz her als der Draytek würde ich vermuten
Ja, der könnte das in 10G Wirespeed. Da ist der kleine Draytek meilenweit von entfernt...Das VLAN, das unser default VLAN 1 ersetzen soll, ist das VLAN100.
Das ist absolut OKAktuell ist auf allen Switchen jeder Port auf Trunk und nur default VLAN1 ist hinterlegt.
Auf den Trunks setzt du dann das Native VLAN auf 100 (PVID 100) und schon passt das.Ich würde es so machen:
Das ist bis aus Punkt 2 auch korrekt so. Auf den Trunks solltest du eben nicht das VLAN 1 als native VLAN laufen lassen sondern das VLAN 100 (PVID 100, 100UP) auf den Trunks. Das hat den großen Vorteil das dein VLAN 1 dann nicht zwischen den Switches verteilt wird sondern pro Switch isoliert ist. Außerdem entfällt dann auch Punkt 5. komplett. Macht die ganze Sache noch VLAN 1 "freier"Ansonsten sind die Punkte perfekt richtig.
Das mit dem nativen VLAN habe ich noch nicht kapiert.
Guckst du hier:Warum gibt es PVID bei VLANs?
Nativ heißt ja in dem Fall, dass das das VLAN ist, über das der ungetaggte, also keinem VLAN zugeordnete Traffic läuft.
Richtig ! Ob man das Native, Default oder PVID VLAN nennt ist kosmetisch und macht jeder Hersteller nach Belieben.Und bei Cisco ist ab Werk das default VLAN (1) auch gleichzeitig das native VLAN (1).
Nicht nur bei Cisco. Das ist weltweit bei (fast) allen Herstellern so !!Ich sage dem Trunk also, dass er ungetaggten Traffic (von den alten Switchen und auch Endgeräten) in VLAN 100 transportieren soll mit dieser Einstellung?
Jein...aber fastWenn du auf der einen Seite (z.B. alte Switches) das Management im Default VLAN 1 hast dann belässt du den Trunk so wie er ist.
Auf der anderen, neuen Seite legst du das Native, Default oder PVID VLAN dann auf VLAN 100.
Das PVID VLAN besagt ja lediglich nur in welches VLAN UNgetaggte Pakete geforwardet werden. Das kann der Switch ja nicht nach raten entscheiden, denn diesen Frames fehlt ja die VLAN Information. Folglich muss man das dem Switch sagen.
Alles was der alte Switch dann am Trunk ungetaggt aussendet (VLAN 1) forwardet der neue Switch dann ins VLAN 100 und umgekehrt. Ein Bild sagt mehr als 1000 Worte...
So kannst du sukzessive die alte Infrastruktur auf die Neue umstellen. Mit neuen Switches setzt du dann das Trunk, PVID VLAN immer auf 100 und elimierst so schrittweise das VLAN 1.
gesteht für den Trunk: 1T,
gesteht ??Warum hast du den ungeliebtes VLAN 1 hier wieder Tagged auf den Trunk gebracht ?? Das ist ist Unsinn, wenn du VLAN 1 frei leben willst in deinem neuen Setup. Das solltest du also besser wieder löschen !
ist aber auf keinem Port eingerichtet.
Glatt gelogen !! Siehe oben ! "1T" 🧐Native VLAN mismatch detected on interface te1/0/11. kommt jetzt immer auf dem SX350.
WAS ist am Port te1/0/10 angeschlossen ?? Vermutlich der Catalyst, oder ?Der sendet über das Cisco Infrastruktur Protokoll CDP seine Native VLAN ID an das Gegenüber aus. Der empfängt das, sieht das seine native VLAN ID anders ist und meckert das an.
Solltest du als Netzwerk Profi eigentlich wissen wenn du Cisco einsetzt !
Ist mehr oder minder kosmetisch nervt aber natürlich auf die Dauer bzw. müllt das Log voll.
CDP ist proprietär und sollte man nicht mehr nutzen. Besser ist es auf den weltweiten Standard LLDP zu gehen. Ganz besonders wenn man eine heterogene Umgebung hat ! Außerdem sollte man immer nur ein Infrastruktur Protokoll nutzen niemals mehrere parallel !
Es gibt 2 Möglichkeiten das zu fixen.
- Auf dem Catalysten am Koppelport "no cdp enable" eingeben und zusätzlich optional "switchport nonegotiate".
- Optional CDP global deaktivieren mit "no cdp run". In den SG Modellen "CDP enable" im GUI deaktivieren. Dann LLDP global aktivieren mit "lldp run" bzw. im SG GUI unter LLDP auf "enable" klicken (Default).
Einen ganz fatalen Nachteil hast du noch wenn du SG und Catalyst Welt zusammenbringst, den du unbedingt fixen musst wenn du nicht in schwere Fehler laufen willst.
Die Catalysten nutzen PVSTP+ als Spanning Tree Verfahren. Ein Cisco proprietäres Spanning Tree Verfahren was die SG nicht supporten ! Die SGs können nur RSTP im Single Span Verfahren was wiederum die Catalysten nicht können oder MSTP.
Das kleineste gemeinsame Vielfache ist also MSTP !
Wenn du also langfristig nicht in fatale Spanning Tree Probleme laufen willst oder deine Redundanz aufs Spiel setzt, dann MUSST du das entsprechend umstellen !!
Dieser Thread beschreibt genau was zu tun ist:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)
Wichtig ist das du dem 350X sollte der neuer Core Switch sein zwingend eine entsprechende STP Priority modulo 4096 setzt !
Der ist nicht alleine der Hauptknoten auf dem alle Switche hängen,
Mehrere separate oder ein Stack ? Stack gilt ja eh als ein Switch. Bei mehreren bekommt dann der, der die meisten Links hält, z.B. die Prio 8195 und der andere dann 12288.Alle anderen belässt man auf dem Default Wert 32768. So ist absolut sichergestellt das die direkten Backbone Links zu den Core Switches immer im Forwarding Mode sind !
Passt man die Prio nicht an wird der Core per Zufall ermittelt (niedrigste Mac). In einem redundanten Netz kann das ein mickriger Access Switch dann sein über den sich alle quälen müssen. Die korrekte STP Priotity der Cores in einem strukturierten Netz ist also extrem wichtig.
Was für schwere Fehler kann das denn bewirken?
Toggelnde oder flappende Links. Die dann über die STP Learning und Forwarding Timeouts wechselnde Unterbrechungen u.a. erzeugen können.Du solltest also immer das STP Log im Auge haben !
Wir haben keine Switche die als Stack laufen.
OK, dann ist das nur ein einzelner 350er im Core, richtig. Ist nicht so toll, denn das ist ein single Point of Failure. Wenn du aber mit einem nicht redundanten Netz leben kannst ist das aber OK so.Ein klassisches, redundantes Banalnetz sähe so z.B. aus:
Daraus kannst du ja die für dich sinnvollest Variante ableiten.
Aber dann ging es.
Normale Spanning Tree Lern- und Forwarding Phase ! Denk dran das du dem Core Switch (350er) dann unbedingt eine höhere STP Prio gibst ! Z.B. 8152 !was von alleine konfiguriert hat
Sowas gehört in der IT, wie immer, in den Bereich der Märchen ! Ging aber nicht...
Da hast du dann den Catalyst falsch konfiguriert ! Die Port Konfig des Catalysten wäre da sehr hilfreich gewesen für eine zielführende Hilfe. Leider hats dafür ja nicht gereicht. Richtig im Vergleich zum SG350X Port müsste die so aussehen:
interface gigabit 2/0/1
description Uplink zum SG350
switchport nonegotiate
switchport mode trunk
switchport trunk allowed vlan all
switchport trunk native vlan 82
Wenn du dediziert am Catalyst nur die VLANs durchreichen willst die der SG350 hat dann ist es besser
switchport trunk allowed vlan 80, 82, 101 statt "all" zu setzen.
Soll das Default VLAN 1 am Trunkport des Catalysten untagged ins VLAN 82 des 350ers musst du das Kommando "switchport trunk native vlan 82" weglassen und dann kann logischerweise natürlich auch die 82 unter "allowed vlans" entfallen, da es das VLAN 82 da ja nicht gibt.
ACHTUNG !! Nochwas Wichtiges !!
Der Catalyst macht in der Regel als Default Spanning Tree PVSTP+ also ein per VLAN STP Verfahren was Cisco proprietär ist. So verrückt wie es klingt aber der 350er ist dazu NICHT kompatibel, da er generell nur ein Standard Single Span Verfahren supportet.
Spanning Tree seitig sind diese Switches so im Default zumindestens inkompatbel und es kommt zu Aussetzern und unkontrolliertem STP Verhalten wenn du das nicht anpasst !!
Es gibt 2 Optionen das zu fixen:
- Spanning Tree am Koppelport beidseitig ausschalten, deaktivieren
- Den Catalysten und 350er auf MSTP umschalten was beide verstehen
Option 2 ist das was der vernünftige Netzwerker macht.
Guckst du dazu auch hier:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)
Und gibt es einen Weg, wie ich den Catalyst umkonfiguriere
Ja ! Indem du das am Catalysten über den seriellen Konsolport machst !
Sinnfreier Post, denn er hilft nicht einen Schritt weiter. Er zeigt NICHT die Konfig bzw. Port Konfig des Catalysten. Schon mal was von show run gehört ?! Solltest du doch auch vom 350er kennen...zumindestens wenn du auf seinem CLI bist.
Status "notconnect" sagt ja auch alles. Da hängt nix dran bzw. der Port hat gar keinen physischen Link. Siehst du ja oben auch am Status Down/Down.
Da hast du wohl vergessen den Stecker vom Catalysten in den 350er zu stecken. Wenn's daran schon scheitert muss man sich ja nicht wundern...
Line Protocol Down sagt schon das grundlegend an der Physik was nicht stimmt. Fixe also erstmal deine Verbindung !
Wenn man den Stecker nicht in die Dose steckt kommt auch kein Saft am anderen Ende an... Einfachste Logik.
Status "notconnect" sagt ja auch alles. Da hängt nix dran bzw. der Port hat gar keinen physischen Link. Siehst du ja oben auch am Status Down/Down.
Da hast du wohl vergessen den Stecker vom Catalysten in den 350er zu stecken. Wenn's daran schon scheitert muss man sich ja nicht wundern...
Line Protocol Down sagt schon das grundlegend an der Physik was nicht stimmt. Fixe also erstmal deine Verbindung !
Wenn man den Stecker nicht in die Dose steckt kommt auch kein Saft am anderen Ende an... Einfachste Logik.