coreknabe
Goto Top

Fragen zu STP

Moin,

wir gestalten unser Netzwerk etwas aktueller und wollen und die letzten drei Altgeräte (Dell Powerconnect) durch Ruckus drei Ruckus ICX7450-48 ablösen. Zusätzlich werden in den Ruckus 12 10Gbit-Ports verbaut, die Geräte sollen dann im Stack als Coreswitche laufen. Spanning Tree im Netzwerk ist aktiv (802-1w).

Ein paar Fragen zu STP:
- Die Root Bridge wird getauscht, allgemein heißt es nur, man soll das nicht im Tageshochbetrieb machen. Sind grundsätzlich Ausfallzeiten damit verbunden, durch Neuaufbau der Topologie? In unserem Netz laufen etwa 10 andere Switche, Ruckus ICX7250 und eine alte HP-Schleuder.
- Wenn die ICX7450 als Dreierstack laufen und die Root Bridge-Rolle innehaben, dann hat quasi 1 Gerät den Hut auf und wenn dieses ausfällt, übernimmt automatisch eines der beiden anderen die Rolle? So wie ich das verstehe, soll die Priorität im Stack angeglichen werden, müssen also so sein, wie ich vermute? Oder muss ich eine Backup Root Bridge konfigurieren?
- Empfiehlt es sich, die Uplink-Ports (Glasfaser) zu den anderen Switchen aus der STP-Konfig herauszunehmen, um zu verhindern, dass ein ganzes Segment im Loop-Fall abgeschnitten wird? Wird in einem Video von Ruckus so gemacht.
- Wir haben aktuell eine Single-Domäne für STP konfiguriert, weil mir damals (noch unter Brocade-Flagge) ein Techniker gesagt hat, ich solle das nicht per VLAN machen, weil es mit den Switchen anderer Hersteller Probleme geben könnte. Alle Best Practices, die ich mir angesehen habe, sagen aber etwas anderes. Was denn nun?

Danke vorab für Eure Meinungen / Erfahrungen!

Gruß

Content-Key: 515112

Url: https://administrator.de/contentid/515112

Ausgedruckt am: 29.03.2024 um 05:03 Uhr

Mitglied: brammer
brammer 14.11.2019 um 10:06:54 Uhr
Goto Top
Hallo,

was spricht den dagegen den ICX7250 zur Root Bridge zu machen, den ICX7450 umzubauen und dann den wieder zur Root bridge zu machen?
Das kannst du gemütlich außerhalb der Bürozeit machen...

brammer
Mitglied: Coreknabe
Coreknabe 14.11.2019 um 10:59:35 Uhr
Goto Top
Moin brammer,

da spricht nix dagegen. Beantwortet aber meine eigentlichen Fragen nicht.
Ausfallzeit? Downtime? Andere Fragen? face-smile

Gruß
Mitglied: Coreknabe
Coreknabe 14.11.2019 um 11:11:32 Uhr
Goto Top
Habe noch das hier gefunden:
Brocade ICX 6450 STP Blocking

Da wir noch eine HP-Kiste im Netz haben, schließt das also PVSTP aus...
Mitglied: LordGurke
Lösung LordGurke 14.11.2019 um 11:18:34 Uhr
Goto Top
Wenn sich die Root-Bridge ändert müssen gemäß Standard erstmal alle Ports auf Blocking-State gehen, bis klar ist, wer die neue Root-Bridge ist.
Die Downtime liegt nach meiner Erfahrung bei RSTP über 11 Switches bei ca. 20 Sekunden.
Wenn es keine klar definierte Backup-Root-Bridge gibt und per Abstimmung erstmal eine neue gewählt werden muss, kann das aber auch durchaus 30-40 Sekunden lang dauern.

Du solltest also vorher einen anderen Switch zur Backup-Bridge konfigurieren.

Was STP und VLAN angeht:
Klassisches STP kann nicht mit VLANs umgehen. Dafür benötigt es MSTP und gerade preisoptimierte Switches sind leider oft nicht in der Lage diese BPDUs zu erzeugen oder zu verstehen.
Problematisch wird es, wenn solche Switches daran teilnehmen:
Erstmal kannst du dir so unerklärbare Loops bauen (weil die Switches die BPDUs teilweise verschlucken und dadurch an der Stelle kein Loop erkannt wird) und zum anderen kannst du dir umgekehrt auch Traffic unterbrechen, wenn der billige Switch behauptet einen Loop zu sehen, wo aber keiner ist, weil auf dem Port nicht alle VLANs durchlässig sind.

