13.01.2020, aktualisiert am 20.02.2020

13456

Spanning Tree Probleme - topology change received - RSTP

Servus alle miteinander,

ich habe leider seit ein paar Wochen Probleme, dass einige ThinClients (vielleicht 20 von 250) kurzfristig ihr Netz verlieren. 1-2 Sekunden, manche aber auch länger.

Im CoreSwitch und dementsprechend auch im Syslog erhalte ich immer wieder spanning tree topology change received.

Auch wenn die Hardware nicht die "beste" Auswahl ist und einige mit den Augen rollen werden und Aqui die Hände über den Kopf zusammenschlägt, hoffe ich auf eure Hilfe oder euren input.

Die Topologie habe ich mal grob aufgezeichnet . Insgesamt sind ca 100 Switche am Netz. Grund sind sehr viele Maschine, PC, Endgeräte, großes Gelände etc.

Core: 2x Netgear M4300-24X gestacked, Layer 3, ca 50 VLAN, 2 weitere M4300 als SFP geplant, um LAG bei allen Verteilerswitchen verwenden zu können.

AccessSwitche: Unifi 48 Port POE, dazwischen Unifi Glasswitche zum verteilen.

Einige Switche sind über LACP LAG angebunden, andere wiederum nicht. Je nachdem , ob es bisher möglich war.

Hier Auszüge vom Core:

<13> Jan 13 18:23:03 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476750 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Jan 13 18:23:01 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476749 %% Spanning Tree Topology Change: 0, Unit: 1
<13> Jan 13 18:23:01 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476748 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Jan 13 18:22:40 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476741 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Jan 13 18:22:38 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476740 %% Spanning Tree Topology Change: 0, Unit: 1
<13> Jan 13 18:22:38 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476739 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
<13> Jan 13 18:00:42 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476358 %% Spanning Tree Topology Change Received: MSTID: 0 1/0/15
<13> Jan 13 18:00:40 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476356 %% Spanning Tree Topology Change: 0, Unit: 1
<13> Jan 13 18:00:40 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476355 %% Spanning Tree Topology Change Received: MSTID: 0 1/0/15
<13> Jan 13 17:57:19 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476297 %% Spanning Tree Topology Change Received: MSTID: 0 1/0/21
<13> Jan 13 17:57:17 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476296 %% Spanning Tree Topology Change: 0, Unit: 1
<13> Jan 13 17:57:17 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476295 %% Spanning Tree Topology Change Received: MSTID: 0 1/0/21
<13> Jan 13 17:56:48 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476285 %% Spanning Tree Topology Change Received: MSTID: 0 1/0/21
<13> Jan 13 17:56:47 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476283 %% Spanning Tree Topology Change: 0, Unit: 1
<13> Jan 13 17:56:47 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476282 %% Spanning Tree Topology Change Received: MSTID: 0 1/0/21
<13> Jan 13 17:45:41 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476089 %% Spanning Tree Topology Change Received: MSTID: 0 1/0/23
<13> Jan 13 17:45:39 SW-CORE-01-1 TRAPMGR[dot1s_task]: traputil.c(795) 476087 %% Spanning Tree Topology Change: 0, Unit: 1

Wie ihr seht kommt der Change nicht nur von einen Port.

Was habe ich bisher gemacht:
Jeden Switch auf die STP Priority überprüft, Neueste Firmware, Neugestartet etc.

An Wochenenden oder in den Nachtschichten treten weniger Change befehle auf.

RSTP nach IEEE 802.1w verwende ich um eine "Sicherung" gegen Schleifen an den Access Switchen zu erhalten. Die Unifi Switche haben leider keine andere Loop Protection. Ein Neukauf von anderen Geräten steht nicht zur Debatte.

Auszug Core:

(M4300-24X) >show spanning-tree 

Bridge Priority................................ 4096
Bridge Identifier.............................. 10:00:08:BD:43:78:6F:7D
Time Since Topology Change..................... 0 day 0 hr 46 min 36 sec
Topology Change Count.......................... 1204
Topology Change in progress.................... False
Designated Root................................ 10:00:08:BD:43:78:6F:7D
Root Path Cost................................. 0
Root Port Identifier........................... 00:00
Bridge Max Age................................. 20
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 15
Hello Time..................................... 2
Bridge Hold Time............................... 6
CST Regional Root.............................. 10:00:08:BD:43:78:6F:7D
Regional Root Path Cost........................ 0
Port Triggered TC.............................. 1/0/22

Auszug Unifi Verteiler:

(UBNT) >show spanning-tree 

Bridge Priority................................ 16384
Bridge Identifier.............................. 40:00:FC:EC:DA:78:9A:73
Time Since Topology Change..................... 0 day 0 hr 47 min 19 sec
Topology Change Count.......................... 6629
Topology Change in progress.................... False
Designated Root................................ 10:00:08:BD:43:78:6F:7D
Root Path Cost................................. 1000
Root Port Identifier........................... 60:1A
Bridge Max Age................................. 20
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 15
Hello Time..................................... 2
Bridge Hold Time............................... 6
CST Regional Root.............................. 40:00:FC:EC:DA:78:9A:73
Regional Root Path Cost........................ 0

Auszug Unifi Access

(UBNT) >show spanning-tree 

Bridge Priority................................ 28672
Bridge Identifier.............................. 70:00:18:E8:29:2C:F8:F4
Time Since Topology Change..................... 30 day 10 hr 38 min 20 sec
Topology Change Count.......................... 2
Topology Change in progress.................... False
Designated Root................................ 10:00:08:BD:43:78:6F:7D
Root Path Cost................................. 4000
Root Port Identifier........................... 80:31
Bridge Max Age................................. 20
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 15
Hello Time..................................... 2
Bridge Hold Time............................... 6
CST Regional Root.............................. 70:00:18:E8:29:2C:F8:F4
Regional Root Path Cost........................ 0

