hausrocker
Goto Top

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.

sg220

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"?

Content-ID: 1283912375

Url: https://administrator.de/contentid/1283912375

Printed on: December 2, 2024 at 14:12 o'clock

aqui
aqui Sep 20, 2021 updated at 12:41:54 (UTC)
Goto Top
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:
  • Port Mode : Trunk
  • Tagged : VLAN 50
  • VLAN 1 belassen wie es ist
Am Port in der VLAN Port Übersicht steht dann 1UP, 50T dann ist es richtig.
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. face-wink
Wie gesagt, Endgeräte Ports immer fest in den Access Mode setzen !
hausrocker
hausrocker Sep 20, 2021 at 13:22:27 (UTC)
Goto Top
Wenn ich von dem untagged VLAN ID 1 weg will, muss ich aber quasi alle Switche gleichzeitig am besten konfigurieren um erst mal von untagged 1 auf z.B. tagged 10 umzustellen, dann von da aus weiter Schritt für Schritt in die VLANs aufsplitte, richtig?

Oder wie ist eine gute Idee das umzustellen?

Oder ich lasse den Teil erst mal so und erstelle auf jedem Switch für alle Trunks zusätzlich das VLAN 50 und transportiere über den Trunk sowohl untagged VLAN1 als auch tagged VLAN 50. Manche Ports für Endgeräte kriegen dann untagged einfach z.B. VLAN 99 - da gibt es keine Uplink nirgendwo hin und damit ist die Kommunikation zum alten VLAN 1 unterbunden und tagged 50 mit Uplink zum WLAN Router/Controller. Das wäre doch auch dann eine Möglichkeit oder?
NixVerstehen
NixVerstehen Sep 20, 2021, updated at Sep 21, 2021 at 05:24:58 (UTC)
Goto Top
Und beachte bei WLAN-APs, das die Ports zu den Accesspoints i.d.R. auf Trunk stehen müssen (außer beim Consumerspielzeug). Falls du hier auch DHCP-Snooping verwendest, dann müssen die Ports zu den APs als DHPC Trusted Ports konfiguriert sein.

Edit: Diese Aussage ist falsch...siehe unten
aqui
aqui Sep 20, 2021 updated at 15:53:38 (UTC)
Goto Top
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. face-wink
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 ! face-wink
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". face-wink

@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.
NixVerstehen
NixVerstehen Sep 20, 2021 at 16:22:45 (UTC)
Goto Top
@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
aqui
aqui Sep 20, 2021 updated at 17:53:49 (UTC)
Goto Top
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... face-wink
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 ...
NixVerstehen
NixVerstehen Sep 21, 2021 at 05:22:43 (UTC)
Goto Top
Zitat von @aqui:

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... face-wink
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.
hausrocker
hausrocker Sep 21, 2021 updated at 06:24:40 (UTC)
Goto Top
Ich habe gestern mal ein wenig rumprobiert, in meiner Testumgebung mit aktuell nur 2 SG220:

VLAN 1 (default), 50 und 99 angelegt unter "Create VLAN"
Interface Setting sieht so aus:
interface setting

Die Idee ist: Port 1-18 sind für normale Clients mit VLAN1 untagged.
Port 19-24 sind für WLAN (also VLAN 50 tagged) aber nicht VLAN1 untagged. Darum da die 99 zusätzlich untagged.
Port 25 und 26 sind die Trunk Ports und sollen sowohl 1 untagged als auch 50 tagged transportieren
port to vlan
port to vlan 50
Hier ist das 50er VLAN irgendwoe bei allen auf "Excluded"... und ich kann auch tagged nicht auswählen?
port vlan membership

Würde das so funktionieren? Oder ist da irgendwo noch ein Fehler drin? Ich musste die Einstellungen in einer bestimmten Reihenfolge machen, sonst hat er mich das 99er VLAN nicht mehr auf untagged stellen lassen.

Von Management VLAN sind wir aktuell noch weit weg. Aktuell liegt alles in einem einzigen IP Bereich mit 23er Subnetzmaske, also auch noch unnötig großes Subnetz mit jeder Menge Broadcast Traffic an alle.
aqui
aqui Sep 21, 2021 updated at 08:07:34 (UTC)
Goto Top
@NixVerstehen: So ist DHCP Snooping dann bilderbuchmässig eingerichtet ! face-wink