Wir setzen aktuell nur MSTP ein und haben damit keine Probleme.
Mitglied: Coreknabe
Coreknabe 14.11.2019 um 11:55:34 Uhr
Goto Top
Du solltest also vorher einen anderen Switch zur Backup-Bridge konfigurieren.

D.h., mit der Backup-Bridge geht es schneller, korrekt? Wenn jetzt keine konfiguriert ist und ich erstelle eine, bringt das auch eine Downtime mit sich?
Alternativ, noch ist die Root Bridge ja im Einsatz, konfiguriere ich jetzt eine Root Bridge und lasse die Backup Bridge noch online, geht das auch schneller?
Mitglied: Coreknabe
Coreknabe 14.11.2019 um 17:42:24 Uhr
Goto Top
Mir brummt ein wenig der Schädel, ich konnte zu einer möglichen Downtime sowohl Links finden, die eine sekundenlange Downtime bestätigen. Allerdings auch welche, die behaupten, dass es kaum Downtime gibt?

https://community.infosecinstitute.com/discussion/52440/stp-vs-rstp-conv ...

Weiß jemand mehr?
Mitglied: aqui
Lösung aqui 15.11.2019 aktualisiert um 14:03:51 Uhr
Goto Top
durch Ruckus drei Ruckus ICX7450-48 ablösen
Eine gute Wahl !
Zu den Fragen:
Ruckus ICX7250 und eine alte HP-Schleuder.
Bedenke hier das die Ruckus Switches wie fast alle Premium Hersteller per Default PVSTP machen !!
Sprich ein Per VLAN Spanning Tree. Also in jedem VLAN rennt eine eigenständige STP Instanz. Allerdings hier im Gegensatz zu Cisco mit den Standard BPDU Mac Adressen (Cisco benutzt bei deren PVSTP+ proprietäre Mac Adressen).
PVSTP ist nicht kompatibel zu Single Spanning Tree was du vermutlich auf den (Zitat) alten HP Schleudern aktiv hast.
Das im Mischbetrieb gibt dann sofort Chaos im Netzwerk mit unkalkulierbarem Verhalten sofern man mehrere VLANs betreibt.
Hier musst du also gewaltig aufpassen, denn das ist ein Punkt den STP Laien immer falsch machen und dann ins Verderben rennen.
Sollen die HP Gurken weiterbetrieben werden, dann hast du nur 2 Optionen:
  • Ruckus ICXe auf Single Span Betrieb umschalten so das sie wie die HPs laufen.
  • HP und ICXe auf MSTP konfigurieren, wenn man auf einem per VLAN Spanning Betrieb bleiben möchte.
Der große Nachteil bei Single Span ist das wenn es in einem VLAN mal rumpelt gleich in allen rumpelt. Das ist bei einem per VLAN STP Verfahren nicht so. Letztere sind also Betriebs sicherer. Zudem bieten sie bei redundanten Uplinks zum Access ein Balancing was mit Single Span unmöglich ist.
Generell macht man aber bei redundanten Uplinks kein STP mehr sondern betreibt die immer mit einem LACP LAG was erhebliche Vorteile bietet. Redundanz plus doppelte Bandbreite mit Failover.
In einem gestackten Core sieht so ein klassisc hes design dann immer so aus:
stackdesign
Das solltest du also auch imemr umsetzen wenn irgend möglich.
Ganz auf STP zu verzichten geht aber nicht wegen der Gefahr von Loops die versehentlich oder vorsätzlich gesteckt werden können. In so fern bleibt es bei einem Mischbetrieb mit dümmeren Switches wie den HPs immer bei der Endtcheidung Single Span oder MSTP.
Das der Root und Backup Root im Core dann per globaler Priority fest definiert werden muss ist klar.
Wenn du diese Dinge beachtest wird auch nix schief gehen. Oben ist ja schon mehr oder weniger alles gesagt worden dazu.
Zum Thema MSTP Integration gibt es hier einen guten Thread zu dem Thema:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)
Da die Ruckus zu 90% Cisco CLI identisch sind ist das ein guter Anhaltspunkt wenn man in Richtung MSTP gehen will.
Mitglied: Coreknabe
Coreknabe 15.11.2019 um 16:38:50 Uhr
Goto Top
Danke, aqui!

