9
Netzwerk-Ausfall trotz konfiguriertem MSTP
Hallo liebe Community,
ich habe aktuell bei einem meiner Kunden ein neues Netzwerk aufgebaut.
Erstmals wird hier eine Stern-Ring-Topologie aufgebaut.
Alle Switche sind via LWL mit 10GBit/s verbunden.
Zwischen allen Switchen mit mehreren parallelen Verbindungen sind LACP Trunks konfiguriert.
Alle sonstigen angebundenen Switche sind via statischen Trunks verbunden.
Zum Einsatz kommen
1x HPE Aruba 5412Rzl2
3x HPE Aruba 5406Rzl2
1x HPE Aruba 3810M
10x HPE Aruba 2540
1x HPE Aruba 2530 (einziger Switch, welcher mit 1Gbit/s angebunden ist)
Explizit geht es um den rot eingekreisten Switch im Bild. Wenn ich dort beide LWL Kabel verbinde, wird an irgend einer anderen Stelle in diesem 4-er Ring das STP aktiv und blockiert mit einen ganzen LACP Trunk.
Auf allen Switchen / Trunks ist MSTP (Multi-Spanning-Tree-Protokoll) mit einer Standard-Priorität von 4 (64) konfiguriert.
Auf dem Trunk zwischen dem rot markierten Switch sowie dem rechts angebundenen 5406 Switch ist selbiges mit Priorität 5 (96) konfiguriert.
Laut meines Verständnisses sollte eigentlich nur auf dem Trunk das STP greifen, wo Priorität 5 gesetzt ist.
Kann mir hier vielleicht jemand weiterhelfen?
Ich habe bereits einige Seiten gefunden mit LACP, aber dort wird LACP immer nur zwischen 2 Switchen erklärt und keine Konstellation mit 3 oder mehr Switchen im Verbund.
ich habe aktuell bei einem meiner Kunden ein neues Netzwerk aufgebaut.
Erstmals wird hier eine Stern-Ring-Topologie aufgebaut.
Alle Switche sind via LWL mit 10GBit/s verbunden.
Zwischen allen Switchen mit mehreren parallelen Verbindungen sind LACP Trunks konfiguriert.
Alle sonstigen angebundenen Switche sind via statischen Trunks verbunden.
Zum Einsatz kommen
1x HPE Aruba 5412Rzl2
3x HPE Aruba 5406Rzl2
1x HPE Aruba 3810M
10x HPE Aruba 2540
1x HPE Aruba 2530 (einziger Switch, welcher mit 1Gbit/s angebunden ist)
Explizit geht es um den rot eingekreisten Switch im Bild. Wenn ich dort beide LWL Kabel verbinde, wird an irgend einer anderen Stelle in diesem 4-er Ring das STP aktiv und blockiert mit einen ganzen LACP Trunk.
Auf allen Switchen / Trunks ist MSTP (Multi-Spanning-Tree-Protokoll) mit einer Standard-Priorität von 4 (64) konfiguriert.
Auf dem Trunk zwischen dem rot markierten Switch sowie dem rechts angebundenen 5406 Switch ist selbiges mit Priorität 5 (96) konfiguriert.
Laut meines Verständnisses sollte eigentlich nur auf dem Trunk das STP greifen, wo Priorität 5 gesetzt ist.
Kann mir hier vielleicht jemand weiterhelfen?
Ich habe bereits einige Seiten gefunden mit LACP, aber dort wird LACP immer nur zwischen 2 Switchen erklärt und keine Konstellation mit 3 oder mehr Switchen im Verbund.
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: 515153
Url: https://administrator.de/forum/netzwerk-ausfall-trotz-konfiguriertem-mstp-515153.html
Ausgedruckt am: 23.12.2024 um 04:12 Uhr
9 Kommentare
Neuester Kommentar
Hi
das wird auch nicht funktionieren. So genanntes MCT (MultiChassisTrunking) können deine Geräte nicht. Ein LACP über physische / logisch mehrere Switche verteilt geht nicht (ohne weiteres).
MCT wird im Regelfall auch nur innerhalb eines Stacks angewandt, wenn z.B. eine mehrfache Anbindung an dem Stack realisert werden soll. Dein dargestelltes Konstrukt funktioniert so nicht, es sei denn alles Geräte würden im Chassis Mode vgl. Brocade/Extrem VDX laufen wo alle Geräte als eine logische Einheit funktionieren.
Das STP da entsprechend eingreift ist vollkommen korrekt da ein Loop erkannt wird und das Protokoll passende reagiert. Ich kenne die "Einstellung" von HP jetzt auch nicht, aber Prio werden in 4096er Schritten gesetzt, ich tippe aber das der Switche das intern korrekt handeln und es nur zu Konfiguration so dargestellt wird wie bei dir.
Und Ring-Topologie mit passenden Protokoll? Ich kenne das jetzt nur von Ruckus/Brocade (MRP) und Cisco aber nicht bei HP...
Gruß
@clSchak
das wird auch nicht funktionieren. So genanntes MCT (MultiChassisTrunking) können deine Geräte nicht. Ein LACP über physische / logisch mehrere Switche verteilt geht nicht (ohne weiteres).
MCT wird im Regelfall auch nur innerhalb eines Stacks angewandt, wenn z.B. eine mehrfache Anbindung an dem Stack realisert werden soll. Dein dargestelltes Konstrukt funktioniert so nicht, es sei denn alles Geräte würden im Chassis Mode vgl. Brocade/Extrem VDX laufen wo alle Geräte als eine logische Einheit funktionieren.
Das STP da entsprechend eingreift ist vollkommen korrekt da ein Loop erkannt wird und das Protokoll passende reagiert. Ich kenne die "Einstellung" von HP jetzt auch nicht, aber Prio werden in 4096er Schritten gesetzt, ich tippe aber das der Switche das intern korrekt handeln und es nur zu Konfiguration so dargestellt wird wie bei dir.
Und Ring-Topologie mit passenden Protokoll? Ich kenne das jetzt nur von Ruckus/Brocade (MRP) und Cisco aber nicht bei HP...
Gruß
@clSchak
Hallo clSchak,
Ja bei HP in der Konfiguration werden die 4096er Schritte in 1er Steps ausgeführt. Heißt Prio 4 ist normal 32768.
Deshalb habe ich auch den besagten Trunk auf Prio 5 (65536)
Im Ring nutzt HP meines Wissens nur das STP, damit Wege, welche die höchsten Kosten haben blockiert werden, sobald günstigere Wege vorhanden sind.
Allgemeine Frage in die Runde:
Was würde passieren, wenn ich von MSTP (Multi-Spanning-Tree-Protokoll) auf RSTP (Rapid-Spanning-Tree-Protokoll) umstelle?
MSTP ist meines Wissens nur notwendig, wenn ich unterschiedliche VLANs auf verschiedene Switche / Strecken priorisieren möchte.
(Dummerweise ist das MSTP bei den HP Switchen standardmäßig unkonfiguriert aktiv)
Da dies bei mir jedoch nicht der Fall ist, da ich alle VLANs gleich priorisiere, sollte doch das RSTP wesentlich zuverlässiger funktionieren, was zudem einen geringeren Konfigurationsaufwand bedeutet.
Anmerkung:
Routing zwischen den Switchen / VLANs ist nicht aktiv, da dies aus Sicherheitsgründen von der angebundenen Firewall übernommen wird.
Das STP da entsprechend eingreift ist vollkommen korrekt da ein Loop erkannt wird und das Protokoll passende reagiert. Ich kenne die "Einstellung" von HP jetzt auch nicht, aber Prio werden in 4096er Schritten gesetzt, ich tippe aber das der Switche das intern korrekt handeln und es nur zu Konfiguration so dargestellt wird wie bei dir.
Ja bei HP in der Konfiguration werden die 4096er Schritte in 1er Steps ausgeführt. Heißt Prio 4 ist normal 32768.
Deshalb habe ich auch den besagten Trunk auf Prio 5 (65536)
Und Ring-Topologie mit passenden Protokoll? Ich kenne das jetzt nur von Ruckus/Brocade (MRP) und Cisco aber nicht bei HP...
Im Ring nutzt HP meines Wissens nur das STP, damit Wege, welche die höchsten Kosten haben blockiert werden, sobald günstigere Wege vorhanden sind.
Allgemeine Frage in die Runde:
Was würde passieren, wenn ich von MSTP (Multi-Spanning-Tree-Protokoll) auf RSTP (Rapid-Spanning-Tree-Protokoll) umstelle?
MSTP ist meines Wissens nur notwendig, wenn ich unterschiedliche VLANs auf verschiedene Switche / Strecken priorisieren möchte.
(Dummerweise ist das MSTP bei den HP Switchen standardmäßig unkonfiguriert aktiv)
Da dies bei mir jedoch nicht der Fall ist, da ich alle VLANs gleich priorisiere, sollte doch das RSTP wesentlich zuverlässiger funktionieren, was zudem einen geringeren Konfigurationsaufwand bedeutet.
Anmerkung:
Routing zwischen den Switchen / VLANs ist nicht aktiv, da dies aus Sicherheitsgründen von der angebundenen Firewall übernommen wird.
Hi
man priorisiert keine VLANs - man setzt lediglich fest welches Gerät die Root-Bridge ist und das sollte ein Router sein bzw. ein zentrales Gerät. Wer schlussendlich das Routing macht spielt keine Rolle, bei uns macht es ein L3 Stack. Wenn es dir um die Sicherheit geht kannst du auch mit ACLs arbeiten. Was du bei den Trunks angegeben hast sieht auch mehr nach PathCost für STP aus.
Wir verwenden bei 802.1w ("per VLAN RSTP), aber ich denke nicht das HP das kann, zumindest konnte das damals kein HP Switch bei uns.
Wenn du Traffic priorisieren willst, mach das über L2 QoS oder L3 DSCP.
Und nein, Ringprotokolle ist eben kein STP, bei Ruckus ist es "Metro Ring Protokoll" das reagiert im ms/ns Bereich und nicht wie STP im Sekundenbereich, da bekommst nicht mal einen Ping-Aussetzer wenn das reagiert, selbst VoIP funktioniert ohne Unterbrechung. Wir hatten das vor unserem jetzigen Stack inkl. VRRP im Einsatz und das lief 1a
Und bei der Größe würde ich nicht die FW als zentralen Router verwenden, alleine wenn das Server Netz darüber läuft. Du kannst überall 100G haben, die Firewall wird das niemals in der Geschwindigkeit routen können. Normale L3 Router routen in der Geschwindigkeit des höchsten PortSpeeds das am Gerät möglich ist, bei uns mit 40G aktuell und das schafft unsere _dicke_ Firewall nicht mal ansatzweise.
Edit Add:
Ich würde mir auch nie wieder Modulare Chassis-Switche kaufen, im Stack fährst du deutlich besser was Sicherheit, Stabilität, Kapazität und Ausfallsicherheit betrifft.
man priorisiert keine VLANs - man setzt lediglich fest welches Gerät die Root-Bridge ist und das sollte ein Router sein bzw. ein zentrales Gerät. Wer schlussendlich das Routing macht spielt keine Rolle, bei uns macht es ein L3 Stack. Wenn es dir um die Sicherheit geht kannst du auch mit ACLs arbeiten. Was du bei den Trunks angegeben hast sieht auch mehr nach PathCost für STP aus.
Wir verwenden bei 802.1w ("per VLAN RSTP), aber ich denke nicht das HP das kann, zumindest konnte das damals kein HP Switch bei uns.
Wenn du Traffic priorisieren willst, mach das über L2 QoS oder L3 DSCP.
Und nein, Ringprotokolle ist eben kein STP, bei Ruckus ist es "Metro Ring Protokoll" das reagiert im ms/ns Bereich und nicht wie STP im Sekundenbereich, da bekommst nicht mal einen Ping-Aussetzer wenn das reagiert, selbst VoIP funktioniert ohne Unterbrechung. Wir hatten das vor unserem jetzigen Stack inkl. VRRP im Einsatz und das lief 1a
Und bei der Größe würde ich nicht die FW als zentralen Router verwenden, alleine wenn das Server Netz darüber läuft. Du kannst überall 100G haben, die Firewall wird das niemals in der Geschwindigkeit routen können. Normale L3 Router routen in der Geschwindigkeit des höchsten PortSpeeds das am Gerät möglich ist, bei uns mit 40G aktuell und das schafft unsere _dicke_ Firewall nicht mal ansatzweise.
Edit Add:
Ich würde mir auch nie wieder Modulare Chassis-Switche kaufen, im Stack fährst du deutlich besser was Sicherheit, Stabilität, Kapazität und Ausfallsicherheit betrifft.
man priorisiert keine VLANs - man setzt lediglich fest welches Gerät die Root-Bridge ist und das sollte ein Router sein bzw. ein zentrales Gerät. Wer schlussendlich das Routing macht spielt keine Rolle, bei uns macht es ein L3 Stack. Wenn es dir um die Sicherheit geht kannst du auch mit ACLs arbeiten. Was du bei den Trunks angegeben hast sieht auch mehr nach PathCost für STP aus.
Entschuldige da hab ich mich falsch ausgedrückt. Mein Gedanke war wie von dir geschrieben, dass ich mit MSTP für jede VLAN-Gruppe eine andere Root-Bridge wählen kann (wenn gewünscht).
Wenn es dir um die Sicherheit geht kannst du auch mit ACLs arbeiten.
Da geb ich dir grundsätzlich recht, aber
1. unser Kunde möchte die "Sicherheit" selbst administrieren und hat von ACLs auf Switchen keinerlei Ahnung, kennt sich jedoch super mit der Firewall aus
2. ist die Firewall auch über 10GBit/s Glasfaser angebunden und schafft theoretisch sogar 15 GBit/s (also 50% Puffer) wobei das Routing auch nur zwischen den div. VLANs benötigt wird.
Wir verwenden bei 802.1w ("per VLAN RSTP), aber ich denke nicht das HP das kann, zumindest konnte das damals kein HP Switch bei uns.
Wenn ich nicht ganz irre meinst du damit sogenanntes PVRSTP, welches bei HP ein Mischmasch aus RSTP und MSTP ist. Können tun das die Devices schon, jedoch muss hier eine Menge Konfigurationsaufwand betrieben werden und ich bin mir nicht sicher, ob hier das Verhältnis von Aufwand zu Nutzen gegeben ist.
...bei Ruckus ist es "Metro Ring Protokoll" das reagiert im ms/ns Bereich und nicht wie STP im Sekundenbereich
Ich habe gerade durch etwas Recherche noch herausgefunden, dass die größeren HPE Devices (5800,7800,10500) ein sogenanntes RRPP (Rapid Ring Protection Protocol) können, bin mir aber zum jetzigen Zeitpunkt nicht sicher, ob das auch die 5400er und 2540er Switche können.
Zumindest gibt HPE für diese Switch-Serien keinerlei Informationen raus.
Ich würde mir auch nie wieder Modulare Chassis-Switche kaufen, im Stack fährst du deutlich besser was Sicherheit, Stabilität, Kapazität und Ausfallsicherheit betrifft.
In manchen Punkten gebe ich dir recht, allerdings habe ich bei einem Modular-Switch (außer bei einem Ausfall des Chassis!) immer eine Redundanz und Ausfallsicherheit gegeben. Die Skalierbarkeit ist genauso gegeben (sogar noch Vielfältiger, da ich hier entweder reine Ethernet, reine SFP+ oder gemischte Module verbauen) und wenn man es genau betrachtet sogar für einzelne Module auch günstiger, als Stacking-Switche.
Aber hier geht es ja auch nicht um die "Rand-Bedingungen" sondern die Funktionalität an sich.
Fakt ist, dass meines Erachtens das STP (wenn auch wesentlich langsamer in Reaktion) auch den Ring unterbrechen sollte und zwar anhand der gegebenen PathCost Einstellungen.
Meine Frage zielt mehr oder weniger eigentlich auf folgendes ab:
Kann ich im Produktionsbetrieb (natürlich auch mit kurzfristigen Ausfällen!) ohne große Schwierigkeiten die Konfiguration von MSTP auf RSTP umbauen bzw. kurzfristig im Mischbetrieb fahren oder fällt mir die Leitung zwischen den Switchen komplett auf die Schnauze und ich muss an jeden Switch physikalisch ran, wenn ich auf Seite A MSTP und auf Seite B RSTP aktiviert habe?
Und läuft RSTP zuverlässiger als MSTP oder macht es Sinn das MSTP komplett durch zu konfigurieren?
Mischbetrieb wird zu einer Downtime führen, die beiden Protokolle vertragen sich nicht wirklich, ggf. musst sogar vor Ort sein wenn dir gesamte Uplinks wegbrechen. Aber das ist einmal, evtl. einen Aufwand von 1-2h dann sollte es fertig sein, ggf. mal im späten Nachmittag durchführen.
Was evtl. funktioniert, alle "Backuppfade" disablen und dann STP abschalten und wieder korrekte Version danach anschalten.
Was evtl. funktioniert, alle "Backuppfade" disablen und dann STP abschalten und wieder korrekte Version danach anschalten.
Hi clSchak,
erstmal danke für deine Unterstützung.
Ich habe jetzt auf allen Switchen STP generell deaktiviert, dann nur an den benötigten Switchen 01-04 auf rstp mode umgebaut, und dort wieder aktiviert.
Danach hab ich die Backupleitung aktiviert und "gehofft", dass mein Netz nicht auf die Nase fällt, da ich das ganze gerade nur via Fernwartung durchgeführt habe.
War zwar etwas riskant (wer liebt nicht das Risiko) aber in Rücksprache mit dem Kunden-ITler kein Problem, da er notfalls in 10 min. in der Firma gewesen wäre.
Das interessante ist nur, dass ich im RSTP Mode nicht nachvollziehen kann, ob und welche LWL nun deaktiviert ist, da mir der Switch hier keinerlei Forwarding/Blocking Informationen ausspuckt.
Aber das Netzwerk läuft stabil und wirft keinerlei Fehler aus.
erstmal danke für deine Unterstützung.
Ich habe jetzt auf allen Switchen STP generell deaktiviert, dann nur an den benötigten Switchen 01-04 auf rstp mode umgebaut, und dort wieder aktiviert.
Danach hab ich die Backupleitung aktiviert und "gehofft", dass mein Netz nicht auf die Nase fällt, da ich das ganze gerade nur via Fernwartung durchgeführt habe.
War zwar etwas riskant (wer liebt nicht das Risiko) aber in Rücksprache mit dem Kunden-ITler kein Problem, da er notfalls in 10 min. in der Firma gewesen wäre.
Das interessante ist nur, dass ich im RSTP Mode nicht nachvollziehen kann, ob und welche LWL nun deaktiviert ist, da mir der Switch hier keinerlei Forwarding/Blocking Informationen ausspuckt.
Aber das Netzwerk läuft stabil und wirft keinerlei Fehler aus.
es ist wichtig dabei, JEDES(!) VLAN damit auszustatten und das dann auf allen Switchen wo es anliegt/eingerichtet ist. Ansonsten bekommst du Loops im Netz und dann werden auch Ports auf "Blocking" gehen. Spanning Tree solltest du grundsätzlich auf allen Geräten aktivieren, egal ob core / aggregation oder access Switche.
Ob STP korrekt arbeitet kannst bei via "show cpu" sehen, wenn die auf Last laufen (>10-20%) dann stimmt etwas nicht, egal was andere Protokolle sagen, das schaukelt sich dann langsam hoch.
Bei der Netzgröße würde ich mir auch eine MAC DB anlegen, netdb (MAC und IP Adressen Tracking Verwaltung) z.B. ist Open Source, damit kannst nach MAC, Teile einer MAC Adresse, IP Adressen usw. suchen um zu schauen wo welches Endgerät gerade angestöpselt ist.
Und wenn schon dabei bist ... - Elasticsearch mit Logstash & Kibana als Log-Sammelstelle, Monitoring wird wohl schon im Einsatz haben, da gibt es viele, je nachdem was man haben möchte.
Ob STP korrekt arbeitet kannst bei via "show cpu" sehen, wenn die auf Last laufen (>10-20%) dann stimmt etwas nicht, egal was andere Protokolle sagen, das schaukelt sich dann langsam hoch.
Bei der Netzgröße würde ich mir auch eine MAC DB anlegen, netdb (MAC und IP Adressen Tracking Verwaltung) z.B. ist Open Source, damit kannst nach MAC, Teile einer MAC Adresse, IP Adressen usw. suchen um zu schauen wo welches Endgerät gerade angestöpselt ist.
Und wenn schon dabei bist ...
- Elasticsearch mit Logstash & Kibana als Log-Sammelstelle, Monitoring wird wohl schon im Einsatz haben, da gibt es viele, je nachdem was man haben möchte.
und bzgl. der FW -15Gbit Routing das ist "nichts", wenn du 4-5 Server hast wo 200-300 Clients dran hängen ist die Leitung alleine schon dicht durch den normalen Traffic. Mit wie vielen Links á 10G ist die FW denn angebunden? Wenn es nur 10G Link ist, dann ist es schon eine _schmale_ Leitung bei der restlichen Bandbreite die in dem Netz zur Verfügung steht.
Unsere Backplane läuft aktuell bei ca. 150-400Gbit im Normalbetrieb, jedes Routing-Interface läuft mit max 40Gbit (maximale Einzelport-Geschwindigkeit aktuell bei uns) - oh sehe gerade der 7850 kommt mit 32x100G .... naja wer es braucht
Unsere Backplane läuft aktuell bei ca. 150-400Gbit im Normalbetrieb, jedes Routing-Interface läuft mit max 40Gbit (maximale Einzelport-Geschwindigkeit aktuell bei uns) - oh sehe gerade der 7850 kommt mit 32x100G .... naja wer es braucht
Erstmals wird hier eine Stern-Ring-Topologie aufgebaut.
Sowas ist immer tödlich und generell ein schlechtes Ethernet Design. Siehe auch hier:Trunk zwischen Switche - Loop möglich?
Gerade wenn man mit gruseligen HP Billigswitches arbeitet die die meisten modernen Topologien heutzutage nicht oder nur unzureichend supporten. Mit solchen Komponenten sind Ringe generell ein NoGo !
Der Ausfall lässt zudem befürchten das das MSTP Protokoll falsch oder fehlerhaft konfiguriert wurde ?! Priority im Speziellen..
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)