@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
So wäre es dann korrekt !
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 !! face-wink
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... face-wink
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 !! face-wink
Du solltest dir besser nochmal die VLAN Schnellschulung reinziehen um das besser zu verstehen und zu verinnerlichen !
hausrocker
hausrocker Sep 21, 2021 at 13:35:26 (UTC)
Goto Top
Muss das bei Konfig als Access Port dann nicht nur entweder 50UP einfach für die WLAN Ports und 1UP(default) für die "normalen" Ports sein?

Nur die Trunkports, über die Switches verbunden sind kriegen einfach sowohl 1UP und 50T, damit sie beides übertragen.

Die Idee hinter den Admin VLAN: Ich setze den Port wo mein PC dran hängt von wo aus ich den Switch (und andere Gerätschäften) konfigurieren will auf Trunk und setze VLAN1 untagged für normale Nutzung und zusätzlich VLAN101 als Admin VLAN damit ich von da aus auch den Switch konfigurieren kann? Aber mein PC kann ja gar nichts mit diesem VLAN Tag in den Paketen anfangen dachte ich? Oder wie kann ein PC in 2 VLAN drin sein?
Welchen Grund hat man denn Ports auf Access zu setzen? Nur Access Ports versorgen Rechner mit etwas anderem als dem default VLAN?

Aktuell habe ich auf einem schon im Einsatz befindlichen Switch gesehen, dass da alle Ports auf Trunk einfach stehen...
aqui
aqui Sep 21, 2021 updated at 14:26:23 (UTC)
Goto Top
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...

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 !!! face-wink
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 ! face-wink
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 ! face-wink
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 ! face-wink
aqui
aqui Oct 11, 2021 at 08:18:06 (UTC)
Goto Top
TO: Wenn's das denn nun war bitte dann nicht vergessen diesen Thread zu schliessen:
How can I mark a post as solved?
hausrocker
hausrocker Oct 12, 2021 at 10:05:49 (UTC)
Goto Top
Hi aqui
Ist noch nicht erledigt.

Ich habe jetzt einen Testaufbau mit 3 Geräten: 2xSG220, 1xSX350X
SX350X hat via Port 11+12 (jetzt schon) sowie 23+24 (geplant) und via GBIC SFP Modul eine Verbindung zu den anderen Switchen.

VLAN habe ich angelegt:
1 default
50 WLAN
99 Default
100 Verwaltung
101 Management

SG220:
1-24 als Access haben Administrative VLANs 100UP, Operational VLANs 100UP
25,26 als Trunk haben Administrative VLANs 1TP,100T,101T , Operational VLANs 1TP,100T,101T

SX350X:
1-10 als Access haben Administrative VLANs 100UP, Operational VLANs 100UP
11-12 als Trunk haben Administrative VLANs 1U, 2-49I, 50T, 51-98I, 100-101T, 102-4094I, Operational VLANs 1U, 50T, 100-101T
Das sind die beiden Trunk Ports und die Konfig haben die automatisch bekommen. Bestimmt haben die das via Spanning Tree als Info ausgetauscht.

Das VLAN 50 WLAN wird auf dem Draytek Router Port basiert mit einem eigenen Subnetz versehen. Port LAN 2 am draytek.
VLAN 100 Verwaltung soll an LAN 1 vom Draytek alle Geräte mit dem eigentlichen Produktivnetzwerk versorgen.

Ist das so richtig mit den Buchstaben und VLAN Zahlen?
Stelle ich das automatisch eingerichtete VLAN auf dem SX350 noch mal selbst per Hand um am besten?

Dieses Default VLAN 1 soll am besten einfach nicht mehr funktionieren/benutzt werden. Dafür wollte ich das von den Trunks runternehmen.

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?

Alternativ könnte ich auch unter IP Configuration - Management Interface - IPv4 Interface ein Interface für das VLAN 100 erstellen mit entsprechender IP, wenn ich von überall auf das Webinterface können möchte, richtig?

Und wenn ich dann einen Access Port der jetzt VLAN100 ist auf VLAN50 umstellen will, weil da das WLAN Subnetz drüber laufen soll, dann gehe ich einfach hin und gehe in "Port to VLAN" auf dem Switch und stelle für 100 um auf "excluded" und 50 um auf "untagged", fertig. Richtig?

