16.03.2022

5272

Redundanz beim Switchstacking (STP?)

Guten Tag zusammen,

dies ist mein erster Beitrag.

Ich bin erst seit einem Jahr ausgelernt und hatte mit Netzwerken leider noch nicht viel zu tun.

Ich hätte eine Frage zum Switchstacking und wäre froh wenn mir dort jemand weiterhelfen könnte.

Ich habe folgende Switche: Netgear M4300 (genauer: https://www.netgear.de/support/product/m4300-52g-poe-plus%20550w%20psu.a ..)

Nun bin ich die Bedienungsanleitung durchgegangen und dort steht auch wie man generell einen Stack konfiguriert. So weit so gut, das habe ich hin bekommen.

Nun möchte ich aber eine möglichst ausfallsichere Infrastruktur schaffen und bei einem Ausfall des Management Switches nicht die Verbindung zum Netzwerk verlieren.

Folgender Aufbau. Ich habe 2 Sophos Firewalls und möchte gerne von jedem der beiden Sophos jeweils eine Verbindung zum Management Switch und eine Verbindung zu einem 2. Switch im Stackverbund. Somit könnte ein Switch, eine Sophos oder ein Kabel das zeitliche Segnen ohne einen Ausfall. Von dem Stack gehts dann nochmal auf 2 Switche an welche Server angesteckt sind.

(Professionelles Bild..., wollte es nur kurz veranschaulichen.)

Ich frage mich nun ob und wie das möglich ist. Regelt der Switch das von alleine oder muss ich hier etwas konfigurieren?

Normalerweise wenn ich von einem Switch 2 Verbindungen an einen anderen Stecke wird eine Verbindung aufgrund von STP deaktiviert.
Jetzt ist STP aber ja Layer 2 und mein Switchstack ist zwar ein logischer Stack, aber die einzelnen Komponenten haben ja dennoch verschiedene MAC-Adressen. Dann würde nach meinem Verständnis STP nicht eingreifen. Ich hab Angst dass das dann zu Netzwerkschleifen führt.

Weitere Frage: Macht das so überhaupt Sinn? Die Serverswitche an den Stack anzuschließen? Oder sollten die lieber auch noch an die Sophos angeschlossen werden?
An den Switchstack werden die ganzen Clientpcs angesteckt. Dann müssten die Clientpcs mit den Servern über die Sophos kommunizieren, keine Ahnung ob das so gedacht ist. Ich bin leider kein Netzwerker aber muss mich jetzt darum kümmern... pls be gentle.

Nach meinem Verständnis würde man eher nochmal 2 Switche hinter die Sophos packen, als "Verteiler" und and diese beiden dann die Serverswitche und den Clientswitchstack anschließen? Aus kostengründen will ich allerdings so wenig Komponenten wie möglich nutzen.

Ich wäre sehr dankbar für euren Input.
Danke im Voraus.

Viele Grüße,
Samuel

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 2182298144

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

Ausgedruckt am: 22.11.2024 um 04:11 Uhr

38 Kommentare

Neuester Kommentar

Hi Samuelit,

dein Keyword ist LAG. Wir haben bei uns die M4300 auch im Stack konfiguriert. Dort erstellst du eine LAG Gruppe und wählst als Ports jeweils einen von jedem Stackmember aus. Also bspw. Für LAG 1 Port 1/1 und Port 2/1.
Wichtig ist, dass du den LAG mit LACP nach 802.1AX-2008 (802.3ad) konfigurierst.

In der Sophos machst du das selbe. LAG Interface mit LACP und das wars. Mit Sophos habe ich allerdings keine Erfahrung was die Konfig angeht.

Wie weit du diese Redundanz ziehen willst musst du sehen. In diesem Szenario hättest du nur die Sophos abgesichert.

Stecken deine Clients mit jeweils nur einem Port an einem Switch der ausfällt, hast du natürlich wieder ein Problem.

Server bindest du am Stack auch via LAG mit LACP an.
Für Clients mit nur einem Ethernetport wäre dann ein Distribution Switch zuständig, den du ebenfalls mit zwei Beinen ans Stack hängst, der dann aber dein Single Point of Failure in dem Konzept ist.

Das ist aber unvermeidbar außer du hängst jeden Client per LAG ans Stack. Bei mir liegt immer ein identisch konfigurierter Distribution Switch im Regal den ich im Zweifel einfach austausche.

lg
Theo

Moin,
Ich kann @theoberlin nur beipflichten wenn du dich daran hältst läuft alles. Ich würde zusätzlich aber noch MSTP konfigurieren. Laufen die Sophos selbst auch im Cluster? So das du hier eine virtuelle IP, zwecks Routing? den sonst fällt dir das Routing innerhalb des Netzes auf die Nase

Grüße

Hallo @theoberlin,

danke für deine ausführliche Antwort.

Vom Switchstack gehts dann direkt aufs Patchpanel, die Clientpcs werden nicht redundant abgesichert, aber mir wäre eben nur wichtig dass nicht der ganze Stack und somit alle Clients kein Netz mehr haben sobald der Master down geht. Das würde mit dem LAG ja dann funktionieren.

Meine Server stehen in einem 2. Rack und werden deswegen nicht quer durch den Raum am Switchstack angeschlossen sondern haben diese wie auf dem Bild oben gezeigt 2 extra Switche an denen sie angesteckt sind.

Soll ich diese beiden "Serverswitche" jetzt mit LAG an den Switchstack anbinden oder auch direkt an die Sophos?
Wie wäre denn da die beste Lösung? Muss ich an der Sophos noch irgendwas konfigurieren damit die Server und die Clients dann kommunizieren können oder funktioniert das dann auch wie eine Art switch..? Oder wäre die Anbindung am Switchstack sinnvoller?

@niklasschaefer die Config der Sophos kenne ich ehrlich gesagt nicht genau. Die eine ist quasi nur dazu da um zu übernehmen sobald die andere ausfällt. Bei der 2. steht HA-Slave.

Was meinst du mit Clients per LAG anstecken? Wenn die Clients nur einen Netzwerkport haben kann man die doch gar nicht redundant anstecken?

Vielen Dank.

Grüße,
Samuel

Es wäre doch viel sinnvoller den FWs über LACP LAGs an den Stack anzubinden. Damit ist man Spanning Tree frei, nutzt sinnvoll die doppelte Kapazität der Links UND hat obendrein eine Linkredundanz und eine Switch Redundanz wenn man die LACP Links auf unterschiedliche Stack Member verteilt.
In der Regel ist das so auch Best Practise wie man sowas umsetzt ! Aber du bist ja noch in der Lernphase...

Weitere Infos dazu auch im LACP LAG Tutorial

Dein Stack ist sehr wahrscheinlich der Core eine klassischen Allerwelts Standard Netzwerk Designs wie diesem, oder ?
Daran kannst du schon ein banales, redundantes Grunddesign erkennen was dann auch mit deinen Sophos Teilen in einem HA Setup (Active/Active) erreicht wird.

Hallo Samuel,

wenn du die Clients auf beide Stack Switche verteilst und es kein Drama ist wenn die Hälfte ausfällt, kannst du das so lösen. Ordentlicher wäre ein Distribution/Access Switch für die Clients der via LAG am Stack hängt.

Ob du die Server Switche mit an das Stack oder direkt an die Sophos anschließt, hängt von deinem Netzwerk Design ab.

Ich würde immer ein Stack für das Clientseitige LAN und eins für das Serverseitige einrichten. Alleine deswegen schon um Clients / Server in separaten VLANS sitzen zu haben.

Klar geht das auch mit einem Stack, macht das VLAN durchreichen aber komplizierter.

Am Ende hängt das von der Sophos ab wie viele Ports ihr habt. Du brauchst zwei pro Stack an jeder Sophos. Habt ihr 4 frei würde ich ein LAG bzw. Stack für die Clients und eins für die Server machen und das ganze mit VLANS segmentieren.

lg
Theo

Hallo ihr beiden,

@aqui das klingt sehr gut. Danke für diese Darstellung. Also so klassisch wie auf dem Bild sieht es bei uns nicht aus. Der Switchstack ist eigentlich nicht der Coreswitch sondern der Clientswitch bzw Access Switch.

Um den Post von @theoberlin noch aufzugreifen. An der Sophos haben wir nicht mehr genügend Ports wie ich gerade bemerkt habe... Ich kann also nur entweder die Serverswitche oder den Stack direkt an die Sophos anschließen.

Wenn ich das ähnlich wie oben in dem 2. Bild von aqui machen würde würde ich die Serverswitche als Coreswitch benutzen und den Stack dann klassisch als Access Switch. Theoretisch könnte ich die Serverswitche auch als Stack configurieren, das sind auch M4300er.
Würde dann so aussehen:

Was meint ihr?

Ist dann nur die Frage wie ich das mit den Vlans mache, eigentlich soll der AccessSwitch dann in ein anderes Vlan als der Core/Serverswitch... die müssen dann da iwie durchgereicht werden?

Danke und VG,
Samuel

Also ich denke das Setup macht für deine Umgebung Sinn.

Bezüglich der Vlans gibt es hier ein schönes Tutorial vom Kollegen @aqui:

VLAN Tutorial

Da solltest du dich dann einarbeiten. Dein Stichwort für das Vlan durchreichen sind Trunk Ports und am Ende Access ports und PVID.

lg
Theo

Also so klassisch wie auf dem Bild sieht es bei uns nicht aus.

Letztlich schon ! Nur das du eben statt einzelner Access Switches dort einen Stack verwendest. Das Grundprinzip dieses einfachen Netzwerk Designs ist auber völlig identisch wie du ja sicher auch selber siehst anahnd der Skizze ?!

die müssen dann da iwie durchgereicht werden?

Ähh ja...! Simpelstes Grundprinzip von VLAN und Tagged Ports. Da hast du vermutlich noch erhebliche Defizite !
Wie Kollege @theoberlin oben schon richtig sagt solltest du dir besser erstmal die simpelsten VLAN Grundlagen beibringen oder jemanden fragen oder an die Hand nehmen der weiss was er da tut.
Hilfreich für dich zum Lesen vielleicht noch die VLAN Schnellschulung und die Designgrundlage für ein Layer 3 VLAN Konzept. Was je exakt deinem Netzwerk Design entspricht mit einem routenden Layer 3 Core und dem Access Switch !
Dort dann besonders das Kapitel "Erweiterung mit weiteren Layer 2 VLAN Switches" was genau deinem Netz entspricht.
Lesen und verstehen...!

Hallo zusammen,

also ich würde mir erst einmal einen Gesamtüberblick verschaffen wollen. Also den IST Zustand
feststellen. Und zweitens wie man das Netzwerk ändert oder überhaupt aufbaut. Und vor allem
was ist an Geld vorhanden um eventuell die zwei anderen "Switche noch dazwischen zu packen"
die Du erwähnt hast. Wie viele Leute arbeiten denn dort und was für ein Bedarf ist denn dort
überhaupt vorhanden? CAD Workstations oder Büro PCs?

Netgear M4300
Schau dort (PDF) bitte einmal rein und sag uns doch erst einmal was für einen Stapel (Stack)
Du dort zusammengebaut hast.

Was für Protokolle sind denn bei den beiden Sophos im Einsatz? VRRP oder etwas anderes?
Die M4300 / M4500 Switche sind Layer3 Switche und können auch VRRP! Aber eben auch
OSPF und anderen Routingprotokolle.

MfG BlueKobold

Ich habe letztes Jahr auch das Netzwerk neu gestaltet mit vier M4300 Switchen als Core. Diese sind im Stack über zwei Gebäude verteilt. Je zwei in einem Serverraum via Glasfaser SFP+ 10G verbunden. Der Stack ist zweifach redundant, bedeutet also, dass je Serverraum gleichzeitig einer der M4300 ausfallen kann.

Die Serverbleche sind jeweils an je einen M4300 angeschlossen mit LACP LAG. Die Access Switche ebenso. Hier aus Kostengründen via RJ45 10G bzw 1G.

Wir haben selbst auch eine Sophos FW aber nur eine. Diese ist über LACP LAG an zwei M4300 angeschlossen. Bei zwei FWs ist es ratsam diese in einem Fail-Over-Cluster zu betreiben, es sei denn die Infrastruktur (ISP, Web-Access etc.) erlaubt es nicht.

Was du vermutlich mit Switch "hinter die Sophos FWs" meinst, ist dass man hier den ISP-Traffic mit einem Switch auf die beiden FWs verteilt wil die eine FW eine public IP und die andere eine weitere public IP nutzt? Im Prinzip möglich und könnte so die Redundanz erhöhen. Ist aber recht komplex, da man dann eine SD-WAN Policy nutzen muss.

Guten Tag zusammen,

danke für die zahlreichen Antworten.
Ich muss mich auf jeden Fall noch genauer mit den Technologien auseinandersetzen, ich hatte bisher nichts mit Netzwerken zu tun und wir haben in unserer Firma leider eine recht kleine IT in der sich auch niemand damit auskennt.
Dementsprechend sieht unser Netzwerk leider auch aus. Da sich niemand im Serverraum auskennt und die Hardware extrem veraltet ist muss ich das jetzt angehen das langsam auszutauschen und zu optimieren.

IST-Zustand:
- ca 150 Leute am Standort
- VPN Verbindung zu 3 anderen Standorten
- Sowohl Büro-Pcs als auch CAD-Workstations im Einsatz
- ca 13 Server am Standort (darauf laufen ca 63 VMs)
- Die Server sind per iSCSI mit dem Speicher verbunden, über separate Switche, allerdings hängen die auch mit im normalen Netz ohne Abgrenzung durch VLANS
- Clients und Server sind auch im gleichen VLAN
- Sophos sind HA aber active/passive
- Es gibt nur eine Verbindung von der Sophos zum Coreswitch welcher bei uns der Access Switch ist..
- Vom Router gehts zu einem Switch (SPOF) und dann auf beide Sophos

So ist der Momentane Aufbau:

Und irgendwie so sollte das dann ausschauen...:

Also wir haben schon 7 M4300er Switche gekauft welche noch nicht eingebaut sind.
2 würde ich als CoreSwtichStack nehmen und den Rest als AccessSwitchStack.
Die Stacks die ich bisher mal getestet habe sind über die 10G Ports als Stackport konfiguriert und im Ring angeschlossen.
Zwischen den beiden Stacks dann ein LAG ebenfalls über die 10G Ports.

Was für Protokolle wir bei der Sophos benutzen weiß ich ehrlich gesagt nicht... OSPF scheint da deaktiviert. Zu VRRP find ich da gar nichts. Wir haben dort nur statische Routen festgelegt. Ausm Lan ins Internet / zu den anderen Standorten.

Also das muss jetzt auch nicht direkt das perfekte Netz werden.
Grundsätzlich wäre es mir am wichtigsten jetzt erstmal alle SPOFs zu eliminieren und LAGs zu konfigurieren.
Und eben die alten Switche zu ersetzen die sehr wacklig mit teilweise defekten Lüftern unterwegs sind.
Dinge wie Vlans kann man ja ggf auch in einem 2. Schritt später einrichten.

Danke und VG,
Samuel

Hi Samuel,

bitte nicht falsch verstehen...aber der Umbau eines Netzwerks mit DIESEM Umfang gestaltet sich in meinen Augen als schwierig bei dem Kenntnissstand.

Wenn ihr für einen solchen Umfang nur eine kleine IT habt, die sich damit auch nicht richtig auskennt, sitzt ihr quasi auf einer Zeitbombe.

Auch Zahlen wie 63 VMs auf 13 Servern...klingt abenteuerlich.

150 Clients und Server ohne VLAN Trennung...das ihr unter dem Broadcast Traffic nicht zusammenbrecht ist schon ein Wunder. Zumal CAD ordentlich Traffic erzeugen kann.
Ich würde wetten, die Server sind auch auf einem abenteuerlichen Patchlevel etc.

Ich würde dir raten:
Wendet euch an ein Systemhaus. Erarbeite mit denen ein Konzept und sei deren Ansprechpartner in der Firma. So kannst du dich selbst weiterbilden und einarbeiten und deine Position in der Firma festigen bzw. das ganze mal übernehmen, das Risiko aber minimieren.

Wenn ich das lese was du da vor dir liegen hast, kann das im alleingang eigentlich nur schief gehen.

lg
Theo

OSPF ist ein Routingprotokoll und eigentlich irrelevant, da hier das Routing eher auf dem Core-Stack statt findet für das interne Netzwerk. Das Core sollte aber eine Default-Route 0.0.0.0/0.0.0.0 zum einen der Sophos FW haben. VRRP macht in deinem Design auch wenig Sinn, da die M4300 im Stack arbeiten und somit bei Ausfall jeweils ein anderer die Master-Rolle übernimmt.

Warum du für Access aber weitere M4300 im Stack benutzt, ist mir etwas rätselhaft. Muss das ein Stack sein oder was ist der Gedanke dahinter? Ob nun im Stack oder Stand Alone einer der Switche ausfällt, sind alle angeschlossenen Clients so oder so offline. Da wäre es günstiger und einfacher "normale" 48-Port L2(+) Switche zu nehmen.

Wenn ihr für einen solchen Umfang nur eine kleine IT habt, die sich damit auch nicht richtig auskennt, sitzt ihr quasi auf einer Zeitbombe.

Auch Zahlen wie 63 VMs auf 13 Servern...klingt abenteuerlich.

150 Clients und Server ohne VLAN Trennung...das ihr unter dem Broadcast Traffic nicht zusammenbrecht ist schon ein Wunder. Zumal CAD ordentlich Traffic erzeugen kann.
Ich würde wetten, die Server sind auch auf einem abenteuerlichen Patchlevel etc.

Das kann passieren. Bestes Beispiel ist meine Firma. Ca. 300 Mitarbeiter, davon in einem Standort ca. 200 aufgeteilt auf drei Gebäude. 5 HW Server mit 33 VMs. Ich bin seit letztem Jahr der verantwortliche Admin, der innerhalb von knapp 5 Monaten das Netzwerk von kein VLAN, nur "billige" L2-Switche, Fritzbox als FW/Router, kein Backup, PPTP VPN, USVs halten nur 5 Minuten, kein Monitoring, keine Inventarisierung der Systeme, kritische Systeme nicht redundant und zum Teil 2 Jahre nicht gepatched, kein zentrales AV-System umgestellt hat auf ein vernünftiges Mass und Standards. Das Ganze mit zwei Azubis und einem weiteren Kollegen, der aber noch nicht so fit ist.

Ich bin kein Systemhaus und vieles musste ich mir erst im Internet zusammen suchen und testen. Trotzdem ist richtig, dass man gewisse IT-Grundlagen kennen sollte. Ich bin in dieser Tätigkeit nun seit 14 Jahren unterwegs und in verschiedenen Unternehmen gewesen, so dass hier genug Praxis und Wissen angesammelt wurde.

Mit jeder neuen Aufgabe wächst auch das Wissen. Nächstes Projekt ist die Migration von Hyper-V zu VMware über Veeam als Zwischenziel.

Hi Maddin,

Oh ich weiß, dass es diese Konstellationen gibt. Und es ist auch alles mach- und Umsetzbar. Auch wenn man kein Systemhaus ist.

Dann sollten aber bei einem (erst recht komplett flachen und chaotischen) Netz verschiedene Wissensbereiche bereits abgedeckt sein.

Am Ende ist sowas ein riesen Aufwand. Und am Ende ist Samuel der dumme. Auch wenn der Chef gesagt hat „du machst das schon“. Diesen Stress muss und sollte man sich nicht geben. Da schläfst du Monate nicht gut und hast deine Reputation versaut bevor du sie hattest.

Man wächst absolut an seinen Herausforderungen und das ist auch gut so. Aber manchmal ist ein Rettungsnetz sinnvoll und ganz wichtig: Niemals falsch!

LG
Theo

Da Gebe ich dir Recht Theo. Wenn die zeit und das Wissen knapp sind, dann ist externe Hilfe von Vorteil. Habe ich auch nicht anders gemacht bei den neuen Servern + SAN. Klar hätte ich mich damit auch befassen können und wäre sicher nen Euro billiger gewesen aber ich hätte viel Zeit dafür geopfert, die an anderer Stelle gefehlt hätte. Und außerdem, wenn das Systemhaus was falsch macht, dann bin ich nicht der Dumme *haha*

Hi,

also eigentlich sind wir an diesem Standort nur zu zweit. Mein Chef hat aber auch keine IT gelernt und hat von Netzwerken ähnlich viel Ahnung wie ich.

Die anderen Standorte machen ihren kram selbst, aber da siehts bestimmt auch nicht besser aus.

Also von den 63 VMs laufen knapp 40 auf nem Cluster. Der sieht aber eigentlich noch ganz entspannt aus.

Der Rest jeweils ca 4 VMs auf anderen Servern.

Wir sind gerade dabei alle Server durch zu patchen aber ja, es ist eigentlich nichts in top Zustand und zu zweit eigentlich nicht zu schaffen. Vor allem wenn man nebenbei noch Support etc machen muss.

Zitat von @DerMaddin:
Warum du für Access aber weitere M4300 im Stack benutzt, ist mir etwas rätselhaft. Muss das ein Stack sein oder was ist der Gedanke dahinter? Ob nun im Stack oder Stand Alone einer der Switche ausfällt, sind alle angeschlossenen Clients so oder so offline. Da wäre es günstiger und einfacher "normale" 48-Port L2(+) Switche zu nehmen.

Diese Switche hat der Kollege der zuletzt gekündigt hatte bestellt... und ich sitz jetzt damit da^^
Und ja, da die jetzt eh Stackbar sind... wieso nicht.

Den Austausch der alten durch die neuen Switche und die LAGs würd ich vielleicht noch ganz gern selber machen.
Aber wenns dann an die VLANs und das Routing geht wäre externe Hilfe wahrscheinlich sehr sinnvoll.

Danke für eure Antworten.

VG, Samuel

Und irgendwie so sollte das dann ausschauen...:

Das sieht dann im Vergleich zum Iststand deutlich besser aus.
Der Iststand ist eher gruselig !
Singulärer Router hängt an einem singulären Switch dahinter aber dann 2 redundante Sophos.
Sinnvolle Redundanz sieht natürlich anders aus und der Soll Entwurf zeigt in die richtige Richtung und ist schon (fast) perfekt !

Das Core sollte aber eine Default-Route 0.0.0.0/0.0.0.0 zum einen der Sophos FW haben.

Nein, das wäre ja Unsinn wenn das auf eine physische IP zeigt. Damit torpediert man ja die Redundanz der 2 FWs.
Die FWs arbeiten ja in einem Active/Passive Design oder noch besser natürlich in einem Active/Active Design mit Balancing und gegenseitigem Backup. Die FWs sharen dann eine VIP (Virtual IP) mit VRRP, CARP oder was auch immer die da verwenden. Auf diese IP sollte die Default Route dann logischerweise zeigen.

Aber wenns dann an die VLANs und das Routing geht wäre externe Hilfe wahrscheinlich sehr sinnvoll.

Dafür gibts ja dann das Forum hier !

Zitat von @aqui:

Das Core sollte aber eine Default-Route 0.0.0.0/0.0.0.0 zum einen der Sophos FW haben.

Bis zum letzten Diagramm war nicht klar ob die FW redundant sein sollen. Bei Sophos ist es irgend Etwas eigenes, da ich selbst eine habe und da ist nichts von VRRP oder Ähnliches zu finden. Es ist scheinbar nur ein Cluster aus FW active/active oder active/passive. Egal welcher Modus, es ist für alle anderen Geräte dahinter und davor transparent. So gesehen ist es immer noch eine IP, wenn auch virtuell, die als Standardroute auf den FW Cluster vom Core gehen sollte.

da ich selbst eine habe und da ist nichts von VRRP oder Ähnliches zu finden.

Das mit dem VRRP wäre nur gut zu wissen gewesen, falls die Sophos Geräte das können
bzw. es dort in Betrieb ist und die Core Switche das auch beherrschen, das man das dann
bei beiden in Betrieb nimmt. Und nach "unten" dann eventuell OSPF, da alle M4300 Layer3
Switche sind. Sicherlich spielt auch die Anbindung der Server eine klare Rolle bei solchen
Überlegungen, gar keine Frage.

Hinsichtlich der Stapel (Stacks) man kann die einmal als Spin/Leaf Konzept aufbauen und
einmal als Stapel im Ring (Ring Stack) und diese werden dann an den Core angeschlossen.
Oder aber man hat einen "großen" Stapel, was eben bei kleineren oder aber mittleren
Unternehmen noch möglich ist.

MfG BlueKobold

Wenn sie ein Active/Active oder Active/Passive Design supporten muss es immer eine irgendwie geartete VIP (Virtual IP) zwischen den Geräten geben.
Bei Active/Passive wandert die dann mit mit dem gerade aktiven Gerät (Failover, bzw. Mac Adress Sharing) und bei Active/Active sorgt sie für ein Session Balancing bzw. auch Failover. Das ist seit Jahrzehnten Standard so. Meist wird dazu immer CARP oder VRRP bzw. VRRP-E verwendet sofern keine proprietären Verfahren Verwendung finden (HSRP etc.)
https://de.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol

Hi zusammen, ich hätte nochmal ein paar Fragen zu Vlans...

Ich habe mir jetzt mal zum Test 2 Switchstacks gebastelt. Beide über ein LAG bestehend aus 2 Leitungen Verbunden.
Dieses LAG als Trunk konfiguriert und lasse alle Vlans darüber getagged weiterleiten.
Ich habe 4 Vlans, 1, 10 (Server + Management), 20 (Clients), und 300 (Sophos). Die hab ich jetzt einfach mal random genommen, da steckt nicht viel Logik hinter. Funktioniert auch soweit wenn ich 2 Rechner pro Vlan anstecke können sie kommunizieren, wenn sie an unterschiedliche angesteckt sind nicht. Das passt also erstmal alles soweit. Routing ist noch keins aktiviert.

Die VLANs bekommen jetzt folgende IPs:

Komischerweise kann ich aus jedem Vlan die Management Website aufrufen...

Obwohl ich als Management Vlan das 10er ausgewählt habe.

Woran liegt das? Ich habe auch gelesen dass man das ggf mit der ACL unterbinden muss dass man von allen VLANs aufs Management kommt? Aber wozu gebe ich dann überhaupt das Management VLAN an?
Und könnt ihr mir sagen was das Standardgateway beim Management VLAN sein soll??? Ich verstehe grad nicht für was ich das brauche. Das VLAN 10 IST doch für alle im VLAN 10 das Gateway. Und vom VLAN 10 solls dann zur Sophos (VLAN 300) gehen. Bei den anderen VLANs zB 20 muss ich ja auch kein Gateway angeben...

Jetzt will ich eigentlich das 300er VLAN als Schnittestelle zwischen Sophos und Coreswitch.

Wie sag ich dem Teil jetzt dass das die Standardroute ist? Bei mir kommt dort ein Fehler wenn ich das so eingeben will... "Error. The route could not be configured."

Und ACLs wie in dieser Anleitung: https://kb.netgear.com/30818/How-to-configure-routing-VLANs-on-a-NETGEAR ...
Kann ich auch nicht erstellen.

Was will er da von mir?

Danke und Viele Grüße,
Samuel

Soweit ich mich nicht irre, ist VLAN1 immer und überall untagged, also jeder Port ist immer VLAN1, es sei denn du nutzt dieses VLAN gar nicht. Das Dilemma habe ich auch und versuche das VLAN1 immer stückchenweise "sterben" zu lassen.

Bedeutet im Umkehrschluss, dass du unter VLAN Member die 1 überall rausnimmst, wo diese nicht gebraucht wird.

ACL kann man machen, ist aber SEEEHR komplexes Thema und eigentlich zum Steuern von VLAN Traffic das falsche Mittel. Wer sich da nicht zu 100% auskennt, sperrt schnell den falschen Server, Client oder Router aus oder das Gegenteil, öffnet das "Scheunentor".

Ich mache das für zwei VLANs über die Sophos FW und entsprechende Policy. Hier speziell Wifi für Sicherheitskameras und Technik/Geräte in der Gebäudesteuerung. Da sollen keine internen Clients oder Server in den Traffic rein oder diese Geräte auf interne LAN Zugriff erhalten.

Das passt also erstmal alles soweit.

Und ist auch bis dahin alles absolut richtig gemacht !

Die VLANs bekommen jetzt folgende IPs:

Mit anderen Worten du aktivierst Layer 3 und damit Routing auf dem Switch. Auch korrekt so...außer vielleicht der Verwendung einer /16er Maske die bei einer Segmentierung eigentlich Unsinn ist. Jeder Admin weiß das L2 Broadcasts Domains nie größer sein sollten als 150 Endgeräte um die Broad- und Multicast Last gering zu halten. Das gilt so als goldener Daumenwert bei Designs plus minus natürlich. Mit 2048 möglichen Endgeräten wäre das also Unsinn wenn man segmentiert.
Aber das rechnen wir jetzt mal deiner Unerfahrenheit mit Netzwerken insgesamt zu.
Ausnahme ist das du ein altes, historisch gewachsenes flaches Dummnetz dieser Größe migrieren musst. Dann würde sowas Sinn machen für die Migrationsphase so ein Segment anzuhängen.

Komischerweise kann ich aus jedem Vlan die Management Website aufrufen...

Wieso ist das für dich komisch ??
Das sollte es normal nicht sein aber hier schlägt vermutlich wieder deine Unerfahrenheit mit Netzwerken an sich zu ?

Ein Layer 3 Switch agiert immer als Router und NICHT als Firewall ! Ihm liegt also immer eine Whitelist Logik zugrunde wie es generell für IP Router üblich ist. Sprich alles ist erlaubt was nicht explizit verboten ist.
Damit ist dann also routingtechnisch in deinem Setup alles erlaubt und da du eine IP Adresse in allen VLAN Segmenten hast antwortet dann natürlich das Switch GUI erwartungsgemäß auf allen diesen IPs wenn du sie als Ziel ansprichst.
Ein erwartbares und logisches Verhalten des Switches also !

Bessere Switches bieten die Möglichkeit das Management GUI fest an ein VLAN zu nageln. Ob deine Netgear Gurken das im Featureset supporten musst du im Handbuch nachlesen.
Ansonsten ist die einfache Lösung, wie oben schon gesagt, mit einfachen ACLs am Management VLAN zu arbeiten was das "Problem" dann elegant löst.
Was oben behauptet wird das ACLs komplex sind ist natürlich völliger Unsinn und abgesehen davon ist komplex ja immer relativ.
Das ist eine sehr einfache Option den Zugriff auf bestimmte VLANs, wenn erforderlich, effizient zu steuern und auch best Practise in einem Layer 3 Switchdesign.
Lass dir da also als Newbie keine Angst einreden das ist vollkommen unbegründet.

Was will er da von mir?

Normale Standard IP Rules sind simple IP Listen die rein nur auf Source IPs filtern, geht oder geht nicht. Extended Rules können Protokoll Typ, Source und Destination IP und TCP oder UDP Ports, TCP States und mehr filtern. Einfache Logik...

Vielen dank für deine ausführliche Antwort.

Zitat von @aqui:
Verwendung einer /16er Maske die bei einer Segmentierung eigentlich Unsinn ist. Jeder Admin weiß das L2

Also das Vlan1 will ich gar nicht nutzen. Das "gammelt" da nur so rum. Das 10er und 20er VLAN haben ja jeweils /24 also 254 mögliche Hosts.

die Möglichkeit das Management GUI fest an ein VLAN zu nageln

Ich dachte das wäre der Sinn der Option "Management VLAN". Wozu wähle ich denn sonst dort ein bestimmtes VLAN aus? Scheint aber nix zu bringen..

Ja ich wollte eine Regel mit Source und Destination IP setzen allerdings bekomme ich unter IP Extended Rules nur diese Meldung dass ich keine ACL habe aber kann auch nirgendswo eine Anlegen. :/

Und wie bekomme ich die Route zur Sophos also das 300er VLAN als Defaultroute? Die Regel lässt er mich irgendwie nicht anlegen.

Danke und schönes Wochenende,
Samuel

Also das Vlan1 will ich gar nicht nutzen. Das "gammelt" da nur so rum.

Und trotzdem gilt die o.a. Daumenregel !

Wenn du es nicht nutzt warum definierst du denn überhhaupt eine IP dafür ?? Wäre ja dann völlig sinnfrei und überflüssig.

Ich dachte das wäre der Sinn der Option "Management VLAN".

Dies gilt so nur für den reinen Layer 2 Betrieb !
Das bedeutet das ARPs dann rein nur aus dem definierten Management IP VLAN Netz auf das interne Management IP Interface geforwardet werden aber nicht aus den anderen VLANs.
Ohne Definition eines Management VLANs hängt das interne Management IP Interface grundsätzlich in ALLEN VLANs aus L2 Sicht.
Sprich du könnest du auch immer aus ALLEN anderen VLANs mit entsprechender IP im Netz des Management Netzes das Management Interface erreichen. Ein Sicherheitsloch !!
Die dedizierte Zuweisung einer Management VLAN ID unterbindet das !
Für Layer 3 Designs gilt das dann generell nicht. Jede IP im L3 Mode gibt dir dann Zugriff auf das Management GUI.
Meister Yoda würde sagen: "Noch viel lernen du noch must...!" 😉

aber kann auch nirgendswo eine Anlegen.

Was natürlich naiver Unsinn ist und du auch selber weisst. Sieh ins Menü Security > ACL > IP ACL !
Also, das Switchmanual in die Hand nehmen und im Kapitel Netzwerk Security unter Accesslisten nachsehen und lesen und verstehen !! Als KlickiBunti GUI Knecht dann im:
GUI Handbuch, Seite 173
Bzw. als angehender, richtiger Netzwerker machst du es natürlich immer über das CLI !! Du weisst ja: "Real networkers do CLI !"
CLI Handbuch, Seite 965 Ebenso lesen und verstehen.
Nun bist du wieder dran und keine Ausreden mehr...!

Hallo zusammen,

tja da @aqui ja schon fast alles dazu gesagt hat bleiben nur noch ein paar Punkte zu erwähnen
die den Einstieg oder Umstieg von anderen Herstellern etwas einfacher machen und das wären;
- Bei Netgear ist das VLAN1 das default VLAN und dort sind alle Ports Mitglied
- Man legt ein VLAN an und dann weist man dem VLAN Ports zu
- Man legt ein LAG an und weist dann dem LAG Ports zu
- Man legt ein LAG an und weist Ihm die Ports des VLANs zu und nicht das VLAN

Geh man methodisch vor und fang an auf zwei Seiten Papier aufzuschreiben was der IST Zustand
und was der SOLL Zustand sind bzw. sein sollen.

- Welche Switche hat man und für was will man sie benutzen
- Welche Geräte hat man und an welche Switche sollen die ran
- Welche Topologie wählt man aus und warum macht man das
- Welche Stapel wählt man aus und aus welchen Grund (Nutzen)

- Welche Geräte sind vorhanden und in welche VLANs sollen die rein
- Welche VLANs sollen untereinander Kontakt haben und welche nicht

- Was habe ich als Admin für Möglichkeiten und wie kann ich Sie steigern oder erweitern
- Konfiguration via CLI, Weboberfläche oder gar NMS 300 (Kostenlos bis 200 Switche / Geräte)

1.
- Management VLAN IPv4 anlegen
- Management Interface IPv4 anlegen
- Management VLAN IPv6 anlegen
- Management Interface IPv6 anlegen

2
Abspeichern, immer wieder abspeichern, neu konfigurieren und wieder abspeichern!
Hast Du mal einen Fehler drin, kannst Du bis zu dem letzten "guten" Zustand alles
wieder herstellen und musst nicht wieder ganz von vorne anfangen!!! Hat man 10
Swiche und was nun? Für jeden einen USB Stick? Nimm bei mehreren Switchen
bitte den NMS300 auf einen Server und es wird einfacher und übersichtlicher für Dich.

Worüber verwalten und/oder administrieren? Console Ports sind üppig vorhanden
an Netgear Switchen es gibt Serien mit bis zu drei oder 4 Console Ports! Micro USB,
USB A, Seriell und RJ45, denke und baue Dir ein Konzept auf was leicht erweiterbar ist!

Ein kleiner Server nur für Dich (Admin) dort kommt dann die NMS300 drauf
Für die wichtigsten Sachen der gleiche oder ein zweiter mit PRTG
Zentrale Verwaltung über einen KVM Switch.

Mit der NMS300 kann man sich ganze Stacks aufrufen, für einen oder alle Switche
ein Firmwareupdate machen und bei Nichtgefallen wieder rückgängig machen oder
aber das Konfig Backup einspielen.

Das Dilemma habe ich auch und versuche das VLAN1 immer stückchenweise "sterben" zu lassen.

Alle Ports sind im Auslieferungszustand im VLAN1 vorhanden und wenn man Sie einem
anderen VLAN zuweist sollen Sie sogar nach Netgears Anweisung dort heraus genommen werden.

Sophos Border / Internet
DMZ 1 - Layer2 Switch und Web und FTP Server
DMZ 2 - Layer2 Switch und NAS für Mitarbeiter und Kunden per VPN

VLAN 5 - Transfernetz zu Sophos hier routet die Sophos
VLAN 6 - Management VLAN
VLAN 10 - Server
VLAN 20 - SAN / NAS
VLAN 30 - PCs
VLAN 40 - WSs
VLAN 50 - Printer
VLAN 60 - VOIP Telefone
VLAN 70 - Dongle Server (USB/LAN)
VLAN 80 - WLAN (Arbeitsgeräte) Zertifikat Radius Server
VLAN 90 - WLAN (Firmenpartner) Zertifikat Radius Server
VLAN 100 - WLAN (Gäste / Besucher) Voucher HotSpot
VLAN 110 - WLAN (Mitarbeiter privat (Kantine)) Voucher HotSpot

VLAN 6 - 192.168.0.0/24 - Gateway 192.168.0.1 - DHCP 192.168.0.254
VLAN 10 - 192.168.1.0/24 - Gateway 192.168.1.1 - DHCP 192.168.0.254
VLAN 20 - 192.168.2.0/24 - Gateway 192.168.2.1 - DHCP 192.168.0.254
VLAN 30 - 192.168.3.0/24 - Gateway 192.168.3.1 - DHCP 192.168.0.254
VLAN 40 - 192.168.4.0/24 - Gateway 192.168.4.1 - DHCP 192.168.0.254
VLAN 50 - 192.168.5.0/24 - Gateway 192.168.5.1 - DHCP 192.168.0.254
VLAN 60 - 192.168.6.0/24 - Gateway 192.168.6.1 - DHCP 192.168.0.254
VLAN 70 - 192.168.7.0/24 - Gateway 192.168.7.1 - DHCP 192.168.0.254
VLAN 80 - 172.xxx.0.0/24 - Gateway 172.xxx.0.1 - DHCP 192.168.0.254
VLAN 90 - 172.xxx.1.0/24 - Gateway 172.xxx.1.1 - DHCP 192.168.0.254
VLAN 100 - 172.xxx.2.0/24 - Gateway 172.xxx.2.1 - DHCP 192.168.0.254
VLAN 110 - 172.xxx.3.0/24 - Gateway 172.xxx.3.1 - DHCP 192.168.0.254

Bei Netgear ist das VLAN1 das default VLAN und dort sind alle Ports Mitglied

Das ist bei jedem Switch auf der Welt so !

Mit deinen LAGs hast du dich oben aber verhaspelt bzw. es doppelt gemoppelt beschrieben.
Korrekt ist:

Man legt ein LACP LAG an und weist dann dem LAG seine Memberports zu
Dem (virtuellen) LAG Port weisst man dann die VLAN IDs zu und ob tagged oder untagged

(Bullet Point Listen erzeugt man übrigens mit einem "*" davor (Siehe hier).

Mit der Verwendung eines zentralen DHCP Servers, wie in deiner recht ausführlichen ToDo Beschreibung oben richtig beschrieben, hättest du der Vollständigkeit halber noch erwähnen müssen das damit dann ein DHCP Relay (ip helper Adressen) zwingend erforderlich ist.

Hi zusammen,

es ist jetzt schon ein wenig länger her. Danke für eure Antworten.
Ich habe mittlerweile in meinem Netzwerk die Sophos redundant per LAG and den neuen Switchstack angebunden. Und diesen wiederum per LAG and den Accessstack.
Jetzt überlege ich im nächsten Schritt VLANs einzuführen. Erstmal nur Server und Clients in unterschiedliche VLANs.
Die IPs der Server würde ich gerne lassen wie sie sind (172er Netz) und den Clients dann per DHCP einfach ein anderes Netzwerk geben. Natürlich muss ich dann noch ein DHCP Relay auf dem Coreswitch konfigurieren. Das wollte ich erstmal in einer Testumgebung testen.
Die würde wie folgt aussehen (bis auf die Sophos):

Wie man auf dem Bild sieht sollen die Clients in VLAN 20. Der Access Switch jedoch soll weiterhin über die 172er IP angesprochen werden. Allerdings kommt bei mir immer ein Error wenn ich Versuche das Management VLAN auf VLAN 10 zu stellen (VLAN 10 wäre das Server + Management VLAN). Über den Trunk würde ja das VLAN 10 auch tagged übertragen werden, somit könnte ich auf die Management IP des Switches zugreifen. Geht nur leider nicht wenn er nur aus VLAN 1 erreichbar ist. Ich habe alle Ports auf dem AccessSwitch auf VLAN 20 und auch Portvid auf 20. Außer einen auf VLAN 1 damit ich noch drauf komme...
Kann mir jemand sagen wie ich das Management VLAN ändere bzw wodurch hier der Fehler entsteht?

Dankeschön.

Viele Grüße,
Samuel

Die IPs der Server würde ich gerne lassen wie sie sind (172er Netz) und den Clients dann per DHCP einfach ein anderes Netzwerk geben.

Das ist auch der richtige Weg!
Zusätzlich solltest du darüber nachdenken ein Management VLAN einzurichten und dort das gesamte Management hineinzulegen (Switches, iLO, Router usw.) und das somit sicher von den Produktiv VLANs zu trennen. Gut, kann auch das Server VLAN sein, hängt imemr davon ab wie groß dein netz ist und welche Sicherheits Policy du umsetzt.
Auch wenn du VoIP Anwendungen betreibst gehören die in Firmen schon aus rechtlichen Gründen in ein separates VLAN. Ebenso wie ein ggf. vorhandenes WLAN und ganz besonders ein Gast WLAN. Es gibt also viele Gründe sinnvoll zu segmentieren!

Allerdings kommt bei mir immer ein Error wenn ich Versuche das Management VLAN auf VLAN 10 zu stellen

Was denn genau für einen "Error"?
Bei einem Cisco Switch z.B. ist das im Handumdrehen mit einem simplen Mausklick im GUI erledigt:

Über den Trunk würde ja das VLAN 10 auch tagged übertragen werden, somit könnte ich auf die Management IP des Switches zugreifen

Das ist richtig. Entscheidend ist immer WO du routest, denn nur dort ist eine Kommunikation der VLANs untereinander möglich!

Geht nur leider nicht wenn er nur aus VLAN 1 erreichbar ist.

Das ist so nicht richtig. Weisst du auch selber...
Du kannst das VLAN 1 ja auch auf den VLAN Router legen und kannst dann zwischen diesen VLANs routen und es so wieder erreichbar machen.
Das ist nur wenig zielführend wenn man das Management in einem gemeinsamen, getrennten VLAN Segment betreiben will wie es ja auch best Practise ist. Es ist ziemlich sinnfrei dann doch wieder das Management wild verteilt in unterschiedlichen VLANs zu haben. Führt ein VLAN Konzept dann wieder ad absurdum.

Kann mir jemand sagen wie ich das Management VLAN ändere bzw wodurch hier der Fehler entsteht?

Ohne das du genauere Angaben zur Art und Weise des Fehlers und zur Hardware machst ist das kristallkugeln pur wie du dir denken kannst. Damit ist dir sicher wenig geholfen...

Hi, vielen Dank für die Antwort.

Da kam ein unspezifischer "Error". Aber jetzt gehts. Es lag daran dass ich das VLAN 10 dann auch mit der gleichen IP angeben wollte.
Aber das VLAN 1 wird dann nicht gelöscht sondern existiert weiter. Und 2 mal das gleiche Netz mag er nicht.
Also anderes Netz angegeben und dann VLAN 1 gelöscht.

Jetzt habe ich alles (bis auf DHCP) wie oben auf dem Bild eingerichtet.
Der Client 1 kann jetzt auch das Interface vom VLAN 10 vom Coreswitch anpingen obwohl er selber ja im VLAN 20 ist. So soll es auch sein. Aber er kann nicht den AccessSwitch anpingen... Auch den DHCP-Server kann der Client nicht anpingen. Obwohl er ja das Interface vom VLAN 10 erreicht... wieso wird er dann nicht weitergeleitet an den DHCP?
Der DHCP kann sowohl den Core als auch den Access Switch anpingen und kommt auch auf die Weboberfläche. Den Client erreicht er auch nicht.

EIDT:
Ich habe jetzt mal beide an den Core angesteckt. DHCP-Server im VLAN 10 und Client1 in VLAN 20 am gleichen Switch. Aber auch hier routet er nicht. Also am Trunk oder irgendwas liegt es nicht.
Der DHCP kann nichtmal das Interface vom VLAN 20 also die 192.168.40.100 anpingen. Es kommt immer "Fehler bei der Übertragung. Allgemeiner Fehler."

EDIT2:
FML... Ich hatte beim DHCP kein GW eingetragen. Aber ich hätte nicht gedacht dass der Client1 den DHCP nicht anpingen kann nur weil der kein GW eingetragen hat bei sich? Oder ist der Client1 vielleicht zu ihm hingekommen aber hat nie eine Antwort bekommen weil der DHCP nicht wusste wo er hin schicken soll? Aber würde der dann nicht auch ohne Standardroute einfach mal losschicken und der Switch wüsste dann wo das Paket hinsoll...? Hmmm

Dankeschön.
MfG,
Samuel

Aber ich hätte nicht gedacht dass der Client1 den DHCP nicht anpingen kann nur weil der kein GW eingetragen hat bei sich?

Oha...viel lernen du noch musst würde da Meister Yoda sagen...

Stelle dir vor du wärst der Server. Du hast als Server die IP 192.168.10.10 und der Client1 in VLAN 20 pingt dich mit einer VLAN 20 IP von 192.168.20.20.
Du als Server hast kein Gateway definiert, kennst also rein nur das 192.168.10.er Netz und nichts anderes.
Nun kommt an deiner Netzwerkkarte ein ICMP Echo Request Paket (Ping) des Clients1 an mit der Absender IP 192.168.20.20. Darauf bis du als Server verpflichet mit einem ICMP Echo Reply zu antworten.
Du stellst fest: "Mist der Absender liegt nicht in meinem Netzwerk!" und sagst dir: "Null Problemo, ich sehe mal eben in meine lokale Routing Tabelle um zu sehen wo ich es hinschicken muss, denn wozu gibt es schliesslich Gateways und Routen?!"
Dann die böse Überrachung! Was steht in der Tabelle??? Genau... nichts! Kein Gateway, keine Route!
Du als Server hast jetzt keine Chance und musst also das Paket von Client1 verwerfen weil du keine Route zum Ziel IP Netz hast und bleibst so dem Absender eine Ping Antwort schuldig!
Ist so als wenn du nach Klein Kleckersdorf fahren musst ohne Ahnung wo das ist, ohne Navi oder Karte.

Sorry aber solche, nun wirklich banalsten IP Grundlagen, lernt der Azubi im ersten Lehrjahr. Und wenn nicht, dann sieht er im hiesigen IP Routing Grundlagen Tutorial nach und dort ganz besonders ins Kapitel "Der Weg eines LAN Paketes durch ein geroutetes Netzwerk"!!
Wenn du ein Video bevorzugst findest du auch HIER ein Filmchen was das sofort klar macht. (Genau bei 5:00)
Eher ein peinliches Geständnis für einen Profi Netz Administrator wie dich aber wenigstens bist du ehrlich und hast dir die Frage ja auch schon richtig selbst beantwortet.

Wie sollte eine Kommunikation in einem segmentierten IP Netz auch sonst funktionieren ohne dynamische Routen wenn nicht statisch mit Gateways und statischen Routing?!

Danke für deine Erklärung. Ist logisch.
Normal trag ich ja das GW auch ein, habe ich nur vergessen. Aber gut wenns einem mal passiert, dann muss man sich auch über die Hintergründe mal Gedanken machen.

Ich habe jetzt meine DHCP Scopes festgelegt und das DHCP Relay auf dem Switch aktiviert. Das funktioniert wunderbar. Und vergibt auch pro VLAN die richtigen Adressen.

Eine andere Sache.... Ich habe noch alte Dell Switche bei denen man leider das Management VLAN nicht wechseln kann (diesmal wirklich (powerconnect 2848)), heißt ich muss auf VLAN 1 zugreifen um auf die GUI zu kommen. Da meine Clients aber in VLAN 20 und meine Server in VLAN 10 sind müsste ich dem VLAN 1 nochmal eine andere IP geben um es rooten zu können. Jetzt will ich aber dass der Switch im gleichen Netzwerk ist wie die Server.
Um meine IPs behalten zu können hätte ich eine unschöne Lösung, aber anders geht das nicht wenn ich das Management VLAN nicht ändern kann: Ich könnte auf dem alten Dell Switch ein Kabel von einem VLAN 10 Port auf einen VLAN 1 Port am gleichen Switch ziehen. Somit könnte ich vom VLAN 10 auf den Port mit VLAN 1 und somit auf das Management. Da es untagged übertragen wird wissen die ja nicht dass sie in unterschiedlichen VLANS sind und kommunizieren ganz normal über das Kabel als wären sie einfach 2 verschiedene Switche. Das funktioniert auch soweit, das habe ich ausprobiert. Aber leider scheint es hier zu einer Art Schleife zu kommen, was ich mir aber nicht ganz erklären kann.
Ich übertrage ja vom Core zum Access (der alte Dellswitch) VLAN 10 und 20 Tagged. Jetzt disabled aber der CoreSw den Port vom Trunk (vermutlich weil er eine Schleife erkennt?). Wenn ich einstelle dass der Trunk ausschließlich Tagged Frames übertragen darf dann disabled er den Port aufeinmal nicht mehr. Scheint also so als würde es eine Flut von Untagged Frames geben die er stoppen mag..? Wo kommen die her? Ich dachte über einen Trunk laufen gar keine untagged frames, da der Switch ja an die Pakete die er darüber schickt einen Tag anhängt. Und wieso sollte es eine Schleife geben, die Ports sind ja in unterschiedlichen VLANs. Wenn ich 2 Switche aneinander hänge gibts ja auch keine Schleife. Ich hab das auch schon anders ausprobiert. Einfach den Dell komplett auf VLAN1 zu lassen aber untagged mit dem CoreSwitch VLAN 20 zu verbinden. Läuft ganz normal nur dass ich jetzt eben den DellSW mit einer Client IP ansprechen muss.

Das ganze wäre jetzt nur eine Übergangslösung bis die Switche ersetzt werden. Und ich verliere natürlich 2 Ports damit, das wäre aber nicht weiter schlimm. Dann muss ich den Switchen zumindest keine Clientip geben.
Auch wenn das Quatsch ist würde ich gerne verstehen wie es zu dieser Schleife kommt..

Danke

Grüße,
Samuel

Und vergibt auch pro VLAN die richtigen Adressen.

So sollte es sein. Works as designed! 😉

heißt ich muss auf VLAN 1 zugreifen um auf die GUI zu kommen.

Wen dem wirklich so ist das nur VLAN 1 als Management supportet ist dann ist das ja erstmal kein Problem
Du musst nur einmal ein bisschen pfiffig nachdenken um das einfach zu umgehen.
Am Trunkport des Switches wo du diesen Dell Switch anschliesst setzt du dein VLAN 10 auf Tagged und dein VLAN 20 auf die PVID (native VLAN), sprich UNtagged. Dann schiebt dieser Switchport VLAN 20 als sein native PVID VLAN untagged raus und das VLAN 10 tagged.
Auf dem alten Dell den du da anschliesst setzt du auf diesem Port nur das VLAN 10 Tagged. Das vlan 20 richtest du nicht ein, denn das ist ja jetzt auf dem Dell das VLAN 1. UNtagged VLAN 20 Traffic am Verbindungsport wird ja auf dem alten Dell dann per Default ins VLAN 1 geforwared und schon stimmt die Sache wieder.
Eigentlich doch kinderleicht wenn man mal ein bisschen logisch nachdenkt, oder? 😉

Ich übertrage ja vom Core zum Access (der alte Dellswitch) VLAN 10 und 20 Tagged.

Und ganze genau DAS ist dein Kardinalsfehler!
Da du das Management ja nie ins VLAN 20 legen kannst (deiner Meinung nach) machst du den o.a. Workaround mit dem UNtagged VLAN 20 Traffic ind VLAN 1 des Dell!

Ich dachte über einen Trunk laufen gar keine untagged frames

Ein weitverbreiteter Irrglaube dem auch du aufgessen bist obwohl du es als netzwerk Profi eigentlich besser wissen solltest. Das PVID VLAN (native VLAN) existiert IMMER an einem Trunk und ist das VLAN in das der Switch UNtagged Traffic forwardet. Eins der Grundlagen des 802.1q Standards den jeder Netzwerker kennt.

Einfach den Dell komplett auf VLAN1 zu lassen aber untagged mit dem CoreSwitch VLAN 20 zu verbinden. Läuft ganz normal nur dass ich jetzt eben den DellSW mit einer Client IP ansprechen muss.

Genau DAS ist die Lösung. Mit dem kleinen kosmetischen Manko das der Dell dann auf seinem VLAN 1 Interface eine VLAN 20 IP hat musst du dann eben leben. Ist aber, wie gesagt, eben nur reine Kosmetik. Der Funktion tut es keinen Abbruch.

Schleifen sollte es so nicht geben. Das kann man abe rnicht sicher sagen, denn das ist vom verwendeten Spanning Tree Protokoll abhängig.
In einem sauberen Spanning Tree Konzept sollte der Core Switch immer auf eine höhere Spanning Tree Priority gesetzt sein als der Default 32768. Das Setting muss immer modulo 4096 erfolgen also das man den Core dann z.B. auch 8192 setzt und die angeschlossenen anderen Switches auf dem Default belässt. So ist dediziert sicher das alle Trunk Ports zum Core Root Ports sind.
Schleifen können in der Regel nur entstehen wenn Switches unterschiedliche Spanning Tree Protokolle benutzen. Einge Hersteller verwenden PVSTP oder PVRSTP, als ein Per VLAN Spanning Tree wo jedes einzelne VLAN je einen STP Prozess hat.
Billige einfache Switches nutzen in der Regel das primitivere Single Span Verfahren mit RSTP was aber zum PVSTP Verfahren nicht kompatibel ist und wo es dann zu solchen Problemen kommen kann. In sofern ist eine saubere STP Planung immer Pflicht in einem größeren Netz.
Leider machst du zu diesem Thema keinerlei Aussagen so das eine zielführende Hilfe und eine Klärung ob Schleife oder nicht dann eher in kristallkugeln ausartet.

Hi aqui,

danke dass du mir bezüglich der Trunks die Augen geöffnet hast. Es funktioniert jetzt alles so wie du es geschrieben hast.

Ich habe jetzt mittlerweile den Accessstack in unser Netzwerk integriert.
An die VLANs hab ich mich in der produktiv Umgebung noch nicht getraut.

Ich hatte jetzt zunächst Probleme mit STP. Die alten Dellswitche in den Etagenverteilerräumen waren auf STP eingestellt und der Rest der Switche auf RSTP. Es kam in die Logs permanent die Meldung STP Topology Change und das Netzwerk hatte schwankende Latenzen. Ich habe jetzt alle Switche auf RSTP gestellt habe und dem Core die 4096 Priority gegeben, alle anderen haben die Standard Priority. Mein Core wird auch brav von allen als rootbridge erkannt. Alle Ports auf den Access Switchen welche keine Uplinks sind habe ich als Edge Port festgelegt. Bei den Dell Switchen habe ich auch P2P auf allen Ports ausser den Uplinks deaktiviert. Bei den neuen Netgear M4300ern bin ich mir nicht sicher wie das geht... Hier sieht man das bei allen Ports die UP sind p2p aktiviert ist:

In der Doku finde ich nicht wirklich wie man das ändern kann...

Es gibt:

Use Port Mode to enable or disable Spanning Tree Protocol Administrative mode
associated with the port or port channel.
The possible values are Enable or Disable. The default value is Disable."

Bei mir steht das komischerweise Standardmäßig bei allen Ports auf Enabled.

Ich gehe davon aus dass man das bei den Uplinks aktiviert und bei dem Rest deaktiviert?

Aber das hat scheinbar nichts mit p2p zu tun.

Jedenfalls ist das mit den STP Topolgy Change eigentlich weg seit meinen Änderungen.

Aber es kommen weiterhin LLDP-MED Topology Changes. Hier gehen permanent irgendwelche Ports Down und wieder Up. Die sind teilweise 20 Sekunden down...

Woran könnte das liegen? Hat das auch noch mit STP zu tun?

Danke.

Viele Grüße,
Samuel

Die alten Dellswitche in den Etagenverteilerräumen waren auf STP eingestellt und der Rest der Switche auf RSTP

STP und RSTP sind untereinander kompatibel solange sie im Single Span Verfahren laufen. RSTP schaltet also an STP Ports auf das alte STP Verfahren um. Das ist nicht gerade schön weil die Recovery Zeiten bei STP immens hoch sind aber machbar.
Entscheidend ist aber immer das du den Core Stack in der Spanning Tree Priority hochschraubst damit seine Link immer Root Ports werden.
Das ist ein Muss in einem sauberen STP Design.
Default ist immer eine Priority von 32768 und die Priority rechnet sich immer modulo 4096. Wenn du deinen Core Switches also eine Prio von 8192 gibts bist du auf der sicheren Seite.

Ich habe jetzt alle Switche auf RSTP gestellt habe und dem Core die 4096 Priority gegeben

Perfekt, dann hast du alles richtig gemacht!
Das man die RSTP Port Modi nicht einstellen kann ist leider häufig üblich bei Billigheimern wie NetGear und Co. Damit musst du dann leben wenn du dich für den Hersteller entschieden hast, ist aber nicht wirklich schlimm.

Deine LLDP Fehlermeldungen sind da eher gravierender. LLDP ist in der Tat ein Topologie Protokoll und hat mit Spanning Tree nix zu tun.
Es zeigt aber das an der HW irgendwas nicht stimmt. Du solltest dir diese Ports an denen das auftritt einmal genauer ansehen.
Dort gibt es vermutlich Mismatches im Port Mode, Speed oder sowas was LLDP anmeckert.
NetGear ist da auch mal wieder etwas komisch im Verhalten. Siehe:
https://community.netgear.com/t5/Managed-Switches/GS752TX-LLDP-MED-Topol ...