Andere Switche sind bzw. sollten nicht im Netz sein. Wenn dann ohne unsere Zustimmung.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 534689

Url: https://administrator.de/forum/spanning-tree-probleme-topology-change-received-rstp-534689.html

Ausgedruckt am: 25.12.2024 um 01:12 Uhr

48 Kommentare

Neuester Kommentar

Hi,

versuche doch erstmal herauszufinden wer denn die "neue" Root-Bridge wird.
10:00:08:BD:43:78:6F:7D ist wohl der Core, oder?

Komisch finde ich gerade, das es auf dem Core öfter Root-Changes gibt es im Acces.

Ach ja, Verteiler ist nicht gerade der richtige Name, das sind eher die Aggregation Switche .

Viele Grüße,
Deepsys

versuche doch erstmal herauszufinden wer denn die "neue" Root-Bridge wird.
10:00:08:BD:43:78:6F:7D ist wohl der Core, oder?

Ja das ist der Core.

siehe dazu:

Bridge Priority................................ 4096
Bridge Identifier.............................. 10:00:08:BD:43:78:6F:7D
Time Since Topology Change..................... 0 day 1 hr 34 min 46 sec
Topology Change Count.......................... 1204
Topology Change in progress.................... False
Designated Root................................ 10:00:08:BD:43:78:6F:7D
Root Path Cost................................. 0
Root Port Identifier........................... 00:00
Bridge Max Age................................. 20
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 15
Hello Time..................................... 2
Bridge Hold Time............................... 6
CST Regional Root.............................. 10:00:08:BD:43:78:6F:7D
Regional Root Path Cost........................ 0
Port Triggered TC.............................. 1/0/22

Komisch finde ich gerade, das es auf dem Core öfter Root-Changes gibt es im Acces.

Naja ich wollte jetzt ungern alle Ausgaben der Access und Aggregation Switche posten. Bei irgendeinem stimmt die Zeit schon immer.

Aber z.B. bei diesem hängen nur WLAN AP dran und dort kommt kein TC zustanden....der läufte seit Tagen einfach durch.

(UBNT) >show spanning-tree 

Bridge Priority................................ 28672
Bridge Identifier.............................. 70:00:18:E8:29:2C:F8:F4
Time Since Topology Change..................... 30 day 10 hr 38 min 20 sec
Topology Change Count.......................... 2
Topology Change in progress.................... False
Designated Root................................ 10:00:08:BD:43:78:6F:7D
Root Path Cost................................. 4000
Root Port Identifier........................... 80:31
Bridge Max Age................................. 20
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 15
Hello Time..................................... 2
Bridge Hold Time............................... 6
CST Regional Root.............................. 70:00:18:E8:29:2C:F8:F4
Regional Root Path Cost........................ 0

Ach ja, Verteiler ist nicht gerade der richtige Name, das sind eher die Aggregation Switche .

Ja...sorry ;

Im Wireshark taucht immer wieder Ubiquiti / Unifi mit STP auf...und zwar wird dort als Dest MAC diese angegeben: 01:80:c2:00:00:00

Bei Netgear gibt es einen Beitragbzgl. 3rd Party AP mit der MAC 01:80:c2:00:00:1c

kb.netgear.com/000038810/Adding-a-MAC-ACL-on-Fully-and-Smart-Managed-switches-to-prevent-STP-leak-of-multicast-packet-from-3rd-party-access-points

Ist es sinnvoll den MAC gemäß FAQ zu filtern? Wenn ja welche?

Du kennst nicht alle Mac Adressen aller Switches?

Ein Port Flapping kannst Du ausschließen?

Hallo,

Hast du geprüft ob alle das gleiche STP Protokoll sprechen?

Grüße
Max

Zitat von @142583:

Du kennst nicht alle Mac Adressen aller Switches?

Doch doch...diese kenne ich alle.
Die 01:80:c2:00:00:00 ist da aber nicht dabei. Soweit ich das richtig deute ist das ein Multicast an eine MAc von Unifi aus - warum auch immer. Die Frage...kann es dadurch STP Probleme geben?

Ein Port Flapping kannst Du ausschließen?

Das würde mich wundern, wenn das auf allen Ports / Egal ob SFP oder Kupfer am Core auftritt.

Hast du geprüft ob alle das gleiche STP Protokoll sprechen?

Es gibt nur 2 Hersteller im Haus.

Im Core der Netgear. Dieser läuft auf IEEE 802.1w also RSTP.

Und die anderen sind alle Ubiquiti Unifi, welche auch auf RSTP gestellt sind.

Hast du LLDP bei den Unifis aktiviert?

Hast du UniFi Access Points und dort das Wireless Uplink aktiviert?

Zitat von @142583:

Hast du UniFi Access Points und dort das Wireless Uplink aktiviert?

Nein. Alle AP sind per LAN angeschlossen.

Ja, sie können per LAN angeschlossen sein und dennoch kann das Feature aktiviert sein.

Zitat von @142583:

Hast du LLDP bei den Unifis aktiviert?

Ja,

das ist auf den Ports, bei denen 802.1x aktiv ist, aktiviert - und das sind ca 95 % aller Ports bei mir hier

Kannst Du das testweise abstellen?

Mein Bauchgefühl sagt mir, dass du kurzzeitig einen Loop hast.

Ich persönlich würde versuchen mit Wireshark den Moment mitzuschneiden.

Das ist deaktiviert. Siehe den Ausschnitt

Ich habe auch einen Switch, an den nur AP dran hängen und bei den ist der letzte Topo Change vor 30 Tagen gewesen.

Kannst Du das testweise abstellen?

Spanning Tree? Das geht erst am Wochenende.

Ich persönlich würde versuchen mit Wireshark den Moment mitzuschneiden.

Läuft die ganze Zeit, aber bisher sehe ich nut die STP Packets ohne Topo Change