Wie ist denn der beste Trick mit dem umstellen von Test auf Produktiv? Wenn ich den Hauptswitch tausche und der mit dem aktuell verwendeten default VLAN1 nicht mehr zu tun haben will, dann muss ich danach ja zu jedem Sub-Switch hin und da die Konfiguration anpassen. Oder fange ich beim tiefsten Subswitch an, stelle den um, dann ist er erst mal offline, bis ich beim Hauptswitch angekommen bin und erst wenn der auch passende VLAN Konfig hat kann ich (im besten Fall) wieder alle erreichen?
aqui
aqui Oct 12, 2021 updated at 10:39:33 (UTC)
Goto Top
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 ! face-wink
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:
mgmt
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:
l3.
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.
l2.
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.
hausrocker
hausrocker Oct 12, 2021 at 11:56:18 (UTC)
Goto Top
Aktuell und bisher ohne den SX350 war der Plan den Draytek Router routen zu lassen. Der macht port basiertes VLAN und hat auf Port 1 das VLAN 100 und auf Port 2 das VLAN 50 mit je eigenem Subnetz und eigenem Gateway.

Der SX350 kann das sicher schneller vom Durchsatz her als der Draytek würde ich vermuten. Aber das ist dann eine der nächsten Ausbaustufen würde ich sagen.

Das VLAN, das unser default VLAN 1 ersetzen soll, ist das VLAN100.
Aktuell ist auf allen Switchen jeder Port auf Trunk und nur default VLAN1 ist hinterlegt.

Ich würde es so machen:
1. Alle VLANs auf allen Switchen schon mal anlegen aber keine Port zuweisen.
2. Die Trunk Ports bleiben auf Trunk und kriegen neben untagged VLAN 1 erst mal auch noch das VLAN100 tagged dazu.
3. Dann die Clients auf untagged 100 und weg von default 1 und auf Access stellen. Welche Reihenfolge? Erst access, dann VLAN 100 untagged würde ich sagen?
4. Dann das IPv4 Management Interface von VLAN 1 auf VLAN 100 umstellen.
5. VLAN 1 von den Trunkports runternehmen.

Durch Schritt 2 ändert sich nichts und ich bin jeder Zeit weiterhin in der Lage bequem von meinem Büro aus alle Switche zu erreichen.
aqui
aqui Oct 12, 2021 at 13:26:13 (UTC)
Goto Top
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 OK
Aktuell 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.
hausrocker
hausrocker Oct 12, 2021 at 14:17:56 (UTC)
Goto Top
Das mit dem nativen VLAN habe ich noch nicht kapiert.
Nativ heißt ja in dem Fall, dass das das VLAN ist, über das der ungetaggte, also keinem VLAN zugeordnete Traffic läuft.
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?


Und bei Cisco ist ab Werk das default VLAN (1) auch gleichzeitig das native VLAN (1). Sind aber 2 unterschiedliche Dinge.
aqui
Solution aqui Oct 12, 2021 updated at 14:43:17 (UTC)
Goto Top
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 fast
Wenn 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. face-wink
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...
unbenannt
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. face-wink
hausrocker
hausrocker Oct 14, 2021 at 11:12:48 (UTC)
Goto Top
Der erste Hauptswitch SX350 ist installiert und mit dem ersten alten Gigabit Switch verbunden und ist erreichbar.
Auf dem SX350 habe ich jetzt das Netz in dem alle Clients drin sind (VLAN100 bzw. ich habe es noch mal umbenannt in 82) auf untagged gesteht für den Trunk: 1T, 50T, 82U, 99T, 101T und ich komme vom alten Switch (mit default VLAN1) auf den neuen Switch (mit untagged VLAN82): Webinterface vom Switch geht, ping geht.

Default steht auf dem neuen weiterhin auf VLAN1 - ist aber auf keinem Port eingerichtet.

Ein Client kriegt auch so wie gewünscht aus dem passenden VLAN82 eine IP etc.