Kannst Du mir vielleicht sagen, wie es sich mit der Downtime bei Wechsel der Root Bridge verhält? Ich bekomme bisher nur widersprüchliche Aussagen...
Mitglied: aqui
Lösung aqui 15.11.2019 aktualisiert um 16:48:23 Uhr
Goto Top
Wenn du RSTP nutzt in einem PVST Design ist das Sub Second. Ebenso im Single Span mit RSTP. Auch da ist es immer unter einer Sekunde. Das ist im RSTP so definiert !! (Das ist das "Rapid" in Rapid Spanning Tree face-wink )
Voraussetzung ist aber das Root und Backup Root definiert sind ! Muss der RSTP Prozess diese noch bestimmen kann das erheblich länger dauern.
AUFGEPASST !!!
Auf keinen Fall "spanning-tree rstp" im ICX verwenden !! Das ist der alte RSTP Draft 3 !
Es muss in jedem Falle "spanning-tree 802.1w" sein, das ist der aktuelle Draft 4. Der Draft 3 schlatet mit Szandard STP zurück und hat erheblich länger Konvergenz Zeiten die weit über einer Sekunde liegen.
Aber wie gesagt. Mit dem design was du anstrebst hast du Spanning Tree nur noch im Edge und dann ist das irrelevant, denn im Core arbeitest du ja dann mit einem Full Stack und LACP LAGs zum Access.
Mitglied: Coreknabe
Coreknabe 15.11.2019 um 16:59:02 Uhr
Goto Top
Super, 802-1w verwenden wir auch.

Dann bastel ich mir noch eine Backup Root Bridge, bevor ich dann einen anderen Switch zur Root Bridge bestimme. Danach kann ich dann hoffentlich die alte Root Bridge (Dell) aus dem Netz nehmen.

Dir vielen lieben Dank und ein schönes Wochenende!
Mitglied: aqui
aqui 15.11.2019 aktualisiert um 17:41:15 Uhr
Goto Top
Super, 802-1w verwenden wir auch.
👍
bevor ich dann einen anderen Switch zur Root Bridge bestimme
Versteh ich nicht ganz ?? Oben schreibst du doch das dein neuer 7450 3er Stack als Core laufen soll was ja auch richtig ist.
Dann setzt du dem mit spanning-tree 802.1w priority 8192 den Stack zum Root Switch und fertig.
Das kannst du machen wenn der Dell auch noch Root Switch ist und auch die 8192 als Prio hat. Wenn es eine Prio Gleichheit gibt ist dann die Mac Adresse der Tie Break. Niederigere Mac gewinnt.
Falls der Dell die 8192 hat oder auch höher reicht es auch wenn du dem ICX Stack dann eine Prio gibst die höher ist als der Dell (niedrigerer Prio Wert modulo 4096). Dann ist der Stack dann sofort der Root Switch sowie du den ins Netz hängst.
Dann kannst du den Dell vollkommen unterbrechnugsrfrei entfernen, denn wenn der Stack eh schon Root ist kommt es natürlich nicht mehr zum Aushandeln eines neuen Root Switches.
So oder so wird der Ausfall sofern es einen gibt in keinem Falle mehr als 4-5 Sekunden dauern was schon worst case wäre.
Mitglied: Coreknabe
Coreknabe 18.11.2019 aktualisiert um 09:59:27 Uhr
Goto Top
Moin aqui,

danke auch für Deine weiteren Anregungen!

Nach reiflicher Überlegungen werde ich die drei ICX7450 jetzt doch einzeln, und nicht im Stack laufen lassen. Die grundsätzlichen Für und Wider beim Einsatz eines Stacks bei Core Switchen sind hinlänglich bekannt, dürfte eine reine Glaubensfrage sein. Und manchmal auch der konkrete Anwendungsfall. Bei mir z.B. lasse ich redundante Leitungen über die Switche laufen (HyperV Hosts im Team, redundantes iSCSI mit Failover für die VMs...). Von der vereinfachten Administration mal abgesehen, hat mich das ISSU-Feature bei den Ruckus Switchen gelockt. Zum Einen aber dauert ein Switch-Software-Update mit dieser Lösung deutlich länger, zum Anderen funktioniert das nur, wenn ich Update der Minor Releases machen will. Bei Major Releases erwischt es den kompletten Stack inkl. Downtime für VMs und Co.