Das LLDP abstellen.
STP abstellen, müsste man gucken wie genau die Implementierung ist. Selbst Portfast heißt ja nicht, dass STP "aus" ist.

Die Topo Chance Pakete treffen im Core weiterhin über mehrere Ports ein? Augenscheinlich gleicher Absender?

BPDU auch alles geprüft?

Das LLDP abstellen.

ja das könnte ich machen - ich stehe nur gerade auf dem Schlauch was das LLDP mit STP zu tun haben soll..

STP abstellen, müsste man gucken wie genau die Implementierung ist. Selbst Portfast heißt ja nicht, dass STP "aus" ist.

Die Topo Chance Pakete treffen im Core weiterhin über mehrere Ports ein? Augenscheinlich gleicher Absender?

ja treffen Sie....den Absender bekomme ich aber nicht raus...im Moment hängt ein Wireshark am Aggregation Switch im VLAN untagged

Eine Idee wie ich die STP Packete am Core einsehen kann? Direkt an einen Untagged Port hängen?

RSTP selbst ist ja VLAN unabhängig.

LLDP war nicht nur ein Mal Buggy. ;)
Ansonsten Ausschlussprinzip.

Lies Mal: https://community.ui.com/questions/Firmware-3-7-x-and-NetGear-Switches-i ...

Wenn du über WS am Core nicht rausbekommt, wo das Störschwein sitzt, dann suche die Links manuell ab, durch trennen der Patchkabel.

Am Anfang in Gruppen, 4 Links/Bündel auf ein Mal. Dann sieht du Recht schnell wenn du das richtige isoliert hast. Bei den vielen Vorgängen sollte Recht schnell Klarheit sich einstellen.

Du kannst auch an den Uplinks zum Core eine ACL probieren.

https://docs.paloaltonetworks.com/pan-os/7-1/pan-os-admin/networking/lld ...

Bezüglich LLDP.

Zitat von @142583:

LLDP war nicht nur ein Mal Buggy. ;)
Ansonsten Ausschlussprinzip.

Ok. Können negative Effekte auftreten, wenn ich LLDP vorerst deaktivere?

Lies Mal: https://community.ui.com/questions/Firmware-3-7-x-and-NetGear-Switches-i ...

Das habe ich ja weiter oben bereits geschrieben...Netgear hat das Hier erklärt. Daher habe ich mal eine ACL dazu erstellt und auf 2 Links vorerst zum test gelegt.

Wenn du über WS am Core nicht rausbekommt, wo das Störschwein sitzt, dann suche die Links manuell ab, durch trennen der Patchkabel.

Ja...das ist halt bei über 100 Switchen viiel Arbeit...wobei das kurios wäre, da an 5 von 8 Uplinks die TC auftreten, aber an die meisten Dosen die Anwender gar nicht rankommen (Industriebetrieb)

Aber vielleicht hat Aqui ja auch noch einen Idee - ich warte ja schon auf seine Antwort...auch wenn er ersta zum UniFi Gegenschlag ausholt :D

Was machst du denn mit dem LLDP über den UniFi Controller hinaus?

Die Mac Adresse, die du nennst, sendet dir jeder Hersteller, bei mehreren Protokollen. Das ist " besondere" Mac, die vielen Admins das Herz erwärmt. Manch einer hat die km Ausweis stehen.

Ich würde mich nicht auf UniFi versteifen.

Deshalb sage ich ja, am Core gleich gruppenweise offline nehmen. Gibt bestimmt was Richtung Portrange und Shutdown oder so.

Besonders in Industriebetrieben ist das nicht ungewöhnlich, eher typisch. Ich komme auch aus der Ecke (Automotive)

Und denke immer an den netten Kollegen der das Patchkabel für Dich wieder eingesteckt hat. Diesen Kollegen kennen viele.

Unbrauchbare Antipathie-Posting bezüglich deiner im Einsatz befindlichen Hardware, brauchst du nicht herbeisehnen. Sie helfen nicht und sind ein Ausdruck von persönlicher Schwäche. Du suchst hier Hilfe.

Guck dir doch immer wieder mal die STP-Ausgabe an, und gucke ob da irgendwann eine andere Root-ID steht.

Ansonsten, kann das nicht Wireshark mitfiltern?

Zitat von @Deepsys:

Guck dir doch immer wieder mal die STP-Ausgabe an, und gucke ob da irgendwann eine andere Root-ID steht.

Bis jetzt war da nichts brauchbares dabei.

Ansonsten, kann das nicht Wireshark mitfiltern?

Ja..mal sehen was rauskommt. Seit 1 h Stunden hängt ein Laptop mit Wireshark direkt am Core und zeichnet auf.

Bisher hing er nur am Access oder Aggregation Switch und da waren nur die bpdu Packets zu sehen

Ein paar wichtige Fragen zum generellen STP Design:

Welches STP Protokoll fährst du netzwerkweit ? STP, RSTP, MSTP ?
Ist das ohne Ausnhame auf allen Switches durchgehend entsprechend eingerichtet ?
Gibt es ggf. Fremdswitches im Netz die PVSTP oder PVSTP+ sprechen, also STP Protokolle die inkompatibel zu den oa. sind ?
Sind die beiden Core Switches explizit mit statischer STP Prio als Root und Backup Root gesetzt ?? (Globale RSTP Prio z.B. 4096 (Root) und 8192 (Backup Root), Rest der Switches Default 32768)
Wenn RSTP hast du alle Uplinks entsprechend als RSTP P2P Ports konfiguriert ? Entsprechend die Access Ports als RSTP Edge Ports ?

All das ist essentiell wichtig in einem sauberen Spanning Tree Design und extrem wichtig in einem Design mit unterschiedlichen Herstellern. Insbesondere die richtige Prio Einstellung um die Pfade vorzugeben.
Leider gibt es keinerlei Infos zu den Konfigs der Komponenten, deshalb muss man diese Banalfragen oben stellen.
Ein paar grundlegende Erklärungen liefert auch ein recht detailierter MSTP Thread hier:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)

