Distribution Layer sinnvoll?

[Zaubermausy]

Hallo Zusammen,

ich stecke momentan in einem sehr umfangreichen Projekt.

Wir werden unsere komplette IT-Netzwerkinfrastruktur neu konzeptionieren.

Der HW-Hersteller ist ausgesucht (CISCO) und die Hardwaretypen ebenfalls.

Jetzt geht es noch um die Begründung eines Distribution-Layers zw. Access-Switches und Core-Switches.

An den einzelnen Standorten arbeiten zw. 200 und 700 Mitarbeiter + Drucker + am NW angeschlossene Produktionsmaschinen, zukünftige Telefonie ü. NW (IP).

Um die Ausfallsicherheit zu minimieren, würde ich gerne einen Distribution-Layer an allen Standorten (klein und groß) einbauen. So könnten bei einem Ausfall/einer Störung wenigstens einzelne Bereiche, sowie WAN, DMZ und Server ohne Beeinträchtigungen weiterarbeiten.

Leider kostet dieser Layer Geld, weshalb ich gute Gründe zur Genehmigung benötige.

Könnt ihr mir da unter die Arme greifen?

Danke schon mal!

[AnDi_P]

Hallo,

also zum einen ist, wie du ja schon gesagt hattest, die Ausfallsicherheit des Netzes ein wichtiger Grund. Vielleicht sollte man mal eine kleine Kostenrechnung für ein mögliches Ausfallszenario anfertigen anfertigen, oder so? Ich meine, wenn Produktionsmaschinen ausfallen, wird das mit Sicherheit einiges an Kosten nach sich ziehen.

[dgr243]

Bei der angestrebten Größe halte ich einen Distribution Layer für nicht allzu sinnvoll und würde lieber in vollredundante Anbindung des Access Layer an einen vollredundanten Core investieren.

Distribution sehe ich eher bei MAN, wo der Core in einem zentralen Rechenzentrum steht und die Einzelstandorte vom Distribution Layer an den Core gebunden werden und sich dann in den Access Layer verzweigen.

Ist allerdings ohne genaue Kenntnis der Anforderungen (physikalisch, Performance, Bandbreiten und Paketmengen sowie eingesetzter Features) seeeeeehr schwer genau zu beurteilen. In einem Roaming VLAN Szenario mit 802.1x ist ein zusätzlicher Distribution Layer zum Beispiel sehr praktisch um "lokale" Authentifizierungen vornehmen zu können, wenn die Anbindung ans Core wegfällt. In einem single Standort Szenario finde ich auch nach wie vor -auch wenn das Ciscos Designphilosophie etwas zuwider läuft- recht interessant Services innerhalb des Distrition Layer anzubinden und den Core wirklich nur noch als reines High Speed Switching Backbone zu nutzen.

[Eleu]

Bei der angestrebten Größe halte ich einen Distribution Layer für nicht allzu sinnvoll und würde lieber in vollredundante Anbindung des Access Layer an einen vollredundanten Core investieren.

Hallo,

wie sähe eine vollredundante Anbindung der Access Layer Switche an einen vollredundanten Core in der Praxis aus ?

Würden dann zwei Core Switche einen LWL - Ring bilden ?

An diesem LWL Ring dann alle Etagenverteiler mit den Access Switchen ?

Wenn dann z.B. der LWL-Ring unterbrochen wird, übernimmt dann der redundante Core den Backbone ?

Wie muss ich mir das vorstellen ?

Gruß

Eleu

[DocInfra]

Die Cores haben eine redundante Verbindung zwischen sich. Jeder Access Layer Switch hat eine Verbindung zu jedem Coreswitch. Fällt ein Core aus, existiert nicht die redundante Verbindung zum zweiten Coreswitch. Wenn du einen Distribution Layer hast, dann erledigst du da das Routing. Im Core wird nur auf Layer-2 gearbeitet.

[dgr243]

wie sähe eine vollredundante Anbindung der Access Layer Switche an einen vollredundanten Core in der Praxis aus ?

Coreswitches untereinander mindestens mit zwei unabhängigen physikalischen Links verbinden. Steigerung wäre dann die Verwendung zweier Etherchannels mit je mindestens 2 Links.

Die access Layer Switches hängen dann mit je einem phy. Link an einem Core. Auch hier wieder die Steigerungsmöglichkeit den phys. Link durch einen Etherchannel mit mindestens 2 phy. Links zu ersetzen.

Wenn du einen Distribution Layer hast, dann erledigst du da das Routing. Im Core wird nur auf Layer-2 gearbeitet.