Noch mal für mich zur Absicherung: Ich kann also einen neuen Switch als Root Bridge konfigurieren, BEVOR ich ihn ins Netz gehängt habe. Dann binde ich ihn an und der wird sofort Root Bridge, ohne dass großartig diskutiert wird / es zu Problemen kommt. So?
Mitglied: aqui
aqui 18.11.2019 um 13:16:32 Uhr
Goto Top
werde ich die drei ICX7450 jetzt doch einzeln, und nicht im Stack laufen lassen
Ohne dein Netz jetzt im Detail zu kennen halte ich das für einen fatalen Fehler. Denn das bedeutet das du dann mit Spanning Tree und VRRP arbeiten musst bei Redundanz.
Das erhöht den Konfig Aufwand erheblich und auch die Fehleranfälligkeit.
Das solltest du dir also nochmal reiflich überlegen ob du das wirklich willst. Die ICXe supporten horizontal Stacking die Stack Member müssen also noch nicht einmal im gleichen Raum sein ! Du gibst da dann ohne Grund einen großen Vorteil auf. Eine Glaubensfrage ist das keineswegs, denn der Stack hat klare Vorteil sofern er redundant ausgelegt ist von den Stack Links (Daisy Chaining). Aber letztlich natürlich deine Entscheidung....
Zum Einen aber dauert ein Switch-Software-Update mit dieser Lösung deutlich länger,
Wie kommst du darauf ? Ein Irrglaube. Hast du das denn schon einmal gemacht ?? Scheinbar nicht. Das copy tftp flash... machst du im Stack nur einmal. Während des kopierens wird es automatisch parallel auf alle Stack Member geflasht. Dabei ist es egal ob du ein 2er, 4er oder 12er Stack hast geht alles gleich schnell da ja parallel.
Bei Major Releases erwischt es den kompletten Stack inkl. Downtime für VMs und Co.
Richtig. Aber daran siehst du auch das ISSU ja nix mit dem Stack oder Einzelbetrieb zu tun hat !!
Bei einem Major Update musst du immer rebooten egal ob Einzelgerät oder Stack. Reboot Zeit ist ca. 3 Minuten. Das kann man in einem geregelten 15 Minuten Wartungsfenster immer umsetzen.
Dann binde ich ihn an und der wird sofort Root Bridge, ohne dass großartig diskutiert wird
Nicht ganz. Ja er wird sofort zur Root Bridge aber es gibt natürlich eine Spanning Tree Recalculation auf allen Switches. Es rumpelt also etwas im Hintergrund was aber keine Auswirkungen auf den Betrieb hat soalngt du die neue Root Bridge nur einbeinig anbindest ohne Backup Limkls.
Solltest du Backup Limnks haben kann es durch die dann ggf. erfolgenden Verschiebungen des Root Pfads im Spanning Tree zu einem kurzen max. 3 Sekunden Aussetzer bei RSTP kommen im Worst Case. Dazu müsste man aber mal deine Topologie kennen.
In einem simplen linearen Netz ohne große paralle Backup Links wie im obigen Bild mit den LACP LAGs wirst du rein gar nichts bemerken, da geht es dann sub second.
Mitglied: Coreknabe
Coreknabe 18.11.2019 um 14:51:54 Uhr
Goto Top
Eine Glaubensfrage ist das keineswegs, denn der Stack hat klare Vorteil sofern er redundant ausgelegt ist von den Stack Links (Daisy Chaining). Aber letztlich natürlich deine Entscheidung....

Da muss ich Dir widersprechen, lieber aqui. Die Meinungen gehen durchaus auseinander...
https://blogs.arubanetworks.com/solutions/stacking-network-switches-why- ...
https://community.spiceworks.com/topic/445482-to-stack-or-not-to-stack


Zum Einen aber dauert ein Switch-Software-Update mit dieser Lösung deutlich länger,

Wie kommst du darauf ? Ein Irrglaube. Hast du das denn schon einmal gemacht ?? Scheinbar nicht. Das copy tftp flash... machst du im Stack nur einmal. Während des kopierens wird es automatisch parallel auf alle Stack Member geflasht. Dabei ist es egal ob du ein 2er, 4er oder 12er Stack hast geht alles gleich schnell da ja parallel.

Ich selbst habe das noch nicht gemacht, aber Terry Henry hat's gemacht face-smile
https://www.youtube.com/watch?v=A4U12Q7Gtc4

Richtig. Aber daran siehst du auch das ISSU ja nix mit dem Stack oder Einzelbetrieb zu tun hat !!
Äh, doch? Ohne den Stack bräuchte ich das ISSU ja nicht?!?