Nur mal nebenebei OT: Ein Netzwerk dieser Größenordnung mit Billigswitches dieser Art zu designen ist aber auch schon recht mutig wenn nicht fahrlässig. STP Topos dieser Größenordnung verlangen entsprechende CPU Power die diese Billigswitches alle nicht haben und deshalb dort nichts zu suchen haben. Von der sehr oft mehr als mickrigen STP Implementation und deren Features mal erst gar nicht zu reden.
Jeder Admin der sowas designt weiss das bei einer STP Infrastruktur dieser Größe ein anderes Kaliber von HW erforderlich ist. Der grundsätzliche Fehler ist also schon viel früher gemacht worden.

Hi aqui,

Zitat von @aqui:

Ein paar wichtige Fragen zum generellen STP Design:

Welches STP Protokoll fährst du netzwerkweit ? STP, RSTP, MSTP ?

Im Netgear (Core) und den Unifi Switchen ist RTSP eingestellt - so steht es auch oben

* Ist das ohne Ausnhame auf allen Switches durchgehend entsprechend eingerichtet ?

ja, sowie auf allen Ports

* Gibt es ggf. Fremdswitches im Netz die PVSTP oder PVSTP+ sprechen, also STP Protokolle die inkompatibel zu den oa. sind ?

Es war mal vor 1 Monat noch ein Cisco SG200 im Netz, welcher aufgrund Inkompatibilität entfernt worden ist

* Sind die beiden Core Switches explizit mit statischer STP Prio als Root und Backup Root gesetzt ?? (Globale RSTP Prio z.B. 4096 (Root) und 8192 (Backup Root), Rest der Switches Default 32768)

Die 2 Core sind gestackt und treten somit als ein Switch in Erscheinung und besitzen die RTSP Prio 4096

Config Core

(M4300-24X) >show switch

    Management   Standby    Preconfig       Plugged-in         Switch       Code      MAC
SW    Switch     Status     Model ID         Model ID          Status       Version   Address
--- ----------- --------- ---------------- ---------------- ------------- ----------- -------------------
1   Mgmt Sw               M4300-24X        M4300-24X        OK            12.0.9.3    08:BD:43:78:6F:7D
2   Stack Mbr   Oper Stby M4300-24X        M4300-24X        OK            12.0.9.3    10:DA:43:D7:33:81

Spanning Tree Auszug von Core

(M4300-24X) >show spanning-tree 
Bridge Priority................................ 4096
Bridge Identifier.............................. 10:00:08:BD:43:78:6F:7D
Time Since Topology Change..................... 0 day 0 hr 31 min 50 sec
Topology Change Count.......................... 1336
Topology Change in progress.................... False
Designated Root................................ 10:00:08:BD:43:78:6F:7D
Root Path Cost................................. 0
Root Port Identifier........................... 00:00
Bridge Max Age................................. 20
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 15
Hello Time..................................... 2
Bridge Hold Time............................... 6
CST Regional Root.............................. 10:00:08:BD:43:78:6F:7D
Regional Root Path Cost........................ 0
Port Triggered TC.............................. 1/0/21

     Associated FIDs           Associated VLANs
     ---------------           ----------------
     1                         1
     1001                      1001

Gui RTSP Core

Die Access Switche waren auf 32768, aber auch eine Änderung entsprechend den Baum abwärts vom Root aus gesehen bringt keine Änderung

* Wenn RSTP hast du alle Uplinks entsprechend als RSTP P2P Ports konfiguriert ? Entsprechend die Access Ports als RSTP Edge Ports ?

Die Unifi erkennen die P2P Ports als solche (es geht oftmals wirklich nur 1 Leitung zum nächsten Switch Richtung Root)-

Kein Problem

Ein paar grundlegende Erklärungen liefert auch ein recht detailierter MSTP Thread hier:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)

Nur mal nebenebei OT: Ein Netzwerk dieser Größenordnung mit Billigswitches dieser Art zu designen ist aber auch schon recht mutig wenn nicht fahrlässig. STP Topos dieser Größenordnung verlangen entsprechende CPU Power die diese Billigswitches alle nicht haben und deshalb dort nichts zu suchen haben. Von der sehr oft mehr als mickrigen STP Implementation und deren Features mal erst gar nicht zu reden.
Jeder Admin der sowas designt weiss das bei einer STP Infrastruktur dieser Größe ein anderes Kaliber von HW erforderlich ist. Der grundsätzliche Fehler ist also schon viel früher gemacht worden.

Ja ich weiß....aber das ist ein anderes Thema. Grundsätzlich sollte ja "simples RSTP" funktionieren. Der Traffic selbst im Netzwerk ist nicht hoch - oftmals nur RDP von den ThinClients oder "Meldedaten"

Ich habe heute den ganzen Tag am Core Wireshark mitlaufen lassen...Filter: STP - trotz das Topo Changes stattgefunden haben, konnte ich nur die bpdu Packets aller 2 Sekunden aufzeichnen. Habe ich eine Chance den Verursacher zu finden, außer alle Kabel Temporär abzuziehen?

Weitere Frage
Port 1/15 am Core - dort hängt ein Bereich dran, welcher im November komplett neu aufgebaut worden ist - dort ist defintiv keine Schleife...die Dose hängen alle an Kabeltraversen und darunter stehen nur Maschinen - dennoch kommt von da hin und wieder ein Topology Change. Kann das auch passieren, wenn in einem anderen Bereich etwas "verrückt" spielt?

Anmerkung

Ich habe hier ein NAC im Einsatz (Mac Auth im LAN), sodass ein fremder Switch normalweise bei mir hier als unregistriertes Gerät auftauchen müsste

Was ist denn mit der Zeile:
Port Triggered TC.............................. 1/0/21

