26
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 378205
Url: https://administrator.de/contentid/378205
Printed on: April 25, 2024 at 13:04 o'clock
26 Comments
Latest comment
Moin,
meinst du mit Trunk den Link Agg Standard?
Was sagen denn die Logs der unbekannten Switches?
Was für Geräte sind das?
Die Timing können auf ein Spanningtree Thema hindeuten.
Gruß
Spirit
meinst du mit Trunk den Link Agg Standard?
Was sagen denn die Logs der unbekannten Switches?
Was für Geräte sind das?
Die Timing können auf ein Spanningtree Thema hindeuten.
Gruß
Spirit
Hi,
nein ich meine wirklich Trunk, nicht LAG.
Unsere beiden Backbone-Switche sind 2920-24G
Die Etagenswitche sind 1920-24G-PoE+
Verbunden sind alle Etagenswitche per Kupfer redundant auf die Backboneswitche.
In den Logs steht haufenweise Excessive Broadcasts und High Collisions. Siehe Screenshot.
nein ich meine wirklich Trunk, nicht LAG.
Unsere beiden Backbone-Switche sind 2920-24G
Die Etagenswitche sind 1920-24G-PoE+
Verbunden sind alle Etagenswitche per Kupfer redundant auf die Backboneswitche.
In den Logs steht haufenweise Excessive Broadcasts und High Collisions. Siehe Screenshot.
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 @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?
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.
Hmmm, die CPU ist so bei 11% und RAM ist bei 40%. Soweit sieht das für mich normal aus. (auf beiden Backbones)
Bei den Etagenswitchen liegt CPU bei 10% und RAM auch bei 44%.
Da das Thema für mich neu ist und ich das Netzwerk hier so übernommen habe, würdest Du es für bitte mich etwas ausführlicher formulieren?
Was muss ich auf tun, um zwei Switche redundant miteinander zu verbinden und keine Loops zu erhalten?
Hab eben erst Deinen Edit gelesen.
Also auf den Backbones auch erstmal die Trunks konfen?
Gruß Hucklebuck
Bei den Etagenswitchen liegt CPU bei 10% und RAM auch bei 44%.
Da das Thema für mich neu ist und ich das Netzwerk hier so übernommen habe, würdest Du es für bitte mich etwas ausführlicher formulieren?
Was muss ich auf tun, um zwei Switche redundant miteinander zu verbinden und keine Loops zu erhalten?
Hab eben erst Deinen Edit gelesen.
Also auf den Backbones auch erstmal die Trunks konfen?
Gruß Hucklebuck
Ich habe noch gerade mal um gehört und ich lieg wohl richtig: Spannung Tree greift und flippt wohl etwas.
Zwischen den Switches bündelst du die links einfach mit nem Trunk.
Zwischen den Switches bündelst du die links einfach mit nem Trunk.
OK, Danke.
Das mach ich erst mal.
Vielen Dank für die schnellen Antworten.
Hucklebuck
Das mach ich erst mal.
Vielen Dank für die schnellen Antworten.
Hucklebuck
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.
Hallo aqui,
Zitat: 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 !
Ich sagte ja bereits, dass das Thema für mich neu ist und auch dass ich das Netzwerk so übernommen habe.
Error-Messages habe ich bisher keine gesehen. Bisher war alles "Warning".
Ich bin für jede Hilfe dankbar. Auch Deinen Satz zu den verschiedenen Spanning-Tree Protokollen nehme als Hilfe auf.
Gruß Hucklebuck
Zitat: 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 !
Ich sagte ja bereits, dass das Thema für mich neu ist und auch dass ich das Netzwerk so übernommen habe.
Error-Messages habe ich bisher keine gesehen. Bisher war alles "Warning".
Ich bin für jede Hilfe dankbar. Auch Deinen Satz zu den verschiedenen Spanning-Tree Protokollen nehme als Hilfe auf.
Gruß Hucklebuck
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 ?
Ich habe gerade nachgeschaut.
Auf den beiden Backbones ist MSTP aktviert, auf den Etagenswitchen RSTP.
Die beiden Backbones haben eine Priority von 0 und der andere von 4096 konfiguriert. Beide müssen also 4096 haben?
Auf den beiden Backbones ist MSTP aktviert, auf den Etagenswitchen RSTP.
Die beiden Backbones haben eine Priority von 0 und der andere von 4096 konfiguriert. Beide müssen also 4096 haben?
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)
1
Alles klar,
Na da hab ich ja was zu tun.
Die Arbeiten am Netzwerk sind für Freitag angekündigt.
Feedback gibt es also erst nächste Woche.
Also, schon mal vielen Danke für eure Tipps und Hilfestellungen.
Gruß Hucklebuck
Na da hab ich ja was zu tun.
Die Arbeiten am Netzwerk sind für Freitag angekündigt.
Feedback gibt es also erst nächste Woche.
Also, schon mal vielen Danke für eure Tipps und Hilfestellungen.
Gruß Hucklebuck
Na da hab ich ja was zu tun.
Nein nicht wirklich, es sei denn du hast 50 Switches und mehr.Das ist mit 2-3 Konfig Kommandos erledigt wenn man weiss was man da tut.
Feedback gibt es also erst nächste Woche.
So lange ??Na, wir sind trotzdem gespannt
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.
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.
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...)
Hallo,
zu viel bin ich hier noch nicht gekommen.
Wir bekommen ein neues SAN und ich musste dafür im Rack noch HE's freistricken.
Rootbridge (stp-prio 4096) und Backuprootbridge (stp-prio 8192) sind eingerichtet.
Auf allen switchen ist jetzt MSTP aktiviert.
Ich habe mal eine grundsätzliche Frage aber bitte schlagt mich nicht. (Ich hab's halt noch nie gemacht)...
Wenn man zwei Switche redundant miteinander verbindet. Dafür einen Trunk baut, muss der Trunk auf beiden Switchen angelegt werden?
Oder nur auf einem der Switche?
Hier läuft alles über das default-Vlan 1. Muss ich da bei den Trunks etwas beachten?
Screenshot, wie es hier aussieht liegt bei.
Wie gesagt, bitte nicht schlagen. Bin lernwillig.
Hucklebuck
zu viel bin ich hier noch nicht gekommen.
Wir bekommen ein neues SAN und ich musste dafür im Rack noch HE's freistricken.
Rootbridge (stp-prio 4096) und Backuprootbridge (stp-prio 8192) sind eingerichtet.
Auf allen switchen ist jetzt MSTP aktiviert.
Ich habe mal eine grundsätzliche Frage aber bitte schlagt mich nicht. (Ich hab's halt noch nie gemacht)...
Wenn man zwei Switche redundant miteinander verbindet. Dafür einen Trunk baut, muss der Trunk auf beiden Switchen angelegt werden?
Oder nur auf einem der Switche?
Hier läuft alles über das default-Vlan 1. Muss ich da bei den Trunks etwas beachten?
Screenshot, wie es hier aussieht liegt bei.
Wie gesagt, bitte nicht schlagen. Bin lernwillig.
Hucklebuck
Trunk auf beiden Seiten identisch.
Danke
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:
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
Zitat von @aqui:
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
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
<weinen>Ich war es doch nicht....das war sogar eine externe Firma!</weinen>
Ja, OK, redundant ist da nix. Das Ziel war es mehr Bandbreite zwischen den Switchen zu realisieren.
Ich würde es sehr gern besser machen.
Die Probleme sind aber folgende:
- die root-Switches sind nicht gestacked sondern schlichtweg verbunden mit EINER LWL-Strippe von Haus zu Haus.
- dieser Graben zwischen den Häusern wurde vermutlich vor 15Jahren zugeschüttet
- ich bekomme also keine redundanten Leitungen zu den Etagenswitchen gezogen.
- (persönliches Problem) unterschiedliche Switche auf den Root-switchen....muss ich durch
- es gibt hier sooo viel zu tun, ich kann nur eins nach dem anderen machen
-- altes SAN voll und lahm (permanent I/O Latency Warnings)
-- ESXer am RAM-Ende
-- Verkabelung...kennt ihr bereits
-- W10-Updates machen mich wahnsinnig...jeden verdammten Monat!
-- WSUS....Platte voll
-- urlalte Serversteine (Bsp.: DB-SRV 2003 32bit mit 4GB RAM) *stöhn*
-- Klimaanlagen ungewartet
-- Löschanlage ungewartet
-- Telefonanlage ist das Grauen
-- AD ist irgendwann eine alte Konfig vom 2008ter auf 2012er kopiert worden. Läuft wie'n Sack Schrauben.
-- ich trete hier von einer Mine auf die Nächste
Und einen Admin, der 61 ist und das alles super OK findet.
Hier mal die aktuellen Konfigs von den Switchen
Konfig Etagenswitch
display current-configuration
#
version 5.20.99, Release 1118
#
sysname hpswitch214
#
clock timezone Amsterdam add 01:00:00
#
domain default enable system
#
ipv6
#
telnet server enable
#
ssl version ssl3.0 disable
#
password-recovery enable
#
vlan 1
#
vlan 2
description Trunk
#
domain system
access-limit disable
state active
idle-cut disable
self-service-url disable
#
user-group system
group-attribute allow-guest
#
local-user admin
password cipher $c$3$DwcT77d0LbRzCKzcvbDA3SxWU4QoCjQBp+aohQ==
authorization-attribute level 3
service-type ssh telnet terminal
service-type web
local-user thoe
password cipher $c$3$v8Mb/2nrDyCpgXknXZKc20BFXcMEyfVp6ZwVJbMLNpzu7g==
authorization-attribute level 3
service-type ssh telnet
service-type web
#
stp enable
#
interface NULL0
#
interface Vlan-interface1
ip address 192.168.100.214 255.255.255.0
#
interface GigabitEthernet1/0/1
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/2
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/3
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/4
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/5
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/6
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/7
speed 100
duplex full
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/8
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/9
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/10
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/11
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/12
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/13
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/14
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/15
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/16
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/17
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/18
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/19
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/20
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/21
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/22
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/23
port link-type trunk
port trunk permit vlan 1 to 2
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/24
port link-type trunk
port trunk permit vlan 1 to 2
poe enable
stp edged-port enable
#
interface GigabitEthernet1/0/25
stp edged-port enable
#
interface GigabitEthernet1/0/26
stp edged-port enable
#
interface GigabitEthernet1/0/27
stp edged-port enable
#
interface GigabitEthernet1/0/28
stp edged-port enable
#
ip route-static 0.0.0.0 0.0.0.0 192.168.100.10
ip route-static 0.0.0.0 0.0.0.0 192.168.100.4
#
undo info-center logfile enable
#
snmp-agent
snmp-agent local-engineid 383030303633413236353133393433464332323546314338
snmp-agent community read public
snmp-agent sys-info contact Thomas im Keller
snmp-agent sys-info location Haus 1 Serverraum
snmp-agent sys-info version all
#
ntp-service unicast-server 192.168.100.38
ntp-service unicast-server 192.168.100.40
#
ssh server enable
#
ip https enable
#
load xml-configuration
#
user-interface aux 0
authentication-mode scheme
user-interface vty 0 15
authentication-mode scheme
#Konfig rootbridge
show config
Startup configuration: 12
; J9726A Configuration Editor; Created on release #WB.16.05.0007
; Ver #12:08.15.9b.3f.b3.b8.ee.34.79.3c.29.eb.9f.fc.f3.ff.37.ef:4a
hostname "HP-2920-24G"
module 1 type j9726a
timesync sntp
sntp broadcast
time daylight-time-rule western-europe
time timezone 120
ip timep manual 192.168.100.38
snmp-server community "public" unrestricted
snmp-server host 192.168.100.6 community "public"
snmp-server location "Keller Haus II, Serverraum, R2"
oobm
ip address dhcp-bootp
exit
vlan 1
name "DEFAULT_VLAN"
untagged 1-24,B1-B2
ip address 192.168.100.206 255.255.255.0
ip igmp
exit
spanning-tree
spanning-tree pathcost mstp 8021d
spanning-tree priority 1 force-version stp-compatible
no tftp server
no autorun
no dhcp config-file-update
no dhcp image-file-update
device-profile name "default-ap-profile"
cos 0
exit
activate software-update disable
activate provision disable
password managerAuf den root-Switchen (2920) finde ich zumindest auf dem Webfrontend nichts von LAG (LACP) nur Trunk, Trunkgroups usw.
Da ich gestern entdeckt habe, dass auf den Etagenswitchen schon ein vlan 2 für trunk angelegt wurde, müsste ich dass auf den beiden root-switchen erstmal nachschieben oder? Das vlan 2 gibt es dort noch nicht.
Wenn ich das richtig verstanden habe, laufen die Trunks doch nie.
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.
unterschiedliche Switche auf den Root-switchen....muss ich durch
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.
Bei den Etagenswitchen hatte ich MSTP global im Webfrontend aktiviert. Sehr seltsam.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.
Was ist eine Instanz? Ich werd mal googlen...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.
Ich habe keine Ahnung wo die Routen herkommen. Zumal eine davon auf unseren Printerserver zeigt. .oOHält dich aber sicher die nächsten Monate noch richtig in Arbeit um das zu bereinigen.
Ja, und wie oben schon geschrieben, dass ist nur ein Thema von vielen.Mein Senioren-Admin hier muss noch zwei Jahre. Dann beginnt seine Altersteilzeit zu wirken.
Ich schiebe das Netzwerkthema erst mal bis September. Habe noch extrem viel anderen Kram bis zum Urlaub.
Ich melde mich auf jeden Fall hier wieder. Eventuell benötige ich dann noch mehr Hilfe von euch.
Gruß Hucklebuck
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 
