Distribution Layer / L3 Switching / Inter-VLAN / Redundanz

[PEASANT KING]

Hallöchen,

ich habe mal eine Frage als nicht so Netzwerkspezialist.

Wenn ich ein Netzwerk aufbaue in einen Distributions Layer habe in dem sich 2x Layer 3 Switches befinden, wo in diesem Layer auch das Inter-VLAN Routing betrieben wird, wofür ich ja SVI benötige, wie konfigiere ich die SVIs in den L3 Switches?
Die L3 Switches sind untereinnader nicht verbunden, aber gibt es hier nicht Ärger, wenn ich SVI gleich konfiguriert auf beiden Switches habe, da vom Access Layer jeder Switch mit jedem L3 Switch verbunden ist, weiß man ja nicht von welchem Switch die Daten weiter geleitet werden.

Grüße

 

[Joe Dalton]

Die meisten Hersteller werden einen Design Guide und/oder Configuration Guide haben, der die entsprechenden Szenarien beschreibt. Sollte sich über die Webseiten jeweils finden lassen, teilweise nachdem man sich dort registriert/eingeloggt hat.

Da wirst Du ausreichend Informationen zur Redundanz für L2-Anbindungen (z.B. Link Aggregation, Spanning Tree), Gateways (z.B. HSRP/VRRP/Active Gateway) und Routing (z.B. statisch, OSPF, EIGRP) haben.

Wie bei vielen Themen beginnt auch hier die Arbeit mit einem Blatt Papier/Bleistift oder einem Whiteboard.

 

[PEASANT KING]

Na das ich STP etc benötige ist klar. Ich wollte nur wissen, ob beide L3 Switches die gleichen SVI Adressen nutzen dürfen / müssen.
Vielleicht eine dumme Frage von einem der kein Netzwerk Spezialist ist.

 

[TheCadillacMan]

Jedes SVI bekommt eine eigene IP. Als Gateway an den Clients kann man dann zusätzliche IP nutzen, die sich beide Switches teilen (z. B. per VRRP).

 

[PEASANT KING]

Okay danke @TheCadillacMan

 

[Joe Dalton]

Na das ich STP etc benötige ist klar.

Ist es das? Glaube ich nicht...

Ich wollte nur wissen, ob beide L3 Switches die gleichen SVI Adressen nutzen dürfen / müssen.
Vielleicht eine dumme Frage von einem der kein Netzwerk Spezialist ist.

Doppelte IP-Adressen sind immer schlecht und es gibt entsprechende Protokolle für First Hop Redundanz.

Schau in die Design Guides Deines Hardwareherstellers. Oder in Dein Schulbuch, wenn es eine Hausaufgabe sein sollte.

 

[DonConto]

Die L3 Switches sind untereinnader nicht verbunden,

Wieso nicht? Das ist eine Schwachstelle im Design.

Ergänzung (19. Januar 2024)

Na das ich STP etc benötige ist klar.

Nö, in deinem (schlechten) Fall nicht.

 

[PEASANT KING]

Naja warum sollten die Distribution Switches untereinder nochmal verbunden sein, wenn sowieso alle Access Layer Switches mit jedem Distribution Switch verbunden ist?

Vielleicht sollte ich noch erwähnen das es sich hier um ein Collapsed Core Design handelt.

 

[Joe Dalton]

Naja warum sollten die Distribution Switches untereinder nochmal verbunden sein, wenn sowieso alle Access Layer Switches mit jedem Distribution Switch verbunden ist?

Die Frage könntest Du Dir selbst beantworten, wenn Du ansatzweise Ahnung von der Materie hättest. Aber alleine schon Deine Ergänzung mit dem Collapsed Core, die am Anfang fehlte, zeigt wie groß die Lücken und Dein Unverständnis sind. RTFM!

Vielleicht sollte ich noch erwähnen das es sich hier um ein Collapsed Core Design handelt.

Warum sprichst Du dann von einem Distribution Layer?

nur als ergänzender Hinweis zu Deinem Design: Mir fällt aktuell genau ein Netzwerkdesign an, in dem die Layer3-Switches keine direkte Verbindung haben. Aber ich glaube, dass Du meilenweit von einer Spine-Leaf-Architektur weg bist.

 

[PEASANT KING]

Entschuldige bitte das ich gefragt habe.

 

[nutrix]

Darf man den genaueren Hintergrund Deiner Frage erfahren?

 

[PEASANT KING]

Ich bin dabei ein kleineres Netzwerk auf dem Papier zu modernisieren und sicherer gegen Ausfälle und sicherer zu machen. Wohlgemerkt auf dem Papier.

 

[nutrix]

Firma oder privat?

 

[PEASANT KING]

Firma ich bin eigentlich fertig, mir ging es hier einfach nur um eine Redundanz an L3 Switches falls einer mal ausfällt und wenn alle Access Switches mit den Collapsed Core verbunden sind wie es sich mit SVIs verhält.

 

[dzorg]

Ein als LAG ausgeführter Crosslink zwischen den L3-Geräten wäre hilfreich. Damit kannst du die Maschinen (in der Regel) zusätzlich als L2-Cluster fahren, so dass du die Uplinks aus dem Access Layer ebenfalls als LAG implementieren kannst. Spanning-Tree hat in so einer Topologie nichts verloren, sonst schmeißt man ja pauschal die Hälfte der verfügbaren Bandbreite weg. STP ist zudem viel zu langsam.

Der Crosslink dient zusätzlich als "Escape Path" (L2 oder L3, je nach Szenario), falls einer der Router mal einen Infrastruktur-Link verliert (Downlinks, Uplinks), den er üblicherweise für das Forwarding bräuchte. So kann der Traffic zum anderen Router "übersetzen", welcher den Traffic dann zustellen kann.

Jedes Chassis hat immer seine eigene, eindeutige IP-Adresse pro VLAN/Nutznetz, nebst einer gemeinsamen IP-Adresse (siehe VRRP, HSRP, oder sonstige Router-Redundanz-Protokolle). Letztere IP sprechen die Clients als Gateway an. Du musst also 3 IP-Adressen pro VLAN/Nutznetz dafür reservieren.
Manche Router-Redundanz-Protokolle erlauben sogar das Forwarding von beiden Routern; also nicht nur vom Master, sondern auch vom Backup (beispielsweise VRRP-E auf den alten Brocade Machinen; short-path-forwarding hieß das bei denen). Somit muss der Traffic nicht über den Crosslink laufen, wenn das Paket vom Access Layer auf dem Backup Router statt auf dem Master Router eintreffen sollte.

 

[Joe Dalton]

@dzorg Deine Aussage stimmen für diverse Konstellationen (für die meisten Konstrukte mit getrennten Controlplanes). Mit einem Switchstack jedoch würde er jedoch diese ganzen Themen größtenteils nicht haben.

Aber für eine korrekte Betrachtung des ganzen müsste der TE mal die Zähne auseinander kriegen und seinen Aufbau beschreiben und die Hardware benennen.

Das ursprüngliche STP war alles andere als flott, aber mit Rapid-STP ist das Thema eigentlich durch. Das Umschalten der Pfade sollte TCP-Session überstehen. Jedoch ist in vielen Fällen eine loopfreie Topologie zu bevorzugen: Spanning-Tree sollte als Notfallmechanismus laufen und nicht als betriebsnotwendige Konfiguration.