TC? Topology Change?
Was hängt denn da dran?

Zitat von @Deepsys:

Was ist denn mit der Zeile:
Port Triggered TC.............................. 1/0/21

TC? Topology Change?

Was hängt denn da dran?

Ein Aggregation Switch, an dem hängen aber dann 4 x 48 Port Access Switche. Jedoch tritt das Problem an 3 Ports am Core auf.

Ich versuche gerade die 48 Port Switche einzeln (zumindest temporär) am Core direkt anzuschließen, damit ich den Verursacher besser eingrenzen kann. Denn am Core sehe ich letztendlich von welchem Port es kommt

Ziehe erstmal die 3 problematischen Ports ab wenn das geht. (Physische Trennung)
Dann checkst du ob die TC Changes aufhören was sie sollten.
Wenn ja, steckst du sie einzelnd sukzessive wieder zu auch ggf. die Switches die hinterher kaskadiert sind an diesem Aggregation Switch.
In der Regel ist an dem Switch dann der Fehler wo die TC Changes wieder auftauchen.
Die Vorgehensweise klingt im ersten Moment etwas dilletantisch aber STP zu troubleshooten auf diesen billigen SoHo Switches ist nicht einfach weil denen vollständig jegliche Debug Funktionen fehlen die im Premium Bereich üblich sind.
Es hilft aber in der Regel immer so den Fehler ziemlich schnell und genau einzukreisen.

Ziehe erstmal die 3 problematischen Ports ab wenn das geht. (Physische Trennung)

die geht leider nicht ohne weiteres - da hängen Maschinen ran -> muss ich aufs WE verschieben.

Die Vorgehensweise klingt im ersten Moment etwas dilletantisch aber STP zu troubleshooten auf diesen billigen SoHo Switches ist nicht einfach weil denen vollständig jegliche Debug Funktionen fehlen die im Premium Bereich üblich sind.

Da gebe ich dir recht....das merke ich gerade

Aber ich bin bereits ein Stück weiter
Ich habe heute einen uralt Netgear Switch ausfindig gemacht, welcher an einer Maschine verbaut war....wer auch immer den wann dort hingebaut hat....laut Datenblatt ist der unmanged (somit sollte er doch keine STP Befehle senden, oder?)

Ich habe den 8 Port Switch natürlich sofort entfernt und gegen ein managed getauscht auf den RTSP aktiv ist.

Auch wenn man im Unifi Controller leider die BPDU Packets leider nicht einsehen kann, so haben sie doch wenigstens eine vollwertige CLI ;)
An dem Port wurden auf jedenfall BPDU Packet empfangen und gesendet.

Hello Time..................................... Not Configured
Port Mode...................................... Enabled
BPDU Guard Effect.............................. Disabled
Root Guard..................................... False
TCN Guard...................................... False
BPDU Filter Mode............................... Disabled
BPDU Flood Mode................................ Disabled
Auto Edge...................................... TRUE
Port Up Time Since Counters Last Cleared....... 32 day 10 hr 36 min 31 sec
STP BPDUs Transmitted.......................... 0
STP BPDUs Received............................. 0
RSTP BPDUs Transmitted......................... 1404864
RSTP BPDUs Received............................ 47
MSTP BPDUs Transmitted......................... 0
MSTP BPDUs Received............................ 0

Bei den anderen Ports steht nur auf "Transmitted". Kann das stimmen?

Am Core werden die Logs weniger - so habe ich nach ein paar Stunden den Eindruck, aber irgendwo muss noch ein Gerät hängen - warum auch immer. (Das sind aber nochmal 6 x 48 Port Switche).

Kann ich über die CLI nach RSTP BPDUs Received filtern, oder muss ich jedes Interface einzeln anschauen?

Noch etwas:

Die Config der Unifi sieht so aus (gekürzt)

(UBNT) #show running-config 

!Current Configuration:
!
!System Description "USW-48P-500, 4.0.66.10832, Linux 3.6.5"  
!System Software Version "4.0.66.10832"  
!System Up Time          "75 days 9 hrs 19 mins 24 secs"  
!Additional Packages     QOS,IPv6 Management
!
...

spanning-tree mode rstp
snmp-server sysname "SW-RZ1-U48-1"  
!
snmp-server group "Ubnt" v3 priv read "Default"  
snmp-server user "snmp" Ubnt auth-sha-key 9461efcbca637573a40ba2889079457605f4806b priv-aes128-key 9461efcbca637573a40ba28890794576  
snmp-server community "private" rw ipaddress 127.0.0.1  
set igmp reportforward lldp
set mld reportforward lldp
ip dhcp snooping 
...

und vom Core:

line console      
serial timeout 160
exit              
                  
line telnet       
exit              
                  
line ssh          
exit              
                  
spanning-tree mst priority 0 4096
port-channel name lag 1 SW-RZ1-1
interface 1/0/13  
addport lag 1     
exit              
interface 2/0/13  
addport lag 1     
exit              
port-channel name lag 2 SW-RZ1-2
interface 1/0/17  
addport lag 2     
exit              
interface 2/0/17  
addport lag 2     
exit    

Beim Core steht bei Spanning Tree nicht "RTSP", obwohl dies laut GUI aktiviert ist.

Im Handbuch (Link) auf Seite 201 lese ich, dass MSTP im RTSP Modus arbeitet, wenn die aktiviert ist. Deute ich das richtig?

Multiple Spanning Tree Protocol (MSTP) supports multiple instances of Spanning Tree to efficiently channel VLAN traffic over different interfaces. Each instance of the Spanning Tree behaves in the manner specified in IEEE 802.1w, Rapid Spanning Tree (RSTP), with slight modifications in the working but not the end effect (chief among the effects, is the rapid transitioning of the port to Forwarding). The difference between the RSTP and the traditional STP (IEEE 802.1D) is the ability to configure and recognize full-duplex connectivity and ports which are connected to end stations, resulting in rapid transitioning of the port to Forwarding state and the suppression of Topology Change Notification. These features are represented by the parameters pointtopoint and edgeport. MSTP is compatible to both RSTP and STP. It behaves appropriately to STP and RSTP bridges. A MSTP bridge can be configured to behave entirely as a RSTP bridge or a STP bridge.

