Switche redundant verbinden
Hallo,
wir haben hier mehrere Switche redundant verbunden.
Auf allen Switchen ist Spanning Tree aktiviert, ein Switch ist als Root-Bridge aktiviert und ein zweiter als Second Root-Bridge.
Alle Portpaare auf den Etagenswitchen, die von unseren Backbone-Switchen versorgt werden sind als Trunk konfiguriert.
Wir haben leider hier unregelmäßige Netzwerkaussetzer so ca. 600-900ms, was uns alle Laufwerke wegpustet. Danach baut sich alles wieder auf und ist wieder schön bis zum nächsten Abenteuer.
Meine Frage wäre jetzt, müssen auf den Backbone-Switchen an den Portpaaren, die zu den Etagenswitchen führen auch Trunks konfiguriert werden?
Kann mir jemand helfen?
Gruß Hucklebuck
wir haben hier mehrere Switche redundant verbunden.
Auf allen Switchen ist Spanning Tree aktiviert, ein Switch ist als Root-Bridge aktiviert und ein zweiter als Second Root-Bridge.
Alle Portpaare auf den Etagenswitchen, die von unseren Backbone-Switchen versorgt werden sind als Trunk konfiguriert.
Wir haben leider hier unregelmäßige Netzwerkaussetzer so ca. 600-900ms, was uns alle Laufwerke wegpustet. Danach baut sich alles wieder auf und ist wieder schön bis zum nächsten Abenteuer.
Meine Frage wäre jetzt, müssen auf den Backbone-Switchen an den Portpaaren, die zu den Etagenswitchen führen auch Trunks konfiguriert werden?
Kann mir jemand helfen?
Gruß Hucklebuck
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 378205
Url: https://administrator.de/forum/switche-redundant-verbinden-378205.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
26 Kommentare
Neuester Kommentar
Die Antwort zu dem Thema steht ja schön in den Logs
Dann begebe dich mal auf die suche nach den betreffenden Ports wenn kein Monitoring verfügbar ist.
\\ Welcher Switches ist denn das? Wenn man den Logs traut hat der ja bei gefühlt allen Ports was zu meckern.
Soll das der Core sein???
Sicher das die Trunk Konfig richtig ist?
Das scheint nicht der Fall zu sein und in dem Netz sind haufenweise loops.
Dann begebe dich mal auf die suche nach den betreffenden Ports wenn kein Monitoring verfügbar ist.
\\ Welcher Switches ist denn das? Wenn man den Logs traut hat der ja bei gefühlt allen Ports was zu meckern.
Soll das der Core sein???
Sicher das die Trunk Konfig richtig ist?
Das scheint nicht der Fall zu sein und in dem Netz sind haufenweise loops.
Zitat von @Hucklebuck:
Das ist einer der beiden Backbones.
Da ist gar kein Trunk konfiguriert. Das war ja meine Frage, ob auf den Backbones auch Trunk konfiguriert sein muss?
Zitat von @Spirit-of-Eli:
Die Antwort zu dem Thema steht ja schön in den Logs
Dann begebe dich mal auf die suche nach den betreffenden Ports wenn kein Monitoring verfügbar ist.
\\ Welcher Switches ist denn das? Wenn man den Logs traut hat der ja bei gefühlt allen Ports was zu meckern.
Soll das der Core sein???
Sicher das die Trunk Konfig richtig ist?
Das scheint nicht der Fall zu sein und in dem Netz sind haufenweise loops.
Die Antwort zu dem Thema steht ja schön in den Logs
Dann begebe dich mal auf die suche nach den betreffenden Ports wenn kein Monitoring verfügbar ist.
\\ Welcher Switches ist denn das? Wenn man den Logs traut hat der ja bei gefühlt allen Ports was zu meckern.
Soll das der Core sein???
Sicher das die Trunk Konfig richtig ist?
Das scheint nicht der Fall zu sein und in dem Netz sind haufenweise loops.
Das ist einer der beiden Backbones.
Da ist gar kein Trunk konfiguriert. Das war ja meine Frage, ob auf den Backbones auch Trunk konfiguriert sein muss?
Über die Spanningtree Geschichte bindet man Grundsätzlich kein Backbone an. Wo das hier gerade ja auch anscheind nicht funktioniert und über all Loops drauf sind welche nicht geblockt werden. // wie ist über haupt die Hardware Auslastung von dem Gerät? Der Switche müsste ja beinahe in die Knie gehen.
Also ja, die entsprechenden Links Bündeln wenn es um Ausfallsicherheit und Bandbreiten Erhöhung geht.
Ansonsten nur einen Link zu den Unterverteilungen nutzen.
Edit: ich habe das Log nur falsch interpretiert glaub ich. Spanning Tree greift wahrscheinlich aber nichts desto Trost sollte man das Thema am besten über Trunks lösen, was im Prinzip nichts anderes als nen Link Agg meint soweit ich weiß.
Ich habe allerdings nicht so oft nen Aruba Switch in den Händen.
Grundsätzlich ist dein STP Design richtig.
Du kannst dort Trunks konfigurieren, das ist aber vollkommen unabhängig vom Spanning Tree selber. Der STP Prozess "sieht" einen Trunk als einzelne Leitung mit besserer Cost.
Ein klassisches Design sähe so aus:
Normal ist in so einem Design keinerlei Spanning Tree Topology Changes (TC) zu sehen wenn es stabil rennt.
Passiert es dennoch kann es daran liegen das du ggf. ein Mischmasch von verschiedenen STP Protokolle fährst wie STP, RST, PVSTP, PVSTP+ oder auch Single Span oder Per VLAN Span Umgebungen oder sowas.
Das passiert sehr häufig in Umgebungen mit gemischten Herstellern die im Default unterschiedliche STP Verfahren nutzen.
Dazu sagst du leider gar nichts so das wir hier nur raten können
Auch Pauschalaussagen wie "unregelmäßige Netzwerkaussetzer" sind eher laienhaft. Als Netzwerker sieht man mindestens ja mal in das Log der Switches ob es da irgendwelche Error Messages gibt !
Aber auch dazu von dir keinerlei Aussagen
Sofern überhaupt die Switches die wirkliche Ursache sind ??!!
Sehr wahrscheinlich auch das der Server selber ein Problem hat sofern er z.B. über einen falsch konfigurierten LAG angebunden ist und die NICs Aussetzer haben usw.
Fehlerhafte Kabel und Optiken jetzt mal gar nicht genannt...
Was also erwartest du von uns als zielführende Hilfe bei solch oberflächlichen Infos ?!
Etwas mehr wäre sicherlich sehr hilfreich hier ansonsten bleibt uns ja auch nur die Glaskugel.
Generell vermeidet man heutzutage in modernen Netz Designs mit moderner Hardware jeglichen Spanning Tree wenn möglich !
Basierend auf die obige Zeichnung nutzt man dann im Core einen Full Stack auch als sog. horizontal Stack über mehrere Räume und bindet die Access Switch dann über 2 Stack Member dieses Core Stacks als LACP LAGs an.
Damit ist man dann komplett STP frei.
Alternativ nutzt man im Core Fabric Verfahren wie TRILL oder SPB und bindet dann am Edge die Access Switches auch wieder mit LACP LAGs an.
Beides sind heutzutage aktuelle Designs für mittlere und große Netze.
Du kannst dort Trunks konfigurieren, das ist aber vollkommen unabhängig vom Spanning Tree selber. Der STP Prozess "sieht" einen Trunk als einzelne Leitung mit besserer Cost.
Ein klassisches Design sähe so aus:
Normal ist in so einem Design keinerlei Spanning Tree Topology Changes (TC) zu sehen wenn es stabil rennt.
Passiert es dennoch kann es daran liegen das du ggf. ein Mischmasch von verschiedenen STP Protokolle fährst wie STP, RST, PVSTP, PVSTP+ oder auch Single Span oder Per VLAN Span Umgebungen oder sowas.
Das passiert sehr häufig in Umgebungen mit gemischten Herstellern die im Default unterschiedliche STP Verfahren nutzen.
Dazu sagst du leider gar nichts so das wir hier nur raten können
Auch Pauschalaussagen wie "unregelmäßige Netzwerkaussetzer" sind eher laienhaft. Als Netzwerker sieht man mindestens ja mal in das Log der Switches ob es da irgendwelche Error Messages gibt !
Aber auch dazu von dir keinerlei Aussagen
Sofern überhaupt die Switches die wirkliche Ursache sind ??!!
Sehr wahrscheinlich auch das der Server selber ein Problem hat sofern er z.B. über einen falsch konfigurierten LAG angebunden ist und die NICs Aussetzer haben usw.
Fehlerhafte Kabel und Optiken jetzt mal gar nicht genannt...
Was also erwartest du von uns als zielführende Hilfe bei solch oberflächlichen Infos ?!
Etwas mehr wäre sicherlich sehr hilfreich hier ansonsten bleibt uns ja auch nur die Glaskugel.
Generell vermeidet man heutzutage in modernen Netz Designs mit moderner Hardware jeglichen Spanning Tree wenn möglich !
Basierend auf die obige Zeichnung nutzt man dann im Core einen Full Stack auch als sog. horizontal Stack über mehrere Räume und bindet die Access Switch dann über 2 Stack Member dieses Core Stacks als LACP LAGs an.
Damit ist man dann komplett STP frei.
Alternativ nutzt man im Core Fabric Verfahren wie TRILL oder SPB und bindet dann am Edge die Access Switches auch wieder mit LACP LAGs an.
Beides sind heutzutage aktuelle Designs für mittlere und große Netze.
Trotzdem liest man sich ja dann wenigstens mal die einfachsten Grundlagen zum Thema Spanning Tree an...aber egal.
Welches STP Protokoll hast du denn überhaupt aktiviert ?
Bedenke das Root und Backup Root Switches immer mit einer Priority modulo 4096 konfiguriert werden müssen. Hast du das so gemacht ?
Bisher war alles "Warning".
Wenn die STP bezogen sind, WIE lauten diese denn ?Welches STP Protokoll hast du denn überhaupt aktiviert ?
Bedenke das Root und Backup Root Switches immer mit einer Priority modulo 4096 konfiguriert werden müssen. Hast du das so gemacht ?
Das ist ein genereller Fehler ! Damit hast du ja inkonsistente STP Protokolle am werkeln quasi ein Dieselauto was du mit Benzin fährst.
Was erwartest du also ??
Das es da zu Problemen kommt liegt dann logischerweise auf der Hand.
Wenn dann solltest du entweder ALLES im MSTP Mode fahren oder alles im RSTP Mode aber niemals Mischbetrieb, da nicht kompatibel.
Die 0 ist großer Unsinn, denn die ist in der Bridge Priority Standardtisierung gar nicht definiert. Das solltest du dringenst ändern !
Die Core Switches sollten auch NIEMALS einen gleiche Bridge Priority haben, denn bei gleicher Prio kaspern die Switches dann wieder dynamisch nach ihrer Mac Adresse aus ! Genau DAS will man ja durch das statische Setzen der Prio verhindern !
Da hat also jemand ziemlich laienhaften Blödsinn gemacht bei der Konfig der wohl selber nicht wusste was er da tut.
Also deine To Dos sind:
So wird ein Schuh aus deiner vermurksten STP Konfig.
Beispiel für eine saubere MSTP Konfig zw. 2 Herstellern findest du hier:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)
Was erwartest du also ??
Das es da zu Problemen kommt liegt dann logischerweise auf der Hand.
Wenn dann solltest du entweder ALLES im MSTP Mode fahren oder alles im RSTP Mode aber niemals Mischbetrieb, da nicht kompatibel.
Die beiden Backbones haben eine Priority von 0
Ebenso tödlich. Bei den meisten Switches wird damit STP komplett deaktiviert.Die 0 ist großer Unsinn, denn die ist in der Bridge Priority Standardtisierung gar nicht definiert. Das solltest du dringenst ändern !
Die Core Switches sollten auch NIEMALS einen gleiche Bridge Priority haben, denn bei gleicher Prio kaspern die Switches dann wieder dynamisch nach ihrer Mac Adresse aus ! Genau DAS will man ja durch das statische Setzen der Prio verhindern !
Da hat also jemand ziemlich laienhaften Blödsinn gemacht bei der Konfig der wohl selber nicht wusste was er da tut.
Also deine To Dos sind:
- Alles entweder EINHEITLICH auf MSTP oder RSTP ziehen. MSTP hat den Vorteil, solltest du mit VLANs arbeiten, das man ein Load Balancing über redundante Uplinks machen kann. MSTP ist auch ein Per VLAN STP Verfahren und generell stabiler in einem VLAN Umfeld.
- Der Root Switch (es kann nur einen geben !) hat die globale Prio 4096 !
- Der Backup Root Switch hat dann die Prio 8192.
- Es reicht wenn die beiden Core Switches entsprechend der o.a Prios konfiguriert sind. Der Rest der (Access) Switches sollte immer seinen Default 32768 behalten. Dort muss man nix fummeln.
So wird ein Schuh aus deiner vermurksten STP Konfig.
Beispiel für eine saubere MSTP Konfig zw. 2 Herstellern findest du hier:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)
Zitat von @Hucklebuck:
Ich arbeite in einem Amt.
Wir haben hier an den meisten Tagen Bürgerverkehr.
Die Mitarbeiter finden's immer uncool wenn der Bürger vor ihnen sitzt und ihre Netzlaufwerke sind bei Manitu.
Ich meld' mich.
Ich arbeite in einem Amt.
Wir haben hier an den meisten Tagen Bürgerverkehr.
Die Mitarbeiter finden's immer uncool wenn der Bürger vor ihnen sitzt und ihre Netzlaufwerke sind bei Manitu.
Ich meld' mich.
Ich dachte die fliegen dir jetzt schon um die Ohren :/
Aus meiner Sicht muss erst das Netz stehen und dann setzt man Spanning Tree oben drauf.
Wo ich aber auch fast nur im Core Bereich Virtuelle Switch Konfiguration habe.
Ich arbeite in einem Amt.
Oha,....du Armer !Aus meiner Sicht muss erst das Netz stehen und dann setzt man Spanning Tree oben drauf.
Nein !Das ist falsch, denn wenn du mit redundanten Links bzw. einem redundanten Netz arbeitest,wie willst du dann ein Netz "zum stehen" bringen ohne Spanning Tree ?
Die redundanten Links loopen dann ja und bringen dein Netz sofort zum Kollabieren !
Auch sollte man schon beim Verkabeln einen Loop oder mehrere oder lokale Loops stecken ob aus Versehen oder nicht, hast du ja schon ein Problem.
Die STP Planung macht man also tunlichst vorweg.
Die Reihenfolge geht so:
- 1.) erst das Design,
- 2.) STP Protokoll auswählen,
- 3.) dann Root und Backup Root festlegen,
- 4.) Dann Netzwerk mit aktiviertem STP verkabeln und aktivieren.
Der TO muss jetzt in einem laufenden Netzwerk strategisch vorgehen.
Idelaerweise fängt er bei den beiden Root Switches an und arbeitet sich dann an den Edge vor.
Da MSTP und RSTP das gleiche STP Verfahren grundlegend nutzen kann dort nichts passieren.
Dennoch gilt die dringende Empfehlung das zu verkehrsarmen Zeiten mit wenig bis keinen aktiven Usern zu machen.
Wann machen Beamte Feierabend ??
Also nach 12 Uhr ist ne gute Zeit...
(Duck und wech...)
Dafür einen Trunk baut, muss der Trunk auf beiden Switchen angelegt werden?
Erstmal solltest du genau klären was due mit "Trunk" meinst, denn der Begriff ist leider doppeldeutig !!Cisco Sprech: Trunk = Tagged Uplink zw. Switches
Rest der Netzwerk Welt: Trunk = LACP LAG = Link Aggregation mehrerer Links zur Bandbreitenerhöhung
Wenn es ein Tagged Uplink zw. 2 Switches ist muss er doch logischerweise auf BEIDEN Seiten identisch sein !!
Die Switches schicken über das VLAN Tagging die VLAN Information mit. Das muss logischerweise auch der empfangene Switch verstehen !
Guckst du hier:
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
Groschen gefallen..??
Deinen Switches oben sind NICHT redundant angebunden !!
Du hast ne simple Kette gesteckt, die eher kontraproduktiv in einer sinnvollerweise sternförmig auszulegenden Design !
So sollte es immer aussehen:
Hier kannst du auch sehen das die Access Switch wirklich redundant an die beiden Root Switches (Core) angebunden sind !
Die beiden Uplinks sind dann die jeweiligen tagged Uplinks (Trunk)
Wenn bei dir der jeweilige Root Switch ausfällt ist das Netzwerk in beiden Häusern mausetot.
In puncto Ausfallsicherheit ist dein Design also dillettantischer Bastelkram...sorry. Wohl leider deiner Unwissenheit geschuldet.
Noch kannst du es besser machen
das war sogar eine externe Firma!
Oh oh...gruselig !Da solltest du aber besser gaaanz schnell den Anbieter wechseln. Das ist ne böse Bastelbude die sowas Übles verzapfen. Da kann nur wenig bis gar kein Netzwerk Know How vorhanden sein ! Sieht man schon daran das die Da HP reinverkauft haben...
So ein falsches Design stöpselt dir auch der Hausmeister zusammen ! (Nichts gegen den ehrenwerten Beruf des Hausmeisters natürlich !)
verbunden mit EINER LWL-Strippe von Haus zu Haus.
Ist es wirklich nur eine einzige Doppelader ?? In der regel bestehen LWL Verlegekabel mindestens aus 8 oder mehr Fasern. Das war auch vor 20 Jahren schon so ??Aber auch wenn...das ist ja kein Beinbruch. Der Traffic zw. den Häusern wird ja eh minimal sein bei 2 popeligen Switches dort. Und wenn dann kannst du ja immer nioch auf 10Gig gehen mit entsprechender Switch HW und Optiken zw. den Häusern !
unterschiedliche Switche auf den Root-switchen....muss ich durch
Bahnhof, Ägypten ??? Was bitte sind denn unterschiedliche Switches auf Switches ???Hast du die "virtualisiert" ?!
Unverständlich
Falls du unterschiedliche Hersteller meinst... Das ist vollkommen egal. Der MSTP ist ein weltweiter IEEE Standard und überall gleich. Es ist also vollkommen egal ob du Cisco, Extreme, D-Link, NetGear oder gruselige HP Gurken oder was auch immer hast.
es gibt hier sooo viel zu tun, ich kann nur eins nach dem anderen machen
Kein Wunder wenn man so ein "Schrottnetz" vor die Füsse geschmissen kommt Und einen Admin, der 61 ist und das alles super OK findet.
Ha, der feixt sich einen und muss das ja nur noch 4 Jahre am glühen halten... Nebenbei:
Die Konfigs oben zeigen keinerlei Spanning Tree Priority Konfig die Root und Backup Root festlegen. Das fehlt komplett !
Beim Etagenswitch ist nichtmal MSTP aktiviert und richtig konfiguriert.
Die Instanzen usw. fehlen komplett. Auch am Root Switch.
Fern hat der 2 falsche statische default Routen. Als Default kanns nur eine geben. Da hat einer ne Konfig Leiche nicht gelöscht mit fatalen Folgen.
Mal ganz davon abgesehen das das gesamte netz wohl komplett doof und flach ist. Also keinerlei Segmentierung in VLANs und damit Reduktion der L2 Broadcast Domains usw. usw.
SAN, Clients, Drucker, Stechuhr und wohlmöglich noch das WLAN sind allesamt in einem dummen, flachen Netz.
Da hast du ne echte Katastrophe vor dir...
Hält dich aber sicher die nächsten Monate noch richtig in Arbeit um das zu bereinigen.
Ich meinte: Unterschiedliche Switche bei Root- und Etagenswitchen.
Kann man mit lesen. Wichtig ist da wie immer eine saubere und vor allem kompatible Konfig zwischen den beiden. In der Regel ist das kein Problem wenn man darauf achtet.hatte ich MSTP global im Webfrontend aktiviert.
Webfrontend...igitt. Mit Klicki Bunti erreicht man meist nur die Hälfte. Haben die Switches auch ein CLI (Kommando Interface) oder sind das nur billige Klicki Buntis ?Was ist eine Instanz? Ich werd mal googlen...
https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-p ...und sehr gut auch:
http://blog.ine.com/2010/02/22/understanding-mstp/
wo die Routen herkommen. Zumal eine davon auf unseren Printerserver zeigt
Kein Kommentar. Zu eurem Gruselnetz ist ja schon alles gesagt....Mein Senioren-Admin hier muss noch zwei Jahre. Dann beginnt seine Altersteilzeit zu wirken.
Also hast du noch 2 Jahre um im Feuer unter dem .... zu machen Eventuell benötige ich dann noch mehr Hilfe von euch.
Immer gerne. Dafür ist das Forum ja da