Vielen Dank Aqui
Ich lasse das mal noch was offen, vllt. kommt noch was beim umstellen der untergeordneten Switche.
aqui
aqui Oct 14, 2021 at 11:25:24 (UTC)
Goto Top
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" 🧐
hausrocker
hausrocker Oct 14, 2021 at 13:16:31 (UTC)
Goto Top
Ok, das war noch ein Fehler wohl. Ist aber raus.
hausrocker
hausrocker Oct 15, 2021 updated at 08:28:22 (UTC)
Goto Top
%CDP-W-NATIVE_VLAN_MISMATCH: Native VLAN mismatch detected on interface te1/0/11. kommt jetzt immer auf dem SX350.

Konfig SX350:

XG11 Trunk Administrative VLAN: 2-49I, 50T, 51-81I, 82U, 83-98I, 99T, 100I, 101T, 102-4094I Operational VLANs: 50T, 82U, 99T, 101T

Der Port 49 auf dem Catalyst 2960 wo das hinverbunden ist steht auf VLAN1, nicht auf trunk... Ist das der Grund??
Es gibt nur VLAN 1 und trunk als Auswahl aktuell im Webinterface.

An sich zumindest mein 82er VLAN. Ob das mit 50 geht habe ich noch nicht ausprobiert weiter. Das ist ja jetzt nicht auf U sondern nur auf T auf dem Trunk. Sollte aber auch funktionieren dann oder?

Und was will die Fehlermeldung von mir?
aqui
aqui Oct 15, 2021 updated at 08:40:08 (UTC)
Goto Top
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 ! face-wink
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).
Ein "show lldp neig" zeigt dir dann auf dem Catalysten die Nachbarn an. Analog im SG GUI wenn man auf Neigbors klickt.

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 !
hausrocker
hausrocker Oct 15, 2021 at 09:26:21 (UTC)
Goto Top
Ok, mit kosmetisch kann ich vorerst leben und die Catalyst sollen ja ersetzt werden.
Was für schwere Fehler kann das denn bewirken?
Der Port 11 ist der, wo der Catalyst dran ist. Also die Erklärung passt.

Dass die SG nicht mit alten Catalyst zusammenarbeiten wollen, habe ich auch schon gemerkt als wir den ersten ersetzt haben.

Wofür ist das mit STP Priority? Der ist nicht alleine der Hauptknoten auf dem alle Switche hängen, weil wir dann nicht genug SFP Ports hätten.

Ich bin ja eben (leider) nicht ausgewiesener Netzwerk und Cisco Profi. Darum bin ich auch für die Hilfe sehr dankbar.

Um VLAN50 funktional zu kriegen auf einem Port, wenn das aktuell mit 50T auf dem Trunk hängt, stelle ich nur einen Port von 82UP auf 50UP um, richtig?
aqui
aqui Oct 15, 2021 at 09:41:25 (UTC)
Goto Top
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 !
hausrocker
hausrocker Nov 05, 2021 updated at 10:50:16 (UTC)
Goto Top
Wir haben keine Switche die als Stack laufen. Zumindest zukünftig nicht mehr. Da sind aktuell noch 2 die durch den 10Gbit Switch aber abgelöst werden. Die Resette ich dann komplett und nehme die als Client Switch am Ende und dann kommen welche mit 100 Mbit weg.

Der 10 Gbit soll der Hauptknosten sein und an den sind so gut es geht die Geräte sternförmig angeschlossen. Der SX-350 hat ja nur 4 SFP Ports, daher wird das ein wenig auf sternförmig mit 2 quasi kaskadierten Switchen rauslaufen.
Sollte ich dann vom Hauptswitch aus zu einem Subswitch gehen und von da aus maximal zu noch einem weiteren Subswitch?

Oder ruhig vom Hauptswitch zu 4 Subswitchen und von jedem davon dann noch mal zu 4 Subswitchen?


Die erste VLAN Konfig läuft aber grundsätzlich jetzt.
SX-350 hat auf den Trunk Ports:
50T, 82U, 99T, 101T
genau wie der SX-220:
50T, 82UP, 101T

Ports mit Access und 82UP sind im 82er VLAN und haben Switch übergreifend Kommunikation.
Ports mit Access und 50UP sind im 50er VLAN und haben Switch übergreifend Kommunikation.

An einem VLAN82 Port hängt der Draytek Router, der port basiertes VLAN macht. An einem anderen Port mit VLAN50 port basiert ist ein Port vom Switch mit VLAN50 angeschlossen.
Ein Port vom Draytek verteilt IPs aus dem 82er Netz und einer aus dem 50er.