Bei einem Major Update musst du immer rebooten egal ob Einzelgerät oder Stack.
Korrekt. Aber Leitung 1 hängt auf Switch 1, Leitung 2 (redundant) auf Switch 2. Beide einzeln updaten und rebooten, fertig is der Lack.

In einem simplen linearen Netz ohne große paralle Backup Links wie im obigen Bild mit den LACP LAGs wirst du rein gar nichts bemerken, da geht es dann sub second.
Danke noch einmal für die hilfreiche Erläuterung, damit hast Du mir sehr geholfen!
Mitglied: aqui
aqui 18.11.2019 um 15:39:42 Uhr
Goto Top
Na ja zu dem Aruba/HP Blog sag ich jetzt mal nix. Jie können gar kein Full Stack und machen nur billiges Clustering (gemeinsames Management only).
Gut die Punkte sind sachlich richtig aber haben in der Praxis keine Relevanz weil die Vorteile überwiegen. Das einzige Argument was richtig ist, ist der Fakt wenn man an so einem Core Stack etwas erweitert oder verkleinert, sprich die Member Hardware verändert, was dann eine Unterbrechung bedingt. Das hast du aber auch bei Einzelswitches.
Der Ausfall eines Stack Members bedeutet nicht den Ausfall des Stacks an sich. Die ICX haben dort auch ein hitless Failover auf den Backup Master.
Und ein Daisy Chaining (Ring) ist de facto redundant. deshlab kamcht man es ja genau so und nicht rein nur linear. Vermutlich können die billigen HP Schrottteile sowas nicht da sie ja dedizierte Stackports haben was heutzutage nicht mehr zeitgemäß ist. HP soll Server und Drucker bauen, das können sie besser als Netzwerke mit ihrem rein extern zugekauften Zoo an Geräten. Mehr muss man dazu nicht sagen...
Jeder der Stacks einsetzt (und zwar richtige Full Stacks wie in den ICX) wird dir bestätigen das die Vorteile in keinem Verhältnis zu den Nachteilen stehen. Der Grundtenor bei Spiceworks sagt das ebenso.
Aber letztentlich ist das natürlich immer eine individuelle Entscheidung des Netzwerk Admins vor Ort.
Ich selbst habe das noch nicht gemacht
OK, ISSU ist immer hitless, da braucht man kein YouTube Video dazu face-wink Bei Mayor Updates musst du rebooten das ist bei allen Herstellern so.
Ohne den Stack bräuchte ich das ISSU ja nicht?!?
Falsch, du kannst ja auch bei einem Einzelswitch ISSU machen. Bedeutet ja nur das man ein Software Update ohne Reboot ausführen kann. Ob das ein Stack ist oder Einzelswitch ist dabei völlig Latte face-wink
Beide einzeln updaten und rebooten, fertig is der Lack.
Ja, das ist letzlich richtig. Bezieht sich auch auf den HP Punkt. Es sei denn du rebootest den Root Switch, dann hast du wieder 3 Sek. Spanning Tree Outage.
Aber um was reden wir hier. In Summe sind das max. 5 Minuten Reboot Zeit im Worst Case wenns mal ein Major Update ist. Wie oft kommt das vor und wie oft hast du Wartungsfenster ? Eine IT Umgebung ohne Wartungsfenster gibt es nicht oder sie ist dann vollredundant. Da sollte man auch mal die Kirche im Dorf lassen...
Aber wie gesagt. DU bist der Admin, DU entscheidest letztendlich denn DU musst das am Ende managen. Als unbeteligter Forenuser kann man das letztendlich auch niemals objektiv beurteilen ohne alle Fakten und Anforderungen an deine Infrastruktur genau zu kennen.
Mitglied: Coreknabe
Coreknabe 20.11.2019 um 13:42:38 Uhr
Goto Top
Abschlusskommentar: Hat alles geklappt, allerdings hat es an ein, zwei Stellen noch etwas geruckelt. Für die Uplink-Ports musste ich noch "spanning-tree 802-1w admin-pt2pt-mac" einflippern, so geht's dann nahezu ohne Ruckler.

Danke, aqui!
Mitglied: aqui
aqui 20.11.2019 um 13:48:07 Uhr
Goto Top
Für die Uplink-Ports musste ich noch "spanning-tree 802-1w admin-pt2pt-mac" einflippern
Uhhh, shame on me ! Du hast natürlich Recht. Das habe ich oben leider übersehen, sorry. face-sad
Sollte man auf allen Backbone Ports machen..beidseitig.