Nein.. jedenfalls nicht zwingend. Je nach Anforderung und vorhandenen Datenströmen kann es durchaus auch Sinn machen, das Routing (bzw. Multilayer Switching) doch erst im Core zu machen.

Man darf an der Stelle aber immer nicht vergessen, dass das alles Designphilosophien eines einzigen Herstellers sind. Da stehen nicht nur technische Begründungen, sondern eben auch wirtschaftliche dahinter. Argumente zu finden, warum ein zusätzlicher Distribution Layer eingesetzt werden soll, steigert natürlich auch den Absatz. Darf man an der Stelle nicht vergessen. HP fährt in seinen Procurve Switching Guides eine ähnliche Linie, zeigt aber auch genügend Abweichungen.

Persönlich halte ich zum Einstieg die Infos aus dem Cisco BCMSN Kurs/Buch für durchaus sinnvoll, trotzdem sollte man nicht vergessen, dass die strikte Umsetzung einer Designphilosophie zwar technisch eindrucksvoll sein mag, aber eben nicht unbedingt zu den eigenen Anforderungen UND zukünftigen Anforderungen passt

[Eleu]

Coreswitches untereinander mindestens mit zwei unabhängigen physikalischen Links verbinden. Steigerung wäre dann die Verwendung zweier Etherchannels mit je mindestens 2 Links.

Die access Layer Switches hängen dann mit je einem phy. Link an einem Core. Auch hier wieder die Steigerungsmöglichkeit den phys. Link durch einen Etherchannel mit mindestens 2 phy. Links zu ersetzen.

Warum gibt es dann keinen Loop ?

Oder funktioniert das dann ungefähr genauso wie das Spanning Tree Protocol ?

(Vorausgesetzt die Core Switche arbeiten nur auf Layer 2)

Müssen die Access Switche speziell dafür ausgelegt sein ?

Bearbeitet 4. Mai 2011 von Eleu

[DocInfra]

Nein.. jedenfalls nicht zwingend. Je nach Anforderung und vorhandenen Datenströmen kann es durchaus auch Sinn machen, das Routing (bzw. Multilayer Switching) doch erst im Core zu machen.

Absolut korrekt. Klassischerweise... oder eben bei Cisco, wird das so gemacht. Erfahrungsgemäß sind Abweichungen aber die Regel.

HP fährt in seinen Procurve Switching Guides eine ähnliche Linie, zeigt aber auch genügend Abweichungen.

HP positioniert seine Switches aber auch etwas anders als Cisco. HP agiert da weniger mit Layern, als viel mehr mit Blocks.

Warum gibt es dann keinen Loop ?

Oder funktioniert das dann ungefähr genauso wie das Spanning Tree Protocol ?

(Vorausgesetzt die Core Switche arbeiten nur auf Layer 2)

STP nimmt heute keiner mehr. RSTP, besser MSTP. Oder im Core gar kein xSTP sondern Trennung über VLANs und Routing. Dann hab ich keine Schleifen, sondern halt redundante Wege die mein Routingprotokoll managed.

Müssen die Access Switche speziell dafür ausgelegt sein ?

Nö. xSTP und Trunking/ Ether-Channel sollten sie können. Standard halt.

[dgr243]

HP positioniert seine Switches aber auch etwas anders als Cisco. HP agiert da weniger mit Layern, als viel mehr mit Blocks.

Was im wesentlichen aber nur eine Benennung ist Der grundlegende Designansatz bleibt sehr ähnlich. Cisco geht etwas mehr auf Routing (bzw. L3 Switching) und HP ist etws L2 lastiger. Die Unterschiede sind aber marginal. Richtig spannend wirds dann in den Details wie Routingprotokolle und co.

[Crash2001]

Eine Alternative die mir noch einfallen würde, und die wir auch hier fahren, ist ein VSS (Virtual Switching System)-Core unter Verwendung von Cisco 6500er Switchen, an die die Access-Switche dann direkt angebunden werden.

Plump ausgedrückt sind das dann zwei Switche, die sich wie ein Switch darstellen und konfigurieren lassen, und wo man MECs (Multi Chassis Ether Channel) nutzen kann, was den Vorteil hat, das die Bandbreite für die Anbindung prinzipiell komplett genutzt werden kann (nicht wie bei z.B. RSTP, dass immer nur ein Link aktiv ist) und bei Ausfall eines Chassis nur die Hälfte der Bandbreite wegfällt und ansonsten alles weiter funktioniert (redundante Anbindungen an alles, vorausgesetzt).

Beispiel siehe hier.

