15
Access-Switch per Stack oder LAG?
Hallo Leute,
aktuell wird ein Redesign unseres Netzwerks geplant.
Es sind zwei Core-Switches, an denen die Server direkt angebunden sind, und ein Access-Switch, über den die Clients zugreifen geplant. Die beiden Core-Switches sollen auf jeden Fall im Stack betrieben werden, um Ausfallsicherheit zu gewährleisten.
Nun geht es darum, wie der Access-Switch angebunden wird. Dieser befindet sich in einem anderen Raum und soll über 2x 10 Gb Glasfaser angebunden werden. Es gibt die Möglichkeit ihn über Link Aggregation mit dem Core-Layer zu verbinden oder ihn in den Stack mit aufzunehmen. Bei dieser Frage bin ich mir unschlüssig und würde gern eure Meinung hören.
Viele Grüße
FelR
aktuell wird ein Redesign unseres Netzwerks geplant.
Es sind zwei Core-Switches, an denen die Server direkt angebunden sind, und ein Access-Switch, über den die Clients zugreifen geplant. Die beiden Core-Switches sollen auf jeden Fall im Stack betrieben werden, um Ausfallsicherheit zu gewährleisten.
Nun geht es darum, wie der Access-Switch angebunden wird. Dieser befindet sich in einem anderen Raum und soll über 2x 10 Gb Glasfaser angebunden werden. Es gibt die Möglichkeit ihn über Link Aggregation mit dem Core-Layer zu verbinden oder ihn in den Stack mit aufzunehmen. Bei dieser Frage bin ich mir unschlüssig und würde gern eure Meinung hören.
Viele Grüße
FelR
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 347463
Url: https://administrator.de/contentid/347463
Ausgedruckt am: 26.11.2024 um 09:11 Uhr
15 Kommentare
Neuester Kommentar
Hallo,
was sind es denn für Switche?
Rein mit deinen Informationen würde ich eine LAGG bilden wenn du ihn schon mit 10Gb anfährst ohne die Modelle zu kennen.
mfg maddig
was sind es denn für Switche?
Rein mit deinen Informationen würde ich eine LAGG bilden wenn du ihn schon mit 10Gb anfährst ohne die Modelle zu kennen.
mfg maddig
Hallo,
als Modelle haben wir geplant: 1x Cisco SG350X-48P als Access-Switch und 2x Cisco SG350XG-24F als Core-Switch
Viele Grüße
FelR
als Modelle haben wir geplant: 1x Cisco SG350X-48P als Access-Switch und 2x Cisco SG350XG-24F als Core-Switch
Viele Grüße
FelR
Ein Stack dient ja wohl eher einer vereinfachten Konfiguration/Management: Mehrere Geräte lassen sich wie ein Gerät managen.
Ausfallsicherheit erreicht man rein durch Redundanz!
Verbindungsredundanz z. B. durch LAG/LACP und Spanning Tree Protocol bei Switches.
LAG/LACP wiederum wird meist (immer?) nur mit 1 Gerät funktionieren. Reine Verbindungsredundanz und erhöhte Datenraten bei Vollauslastung.
Geräteredundanz sagt uns bereits der Name. Mit dem Spanning Tree Protocol (standardisiert) auch herstellerübergreifend/geräteübergreifend möglich. Führt jedoch zu keiner Erhöhung der Datenrate, da Auflösung von Schleifen / redundanten Verbindungen.
Nun der Intelligenztest: Hat deine Access-Ebene und deine Core-Ebene auch nur annähernd die gleiche Funktion/Konfiguration - als dass man dafür ein gemeinsames/einheitliches Management benötigt?
Intelligenztest Nr. 2: Wie gefährdet sind Kabel/Verbindungen innerhalb eines Gebäudes oder Raumes? Ist ein Ausfall von Geräten wahrscheinlicher?
Intelligenztest Nr. 3: Kosten vs. Nutzen, Redundanz nur mit notwendiger und damit sowieso mehrfach vorhandener (Core-) Technik sinnvoll?
Zeichnung A + B haben nichts miteinander zu tun, sind keine unterscheidlichen Konzepte: Zeichnung A zeigt eine Betriebsfunktion, Zeichnung B eine Managementebene.
Mann oh mann ... wer so alles plant ... konzipiert.
Ausfallsicherheit erreicht man rein durch Redundanz!
Verbindungsredundanz z. B. durch LAG/LACP und Spanning Tree Protocol bei Switches.
LAG/LACP wiederum wird meist (immer?) nur mit 1 Gerät funktionieren. Reine Verbindungsredundanz und erhöhte Datenraten bei Vollauslastung.
Geräteredundanz sagt uns bereits der Name. Mit dem Spanning Tree Protocol (standardisiert) auch herstellerübergreifend/geräteübergreifend möglich. Führt jedoch zu keiner Erhöhung der Datenrate, da Auflösung von Schleifen / redundanten Verbindungen.
Nun der Intelligenztest: Hat deine Access-Ebene und deine Core-Ebene auch nur annähernd die gleiche Funktion/Konfiguration - als dass man dafür ein gemeinsames/einheitliches Management benötigt?
Intelligenztest Nr. 2: Wie gefährdet sind Kabel/Verbindungen innerhalb eines Gebäudes oder Raumes? Ist ein Ausfall von Geräten wahrscheinlicher?
Intelligenztest Nr. 3: Kosten vs. Nutzen, Redundanz nur mit notwendiger und damit sowieso mehrfach vorhandener (Core-) Technik sinnvoll?
Zeichnung A + B haben nichts miteinander zu tun, sind keine unterscheidlichen Konzepte: Zeichnung A zeigt eine Betriebsfunktion, Zeichnung B eine Managementebene.
Mann oh mann ... wer so alles plant ... konzipiert.
Moin,
ein Stack zwischen Acces und Core wird mit den genannten Geräten ohnehin nicht funktionieren.
Gemäß Manual (S. 130) kann ein Stack nur innerhalb einer Modellserie aufgebaut werden. Da du aber einen SG350X mit einem SG350XG verbinden willst, bleibt dir nur eine LAG. Spricht ja aber auch nichts gegen. Wird seit Jahren so gemacht und wird sich vermutlich auch soo schnell nichts ändern, denke ich.
Gruß
em-pie
ein Stack zwischen Acces und Core wird mit den genannten Geräten ohnehin nicht funktionieren.
Gemäß Manual (S. 130) kann ein Stack nur innerhalb einer Modellserie aufgebaut werden. Da du aber einen SG350X mit einem SG350XG verbinden willst, bleibt dir nur eine LAG. Spricht ja aber auch nichts gegen. Wird seit Jahren so gemacht und wird sich vermutlich auch soo schnell nichts ändern, denke ich.
Gruß
em-pie
Mit der SG Reihe ist nach meinem Wissensstand kein HSRP (VSS sowieso nicht) verfügbar.
Da wird es schwierig die Ausfallsicherheit herzustellen..
Deine einzige Möglichkeit ist es den Access per LAGG an einen deiner Cores anzubinden.
Wie Karla schreibt ist das nur eine Verbindungsredundanz keine Hardwareredundanz.
mfg
Da wird es schwierig die Ausfallsicherheit herzustellen..
Deine einzige Möglichkeit ist es den Access per LAGG an einen deiner Cores anzubinden.
Wie Karla schreibt ist das nur eine Verbindungsredundanz keine Hardwareredundanz.
mfg
Guten Morgen Karla und em-pie,
meinem Verständnis nach dient ein Stack sehr wohl auch der Ausfallsicherheit. Die Server werden per LAG je einmal pro Switch angebunden. Fällt nun einer der Switches aus, läuft der ganze Traffic über den verbliebenen. Um die Server redundant per LAG an die Switche anzuschließen, müssen diese im Stack betrieben werden (ist zumindest mein Kenntnisstand. Verbessert mich, wenn ich falsch liege).
Im Hybrid-Stacking-Mode sind auch die Modellreihen untereinander stapelbar, also SG350X mit SG350XG und SG500X mit SG500XG.
Viele Grüße
FelR
meinem Verständnis nach dient ein Stack sehr wohl auch der Ausfallsicherheit. Die Server werden per LAG je einmal pro Switch angebunden. Fällt nun einer der Switches aus, läuft der ganze Traffic über den verbliebenen. Um die Server redundant per LAG an die Switche anzuschließen, müssen diese im Stack betrieben werden (ist zumindest mein Kenntnisstand. Verbessert mich, wenn ich falsch liege).
Im Hybrid-Stacking-Mode sind auch die Modellreihen untereinander stapelbar, also SG350X mit SG350XG und SG500X mit SG500XG.
Viele Grüße
FelR
HSRP wird auch nicht benötigt. Die Routing-Redundanz wird über zwei Sophos-Appliances im Hot-Standby gewährleistet.
VG
FelR
VG
FelR
Jo, stimmt... den Hybrid-Modus hatte ich überschlagen -.-
Aber warum willst du den Access via Stack an die Cores anbinden? Nur der Administration wegen?
Wenn der Access weg ist, bringt dir der redundante PFad zum Core-Switch auch nichts.
Du kannst zudem den Access mit je einem Bein an einen der beiden Cores anbinden.
Wir haben im Serverrack zwei SGX500 im Stack laufen. Beide laufen zu einem ProCurve 5406, wobei jeder StackMember drei Beine am E5406zl hat.
Wir machen es also umgekehrt, am Core-Switch (derweil der einzige physische Switch, aber verschiedene Module) treffen die LWL-Strippen beider StackMember zusammen. Alles angebunden via LACP/ LAG. Klappt einwandfrei.
Du musst also keinen Stack betreiben, um den Access Redundant am Core anzuschließen
Aber warum willst du den Access via Stack an die Cores anbinden? Nur der Administration wegen?
Wenn der Access weg ist, bringt dir der redundante PFad zum Core-Switch auch nichts.
Du kannst zudem den Access mit je einem Bein an einen der beiden Cores anbinden.
Wir haben im Serverrack zwei SGX500 im Stack laufen. Beide laufen zu einem ProCurve 5406, wobei jeder StackMember drei Beine am E5406zl hat.
Wir machen es also umgekehrt, am Core-Switch (derweil der einzige physische Switch, aber verschiedene Module) treffen die LWL-Strippen beider StackMember zusammen. Alles angebunden via LACP/ LAG. Klappt einwandfrei.
Du musst also keinen Stack betreiben, um den Access Redundant am Core anzuschließen
Wünsche ich dir auch! Und nichts für ungut, bin impulsiv. 
Die Server werden per LAG [Einfügung: zu 1 Access-Switch] angebunden. ... Um die Server redundant per LAG an die Switche anzuschließen, müssen diese im Stack betrieben werden ...#
Nö. "dual homing" bei 2 unterschiedlichen Access-Switches ohne stacking möglich. LAG zu einem Access-Switch wegen doppelter Datenrate der Server. Dual-Homing für Geräteredundanz. Entscheide dich.
Hallo em-pie,
vielen Dank für deinen konstruktiven Beitrag.
Anfänglich sollte der Access-Switch zur einfacheren Konfiguration in den Stack aufgenommen werden. An den Wegfall der Redundanz in der Core-Ebene bei Ausfall des Access-Switches habe ich dabei allerdings nicht gedacht. Das ist auf jeden Fall ein guter Grund, der für eine Anbindung per LAG spricht.
VG
FelR
vielen Dank für deinen konstruktiven Beitrag.
Anfänglich sollte der Access-Switch zur einfacheren Konfiguration in den Stack aufgenommen werden. An den Wegfall der Redundanz in der Core-Ebene bei Ausfall des Access-Switches habe ich dabei allerdings nicht gedacht. Das ist auf jeden Fall ein guter Grund, der für eine Anbindung per LAG spricht.
VG
FelR
Zitat von @134058:
Nö. "dual homing" bei 2 unterschiedlichen Access-Switches ohne stacking möglich. LAG zu einem Access-Switch wegen doppelter Datenrate der Server. Dual-Homing für Geräteredundanz. Entscheide dich.
Das ist doch eben der Vorteil, wenn man zwei Switches im Stack betreibt. Im Normalbetrieb wird dank LAG eine erhöhte Datenrate erzielt und sollte einer der Switches ausfallen, läuft die Verbindung dank Dual-Homing trotzdem weiter. Verbindungs- und Geräteredundanz in einem Nö. "dual homing" bei 2 unterschiedlichen Access-Switches ohne stacking möglich. LAG zu einem Access-Switch wegen doppelter Datenrate der Server. Dual-Homing für Geräteredundanz. Entscheide dich.
Aber nur, wenn LAG/LACP über 2 verschiedene Switches funktioniert. Wage ich zu bezweifeln (LACP und Spanning TreeProtocol - letzteres eventuell damit/dafür deaktiviert), lasse mich jedoch gern eines Besseren belehren.
Nichstdestotrotz sind wir jetzt richtigerweise bei getrennten Stacks für Access und Core.
(Ausserdem sehe ich ein höheres Ausfallrisiko beim Server selbst als bei einem ordentlichem Switch. Wenn Redundanz, dann richtig oder nur kostenlos vorhandene. Oder eben nur Bandbreitenerhöhung durch LACP: 1. Absatz.)
Nichstdestotrotz sind wir jetzt richtigerweise bei getrennten Stacks für Access und Core.
(Ausserdem sehe ich ein höheres Ausfallrisiko beim Server selbst als bei einem ordentlichem Switch. Wenn Redundanz, dann richtig oder nur kostenlos vorhandene. Oder eben nur Bandbreitenerhöhung durch LACP: 1. Absatz.)
Hier wird es für einen Stack aus Catalyst 3750 konfiguriert, aber das Prinzip ist auch auf die SG350er anwendbar.
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series ...
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series ...
Mit der SG Reihe ist nach meinem Wissensstand kein HSRP (VSS sowieso nicht) verfügbar.
Ist ja auch vollkommen unnötig, denn wenn die Core Systeme im Stack laufen ist HSRP oder VSRP ja vollkommen überflüssig.Also Cores im Full Stack und den Access per LACP ankoppeln sofern der Access Switch nicht in den Stack aufgenommen werden kann und gut iss...
Sollte man alle drei stacken können wäre auch ein Stack über alle drei sehr sinnvoll, denn die Stack Links können das Traffic Balancing etwas besser als ein LACP Link der auf Hashing der Mac Adressen basiert.
Zitat von @FelR0429:
Hier wird es für einen Stack aus Catalyst 3750 konfiguriert, aber das Prinzip ist auch auf die SG350er anwendbar.
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series ...
Danke! Dazugelernt. Hier wird es für einen Stack aus Catalyst 3750 konfiguriert, aber das Prinzip ist auch auf die SG350er anwendbar.
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series ...
