Frage zu RSTP

[Eleu]

Hallo,

ich habe eine Frage zu RSTP.  Wir haben an unseren Etagenswitchen, managebare Switche kaskadiert. Diese sind nicht über LWL verbunden, sondern über Kupfer – Patchkabel. Zu Beginn, hat der Etagenswitch den Port zum unterlagerten Switch geblockt, da dieser BPDU Pakete vom angeschlossenen managebaren Switch erhalten hat.  Damit der Port nicht mehr geblockt wird, wurde auf dem kaskadierten, Switch auf dem Uplink Port zum Etagenswitch, dass RSTP ausgeschaltet. Dadurch sendet dieser keine BPDU Pakete mehr und seit dem funktioniert die Kommunikation.

Was ich noch nicht verstanden habe ist, warum der Etagenswitch den Port blockt, wenn er BPDU Pakete erhält? Ich dachte immer das RSTP sich automatisiert abspielt? Ich hätte angenommen, dass der kaskadierte Switch einfach mit in die konfigurierte Baumstruktur des Root – Switches aufgenommen wird?

Gruß

Eleu  

[tmp]

Wenn rstp in allen switches aktiviert ist, sollten die Switches sich entsprechend automatisiert konfigurieren.
Was du beschreibst, klingt erstmal nach ganz normalen rstp-verhalten, wenn es irgendwo Schleifen gibt. Ist denn die Erreichbarkeit zwischen zwei Knoten überhaupt irgendwie eingeschränkt?
Um mehr zu sagen zu können, wären ein Diagramm und die Konfigs hilfreich.

[Eleu]

vor 2 Minuten schrieb tmp:

Wenn rstp in allen switches aktiviert ist, sollten die Switches sich entsprechend automatisiert konfigurieren.
Was du beschreibst, klingt erstmal nach ganz normalen rstp-verhalten, wenn es irgendwo Schleifen gibt. Ist denn die Erreichbarkeit zwischen zwei Knoten überhaupt irgendwie eingeschränkt?
Um mehr zu sagen zu können, wären ein Diagramm und die Konfigs hilfreich.

Ich administriere nur die unterlagerten Switche. Die Etagenswitche werden von unserer IT administriert. Auf den unterlagerten Switchen ist Global die Funktion RSTP eingeschaltet. Wie gesagt, ist dediziert an dem Uplink Kupfer Port zum Etagenswitch STP deaktiviert. Kann es sein, dass es auf dem Etagenswitch die Ports per default so eingestellt sind, dass nur Endgeräte, die keine BPDU Pakete senden angeschlossen werden dürfen und wenn doch BPDU Pakete empfangen werden, dieser Port dann geblockt wird?

Normalerweise werden ja nur Switche von unserer IT Abteilung zur Netzwerkinfrastruktur hinzugefügt und dann schalten die den entsprechenden Port vielleicht dafür frei?  

[Tearek]

Ich hatte in einer Außenstelle mal was ähnliches, da hatte ein Kollege an dem "core" (so nenn ich das jetzt einfach mal) auf allen ports (cisco) Spanning-tree portfast konfiguriert. Da war das problem das gleiche.

 

http://www.nwlab.net/know-how/Cisco/bpdu-guard.html

[Eleu]

Die Frage wäre nur, ob diese Konfiguration vielleicht zukünftig mal Probleme verursachen könnte? Gibt es noch andere Layer 2 Redundanzprotokolle, die nicht mit BPDU Paketen arbeiten? Mal angenommen, es wird in der Hinsicht was erweitert, oder von unserer IT geändert? Aus dem Bauch raus, würde ich sagen kein Problem, aber ich weiß nicht wie die unterlagerten Switche reagieren, wenn da plötzlich irgendwann mal andere Redundanz Protokolle auflaufen? Es sind ja Switche und keine Endgeräte... 

[Tearek]

