11
Frage zu Spanning-Tree-Layout
Hallo zusammen,
ich habe aktuell das Problem, dass in einem relativ frisch aufgebauten Netzwerk mit redundanten Pfaden und MSTP inzwischen drei Mal ein Loop entstanden ist, der sich nur durch das Abschalten mehrerer Verbindungen auflösen ließ.
Dieser Vorfall hat sich nun noch ein paar Mal wiederholt und ich ging irgendwann zum Hersteller, der mir zum einen eine neue Firmware gab, aber auch etwas unspezifisch anmerkte, dass das am Netzwerkdesign selbst liegen könnte. Irgendwas wegen der Anzahl redundanter Wege.
Die neue Firmware habe ich eingespielt, aber jetzt frage ich mich, was an dem Netzwerklayout so verkehrt sein soll, dass es trotz (oder wegen) Spanning-Tree immer wieder ohne erkennbaren Grund Loops produziert.
Zum Netzwerkdesign:
Die Switches sind jeweils als Pärchen auf insgesamt drei Racks verteilt.
In Rack 2 befindet sich das Storage, deshalb sind dort auch die Root-Bridges.
Es existieren insgesamt fünf VLANs, von denen aber nur zwei für Storage verwendet werden. Die anderen drei VLANs transportieren anderen Traffic mit jeweils geringer Bandbreite.
Switches mit einer ungeraden Nummer sollen bevorzugt für die Anbindung an das Storage verwendet werden,
die Switches mit einer geraden Nummer dienen als Failover und transportieren sonst bevorzugt die anderen Nicht-Storage VLANs.
Die angeschlossenen Server sind mittels Master-Slave-Bonding (Linux) an beide Switches gleichzeitig angeschlossen und sind pro VLAN konfiguriert um wie oben beschrieben den Traffic auf die Switches aufzuteilen, aber gleichzeitig auch Failover zu bieten, falls die Verbindung über den bevorzugten Weg ausfällt.
Dementsprechend soll Traffic auch möglichst bevorzugt immer auf einer "Linie" bleiben - Switches mit gerader Nummer sollen den Traffic also möglichst immer nur an einen Switch mit ebenfalls gerader Nummer weitergeben. Aus diesem Grund sind die Links innerhalb des Racks (hier mit L1, L2, L3 markiert) künstlich durch höhere Pfadkosten verschlechtert worden.
Bei Tests funktionierte alles wie gewollt, auch die Pfadkosten werden korrekt berücksichtigt und so Stunts wie nicht überall konfigurierte VLANs sind kein Problem.
Als das Netz dann in den produktiven Betrieb ging funktionierte auch alles wie gewollt, bis nach einigen Monaten plötzlich ein Loop entstand, der sich nur auflösen ließ, indem L1-L3 getrennt wurden.
Wurden die Netze wieder zusammengesteckt, lief alles wieder sauber.
Ist das, was da gebaut wurde wirklich nicht für normales MSTP geeignet? Mir wurde von dem Support des Herstellers empfohlen, die redundanten Pfade zu reduzieren.
Das würde aber die Idee hinter dem Design konterkarieren, weil wir ja explizit den Totalausfall eines Switches und/oder 10G-Verbindung abfangen wollen. Und da komme ich nicht umhin, alle Switches jweils mit zwei Nachbarn zu verbinden...?
Vielen Dank!
ich habe aktuell das Problem, dass in einem relativ frisch aufgebauten Netzwerk mit redundanten Pfaden und MSTP inzwischen drei Mal ein Loop entstanden ist, der sich nur durch das Abschalten mehrerer Verbindungen auflösen ließ.
Dieser Vorfall hat sich nun noch ein paar Mal wiederholt und ich ging irgendwann zum Hersteller, der mir zum einen eine neue Firmware gab, aber auch etwas unspezifisch anmerkte, dass das am Netzwerkdesign selbst liegen könnte. Irgendwas wegen der Anzahl redundanter Wege.
Die neue Firmware habe ich eingespielt, aber jetzt frage ich mich, was an dem Netzwerklayout so verkehrt sein soll, dass es trotz (oder wegen) Spanning-Tree immer wieder ohne erkennbaren Grund Loops produziert.
Zum Netzwerkdesign:
Die Switches sind jeweils als Pärchen auf insgesamt drei Racks verteilt.
In Rack 2 befindet sich das Storage, deshalb sind dort auch die Root-Bridges.
Es existieren insgesamt fünf VLANs, von denen aber nur zwei für Storage verwendet werden. Die anderen drei VLANs transportieren anderen Traffic mit jeweils geringer Bandbreite.
Switches mit einer ungeraden Nummer sollen bevorzugt für die Anbindung an das Storage verwendet werden,
die Switches mit einer geraden Nummer dienen als Failover und transportieren sonst bevorzugt die anderen Nicht-Storage VLANs.
Die angeschlossenen Server sind mittels Master-Slave-Bonding (Linux) an beide Switches gleichzeitig angeschlossen und sind pro VLAN konfiguriert um wie oben beschrieben den Traffic auf die Switches aufzuteilen, aber gleichzeitig auch Failover zu bieten, falls die Verbindung über den bevorzugten Weg ausfällt.
Dementsprechend soll Traffic auch möglichst bevorzugt immer auf einer "Linie" bleiben - Switches mit gerader Nummer sollen den Traffic also möglichst immer nur an einen Switch mit ebenfalls gerader Nummer weitergeben. Aus diesem Grund sind die Links innerhalb des Racks (hier mit L1, L2, L3 markiert) künstlich durch höhere Pfadkosten verschlechtert worden.
RACK 1 RACK 2 RACK 3
┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ SW 3 / Br-Prio. 32k │════════│ SW 1 / Br-Prio. 4096 │══════════│ SW 5 / Br-Prio. 32k │
└──────────────────────┘ └──────────────────────┘ └──────────────────────┘
║ <-- L1 L2 --> ║ L3 --> ║
┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ SW 4 / Br-Prio. 32k │════════│ SW 2 / Br-Prio. 8192 │══════════│ SW 6 / Br-Prio. 32k │
└──────────────────────┘ └──────────────────────┘ └──────────────────────┘Bei Tests funktionierte alles wie gewollt, auch die Pfadkosten werden korrekt berücksichtigt und so Stunts wie nicht überall konfigurierte VLANs sind kein Problem.
Als das Netz dann in den produktiven Betrieb ging funktionierte auch alles wie gewollt, bis nach einigen Monaten plötzlich ein Loop entstand, der sich nur auflösen ließ, indem L1-L3 getrennt wurden.
Wurden die Netze wieder zusammengesteckt, lief alles wieder sauber.
Ist das, was da gebaut wurde wirklich nicht für normales MSTP geeignet? Mir wurde von dem Support des Herstellers empfohlen, die redundanten Pfade zu reduzieren.
Das würde aber die Idee hinter dem Design konterkarieren, weil wir ja explizit den Totalausfall eines Switches und/oder 10G-Verbindung abfangen wollen. Und da komme ich nicht umhin, alle Switches jweils mit zwei Nachbarn zu verbinden...?
Vielen Dank!
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: 548493
Url: https://administrator.de/forum/frage-zu-spanning-tree-layout-548493.html
Ausgedruckt am: 21.12.2024 um 16:12 Uhr
11 Kommentare
Neuester Kommentar
Hallo,
grundlegend: Welche Systeme/Hardware wurde(n) denn benutzt.
Du sagst ja selbst, dass es "eigentlich" funktioniert, nur auf Dauer (kann dies exakt auf n Tage eingegrenzt werden?) zu einem Loop kommt.
Die Frage ist demnach erstmal, warum tut es das, was spielt da verrückt. Hier wäre ein Ansatz die Konfiguration generell, sowie die impl. Switchkonfiguration speziell zu analysieren, oder andersherum sich zu fragen, warum tut es erst und dann nicht mehr. (was ich für sinnvoller halte).
Hier kann man natürlich auch generell hinterfragen (FW fehler etc). Aber all das macht keinen Sinn, ohne die relevanten Details zu haben, bzw das musst du sowieso mit dem Anbieter klären. Logs wären dazu auch nicht schlecht und dann hast du vermutlich schon genug Munition, um selbst auf die Jagd zu gehen.
Viele Grüße,
Christian
certifiedit.net
grundlegend: Welche Systeme/Hardware wurde(n) denn benutzt.
Du sagst ja selbst, dass es "eigentlich" funktioniert, nur auf Dauer (kann dies exakt auf n Tage eingegrenzt werden?) zu einem Loop kommt.
Die Frage ist demnach erstmal, warum tut es das, was spielt da verrückt. Hier wäre ein Ansatz die Konfiguration generell, sowie die impl. Switchkonfiguration speziell zu analysieren, oder andersherum sich zu fragen, warum tut es erst und dann nicht mehr. (was ich für sinnvoller halte).
Hier kann man natürlich auch generell hinterfragen (FW fehler etc). Aber all das macht keinen Sinn, ohne die relevanten Details zu haben, bzw das musst du sowieso mit dem Anbieter klären. Logs wären dazu auch nicht schlecht und dann hast du vermutlich schon genug Munition, um selbst auf die Jagd zu gehen.
Viele Grüße,
Christian
certifiedit.net
Wie die Switches such Einigen, wenn die STP-ID mehrfach vorhanden ist, weißt du?
Kannst du längere Zeit seriell die Switchlogs aufzeichnen, bis es zum vermeintlichen oder echten Loop kommt?
Hast du Gewissheit, dass es ein Loop ist, oder ein Switch oder mehrere das glauben?
Wer ist der Switchhersteller?
Du nutzt die Switches im mittleren Rack für SAN und LAN gleichzeitig?
Das Design, ich würde es als selten bezeichnen, ist weshalb im Einsatz?
Kannst du längere Zeit seriell die Switchlogs aufzeichnen, bis es zum vermeintlichen oder echten Loop kommt?
Hast du Gewissheit, dass es ein Loop ist, oder ein Switch oder mehrere das glauben?
Wer ist der Switchhersteller?
Du nutzt die Switches im mittleren Rack für SAN und LAN gleichzeitig?
Das Design, ich würde es als selten bezeichnen, ist weshalb im Einsatz?
Aktuell sind das Ubiquiti EX-16, die auf der im Januar aktuellsten Firmware laufen.
Die Backup-Root-Bridge hatte bei Einsetzen des letzten Loop-Vorwalls die höchste Uptime mit 176 Tagen, die anderen Geräte waren knapp darunter.
Aus dem, was ich aus den Syslogs bekomme (was teilweise schwierig ist, weil man nie genau weiß, ob ein Fehler Symptom oder Ursache ist) könnte es möglicherweise sein, dass die Backup-Root-Bridge eine Topologieänderung sieht, die nicht alle anderen Switches auch sehen.
Aber dies ist wie gesagt schwierig herauszufinden, weil die Switches natürlich so derart hart mit BPDUs geflutet werden, dass die Syslog-Nachrichten nicht immer sekundengenau gleich kommen.
Ich habe jedenfalls mal überall die aktuellste Firmware eingespielt, wie mir geheißen wurde.
Mir geht es prinzipiell auch ersmtal nur darum zu verifizieren, ob das Design an sich schon fehleranfällig ist resp. "zu viele redundante Pfade hat" wie man mir angedeutet hat.
Die Backup-Root-Bridge hatte bei Einsetzen des letzten Loop-Vorwalls die höchste Uptime mit 176 Tagen, die anderen Geräte waren knapp darunter.
Aus dem, was ich aus den Syslogs bekomme (was teilweise schwierig ist, weil man nie genau weiß, ob ein Fehler Symptom oder Ursache ist) könnte es möglicherweise sein, dass die Backup-Root-Bridge eine Topologieänderung sieht, die nicht alle anderen Switches auch sehen.
Aber dies ist wie gesagt schwierig herauszufinden, weil die Switches natürlich so derart hart mit BPDUs geflutet werden, dass die Syslog-Nachrichten nicht immer sekundengenau gleich kommen.
Ich habe jedenfalls mal überall die aktuellste Firmware eingespielt, wie mir geheißen wurde.
Mir geht es prinzipiell auch ersmtal nur darum zu verifizieren, ob das Design an sich schon fehleranfällig ist resp. "zu viele redundante Pfade hat" wie man mir angedeutet hat.
Hallo,
sicher, dass so ein Design mit dem Hersteller zu machen ist?
Ich meine zu den üblichen Unkenrufen, der Hersteller winkt dir da schon mit dem Zaunpfahl zu...
VG
sicher, dass so ein Design mit dem Hersteller zu machen ist?
Ich meine zu den üblichen Unkenrufen, der Hersteller winkt dir da schon mit dem Zaunpfahl zu...VG
Das Design ist OK und nicht ungewöhnlich, daran kann es normal nicht liegen. Die beiden Rack 2 Switches sind Root bzw. Backup Root also werden deren Uplinks auch immer aktiv sein.
In den Blocking State gehen dann L1 und L3 immer auf Switch 4 und 6. Soweit so gut.
Machst du noch irgendwelche unterschiedlichen Priority Wichtungen pro VLAN zum Balancing oder sind alle VLANs in einer Instance ?
Wenn du keine Instances definiert hast landen alle VLANs in der default Instance.
Die MSTP Konfig wäre mal ganz hilfreich vom Root und einer den non Root Switches.
In diesem Thread gibts noch ein bischen Design- und Konfig Futter zum Thema MSTP (Cisco, HP) Es ist aber natürlich nicht Produkt spezifisch da Standard.
3 Fragen noch:
Ein möglicher Grund könnte eine falsche oder fehlerhafte Active Standby Anbindung (Master Slave) der Server sein. Gibt es einen Grund hier kein LACP zu verwenden was etwas sicherer wäre durch ein eigenes Loop Prevention Detect im 802.3ad.
Das das für ein RZ kein ganz so ein tolles Design mit STP mehr ist weisst du sicher selber und ist auch nicht das Thema hier. Besser wäre STP frei eine Fabric oder ein Stack zu verwenden.
In den Blocking State gehen dann L1 und L3 immer auf Switch 4 und 6. Soweit so gut.
Machst du noch irgendwelche unterschiedlichen Priority Wichtungen pro VLAN zum Balancing oder sind alle VLANs in einer Instance ?
Wenn du keine Instances definiert hast landen alle VLANs in der default Instance.
Die MSTP Konfig wäre mal ganz hilfreich vom Root und einer den non Root Switches.
In diesem Thread gibts noch ein bischen Design- und Konfig Futter zum Thema MSTP (Cisco, HP) Es ist aber natürlich nicht Produkt spezifisch da Standard.
3 Fragen noch:
- Sind dort noch andere aktive Komponenten angeschlossen die kein MSTP machen oder irgendeine andere Form des STP ?
- Switches auf dem aktuellen recommendeten Firmware Stand und vor allem auf dem gleichen. Gibts irgendwelche Einträge zu MSTP in den Release Notes ?
- Kannst du im Log irgendwelche Messages sehen. MSTP Topo Changes, Link Loss usw. ?
Ein möglicher Grund könnte eine falsche oder fehlerhafte Active Standby Anbindung (Master Slave) der Server sein. Gibt es einen Grund hier kein LACP zu verwenden was etwas sicherer wäre durch ein eigenes Loop Prevention Detect im 802.3ad.
Das das für ein RZ kein ganz so ein tolles Design mit STP mehr ist weisst du sicher selber und ist auch nicht das Thema hier. Besser wäre STP frei eine Fabric oder ein Stack zu verwenden.
Wie die Switches such Einigen, wenn die STP-ID mehrfach vorhanden ist, weißt du?
Welche ID meinst du? Die Bridge-ID oder die MSTP-Config-ID?
Die Bridge-IDs sollten optimalerweise nicht identisch sein weil ja auch definitiv unterschiedliche Prioritäten für Root-Bridge und wer Backup-Root-Bridge festgelegt sind - die können also erstmal nicht doppelt auftauchen.
Was die restlichen Switches angeht, könnte ich natürlich in jedem Rack jeweils einen Switch mit 16k Priorität versehen, um bei komplettem Konnektivitätsverlust zu Rack 1 was zu haben, aber würde das helfen?
Kannst du längere Zeit seriell die Switchlogs aufzeichnen, bis es zum vermeintlichen oder echten Loop kommt?
Könnte ich mal machen.
Allerdings habe ich Logs eines solchen Vorfalls, die sind nur leider nicht wirklich ergiebig.
Einzelne Switches behaupten, sie würden eine Topologieänderung sehen (zu einem Zeitpunkt wo der Loop definitiv bereits bestand), was durchaus mit verloren gehenden BPDUs zusammenhängen könnte.
Hast du Gewissheit, dass es ein Loop ist, oder ein Switch oder mehrere das glauben?
Ich bin mir ziemlich sicher - man sieht alle Ports auf allen Switches dauerhaft blinken und die NICs in den Servern verzeichnen teilweise über 1 Mpps.
Wenn man da mit tcpdump reinhört sieht man auch zigtausendfach die selben ARP-Anfragen kommen.
Wer ist der Switchhersteller?
Ubiquiti
Du nutzt die Switches im mittleren Rack für SAN und LAN gleichzeitig?
Das Storage ist ein Ceph, da hast du by Design mehrere VLANs mit unterschiedlichen Funktionen.
Ansonsten laufen in einem VLAN nur noch Protokolle für die HA-Umgebungen der virtuellen Maschinen.
Das Design, ich würde es als selten bezeichnen, ist weshalb im Einsatz?
Wie ganz oben beschrieben soll es die folgenden Eventualitäten (einzeln oder in Kombination) kompensieren:
- Ein Switch fällt komplett aus
- Ein Transceiver fällt aus (und dadurch verliert ein Server die Anbindung zu einem der Switches)
- Ein Transceiver auf der Verbindung zwischen zwei Switches fällt aus
Die Syslogs werden dir nur bedingt helfen, wenn dein Forwarding crasht oder zu crashen droht.
Ganz ehrlich, echtes logging sollte über die serielle Verbindung laufen. Ich glaube, die Unifis können das.
Ich habe immer einen kleinen Optiplex mit 12 COM Ports dabei für das logging.
BPDUs und deren teilweise unmögliche Implementierung sorgt nicht selten für Spaß. Ich sage nur Hello Time.
Die Bewertung über zu viele redundante Pfade kann man pauschal nicht treffen.
Die Frage ist primär nach dem Grund des Designs und die Sicherheit, dass es nicht zu Loops oder dergleichen kommt.
Hast du Gewissheit, dass der Loop bestehen bleibt oder kann es auch sein, dass die Switches such nicht wieder einkriegen und der Loop nur temporär war?
Wie gesagt, dass Design ist zulässig, wenn auch selten.
Ganz ehrlich, echtes logging sollte über die serielle Verbindung laufen. Ich glaube, die Unifis können das.
Ich habe immer einen kleinen Optiplex mit 12 COM Ports dabei für das logging.
BPDUs und deren teilweise unmögliche Implementierung sorgt nicht selten für Spaß. Ich sage nur Hello Time.
Die Bewertung über zu viele redundante Pfade kann man pauschal nicht treffen.
Die Frage ist primär nach dem Grund des Designs und die Sicherheit, dass es nicht zu Loops oder dergleichen kommt.
Hast du Gewissheit, dass der Loop bestehen bleibt oder kann es auch sein, dass die Switches such nicht wieder einkriegen und der Loop nur temporär war?
Wie gesagt, dass Design ist zulässig, wenn auch selten.
Was die restlichen Switches angeht, könnte ich natürlich in jedem Rack jeweils einen Switch mit 16k Priorität versehen,
Das bringt nichts, denn die Pfade sind mit dem Root und Backup Root Switch ja eh fest vorgegeben.Die Syslogs werden dir nur bedingt helfen, wenn dein Forwarding crasht oder zu crashen droht.
Man kann dann aber immer den Auslöser dingfest machen ! In so fern ist das schon hilfreich.Einzelne Switches behaupten, sie würden eine Topologieänderung sehen
Das darf ja niemals sein !In einer statischen Topologie wie dieser darf es niemals zu Topo Changes kommen ? Wie auch denn dort ist ja alles fix wenn der STP einmal berechnet wurde. Es sei denn du ziehst willentlich einen der Uplinks oder dieser fällt aus ?!
Das solltest du also mal ganz genau untersuchen wer oder was da der Auslöser ist.
Topo Changes sollten niemals auftauchen. Sowas ist dann eher ein Indiz auf einen defekten Port, Kabel oder Optik.
Wenn man da mit tcpdump reinhört sieht man auch zigtausendfach die selben ARP-Anfragen kommen.
Uuuhhhh, definitiv ein Loop. Das ist ein Klassiker....Ubiquiti
Kein Kommentar ! Sowas hat in einem RZ Design nichts zu suchen. Oder was erwartest du von einem WLAN Hersteller ?!Das ist OEMter Billigmist der gar nicht von denen kommt geschweige denn entwickelt wurde. Massenbarebone von Accton.
Gut, hilft dir auch nicht weiter und ist ggf. fehl am Platze hier, da wohl nicht mehr zu ändern aber so ein RZ Design damit zu lösen hat schon etwas von Fahrlässigkeit.
Nachtrag:
Du schreibst die Switches 3,4,5 UND 6 haben die Priorität 32k? Das kann zu Problemen führen oder längeren oder häufigere Aktivitäten im "Baum".
Bezüglich Design Anmerkung.
Wenn du keine bombproofed Switches für konvergierten SAN und LAN Traffic hast, das ist der Fall bei den UBNTs, dann solltest du Abstand von dem Design nehmen, wenn die Umgebung wichtig ist.
Auch im Jahr 2020 ist es ein guter Rat, wenn die beiden SAN Switches völlig autonom für dich allein eine Storage Domain machen.
Konvergieren ja, find ich auch toll, dann aber nicht mit UBNT.
Heißt Standalone EX-16 mit VLAN für Storage Domain und untagged LAN für Controller und Logging-Zwecke. Das zwei Mal.
Du schreibst die Switches 3,4,5 UND 6 haben die Priorität 32k? Das kann zu Problemen führen oder längeren oder häufigere Aktivitäten im "Baum".
Bezüglich Design Anmerkung.
Wenn du keine bombproofed Switches für konvergierten SAN und LAN Traffic hast, das ist der Fall bei den UBNTs, dann solltest du Abstand von dem Design nehmen, wenn die Umgebung wichtig ist.
Auch im Jahr 2020 ist es ein guter Rat, wenn die beiden SAN Switches völlig autonom für dich allein eine Storage Domain machen.
Konvergieren ja, find ich auch toll, dann aber nicht mit UBNT.
Heißt Standalone EX-16 mit VLAN für Storage Domain und untagged LAN für Controller und Logging-Zwecke. Das zwei Mal.
ich hänge mich mal hier mit ran, da ich selbst auch Ubiquti Switche in einem großen Netzwerk im Einsatz habe und auch hin und wieder Spanning Tree Topo Changes habe. Aber keine Schleifen direkt.
Sicher das du auch MSTP verwendet? Ich habe die UniFi Serie im Einsatz , nicht die Edge. Und die unterstützen über dne controller nur RSTP
Sicher das du auch MSTP verwendet? Ich habe die UniFi Serie im Einsatz , nicht die Edge. Und die unterstützen über dne controller nur RSTP
Der eine nur RSTP der andere auch MSTP...klingt alles richtig gruselig für ein RZ.