Die beiden Ports auf dem Switch jeweils stehen auf Access. Durch Port basierte VLAN Konfig auf dem Draytek brauche ich ja hier keine Trunk konfig, richtig? Ich weiß auch nicht, ob der Draytek da einen seiner Switchports auch auf Trunk stellen könnte und dann beide VLAN über einen Port verarbeiten könnte. Das 82er vermutlich U und das 50er T.

Zuerst als ich die VLAN Konfig da oben physikalisch mit dem Router verbunden habe hat es ein paar Minuten gedauert. In Wireshar waren Spanning-tree Pakete nur zu sehen und die DHCP discover von meinem Testclient.
Aber dann ging es. Ich kann nicht sehen, ob sich da auf einem der Switche was von alleine konfiguriert hat mit doch von mir falsch eingestellten VLANs. Dürfte aber ja nicht sein.
aqui
aqui Nov 05, 2021 updated at 14:53:38 (UTC)
Goto Top
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:
stackdesign
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 !
stp
was von alleine konfiguriert hat
Sowas gehört in der IT, wie immer, in den Bereich der Märchen ! face-wink
hausrocker
hausrocker Dec 08, 2021 updated at 13:27:57 (UTC)
Goto Top
Hi aqui

Teil 1 der Konfig ist funktional. Also 2 Switche, der SX350 und auch ein SG220 haben wie erwartet funktioniert. Alles easy per webinterface zu konfigurieren. Jetzt kommt aber der Endgegner, ein Catalyst WS-C2960X-48TS-L.
Das Webinterface kennt nur so komische "Smart Ports"...

Ich habe die VLANs angelegt via CLI und auch die ports auf mode trunk gesetzt, danach das native VLAN auf 82 (switchport trunk native vlan 92) gestellt und 1,50,82,99,101 auf allowed (switchport trunk allowed vlan 1,50,82,99,101).

Danach sollte der Catalyst via SFP Modul mit dem SX-350 sprechen, dessen Trunkport auf 80T, 82UP, 101T steht.

Ging aber nicht... Bis ich das native VLAN auf 1 für den Trunkport gestellt habe auf dem Catalyst. Warum? Liegt das an dem Management VLAN ID1 auf dem Catalyst? Das läßt sich per webinterface nur anzeigen aber nicht ändern. Dafür muss die CLI zwingend her?

Ich habe da im Moment 15.2(2)E6 drauf. Ich habe schon gesehen es gibt eine 15.2(7)E5 - die wird aber auch nicht Funktionen wie der SX350 via Webinterface dann haben oder?

Und gibt es einen Weg, wie ich den Catalyst umkonfiguriere ohne die Verbindung zu verlieren auf dem Trunk Port und VLAN1? Da hängt wichtige Infrastruktur dran und ich habe angst, wenn ich was umstelle, dass die offline geht... Da würde auch 1 Sekunde reichen und die ESX erreichen ihren Datastore nicht, das würde sehr böse enden sicher.
aqui
aqui Dec 08, 2021 updated at 18:32:05 (UTC)
Goto Top
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. face-sad
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 1 ist quick and dirty und birgt hohe Loop Gefahr. Ist aber tolerabel wenn man ein nicht redundantes Netzwerk hat (nur ein Link)
Option 2 ist das was der vernünftige Netzwerker macht. face-wink
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 !
hausrocker
hausrocker Dec 08, 2021 at 21:04:38 (UTC)
Goto Top
Danke für die Hilfe. Und sorry, dass ich das nicht direkt gepostet habe.
Port      Name               Status       Vlan       Duplex  Speed Type
...
Gi1/0/49  Uplink SX-350      notconnect   50           auto   auto Not Present
...

und

DEGHSW002-2#show interfaces gi1/0/49
GigabitEthernet1/0/49 is down, line protocol is down (notconnect)
  Hardware is Gigabit Ethernet, address is 009a.d2cb.c5b1 (bia 009a.d2cb.c5b1)
  Description: Uplink SX-350
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Auto-duplex, Auto-speed, link type is auto, media type is Not Present
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 05:34:38, output 05:34:12, output hang never
  Last clearing of "show interface" counters never  
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     37425 packets input, 29721526 bytes, 0 no buffer
     Received 16126 broadcasts (13380 multicasts)
     1 runts, 0 giants, 0 throttles
     1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 13380 multicast, 0 pause input
     0 input packets with dribble condition detected
     2624474 packets output, 326869385 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out