Wie ging dieses Thema eigentlich weiter?

Wäre in der Tat mal spannend...
Zumal der TO den Thread auch noch nicht auf "Gelöst" gesetzt hat ?!!

Zitat von @aqui:

Wäre in der Tat mal spannend...
Zumal der TO den Thread auch noch nicht auf "Gelöst" gesetzt hat ?!!

Leider gibt es noch nichts konkretes neues....wir sind derzeit auf Ursachensuche....

Stand ist, dass wir über 2000 AccessPort haben , wo Endgeräte theroretisch ran könnten (insgesamt sind es viel mehr Ports, aber da stehen einige im RZ bwz in zutrittbeschränkten Räumen). Da die meisten Doppeldosen an oder auf Kabelrinnen sind, haben wir leider noch nicht alle überprüfen können.

Folgendes kann ich sagen:

- Die Topo Changes kommen meistens von bestimmen TrunkPorts (von einigen anderen kommt gar nichts)
- Es gibt Switche.....da findet ein Topo Changes statt , aber da hängen nur ein Dutzend Endgeräte dran - selbst überprüf - wie kann das sein?

Kann es sein, dass wenn ein Switch "verrückt" spielt sich das ganze hochschaukelt und dann für eine Gewisse Zeit normalisiert?
Ist es denkbar, dass die BPDU zu "lang" für den Weg benötigen (hohe Last etc...) und es daher zu den Topo Changes kommt?

Als Workaround habe ich auf den Trunkports am CoreStack derzeit "Root Guard" & TCN Guard aktiviert, sodass dieser die TopoChanges sieht, aber nicht darauf reagiert.....seitdem ist es erstmal stabiler, aber ja nicht die Ursache.

Können Probleme Auftreten, wenn auf den Ports am Coreswitch (Root Bridge) der Root Guard / TCN Guard aktiviert ist? Eigtl müsste der Port bei RootGuard doch blockiert werden... tut er aber nicht... also er verwirrt die TC nur und die Geräte dahinter sind weiterhin erreichbar

Use Root Guard to configure the root guard mode, which sets a port to discard any superior information received by the port and thus protect against root of the device from changing.

Use TCN Guard to configure the TCN guard for a port restricting the port from propagating any topology change information received through that port

BDPU guard habe ich extra nicht aktiviert, da ja sonst der Port auf blockiert geht. Korrekt?

PS.: mir kommt es so vor, dass die TC stattfinden, wenn Geräte angeschaltet werden, da in der Nacht und am Wochenende Ruhe ist. Kann das sein? Wen ja wodurch? Die Geräte sind meist ThinClients oder Industrie PC. Die Maschinen haben immer ein eigenes physisches Netz und hängen nicht bei uns drin.

Kann es sein, dass wenn ein Switch "verrückt" spielt sich das ganze hochschaukelt und dann für eine Gewisse Zeit normalisiert?

Könnte sein, würde dann aber auch klar auf temporäre Loops oder andere STP Probleme hinweisen. Ggf. Broadcast Stürme usw.

Ist es denkbar, dass die BPDU zu "lang" für den Weg benötigen

Nein, das ist völlig ausgeschlossen denn BPDU Beziehungen bestehen immer nur rein Punkt zu Punkt. Also immer nur von einem Switch zum nächsten. Sowas wir nicht weitergereicht wie IP Pakete z.B. Sollte man als Netzwerker aber eigentlich auch wissen !

seitdem ist es erstmal stabiler, aber ja nicht die Ursache.

Richtig ! Damit hast du nur die Symptome bekämpft aber nicht die Ursache. Das Netz bleibt also weiter latent instabil.

Eigtl müsste der Port bei RootGuard doch blockiert werden

Wenn Root Guard aktiviert ist auf den Roots Uplink Ports bleibt der in seiner Designated Rolle. Sollte er dort BPDU Pakete mit einer höheren Priority empfangen wird der Port in den Inconsistend State gesetzt was vergleichbar mit Blocking bzw Discard ist. Kein Traffic wir mehr geforwardet und eine SNMP und Syslog Message generiert. . No further traffic is forwarded on this port. So wird verhindert das falsch oder fehlkonfigurierte Switches Root Ports kapern können.
Kommen an solchen RG Ports keine BPDUs mehr geht der Port sofort wieder in den Learning und Forwarding State.
Es ist also sehr sinnvoll Root Guard auf den Root Uplink Ports zu aktivieren um hier Sicherheit zu erlangen.

BDPU guard habe ich extra nicht aktiviert, da ja sonst der Port auf blockiert geht. Korrekt?

Das ist korrekt wenn es eben diese dedizierten Uplink Ports sind. Auf Access Ports aktiviert man das z.B. damit nicht unbefugte dort STP Switches anschliessen die dir deine gesamte Spanning Tree Topologie damit aus dem Tritt bringen und damit dein Netzwerk in den Orcus reissen.

mir kommt es so vor, dass die TC stattfinden, wenn Geräte angeschaltet werden

Das ist gut möglich. Deshalb definiert man m 802.1w STP Edge Ports im RSTP ja auch immer als Edge Ports dann haben Port Changes an diesen Ports keinerlei Topo Changes zur Folge. Das ist also ein zwingendes ToDo mit dem Kommando: Admin Edge Port
Andersrum definiert man Uplink Ports immer zwingend als Point to Point Ports: Admin Pt2pt Mac

Die Maschinen haben immer ein eigenes physisches Netz und hängen nicht bei uns drin.