Bearbeitet 10. Mai 2011 von Crash2001

[DocInfra]

Keine Frage. HP verteilt seine "Layer" halt anders. Wo siehst du denn die großen Unterschiede bei HP in Sachen Routing? Gerne per PN, ist hier wohl OT.

[Eleu]

Eine Alternative die mir noch einfallen würde, und die wir auch hier fahren, ist ein VSS (Virtual Switching System)-Core unter Verwendung von Cisco 6500er Switchen, an die die Access-Switche dann direkt angebunden werden.

Plump ausgedrückt sind das dann zwei Switche, die sich wie ein Switch darstellen und konfigurieren lassen, und wo man MECs (Multi Chassis Ether Channel) nutzen kann, was den Vorteil hat, das die Bandbreite für die Anbindung prinzipiell komplett genutzt werden kann (nicht wie bei z.B. RSTP, dass immer nur ein Link aktiv ist) und bei Ausfall eines Chassis nur die Hälfte der Bandbreite wegfällt und ansonsten alles weiter funktioniert (redundante Anbindungen an alles, vorausgesetzt).

Beispiel siehe hier.

Ich habe ein bisschen Probleme mir das in der Praxis vorzustellen.

Bei einer strukturieren Verkabelung in einem Gebäude mit mehreren Etagenverteilern (In den Etagenverteilern dann Access Switche) wird von jedem Etagenverteilern jeweils eine LWL - Leitungen in den Core Bereich gezogen.

Dort sind die ankommenden LWL Leitungen z.B. an zwei Core Switchen angeschlossen.

Die beiden Core Switche sind über eine oder zwei LWL - Leitungen miteinander verbunden.

Die herkömmliche Redundanz dann z.B. über RSTP

Wenn ich nun VSS verwenden würde und ein Core Switch fällt nun aus, würde doch trotzdem die Verbindung zu einigen Access Switchen wegfallen, da ja die Etagenverteiler die am defekten Core Switch angeschlossen sind nicht mehr vom anderen Core Switch erreicht werden können.

Wie kann ich denn erreichen das alle Access Switche an allen Core Switchen verkabelt sind ?

[Crash2001]

Damit genau das was du erwähnst nicht passiert, macht man da Multi Chassis Etherchannel (also je mindestens eine Verbindungen von beiden Chassis zum jeweiligen Switch, die dann als Etherchannel zusammengefasst werden).

Bei VSS ist immer nur eine Supervisor-Engine aktiv und die andere auf "Standbye", wobei sie aber die Routingtabelle bereits gefüllt hat und so jederzeit übernehmen kann, wenn die andere ausfallen sollte.

So geht dann z.B. von Port 1/2/1 (Chassis / Modus / Port) und von Port 2/2/1 jeweils eine LWL zum Access-Switch. Dazu richtet man sowohl auf dem Access-Switch, als auch auf dem VSS-Core-Switch einen Etherchannel ein.

Ist vom Prinzip her auf jeden Fall eine nette Sache. Der begrenzende Faktor dabei ist jedoch die Verbindung zwischen den beiden Chassis. (Standardmässig mit je einer SUP720 afaik max 20GBit/s.)

[Eleu]

So geht dann z.B. von Port 1/2/1 (Chassis / Modus / Port) und von Port 2/2/1 jeweils eine LWL zum Access-Switch. Dazu richtet man sowohl auf dem Access-Switch, als auch auf dem VSS-Core-Switch einen Etherchannel ein.

Wenn ich dich richtig verstehe, sind dann am Access Switch 4 einzelne LWL Leitungen angeschlossen

LWL Port 1 (RX und TX) vom Access Switch 1 verbunden mit Core Switch 1

LWL Port 2 (RX und TX) vom Access Switch 1 verbunden mit Core Switch 2

Damit genau das was du erwähnst nicht passiert, macht man da Multi Chassis Etherchannel (also je mindestens eine Verbindungen von beiden Chassis zum jeweiligen Switch, die dann als Etherchannel zusammengefasst werden)..)

Die beiden Core Switche sitzen dann in einem Baugruppenträger (oder so ähnlich) der gewährleistet das alle Core Switch Ports untereinander gebrückt sind.

Richtig ?

[Crash2001]

Access Switch 1 ist mit jeweils einer LWL an jeden der beiden VSS-Cores angeschlossen - genau.

Die müssen nicht nebeneinander / untereinander sitzen, sondern da kann halt so eine große Strecke dazwischen sein, wie die LWL hergeben. Hier sind z.B. 2 Stockwerke dazwischen.