Also switches würde ich grundsätzlich immer mit 2 beinen anbinden. Möglicht an 2 verschiedenen switches (heißt bei uns gibts 2 cores, die cores sind in 2 weit auseinander liegenen RZ`s und jeder Etagenverteiler geht mit einem bein an jeden core(VSS mittlerweile heißt das glaub StackWise-Virtual) also min immer 2 Uplinks. Das ist teurer, bei kleineren firmen lässt sich aber vlt was ähnliches realisieren und anderen fehlern (vor allem ausfällen) vorbeugen. Wenn du nur die EV hast, sind dort evtl mehrer Switches / Stacks über die du die switches die du betreust (sind die in den büros?) anbinden kannst ?

außerdem konfiguriere ich bei unseren Switches Immer LACP, nen switch über STP /RSTP /MSTP

[Eleu]

vor 3 Minuten schrieb Tearek:

Also switches würde ich grundsätzlich immer mit 2 beinen anbinden. Möglicht an 2 verschiedenen switches (heißt bei uns gibts 2 cores, die cores sind in 2 weit auseinander liegenen RZ`s und jeder Etagenverteiler geht mit einem bein an jeden core(VSS mittlerweile heißt das glaub StackWise-Virtual) also min immer 2 Uplinks. Das ist teurer, bei kleineren firmen lässt sich aber vlt was ähnliches realisieren und anderen fehlern (vor allem ausfällen) vorbeugen. Wenn du nur die EV hast, sind dort evtl mehrer Switches / Stacks über die du die switches die du betreust (sind die in den büros?) anbinden kannst ?

außerdem konfiguriere ich bei unseren Switches Immer LACP, nen switch über STP /RSTP /MSTP

Die Switche, die ich betreue haben nicht die Eigenschaften, wie die Etagenswitche. Die Etagenswitche, verfügen auch über zwei LWL Anschlüsse und ich vermute, sie werden von zwei verschiedenen Core - Switchen aus zwei RZ`s angebunden (so wie du es beschreibst)?

Die vor Ort Switche, werden im Bereich der Automatisierung eingesetzt und haben eine geringere Portdichte (18 Ports) Geeignet für Schaltschrankeinbau (Hutschienenmontage etc.)   Die Geräte unterscheiden sich hinsichtlich der Konfigurationsmöglichkeiten aber vermutlich nicht sehr von den Access Switchen. Mit den Geräten, kann man zum Beispiel einen Hyper Ring, oder MRP realisieren. Die Switche hängen aber lediglich nur mit einem Gigabit Port an dem Etagenswitch.   

[Tearek]

Okay und bei den Switches ist keine Zweibeinige anbindung erforderlich/notwendig/gewünscht?

Also ich habe beigebracht bekommen switches werden in einer solchen struktur per LACP konfiguriert und zweibeinig angebunden. Immer.

Alternativ würde ich bei ner anbindung von Switch wenns garnicht anders geht und du die konfig der anderen switches auch nicht beeinflussen kannst den port als Trunk ohne STP konfigurieren. Eine Loop-freie umgebung sollte ja sowieso das ziel sein.

[Eleu]

vor 13 Minuten schrieb Tearek:

Okay und bei den Switches ist keine Zweibeinige anbindung erforderlich/notwendig/gewünscht?

Dieses Feature wird von den vor Ort Switchen nicht unterstützt. Ob das erforderlich/notwendig/gewünscht ist, kann ich dir auch nicht sagen. Die eingesetzten Geräte und die Topologie, ist unserer IT bekannt. D.h. es wird mir gewissermaßen vorgegeben. Es wäre möglich,  mehrere vor Ort Switche als Ring zu verbinden und dann ist ein Switch Redundanzmanager. Wird der Ring unterbrochen, schaltet der Redundanzmanager auf Linie um. Dazu hat jeder vor Ort Switch, zwei GBit Port, die man dafür dann konfigurieren kann.  Wir verwenden aber schon einen GBit - Port als Uplink zum Access Switch, also lässt sich damit der Ring schon mal nicht mehr realisieren. Loops werden vermieden, da ja auf allen anderen Ports, außer dem Uplink Port das STP eingeschaltet ist.    

Edit: Ein Trunk ist nicht nötig, da auf den vor Ort Switchen nur einziges VLAN verwendet wird. Aktuell das default VLAN mit der ID 1

Bearbeitet 19. August 2020 von Eleu

[tmp]

vor 2 Stunden schrieb Eleu:

Ich administriere nur die unterlagerten Switche. Die Etagenswitche werden von unserer IT administriert.

[...]

Normalerweise werden ja nur Switche von unserer IT Abteilung zur Netzwerkinfrastruktur hinzugefügt und dann schalten die den entsprechenden Port vielleicht dafür frei?  

Möglich. Würde vorschlagen, dass du mit denen redest.

Außerdem klingt das nach einem krassen Zuständigkeitsproblem, das solltet ihr dann vllt auch gleich angehen.

Ansonsten, wenn ihr sowieso keine Loops habt, braucht ihr nicht zwingend STP. Irgendwann kommt aber garantiert irgendeiner, der seinen Privatswitch irgendwo dawzischen schaltet und dann gibts Probleme. Also eigentlich schon zwingend.

[Eleu]

vor 15 Minuten schrieb tmp:

Möglich. Würde vorschlagen, dass du mit denen redest.

Außerdem klingt das nach einem krassen Zuständigkeitsproblem, das solltet ihr dann vllt auch gleich angehen.

Ansonsten, wenn ihr sowieso keine Loops habt, braucht ihr nicht zwingend STP. Irgendwann kommt aber garantiert irgendeiner, der seinen Privatswitch irgendwo dawzischen schaltet und dann gibts Probleme. Also eigentlich schon zwingend.

Was soll ich denn mit "denen" besprechen? Sie kennen ja die gegenwärtige Konstellation aller beteiligter Komponenten und es funktioniert ja alles. Was anderes wäre es, wenn zukünftig diesbezüglich Probleme zu erwarten sind, insofern sich bzgl. RSTP was ändert (Z.B. aufgrund anderer eingesetzter Redundanzprotokolle o.ä.?)  Wenn du da eine konkrete Info für mich hast, würde ich natürlich darauf hinweisen. Alle anderen Vor - bzw. Nachteile kennen die ja schon... 

[tmp]

joa, wie gesagt, ohne topologie und configs kann ich nichts konkretes sagen. aber wenn für dich alles geklärt ist, dann passt das doch. wenn verschiedene stp modi konfiguriert sind, wird normalerweise automatisch standard (ieee) stp verwendet.

[Craaq]

STP nie einfach grundlos deaktivieren,  Auch wenn die Switche aktuell nur einpfadig angebunden. Es könnte immer mal jemand ausversehen ein Loop stecken von Switch zu Switch. Welche Switche habt ihr im Einsatz? Eventuell ist auf den Ports noch der BPDU Guard aktiviert. Der nimmt den Port in error disabled, wenn BPDU dort ankommen.

[Tearek]

vor 16 Stunden schrieb Craaq:

STP nie einfach grundlos deaktivieren,  Auch wenn die Switche aktuell nur einpfadig angebunden. Es könnte immer mal jemand ausversehen ein Loop stecken

Grundsätzlich Korrekt, wenn aber jemand An den verbindungen zwischen den Switches (zu denen nur das dafür zuständige personal zugang haben sollte) Einfach wild kabel reinstecken, dann läuft da leider einiges Falsch.

Für gewöhnlich sollten die Personen (Netzwerkadmins) die solche Strecken anfassen wissen was sie tun und Zumindest die Uplinks Dokumentieren. Aber grade um Problemen wie diesen aus dem weg zu gehen -> LACP (ja hier vlt nicht das mittel der wahl weil nicht konfigurierbar).
 

Was genau für switches sind denn im einsatz?

[Eleu]

vor 54 Minuten schrieb Tearek:

Was genau für switches sind denn im einsatz?

Die Access Switche sind von Juniper und die kaskadierten vor Ort Switche, sind von Hirschmann RS30

[Craaq]

vor 3 Stunden schrieb Tearek:

Grundsätzlich Korrekt, wenn aber jemand An den verbindungen zwischen den Switches (zu denen nur das dafür zuständige personal zugang haben sollte) Einfach wild kabel reinstecken, dann läuft da leider einiges Falsch.

Für gewöhnlich sollten die Personen (Netzwerkadmins) die solche Strecken anfassen wissen was sie tun und Zumindest die Uplinks Dokumentieren. Aber grade um Problemen wie diesen aus dem weg zu gehen -> LACP (ja hier vlt nicht das mittel der wahl weil nicht konfigurierbar).
 

Was genau für switches sind denn im einsatz?

schon oft genug erlebt, dass user dann vornerum also vom Switch zu Netzwerkdose und das Kabel dann wieder in die Netzwerkdose auf einen anderen Switch durchgepatcht haben. Da bist du dann froh, wenn du sauber STP konfiguriert hast und es auch greift.

[Eleu]

vor 6 Stunden schrieb Tearek:

Aber grade um Problemen wie diesen aus dem weg zu gehen -> LACP (ja hier vlt nicht das mittel der wahl weil nicht konfigurierbar).

Es wäre sicher auch aus Gründen der Herstellerhomogenität besser, wenn man Juniper auch vor Ort einsetzen könnte? Ich hatte mal mit einem Kollegen aus der IT eine Diskussion darüber und er hat mir gesagt, dass Juniper halt nur Access Switche mit hoher Portdichte und vornehmlich für den Einbau in Etagenverteilern verkauft.

In Bereich der Automatisierung braucht man aber halt geringere Portdichten, da die einzelnen aktiven Komponenten, dezentral im Feld verteilt sind. Am besten Switche, geeignet für die Montage in einem Schaltschrank. 

Ich stelle es mir auch unwirtschaftlich vor, den Backbone aus beiden RZ`s zu allen einzelnen vor Ort Switchen zu ziehen. In den Etagenverteilern sind mehrere Access Switche eingebaut und über den Backbone sind dann alle einfach über LWL anzuschließen, da sie ja zentral im Etagenverteiler verbaut sind.    

Nun könnte man ja noch ein einige Juniper Switche nachrüsten und dann von dort aus alle aktive Komponenten einsammeln, was aber m.E. ein ziemlicher Verkabelungsaufwand wäre. Ich mag es mir gar nicht vorstellen. Die Kabelkanäle würden überquellen und ich glaube, da wäre ein neuer Etagenverteiler fällig, weil der Bestehende schon aus allen Nähten platzt.  

Kann man so oder so sehen. 

[Tearek]

vor 3 Stunden schrieb Craaq:

schon oft genug erlebt, dass user dann vornerum also vom Switch zu Netzwerkdose und das Kabel dann wieder in die Netzwerkdose auf einen anderen Switch durchgepatcht haben. Da bist du dann froh, wenn du sauber STP konfiguriert hast und es auch greift.

ich glaub wir sprechen vom selben ich hab nie gesagt, deaktiviere überall STP. Ich habe gesagt, auf den Uplinks  also den links von switch <-> zu switch wird STP deaktiviert. Dort hat ein Normaler User nix zu suchen.

[eneR]

STP macht einen Sinn wenn man gezielt die Uplinks deaktiviert. Selbst dann kann man, wie Craaq schrieb, relativ schnell Loops im Netzwerk haben. Und da ist es auch nicht unbedingt notwendig das jemand Zugriff auf die Etagenverteiler o.ä. hat. Und LACP ist auch nicht dafür gemacht Loops zu verhindern?! Aber es kommt wie immer drauf an.. vor allem wie die Verkabelung vor Ort in die Büros aussieht und ob dort vielleicht zusätzlich noch Mini-/Büro-/Tableswitche oder wie auch immer man die nennen möchte im Einsatz sind...

Ich würde hier eher nach dem Fehler suchen anstatt als einfachen Workaround STP auf einzelnen Ports zu deaktivieren..

[Eleu]

vor 19 Minuten schrieb eneR:

Ich würde hier eher nach dem Fehler suchen anstatt als einfachen Workaround STP auf einzelnen Ports zu deaktivieren..

STP ist aber nur am Uplink Port vom Hirschmann Switch deaktiviert. Nicht am Access Switch. Würde also wirklich jemand das LAN Kabel vom Uplink Port abziehen und einen Loop stecken, würde schlimmstenfalls der Hirschmann Switch aussteigen.  

  

[Craaq]

vor einer Stunde schrieb Eleu:

STP ist aber nur am Uplink Port vom Hirschmann Switch deaktiviert. Nicht am Access Switch. Würde also wirklich jemand das LAN Kabel vom Uplink Port abziehen und einen Loop stecken, würde schlimmstenfalls der Hirschmann Switch aussteigen.  

  

Und wenn switchübergreifend ein loop gesteckt wird? Wie schaltet ihr stp aus? Bpdu filter auf den uplinks? Grundsätzlich sollte stp funktionieren ohne es auf den uplinks auszuschalten. Eventuell per console mal die logs durchschauen bzw den einzelnen port wieso er dicht macht.

[eneR]

vor 2 Stunden schrieb eneR:

STP macht einen Sinn

Ich zitiere mich selber, haha... es macht natürlich "k"einen Sinn.. wo auch immer das k hin ist.

Ansonsten ja, es ist mühsam zu diskutieren da wir die Architektur nicht kennen... aber wie Craaq schon schrieb... da braucht ihr ja nur zwei von den "Hirschen" im selben Schrank hängen haben und jemand patcht ausversehen einen Interconnect.. dann hast du deinen Loop. 

[djmaker]

Ihr solltet mal schauen wie die BDPU-Config aussieht (Serial-Numer der Switche, bridge priority etc. pp.).

[Crash2001]

Auch auf den Uplinks sollte wenn möglich Spanning Tree gesprochen werden. Ausnahme ist eigentlich nur, wenn L3-Verbindungen genutzt werden für die Uplinks.

Ports als Trunk konfigurieren
Wenn man 2 oder mehr Uplinks hat, LACP-Channel drauf packen
RSTP aktivieren
STP Link Type auf Point to Point
Seiten BPDU Guard deaktivieren 
Portfast deaktivieren
Port-Security anpassen / ausschalten
DHCP Snooping auf Trust setzen für den Uplink Port
Bei Glas-Uplinks UDLD aktivieren


Natürlich jeweils auf beiden Seiten. Für mich klingt das, als ob die Uplinks auf der Gegenseite, für die du nicht zuständig bist, falsch konfiguriert sind, so dass der BPDU Guard anspringt. Dieser wird aber nur auf Client-Ports genutzt, da die Switche ja miteinender STP sprechen und somit BPDUs austauschen sollen.
Auf den Uplinks STP auszuschalten, oder einen BPDU Filter herzunehmen, ist totaler Humbug.

[Eleu]

Am 10.2.2021 um 13:44 schrieb Crash2001:

Auch auf den Uplinks sollte wenn möglich Spanning Tree gesprochen werden. Ausnahme ist eigentlich nur, wenn L3-Verbindungen genutzt werden für die Uplinks.

Ports als Trunk konfigurieren
Wenn man 2 oder mehr Uplinks hat, LACP-Channel drauf packen
RSTP aktivieren
STP Link Type auf Point to Point
Seiten BPDU Guard deaktivieren 
Portfast deaktivieren
Port-Security anpassen / ausschalten
DHCP Snooping auf Trust setzen für den Uplink Port
Bei Glas-Uplinks UDLD aktivieren


Natürlich jeweils auf beiden Seiten. Für mich klingt das, als ob die Uplinks auf der Gegenseite, für die du nicht zuständig bist, falsch konfiguriert sind, so dass der BPDU Guard anspringt. Dieser wird aber nur auf Client-Ports genutzt, da die Switche ja miteinender STP sprechen und somit BPDUs austauschen sollen.
Auf den Uplinks STP auszuschalten, oder einen BPDU Filter herzunehmen, ist totaler Humbug.

Hallo Crash2001 ,

auf meiner Seite ist der BPDU Guard jedenfalls per default ausgeschaltet. Den kann ich nur global, für alle Ports ein- bzw. ausschalten. Ich gehe ja mal ganz stark davon aus, dass auf den Access Swichen unserer IT, auf den Kupfer Ports der BPDU Guard eingeschaltet ist (Damit eben keiner einfach einen Switch dranhängen kann)? Ich müsste unsere IT ansprechen, ob die das testweise für den Port an dem mein Switch hängt ausschalten? Dann könnte ich das STP mal wieder aktivieren und dann mal schauen, ob die Kommunikation noch funktioniert.

Wenn ja, würde mein Switch in die Spanningtree Struktur, der gesamten Netzwerkinfrastruktur mit aufgenommen, nehme ich an? Na, ob die das wollen?

Gruß

Eleu