Ist dieses Netz dann physisch vollkommen getrennt ??
Wenn ja kann es ja so oder so niemals eine RSTP Wechselwirkung geben.
Wenn nein dann schon. Ist also die Frage wie "getrennt" genau gemeint ist ?!

Zitat von @aqui:

Könnte sein, würde dann aber auch klar auf temporäre Loops oder andere STP Probleme hinweisen. Ggf. Broadcast Stürme usw.

Richtig ! Damit hast du nur die Symptome bekämpft aber nicht die Ursache. Das Netz bleibt also weiter latent instabil.

ja ich weiß, aber somit ist es erstmal "behoben"....natürlich möchte ich die Ursache beheben.

Also stelle ich den Root Guard an allen Ports auf enabled am RootSwitch (core), an denen die AccessSwitch angeschlossen sind, richtig?

Am CoreSwitch sind nur AccessSwitche & Server angeschlossen -> daher betrifft mich das am Core (root) ja nicht. Dies müsste ich ja an den AccessPorts vornehmen

Ist dieses Netz dann physisch vollkommen getrennt ??
Wenn ja kann es ja so oder so niemals eine RSTP Wechselwirkung geben.
Wenn nein dann schon. Ist also die Frage wie "getrennt" genau gemeint ist ?!

Meist ist es so, dass es einen InudstriePC gibt mit 2 LAN Schnittstellen. 1 Schnittstelle im Firmennetz, 2. Schnittstelle geht direkt an die Maschine. Somit Physisch getrennt. Die Schnittstellen sind niemals gebrückt.

Aslo evtl. bin ich ein Stück weiter....

Wir setzen seit dem Sommer 2019 im ganzen Gelände Alcatel-Lucent 8378 DECT IP-xBS DECT IP Repeater ein. Kein Typisches VOIP. Nur die DECT Repeater sind VOIP und alle Geräte sind über DECT angebunden.

Aber jetzt kommt der gemeinsame Nenner...An allen AccessSwitchen, an denen ein Alcatel-Lucent 8378 DECT IP-xBS Repeater angeschlossenist, findet regelmäßig ein Topo Change statt. Manchmal steckt an einem 48 Port Switch auch nur ein Repeater.

Ich habe heute versuchweiße an dem Port direkt am Switch LLDP-MED und RTSP deaktiviert.....und siehe da....der Switch hat seit 16 Stunden keinen Topo Change...LLDP verhindert ja auch Schleifenbildung, Richtig? Ist das kompatible zu RTSP? Liegt da der Hase begraben?

Benötige ich zwingend LLDP-MED, wenn ich keine reinen VOIP Telefone einsetze?

Hier das Datenblatt für den Repeater www.al-enterprise.com/-/media/assets/internet/documents/8378-dect-ip-xbs-datasheet-de.pdf

Hier ein Auszug vom Switch mit LLDP

Bridge Priority................................ 32768
Bridge Identifier.............................. 80:00:B4:FB:E4:1D:17:F7
Time Since Topology Change..................... 0 day 0 hr 8 min 29 sec
Topology Change Count.......................... 208
Topology Change in progress.................... False
Designated Root................................ 10:00:08:BD:43:78:6F:7D
Root Path Cost................................. 4000
Root Port Identifier........................... 80:31
Bridge Max Age................................. 20
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 15
Hello Time..................................... 2
Bridge Hold Time............................... 6
CST Regional Root.............................. 80:00:B4:FB:E4:1D:17:F7
Regional Root Path Cost........................ 0

Hier ohne LLDP am Port

Bridge Priority................................ 32768
Bridge Identifier.............................. 80:00:18:E8:29:2C:F9:57
Time Since Topology Change..................... 0 day 10 hr 23 min 57 sec
Topology Change Count.......................... 4
Topology Change in progress.................... False
Designated Root................................ 10:00:08:BD:43:78:6F:7D
Root Path Cost................................. 4000
Root Port Identifier........................... 80:32
Bridge Max Age................................. 20
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 15
Hello Time..................................... 2
Bridge Hold Time............................... 6
CST Regional Root.............................. 80:00:18:E8:29:2C:F9:57
Regional Root Path Cost........................ 0

Man sieh, es finden viel weniger Topo Changes statt.

Weiter oben hat ja bereits jemand erwähnt, dass LLDP Probleme verursachen kann. @aqui....hast du da Erfahrungen oder Infos?

Ps.: Der Port für die VOIP DECT Repeater wird per 802.1 x mac auth untagged für das VOIP zugeordnet. Alternativ wäre eine statische VLAN Zuordnung für den Port möglich

Ich hatte ja schon Mal erwähnt, dass LLDP aus der Masse zu nehmen.
Ich erlebe es nicht so selten, dass LLDP Buggy ist. Irgendwie ist das auch mehr geworden über die letzten Jahre.

Für mich wären jetzt die Fragen:

Müssen die DECT-Basen LLDP haben?
Ist es eine grundsätzliche und beidseitige Inkompatibilität oder eine einseitige einer Hardware.

Ich würde LLDP-MED bestenfalls für ein VoIP Phone aktivieren. Für die APs vermutlich nicht, wenn Alcatel nicht gute Gründe liefert.

Mein Chef 2008 und Telekom-Lebenslauf, Zitat: Keine dummen Frauen und nichts was Franzosen bauen.

Er hat nur Panasonic PBX gemacht und Alcatel hat ihm gleich Pickel am Arsch verschafft. War immer sehr lustig.

Zitat von @142583:

Ich hatte ja schon Mal erwähnt, dass LLDP aus der Masse zu nehmen.
Ich erlebe es nicht so selten, dass LLDP Buggy ist. Irgendwie ist das auch mehr geworden über die letzten Jahre.

ja eben...das habe ich ja nochml erwähnt.....danke dir dahingehend schon mal. ich kann mir nur noch nicht erklären wie das ganze Zusammenhängen kann....Aber LLDP-MED baut j auch eine Topologie auf