[Eleu]

Die müssen nicht nebeneinander / untereinander sitzen, sondern da kann halt so eine große Strecke dazwischen sein, wie die LWL hergeben. Hier sind z.B. 2 Stockwerke dazwischen.

Aber dann muss man ja zu jedem Etagenverteiler ein weiteres neues LWL Kabel verlegen, um den

zweiten Core Switch im anderen Stockwerk mit anzubinden.

Ich hatte gedacht, dass man noch freie LWL Leitungen des bereits verlegten LWL-Kabels zum Etagenverteiler für den zweiten Anschluss am Access Switch nutzen kann.

Dann wären allerdings beide Core Switche in einem Raum.

Oder man setzt beim Core Switch 1 einen LWL-Verteiler, der alle Access Switche mit dem Core Switch 2 zweiten Stock verbindet ?

Wie habt ihr das gemacht ?

[DocInfra]

Ja wo liegt denn das Problem? Wer zieht denn zu einem Etagenverteiler nur zwei Fasern? Also nach Möglichkeit sollte man min. 4, besser 8 oder gar 12 Fasern ziehen. Oder ziwe Mal 8 Fasern über getrennte Wege.

[Crash2001]

Kommt ganz drauf an, wie die bereits vorhandenen LWLs so liegen.

Hier war es auch vorher schon so ausgebaut, dass je eine Leitung zum einen Core und die andere Leitung zum anderen Core (anderes Stockwerk) ging. Von daher war das kein Problem.

Man KANN sie natürlich auch direkt nebeneinander aufstellen. Nur überlege dir mal, wann ein Chassis nicht mehr geht - meist nur dann, wenn es ungewöhnlichen Bedingungen ausgesetzt wird (Brand/hohe Temperaturen, Flüssigkeit / Sprinkleranlage, Überspannung / Blitz, Unterspannung / Stromausfall). Wenn sie direkt nebeneinander stehen, ist die Wahrscheinlichkeit doch recht hoch, dass es dann beide Chassis trifft. Wenn man also die Möglichkeit hat, die beiden Switche räumlich zu separieren, dann sollte man das auch machen, wenn es nicht zu viel Aufwand bedeutet.

Und auch die LWL-Führung könnte ja mal kaputt gehen, durch Sabotage / Bagger o.ä. ... Da ist es dann von Vorteil, wenn die zweite LWL einen anderen Weg geht.

Wie man sieht hat also beides seine Vorteile, aber genauso auch seine Nachteile. z.B. etwas ist sicherer mit redundanter und komplett unabhängiger Anbindung, dafür ist der Mehraufwand aber auch nicht zu vernachlässigen.

Etwas ist einfacher so und so zu machen, dafür hat man dann aber keine Redundanz auf der Strecke...

Ja nur eine LWL zum Etagenverteiler ist evtl was unterdimensioniert. Wir haben hier keine Etagenverteiler, da alles per Glasfaser angebunden ist und somit die Verteiler alle im RZ konzentriert sind. Zu allen wichtigen Stellen im Haus liegen aber direkt komplette Stammkabel mit x LWLs.

[dgr243]

Eine Alternative die mir noch einfallen würde, und die wir auch hier fahren, ist ein VSS (Virtual Switching System)-Core unter Verwendung von Cisco 6500er Switchen, an die die Access-Switche dann direkt angebunden werden.

VSS Core ist auch nix anderes als ein normales Collapsed Core Design unter Integration des Distribution Layers ins Core.

Ist also nix neues an dieser Stelle, sondern lediglich die konkretere technische Ausgestalltung

@blah: Ui.. das Thema Routing und HP wird aber dann zu einer Dissertation Ich glaub das lassen wir lieber

[DocInfra]

@blah: Ui.. das Thema Routing und HP wird aber dann zu einer Dissertation Ich glaub das lassen wir lieber

Solange du nirgendwo abschreibst...

[Crash2001]

VSS Core ist auch nix anderes als ein normales Collapsed Core Design unter Integration des Distribution Layers ins Core.

Ist also nix neues an dieser Stelle, sondern lediglich die konkretere technische Ausgestalltung [...]

Nunja, MECs sind aber bei einem "normalen" Collapsed Core nicht möglich. Von daher ist es definitiv nicht das gleiche. Auch weil zwei Switche zwar einerseits autark sind, andererseits jedoch zusammenarbeiten. Das einfach so als "normales collapsed Core Design" abzutun ist wohl ein wenig überheblich in meinen Augen.

[Eleu]

