Vorschlag für Switch-Redundanz am Hauptverteiler
Hallo,
ich möchte gerne den Switch an unserem Haupt-Knotenpunkt redundant auslegen. Kann jemand eine Empfehlung machen, wie das am Besten realisiert werden kann? Bisher sind alle Switche und auch die Verkabelung zwischen diesen nur einfach vorhanden. Die Switche und Verbindungen in der Unterverteilung benötigen vorerst keine Redundanz, mir ist es nur wichtig, dass nicht alle Zweige der Unterverteilung auf einmal ausfallen, wenn die Hauptverteilung ausfällt. Als Switche sind hauptsächlich HP ProCurve 4204vl im Einsatz. Ein Beispiel habe ich visualisiert, in Wirklichkeit gibt es aber noch deutlich mehr Zweige, die vom Hauptverteiler abgehen.
Gruß
PSaR04
ich möchte gerne den Switch an unserem Haupt-Knotenpunkt redundant auslegen. Kann jemand eine Empfehlung machen, wie das am Besten realisiert werden kann? Bisher sind alle Switche und auch die Verkabelung zwischen diesen nur einfach vorhanden. Die Switche und Verbindungen in der Unterverteilung benötigen vorerst keine Redundanz, mir ist es nur wichtig, dass nicht alle Zweige der Unterverteilung auf einmal ausfallen, wenn die Hauptverteilung ausfällt. Als Switche sind hauptsächlich HP ProCurve 4204vl im Einsatz. Ein Beispiel habe ich visualisiert, in Wirklichkeit gibt es aber noch deutlich mehr Zweige, die vom Hauptverteiler abgehen.
Gruß
PSaR04
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 201418
Url: https://administrator.de/contentid/201418
Ausgedruckt am: 22.11.2024 um 20:11 Uhr
9 Kommentare
Neuester Kommentar
moin,
eher nein - um eine echte redundanz zu haben, mußt du aus deinem Stern einen Ring machen.
Machst du einen Ring und deine Switche oder die Firmware derjenigen kann das nicht / oder nicht richtig - dann hast du keine Redundanz geschaffen sondern einen Loop.
Ergo:
Für deine Anforderung zuwenig Info und eijne Zeile ala
Aber wenn der "core" nur ein 4xxx HP ist - vergiss es einfach wieder.
Ich müsste tatsächlich überlegen, wann es für die das letzte Firmwareupgrade gab - wahrscheinlich hatt eich da noch keine grauen Haare
Wir haben irgendwelche der 8000er Reihe als Core und die können das (auch erst sauber seit nem Firmwareupdate das es Anfang 2012 erst gab)
Gruß
eher nein - um eine echte redundanz zu haben, mußt du aus deinem Stern einen Ring machen.
Machst du einen Ring und deine Switche oder die Firmware derjenigen kann das nicht / oder nicht richtig - dann hast du keine Redundanz geschaffen sondern einen Loop.
Ergo:
Für deine Anforderung zuwenig Info und eijne Zeile ala
Als Switche sind hauptsächlich HP ProCurve 4204vl im Einsatz.
ist nur die halbe Wahrheit, welche noch und wie sind die angebunden.Aber wenn der "core" nur ein 4xxx HP ist - vergiss es einfach wieder.
Ich müsste tatsächlich überlegen, wann es für die das letzte Firmwareupgrade gab - wahrscheinlich hatt eich da noch keine grauen Haare
Wir haben irgendwelche der 8000er Reihe als Core und die können das (auch erst sauber seit nem Firmwareupdate das es Anfang 2012 erst gab)
Gruß
Hallo PSaR04,
ich wollte einmal etwas zu Deinem Bild erfragen, wenn es denn nichts ausmacht.
Ich meine ich kenne weder das Netzwerk noch deren Aufgaben oder Größe und für wie viele Leute es taugen muss,
respektive welche Protokolle und welches Setup Du hast und es ist auch nur rein vom Interesse halber.
Sind dort nicht zwischen der Wolke und dem Hauptverteiler noch Router, Firewalls oder Gateways?
Ist die DMZ in der Wolke so richtig oder geht die nicht vom Gateway ab?
Habt Ihr ein GBP setup mit OSPF?
Gruß
Dobby
ich wollte einmal etwas zu Deinem Bild erfragen, wenn es denn nichts ausmacht.
Ich meine ich kenne weder das Netzwerk noch deren Aufgaben oder Größe und für wie viele Leute es taugen muss,
respektive welche Protokolle und welches Setup Du hast und es ist auch nur rein vom Interesse halber.
Sind dort nicht zwischen der Wolke und dem Hauptverteiler noch Router, Firewalls oder Gateways?
Ist die DMZ in der Wolke so richtig oder geht die nicht vom Gateway ab?
Habt Ihr ein GBP setup mit OSPF?
Gruß
Dobby
Hi PSaR04
Moment - 1500 User? Und dann im Core Bereich HP (Gerummel) das nicht einmal PVST kann? ôÔ (aus dem Grund sind die bei uns rausgeflogen )
Wenn du einen Ring aufbauen willst nimm Brocade (MRRP), Cisco, Juniper oder was auch immer - aber mit Sicherheit nicht HP (die haben wir, wenn überhaupt, nur noch im Access Bereich im Einsatz).
Wenn du Redudanzen willst, mach es richtig, und arbeite auch mit VRRP usw.
Bei größeren Netzen macht es schon Sinn das etwas anders zu gestallten:
Damit hättest den "Core" inkl. den Routern Redundant ausgelegt und den Aggregationlayer wo du dann die Access-Switche anschließen kannst auch.
Dann auch noch solche Sachen die z.B. Dobby angesprochen hat
Und zum Thema HP: wenn du in einem VLAN ein Loop hast - steht alles und die HP Kisten steigen dir alle nacheinander aus, bis das STP/Loopprotection greift - wir haben die (fast) alle ausgetauscht - weil es immer wieder "Helden" gibt die Lustig fröhlich umstecken usw. und das PVST sich bewährt hat und dadurch max. ein Bereich betroffen ist.
Bzgl. Ringprotokoll hatte ich auch schon einen Thread: MRP Sinnvoll - Ringprotokoll.
Vielleicht ist es bei eurer Große nicht schlecht, aber definitiv nicht mit HP ... - vor allem weil du immer eine Zuleitung und einen Abgang haben musst, eure Verkabelung muss das halt hergeben und der Ring selbst sollte eine eigene dedizierte Leitung haben (zum. ist das die Aussage von einem Borcade Techniker) zusätzlich zu den regulären Uplinks - die Umschaltzeit im Fehlerfall ist allerdings bedeutend schneller wie im STP
Moment - 1500 User? Und dann im Core Bereich HP (Gerummel) das nicht einmal PVST kann? ôÔ (aus dem Grund sind die bei uns rausgeflogen )
Wenn du einen Ring aufbauen willst nimm Brocade (MRRP), Cisco, Juniper oder was auch immer - aber mit Sicherheit nicht HP (die haben wir, wenn überhaupt, nur noch im Access Bereich im Einsatz).
Wenn du Redudanzen willst, mach es richtig, und arbeite auch mit VRRP usw.
Bei größeren Netzen macht es schon Sinn das etwas anders zu gestallten:
Damit hättest den "Core" inkl. den Routern Redundant ausgelegt und den Aggregationlayer wo du dann die Access-Switche anschließen kannst auch.
Dann auch noch solche Sachen die z.B. Dobby angesprochen hat
- Routing via OSPF? Wenn ja mit oder ohne Areas
- VoIP Technik?
- VLAN Umsetzung
- Spanningtree - wenn ja welches? (802.1w können die HP Kisten z.B. nicht sauber)
- Was ist mit 802.1x oder evtl MAC-SEC?
- Wie sieht das mit Multimedia-Anwendungen aus z.B. Streamingdienste?
- Was ist mit SAN?(iSCSI, FC, FCoE ...)
- Wie sieht es mit dem Backbone für die Server aus? Oder sind die mit an den HP Kisten?
Und zum Thema HP: wenn du in einem VLAN ein Loop hast - steht alles und die HP Kisten steigen dir alle nacheinander aus, bis das STP/Loopprotection greift - wir haben die (fast) alle ausgetauscht - weil es immer wieder "Helden" gibt die Lustig fröhlich umstecken usw. und das PVST sich bewährt hat und dadurch max. ein Bereich betroffen ist.
Bzgl. Ringprotokoll hatte ich auch schon einen Thread: MRP Sinnvoll - Ringprotokoll.
Vielleicht ist es bei eurer Große nicht schlecht, aber definitiv nicht mit HP ... - vor allem weil du immer eine Zuleitung und einen Abgang haben musst, eure Verkabelung muss das halt hergeben und der Ring selbst sollte eine eigene dedizierte Leitung haben (zum. ist das die Aussage von einem Borcade Techniker) zusätzlich zu den regulären Uplinks - die Umschaltzeit im Fehlerfall ist allerdings bedeutend schneller wie im STP
Hallo nochmal,
hinsichtlich einer neu oder Umstrukturierung des ganzen Netzwerkes, das hört sich schlimmer an als es
in Wirklichkeit ist.
Entweder bezogen auf die Switch Hierarchie man geht den Weg:
Core Layer - Dstributed Layer - Access Layer
Gebäude------Etagen-------------Abteilungen
oder hält die Hierarchie möglichst flach und hat alles in einem zentralen Serverraum untergebracht:
Core Layer - Access Layer
Gebäude- ----Abteilungen
Das kommt aber auch ganz darauf an was die restliche Netzwerkstruktur denn so hergibt, aussagt oder wie sie sich darstellt!
Wenn man aufgrund der schnellen Konvergenz und Reaktionszeit wird EIGRP oft als alternative zu dem Team
BGP und OSPF, auch gerne zur Kostensenkung und der Switche selbst wegen!
Denn wenn die Router wegfallen sollen wie in Deinem Fall müssen oder sollten diese (die Switche) auch diese
Protokolle beinhalten und verstehen und da geht es dann nur noch um das liebe Geld wie immer.
Ich verstehe gerne wenn eine Firma wächst und man eben vor sehr langer Zeit angefangen hat
mit einer bestimmten Switchserie eines bestimmten Herstellers zu arbeiten das man sich nur ungern
davon trennt und wechselt, aber dann sollte die Netzwerkumgebung dem ganzen vorhaben auch entsprechen
und vor allem anderen Ihre Aufgaben.
Wie Du das im Endeffekt realisierst sei Dir überlassen, aber Router kann man auch selber bauen
mit Serverhardware und zwar ziemlich mächtige Router und diese kann man dann auch Hardware Upgraden
wenn es wirklich ums liebe Geld geht, aber die Core Switche kann man nicht erweitern und muss dann schone neue holen und sie stapeln, was dann auch richtig zu buche schlägt.
Hier meine 5 Cent zur Redundanz von Switchen, ok das sind nicht die von meinem Vorredner angesprochenen
aber das ist im Prinzip ja auch egal, denn die Zeichnung sollte das eigentliche Thema sein, was jeder nutzt
ist auch irgent wie meist vorgegeben und lässt sich nicht all zu oft vom Admin regeln, leider.
Switch Redundanz
Aber so wie mein Vorredner es aufgezeichnet hat, habe ich mir das auch schon gedacht.
- Netzwerk ist bis auf einige kleine Außenstellen auf mehrere, größere Gebäude verteilt
Jo dann würde ich einmal sagen oder raten das Du dir evtl. ein paar Gedanken am Wochenende machst,hinsichtlich einer neu oder Umstrukturierung des ganzen Netzwerkes, das hört sich schlimmer an als es
in Wirklichkeit ist.
Entweder bezogen auf die Switch Hierarchie man geht den Weg:
Core Layer - Dstributed Layer - Access Layer
Gebäude------Etagen-------------Abteilungen
oder hält die Hierarchie möglichst flach und hat alles in einem zentralen Serverraum untergebracht:
Core Layer - Access Layer
Gebäude- ----Abteilungen
Das kommt aber auch ganz darauf an was die restliche Netzwerkstruktur denn so hergibt, aussagt oder wie sie sich darstellt!
Wenn man aufgrund der schnellen Konvergenz und Reaktionszeit wird EIGRP oft als alternative zu dem Team
BGP und OSPF, auch gerne zur Kostensenkung und der Switche selbst wegen!
Denn wenn die Router wegfallen sollen wie in Deinem Fall müssen oder sollten diese (die Switche) auch diese
Protokolle beinhalten und verstehen und da geht es dann nur noch um das liebe Geld wie immer.
Ich verstehe gerne wenn eine Firma wächst und man eben vor sehr langer Zeit angefangen hat
mit einer bestimmten Switchserie eines bestimmten Herstellers zu arbeiten das man sich nur ungern
davon trennt und wechselt, aber dann sollte die Netzwerkumgebung dem ganzen vorhaben auch entsprechen
und vor allem anderen Ihre Aufgaben.
Wie Du das im Endeffekt realisierst sei Dir überlassen, aber Router kann man auch selber bauen
mit Serverhardware und zwar ziemlich mächtige Router und diese kann man dann auch Hardware Upgraden
wenn es wirklich ums liebe Geld geht, aber die Core Switche kann man nicht erweitern und muss dann schone neue holen und sie stapeln, was dann auch richtig zu buche schlägt.
Hier meine 5 Cent zur Redundanz von Switchen, ok das sind nicht die von meinem Vorredner angesprochenen
aber das ist im Prinzip ja auch egal, denn die Zeichnung sollte das eigentliche Thema sein, was jeder nutzt
ist auch irgent wie meist vorgegeben und lässt sich nicht all zu oft vom Admin regeln, leider.
Switch Redundanz
Aber so wie mein Vorredner es aufgezeichnet hat, habe ich mir das auch schon gedacht.
Eine ganz andere Alternative wäre auch, was Aqui in meinem Thread geschrieben hat, komplett weg vom STP/Ring, allerdings sind das natürlich etwas höhere Kosten, ich weis nicht ob Cisco das auch bietet was z.B. Brocade mit der VDX Serie bietet (TRILL).
Ein weitere Pluspunkt ist, du kannst auf Dauer auch das FC mit über die Switche laufen lassen (FCoE) und bei SAN Erweiterung auch auf iSCSI Geräte zurückgreifen kannst - und wenn Ihr viel mit VMWare arbeitet - sind die Geräte richtig nett - die lassen sich ins vCenter einbinden Mit der Technik kannst auch solche lustigen Sachen bauen:
(mal übertrieben dargestellt)
und auf allen Links ist volle Bandbreite verfügbar und sind aktiv und das ganze lässt sich als ein Gerät managen - ohne das du auch nur eine STP Instanz konfigurieren musst
Ein weitere Pluspunkt ist, du kannst auf Dauer auch das FC mit über die Switche laufen lassen (FCoE) und bei SAN Erweiterung auch auf iSCSI Geräte zurückgreifen kannst - und wenn Ihr viel mit VMWare arbeitet - sind die Geräte richtig nett - die lassen sich ins vCenter einbinden Mit der Technik kannst auch solche lustigen Sachen bauen:
(mal übertrieben dargestellt)
und auf allen Links ist volle Bandbreite verfügbar und sind aktiv und das ganze lässt sich als ein Gerät managen - ohne das du auch nur eine STP Instanz konfigurieren musst