Für mich wären jetzt die Fragen:

Müssen die DECT-Basen LLDP haben?
Ist es eine grundsätzliche und beidseitige Inkompatibilität oder eine einseitige einer Hardware.

Gute Frage....Ich kann ja dasn VOIP VLAN für die DECT IP Basen auch statisch zuordnen.

Ich würde LLDP-MED bestenfalls für ein VoIP Phone aktivieren. Für die APs vermutlich nicht, wenn Alcatel nicht gute Gründe liefert.
VOIP Phones haben wir nicht. Nur die DECT Basen gehen über VOIP.

Mein Chef 2008 und Telekom-Lebenslauf, Zitat: Keine dummen Frauen und nichts was Franzosen bauen.

das sehe ich mittlerweile auch so

Frage Mal den Händler oder Alcatel was der Mehrwert sein soll für die DECT-Basen und LLDP-MED.
Mir persönlich wäre das nicht wichtig.

Gibt es einen Grund, das VoIP LAN nicht statische zugeordnet zu haben? In dem Umfeld und der Geräteklasse fällt mir spontan kein Grund ein.

Ansonsten muss ich feststellen, dass ich schmerzhafte Erinnerungen an LLDP Inbetriebnahmen habe.

Zitat von @142583:

Frage Mal den Händler oder Alcatel was der Mehrwert sein soll für die DECT-Basen und LLDP-MED.
Mir persönlich wäre das nicht wichtig.

kann ich machen, aber von Alcatel direkt kommt da sicherlich nichts

Gibt es einen Grund, das VoIP LAN nicht statische zugeordnet zu haben? In dem Umfeld und der Geräteklasse fällt mir spontan kein Grund ein.

Also mit statisch meinte ich den Port auf VOIP VLAN untagged setzen.
Da ich hier ein NAC habe, setze ich die Ports dynmissch nach MAC Auth. E

Ansonsten muss ich feststellen, dass ich schmerzhafte Erinnerungen an LLDP Inbetriebnahmen habe.

gut zu wissen

Ansonsten muss ich feststellen, dass ich schmerzhafte Erinnerungen an LLDP Inbetriebnahmen habe.

LLDP-MED wurde gestern abgestellt, doch leider keine Besserung

Aber vielleicht aqui oder wer auch anders eine Idee?

Ich hab ja die Vermutung, dass die IndustriePC oder ein anderes Gerät evtl. schuld sind. KAnn das sein, dass die ein TC auslösen, wenn diese angeschalten werden? Die haben immer 2 Netzwerkkarten...aber zu 90 % ist nur eine am Netz......

Ja, ist möglich. Unwahrscheinlich aber möglich.

In Industrieumgebung musst Du mit sowas rechnen.

So Leute.....erstmal danke für die ganzen Hilfen von euch.

Die Verursacher sind die kleinen 8 Port Switche, welche manchmal an einzeln Ports angeschlossen sind.

Beispiel:

48 Port Switch Produktion, 1 Leitung geht zum Arbeitsplatz -> 8 Port Switch -> PC; Maschine; Etikettendrucker

Schleife kann dort ausgeschlossen werden.

Die 8 Port Switche laufen auch mit RSTP; Priority 53248

Wenn ich beim 48Port Switch am Downlink Port zum 8 Port Spanning Tree deaktivere ist Ruhe und keine TopoChanges.

Derzeit gibt es für die Switche eine neue Firmware, ich werde die jetzt mal testen.

Somit ist das Thema gelöst bzw der Verursacher gefunden

Schleife kann dort ausgeschlossen werden.

So so... Und wie schliesst du dann sicher aus das der Azubi einfach mal versehntlich ein Patchkabel am 8 Poert Switch wieder in den Switch steckt ? Sowas bleibt permanent unsicher, denn gegen solche Loops hilft dir nichtmal Spanning Tree sondern nur eine Port Loop Detection sofern den Core Switch sowas überhaupt supportet ?!

Die 8 Port Switche laufen auch mit RSTP; Priority 53248

Sehr merkwürdige Priority und absolut unüblich. Üblich ist der Default Wert von 32.768 ! Auch vor dem Hinblick das die RSTP Priority immer nur modulo 4096 sein kann ist dieser Wert vollkommen falsch und technisch völlig unsinnig. Vermutlich billigste China Hardware unterster Kategorie aber egal.
Sinnvoll ist diesen den Priority Default Wert von 32768 zu geben und einzig nur den Core Switches 4096 oder 8192 (Root und Backup Root) um so einen saubere Spanning Tree Hierarchie zu gewährleisten !
Kein Wunder also das dieser Schrott mit den völlig irren RSTP Settings dir da Chaos schafft.
Kann man nur hoffen das eine neue Firmware da Abhilfe schafft.
Wenn allerdings einen Frimware schon an solchen banalen Basics scheitert sollte dir das erheblich zu denken geben ob du dort die richtige Hardware im Einsatz hast !
Beachte auch das manche Premium Hersteller PVRSTP oder PVRSTP+ per Default machen. Das ist inkompatibel zu Single Span RSTP dieser Billigswitches !

Nein nicht falsch verstehen...ich meinte nicht, dass das grundsätzlich ausgeschlosseb werden. Das war nur meine Aussage zum Zeitpunkt der Prüfung, als das Problem aufgetreten ist . Verstehst du?

Die 8 Port Switche laufen auch mit RSTP; Priority 53248

Ja das sind 8 Port Billiggurken von D-Link. Ich werde die jetzte ersetzen bzw. nur noch zusätzliche Leitung ziehen lassen, sodass die Geräte direkt an den 48 Port gehen.

Aber Priority 53248 ist Modulo 4096 ;). 53248/4096 = 13 ;). Nichtdestotrotz ist das Teil nicht besonders schön