Bei VSS ist immer nur eine Supervisor-Engine aktiv und die andere auf "Standbye", wobei sie aber die Routingtabelle bereits gefüllt hat und so jederzeit übernehmen kann, wenn die andere ausfallen sollte.

So geht dann z.B. von Port 1/2/1 (Chassis / Modus / Port) und von Port 2/2/1 jeweils eine LWL zum Access-Switch. Dazu richtet man sowohl auf dem Access-Switch, als auch auf dem VSS-Core-Switch einen Etherchannel ein.

Ist vom Prinzip her auf jeden Fall eine nette Sache. Der begrenzende Faktor dabei ist jedoch die Verbindung zwischen den beiden Chassis. (Standardmässig mit je einer SUP720 afaik max 20GBit/s.)

Mal ne blöde Frage.

Wäre es möglich, einen einzelnen Server (host) in einer solchen Umgebung mit je einer NIC an beide Core Switche anzuschließen ?

Der Server verwendet dann für die Kommunikation nur den angeschlossenen aktiven Coreswitch.

Fällt ein Core Switch aus, schaltet der Server direkt um auf den Core Switch der vorher stand by war.

Dann hätte man die Redundanz auch für einzelne Server.

Das standard NIC Teaming wäre das ja nicht, weil ja immer nur ein LAN Adapter aktiv sein dürfte.?

Geht so was ?

Gibt es hierfür fertige Software von Cisco ?

In der Regel stehen die Server ja zusammen mit den Core Switchen im RZ, oder ?

So etwas würde sich m.E. anbieten.

[Crash2001]

Man kann sowohl bei einem VSS-Core, als auch bei einem "normalen" Core genauso STP (RSTP/MSTP, ...) nutzen, genauso wie auch Etherchannel / Trunking. Das mit dem STP scheint ja das zu sein, was du meinst, oder?

Wenn mehrere Wege vorhanden sind, werden alle außer einem deaktiviert per STP und sobald dieser wegfällt, wird ein anderer aktiv. Dafür braucht man dann auch keine zusätzliche Software.

Das ist dann das gleiche, wie wenn du nur einen Switch hättest und dort 2 Leitungen zu einem Server anstöpseln würdest.

[Eleu]

Das mit dem STP scheint ja das zu sein, was du meinst, oder?

Wenn mehrere Wege vorhanden sind, werden alle außer einem deaktiviert per STP und sobald dieser wegfällt, wird ein anderer aktiv. Dafür braucht man dann auch keine zusätzliche Software.

Ich bin nicht sicher, ob das dann schon ausreicht.

Oder ich verstehe noch nicht wie es gemeint ist.

Normalerweise wäre der Server mit nur einer NIC an einem Access Switch angeschlossen.

Der Access Switch ist mit 2 LWL- Links jeweils am Core Switch 1 und am Core Switch 2 angeschlossen.

Der Core Bereich wäre mit VSS somit redundant ausgelegt.

Der Server aber dann noch nicht.

Fällt der Access Switch aus, ist für den Server Feierabend.

Bei meinem Beispiel, müssten die zwei NIC`s im Server die gleichen Adresseinstellungen haben (Virtuell nur eine IP für beide NIC`s)

Physikalisch wäre dann NIC 1 am Core Switch 1 angeschlossen und NIC 2 am Core Switch 2.

Wenn der Core Switch 1 der aktive ist, darf nur die NIC 1 am Server aktiv sein.

Wenn der Core Switch 2 aufgrund einer Störung am Core Switch 1 aktiv wird, muss die NIC 1am Server deaktiviert werden und die NIC 2 wird eingeschaltet, damit der Server den

redundanten Core Switch verwenden kann.

STP funktioniert m.Wissens nur bei Switchen innerhalb eines Subnetzes.

Ein Switch wird zur Rootbridge und ermittelt mit den anderen Switchen über BPDU Pakete den günstigsten Pfad (Nur auf Layer 2).

Redundante Pfade werden von den beteiligten Switchen geblockt.

Der Pfad mit den geringsten Kosten gewinnt.

Ein Server mit zwei NIC´s versteht doch die BPDU Pakete nicht ?

Er verhält sich eher wie ein Router, da beide NIC´s eigene MAC Adressen haben.

[DocInfra]

Netzwerkkartenredundanz/ Teaming ist ja nun kein Hexenwerk. Auch bei zwei Switches nicht. So ziemlich jeder Hersteller bietet dafür eine passende Software an. Und ob du dann Active/ Standby oder ein Load-Balancing (Send/ Receive Load Balancing o.ä.) bleibt dir überlassen.