9
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
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: 201418
Url: https://administrator.de/forum/vorschlag-fuer-switch-redundanz-am-hauptverteiler-201418.html
Ausgedruckt am: 23.12.2024 um 08:12 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ß
Moin,
ein Ring aus 3 Switchen soll später noch aufgebaut werden (auf dem Bild zwischen Hauptverteiler und Wolke), welche Switche dazu zum Einsatz kommen ist noch nicht ganz klar, ich hatte an die 7000er Serie gedacht, muss aber die Funktionen noch mal genau prüfen, vielleicht wirds auch sowas wie die 5400zl oder sonst was (z. B. 8000er Serie oder was kleines aus der 12000er Serie).
Ok, welche Switche es sonst noch gibt: 4000M (fliegen gerade raus), 2512, 2524, 4108gl, 1810g/1910g (Büroswitche), ich glaube das war das wesentliche. Die Verbindung zum Hauptverteiler erfolgt aber entweder durch die 4204vl oder 4108gl, die anderen Modelle sind höchstens noch dahintergeschaltet.
Ich hatte schon überlegt zwischen dem 1. Switch der Unterverteilung in Richtung Hauptverteiler zwei Leitungen zu verwenden (je eine an die beiden Switche).
Gruß
ein Ring aus 3 Switchen soll später noch aufgebaut werden (auf dem Bild zwischen Hauptverteiler und Wolke), welche Switche dazu zum Einsatz kommen ist noch nicht ganz klar, ich hatte an die 7000er Serie gedacht, muss aber die Funktionen noch mal genau prüfen, vielleicht wirds auch sowas wie die 5400zl oder sonst was (z. B. 8000er Serie oder was kleines aus der 12000er Serie).
Ok, welche Switche es sonst noch gibt: 4000M (fliegen gerade raus), 2512, 2524, 4108gl, 1810g/1910g (Büroswitche), ich glaube das war das wesentliche. Die Verbindung zum Hauptverteiler erfolgt aber entweder durch die 4204vl oder 4108gl, die anderen Modelle sind höchstens noch dahintergeschaltet.
Ich hatte schon überlegt zwischen dem 1. Switch der Unterverteilung in Richtung Hauptverteiler zwei Leitungen zu verwenden (je eine an die beiden Switche).
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
Hallo,
ein paar kurze Infos:
- Netzwerk ist bis auf einige kleine Außenstellen auf mehrere, größere Gebäude verteilt
- ca. 1500 Leute
- Protokolle: Bisher wenig, soll sich aber ändern. Als Routing-Protokoll ist zurzeit EIGRP im Einsatz, muss sich wegen Umstellung auf HP auch ändern. Zusätzlich ist in Planung mehr VLANs + GVRP einzusetzen. Spanning-Tree evtl. später, wenn erforderlich (da bisher im Switch-Bereich keine Redundanz auch nicht im Einsatz).
- Ja, kann man sehen wie man will, zwischen Wolke und Hauptverteiler bzw. in der Wolke schließen sich noch 2 Router an, dann der Firewall/DMZ-Bereich und schließlich das Internet. Die Router sollen halt noch weg und gegen L3-Switche getauscht werden, die im Ring geschaltet sind. An den Ring kommt dann die Firewall und auch noch weitere Zweige (wie oben als Unterverteilung dargestellt. Genau genommen müsste man den Hauptverteiler auch eher als Gebäudeverteiler kennzeichnen, aber so detailliert wollte ich eigentlich nicht darauf eingehen, daher habe ich das stark vereinfacht mit der Wolke. Das dargestellte Gebilde ist also nur ein Bruchstück.
ein paar kurze Infos:
- Netzwerk ist bis auf einige kleine Außenstellen auf mehrere, größere Gebäude verteilt
- ca. 1500 Leute
- Protokolle: Bisher wenig, soll sich aber ändern. Als Routing-Protokoll ist zurzeit EIGRP im Einsatz, muss sich wegen Umstellung auf HP auch ändern. Zusätzlich ist in Planung mehr VLANs + GVRP einzusetzen. Spanning-Tree evtl. später, wenn erforderlich (da bisher im Switch-Bereich keine Redundanz auch nicht im Einsatz).
- Ja, kann man sehen wie man will, zwischen Wolke und Hauptverteiler bzw. in der Wolke schließen sich noch 2 Router an, dann der Firewall/DMZ-Bereich und schließlich das Internet. Die Router sollen halt noch weg und gegen L3-Switche getauscht werden, die im Ring geschaltet sind. An den Ring kommt dann die Firewall und auch noch weitere Zweige (wie oben als Unterverteilung dargestellt. Genau genommen müsste man den Hauptverteiler auch eher als Gebäudeverteiler kennzeichnen, aber so detailliert wollte ich eigentlich nicht darauf eingehen, daher habe ich das stark vereinfacht mit der Wolke. Das dargestellte Gebilde ist also nur ein Bruchstück.
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.
Zitat von @clSchak:
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
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
- 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 eineZuleitung 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,
ein Ring wird noch ab ca. April aufgebaut, aber dazu muss erst noch ein Kilometer LWL verlegt werden, bloß darauf bezog sich meine ursprüngliche Frage eigentlich gar nicht. Der Internetzugang ist bereits redundant durch Juniper Firewalls (2 aktiv, 2 passiv).
Um dann die Fragen noch zu beantworten:
- Ich hatte ja bereits geschrieben, dass zurzeit fürs Routing EIGRP eingesetzt wird.
- VOIP kommt frühestens in 3 Jahren.
- VLANs: Bisher wenige, werden aber dieses Jahr deutlich mehr und daher wird dann GVRP eingesetzt.
- 802.1X: Bisher nur im WLAN-Bereich, Ausbau auf verkabelte Verbindungen bis Jahresende
- Multimedia: Eher wenig, muss daher zurzeit nicht extra berücksichtigt werden.
- SAN: Auf 3 Standorte verteilt. Zum Einsatz kommen Brocade-Switche mit FC.
- Server: Sind auch an (separaten) HP-Kisten.
Die Auswirkungen eines Loops musste ich auch schon mit erleben, daher werde ich mir noch das von den HPs unterstützte MSTP (802.1s) ansehen. Mir wäre ehrlich gesagt für die Switche/Router Cisco am liebsten, da ich da auch zertifiziert bin, aber das habe ich halt nicht zu entscheiden. Es wird halt versucht in dem Bereich zu sparen und da irgendwann mal angefangen wurde HP einzusetzen (STP, Redundanz usw. war da auch noch kein Thema) wird das jetzt auch so weitergemacht, um zumindest in dem Bereich Geräte vom selben Hersteller zu haben.
Zitat von @108012:
Hallo nochmal,
> - 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.
Hallo nochmal,
> - 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.
Ganz so schlimm, wie ihr vielleicht denkt sieht die Verkabelung ja gar nicht aus, ich möchte daher noch mal betonen, dass auf dem Bild in meinem Start-Post nur ein kleiner Zweig des Netzwerks dargestellt ist. Weitestgehend ist das Netz auch gemäß der EN50173 aufgebaut, auch wenn es hier und da schon mal ein paar Abweichungen gibt.
Außerdem sind wir kein Rechenzentrum, wenn dann mal ein Switch in einem Bereich ausfällt, der nicht redundant vorhanden ist, da man sich die Kosten sparen wollte, dann ist das halt so und wird auch geduldet. Locker gesagt: Dann haben halt 50-100 Leute mal für ne Stunde keinen Netzwerkzugang, bis jemand mit dem Reserve-Switch vor Ort war und diesen getauscht hat. Da kann man erstmal nichts machen, dafür liefen die HP-Kisten, so wie ich von Kollegen gehört habe, in den letzten Jahren einfach zu zuverlässig.
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: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