DEGHSW002-2#

DEGHSW002-2#show interface trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi1/0/51    on               802.1q         trunking      82
Po4         on               802.1q         trunking      1
Po5         on               802.1q         trunking      1
Po6         on               802.1q         trunking      1

Port        Vlans allowed on trunk
Gi1/0/51    1-4094
Po4         1-4094
Po5         1-4094
Po6         1-4094

Port        Vlans allowed and active in management domain
Gi1/0/51    1,50,82,99,101
Po4         1,50,82,99,101
Po5         1,50,82,99,101
Po6         1,50,82,99,101

Port        Vlans in spanning tree forwarding state and not pruned
Gi1/0/51    1,50,82,99,101
Po4         1,50,82,99,101
Po5         1,50,82,99,101
Po6         1,50,82,99,101
DEGHSW002-2#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi1/0/1, Gi1/0/2, Gi1/0/3, Gi1/0/4, Gi1/0/5, Gi1/0/6, Gi1/0/7, Gi1/0/8, Gi1/0/9, Gi1/0/10, Gi1/0/11, Gi1/0/12, Gi1/0/13
                                                Gi1/0/14, Gi1/0/15, Gi1/0/16, Gi1/0/17, Gi1/0/18, Gi1/0/19, Gi1/0/20, Gi1/0/21, Gi1/0/22, Gi1/0/23, Gi1/0/24, Gi1/0/25
                                                Gi1/0/26, Gi1/0/27, Gi1/0/28, Gi1/0/29, Gi1/0/30, Gi1/0/31, Gi1/0/32, Gi1/0/33, Gi1/0/34, Gi1/0/37, Gi1/0/38, Gi1/0/39
                                                Gi1/0/40, Gi1/0/41, Gi1/0/42, Gi1/0/43, Gi1/0/44, Gi1/0/46, Gi1/0/47, Gi1/0/48, Gi1/0/50, Gi2/0/1, Gi2/0/2, Gi2/0/3, Gi2/0/4
                                                Gi2/0/5, Gi2/0/6, Gi2/0/7, Gi2/0/8, Gi2/0/9, Gi2/0/10, Gi2/0/11, Gi2/0/12, Gi2/0/13, Gi2/0/14, Gi2/0/15, Gi2/0/16, Gi2/0/17
                                                Gi2/0/18, Gi2/0/19, Gi2/0/20, Gi2/0/21, Gi2/0/22, Gi2/0/23, Gi2/0/24, Gi2/0/25, Gi2/0/26, Gi2/0/27, Gi2/0/28, Gi2/0/29
                                                Gi2/0/30, Gi2/0/31, Gi2/0/32, Gi2/0/33, Gi2/0/34, Gi2/0/37, Gi2/0/38, Gi2/0/39, Gi2/0/40, Gi2/0/41, Gi2/0/42, Gi2/0/43
                                                Gi2/0/44, Gi2/0/45, Gi2/0/46, Gi2/0/47, Gi2/0/48, Gi2/0/49, Gi2/0/50, Gi2/0/51
50   WLAN                             active    Gi1/0/47, Gi1/0/49
82   Verwaltung                       active
99   Default                          active
101  Management                       active
1002 fddi-default                     act/unsup
1003 token-ring-default               act/unsup
1004 fddinet-default                  act/unsup
1005 trnet-default                    act/unsup
DEGHSW002-2#



Ich schalte das dann wohl mal aus mit STP. Ich brauche das ja an sich auch wirklich nicht, wenn nichts redundant verbunden ist.

Das unverständliche ist, dass auf dem Catalyst Switch schön LCAP eingerichtet wurde und nen paar Portgruppen. Aber kein einziger Port so richtig auf Trunk steht.
aqui
aqui Dec 08, 2021 updated at 22:59:06 (UTC)
Goto Top
Sinnfreier Post, denn er hilft nicht einen Schritt weiter. face-sad 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... face-sad
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. face-wink