Spanning Tree Probleme
Hallo,
wir haben hier eigenartige Spanningtree Probleme, die wir zur Zeit nicht gelöst bekommen:
New Root Port MAC ist die Core Mac Adresse.
Dier Verbindung besteht zwischen einem Core und einem Access Switch, beide Cisco.
Wir haben die Konfigs mehrmals gecheckt und können keinen Fehler erkennen.
Access Switch
WS-C3850-24T 16.6.7 CAT3K_CAA-UNIVERSALK9
Core:
cisco WS-C4500X-32
Alle anderen Switche und Verbindungen funktionieren ohne Probleme und sind gleich konfiguriert.
An dem Access Switch hängen noch 2 Industrie Firewalls im VLAN 128.
Deren Konfig haben wir auch mehrmals überprüft und sogar komplett neu geschrieben(Hard Reset)
Hat hier jemand eine Erklärung für das Verhalten?
Auf allen Switches bzw. in allen VLAN ist
Spanning tree enabled protocol rstp
aktiviert.
Wir haben jetzt noch folgende Erklärungen, die wir Morgen abklären werden:
1. Der Link hat ein physikalisches Problem
2. Der Switch bzw dessen Firmware hat eine Macke, wird Morgen upgegraded.
3. Der Switch hat einen defekt.
4. Ein unbekanntes Gerät(Switch) ist im Netzwerk
Die Verbinungsprobleme treten nicht die ganze Zeit auf, es vergehen auch mal eininge Stunden ohne Störungen.
Dann plötzlich geht es wieder los.
Wer kann noch Punkte nennen, die wir checken sollten?
Danke.
wir haben hier eigenartige Spanningtree Probleme, die wir zur Zeit nicht gelöst bekommen:
Oct 19 02:51:45.242 CAN: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel60 on VLAN0128. Port consistency restored.
Oct 19 02:51:45.378 CAN: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 128: New Root Port is Port-channel60. New Root Mac Address is 0xxxxxx
Oct 19 02:51:45.384 CAN: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 128
Oct 19 02:52:00.241 CAN: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel60 on VLAN0128. Inconsistent local vlan.
Oct 19 02:52:15.242 CAN: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel57 on VLAN0128. Port consistency restored.
Oct 19 02:52:15.378 CAN: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 128: New Root Port is Port-channel60 New Root Mac Address is 0xxxxxxx
Oct 19 02:52:15.381 CAN: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 128
Oct 19 02:58:18.295 CAN: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel60 on VLAN0001. Inconsistent local vlan.
Oct 19 02:58:33.296 CAN: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel57 on VLAN0001. Port consistency restored.
Oct 19 02:58:33.437 CAN: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 1: New Root Port is Port-channel60. New Root Mac Address is 0xxxxxxxxx
Oct 19 02:58:33.439 CAN: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 1
Oct 19 03:34:08.547 CAN: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel60 on VLAN0001. Inconsistent local vlan.
Oct 19 03:34:23.548 CAN: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel57 on VLAN0001. Port consistency restored.
Oct 19 03:34:23.636 CAN: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 1: New Root Port is Port-channel60. New Root Mac Address is 00xxxxxxx
Oct 19 03:34:23.637 CAN: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 1
Oct 19 03:57:02.763 CAN: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel60 on VLAN0001. Inconsistent local vlan.
Oct 19 03:57:17.763 CAN: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel57 on VLAN0001. Port consistency restored.
Oct 19 03:57:17.834 CAN: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 1: New Root Port is Port-channel60. New Root Mac Address is 0xxxxxxxxxxx
Oct 19 03:57:17.838 CAN: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 1
Oct 19 04:14:00.882 CAN: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel60 on VLAN0001. Inconsistent local vlan.
Oct 19 04:14:15.884 CAN: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel57 on VLAN0001. Port consistency restored.
Oct 19 04:14:15.908 CAN: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 1: New Root Port is Port-channel60. New Root Mac Address is 0xxxxxxxxxxx
Oct 19 04:14:15.911 CAN: %SPANTREE-5-TOPOTRAP: Topology Change Trap for vlan 1
Oct 19 05:33:47.665 CAN: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking Port-channel60 on VLAN0128. Inconsistent local vlan.
Oct 19 05:34:02.665 CAN: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking Port-channel57 on VLAN0128. Port consistency restored.
Oct 19 05:34:02.692 CAN: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 128: New Root Port is Port-channel60. New Root Mac Address is 00xxxxxxxxxxx
Dier Verbindung besteht zwischen einem Core und einem Access Switch, beide Cisco.
Wir haben die Konfigs mehrmals gecheckt und können keinen Fehler erkennen.
Access Switch
WS-C3850-24T 16.6.7 CAT3K_CAA-UNIVERSALK9
Core:
cisco WS-C4500X-32
Alle anderen Switche und Verbindungen funktionieren ohne Probleme und sind gleich konfiguriert.
An dem Access Switch hängen noch 2 Industrie Firewalls im VLAN 128.
Deren Konfig haben wir auch mehrmals überprüft und sogar komplett neu geschrieben(Hard Reset)
Hat hier jemand eine Erklärung für das Verhalten?
Auf allen Switches bzw. in allen VLAN ist
Spanning tree enabled protocol rstp
aktiviert.
Wir haben jetzt noch folgende Erklärungen, die wir Morgen abklären werden:
1. Der Link hat ein physikalisches Problem
2. Der Switch bzw dessen Firmware hat eine Macke, wird Morgen upgegraded.
3. Der Switch hat einen defekt.
4. Ein unbekanntes Gerät(Switch) ist im Netzwerk
Die Verbinungsprobleme treten nicht die ganze Zeit auf, es vergehen auch mal eininge Stunden ohne Störungen.
Dann plötzlich geht es wieder los.
Wer kann noch Punkte nennen, die wir checken sollten?
Danke.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 614283
Url: https://administrator.de/contentid/614283
Ausgedruckt am: 06.11.2024 um 01:11 Uhr
13 Kommentare
Neuester Kommentar
Gibt es noch andere Switches außer Cisco (auch Cisco SoHo Modelle) im Netz oder ist das ein reines Catalysten oder Nexus Netzwerk ?
Die Frage deshalb weil Cisco per Default ihr proprietäres PVSTP+ machen. Also ein Per VLAN Spanning Tree mit proprietären BPDU Mac Adressen.
Es gibt nur sehr wenige Hersteller die dazu kompatibel sind. Die meisten Fremdhersteller nutzen das banale Single Span auf Basis von RSTP was dazu nicht kompatibel ist.
Ein einziger solcher Switch oder ein anderes Device was auch nur Standard Spanning Tree fähig ist und das nicht angepasst wurde kann zu solchen Problemen führen.
Spanning Tree basiert auf einer strikten Hierarchie und daraus resultiert die 2te Frage weil leider deine Konfig fehlt.
Der Root Switch (was meistens der Layer 3 Core ist) sollte immer eine entsprechend höhere STP Priority haben als der Rest (default ist 32768). STP Priority Werte werden immer modulo 4096 konfiguriert.
Frage ist das bei dir so korrekt konfiguriert ?
Fehlt das kann jeder bleibige Switch die Root Rolle kapern allein aufgrund sein Bridge Mac Adresse was dann zu einem STP Recalculation Prozess im ganzen Netz führt mit kurzzeitigem Stillstand.
Genau das was bei dir oben passiert. Du erkennst es an den zyklischen Topology Changes ! Diese dürfen in einem stabilen STP Netz niemals auftreten solange kein Switch komplett ausgefallen ist.
Es ist also essentiell wichtig den STP Root und auch Backup Root Switch mit entsprechenden globalen Priority Werten zu versehen !
Wichtig auch: Ist BPDU Guard konfiguriert ?
All das was wichtig ist hast du leider nicht angegeben.
Die Frage deshalb weil Cisco per Default ihr proprietäres PVSTP+ machen. Also ein Per VLAN Spanning Tree mit proprietären BPDU Mac Adressen.
Es gibt nur sehr wenige Hersteller die dazu kompatibel sind. Die meisten Fremdhersteller nutzen das banale Single Span auf Basis von RSTP was dazu nicht kompatibel ist.
Ein einziger solcher Switch oder ein anderes Device was auch nur Standard Spanning Tree fähig ist und das nicht angepasst wurde kann zu solchen Problemen führen.
Spanning Tree basiert auf einer strikten Hierarchie und daraus resultiert die 2te Frage weil leider deine Konfig fehlt.
Der Root Switch (was meistens der Layer 3 Core ist) sollte immer eine entsprechend höhere STP Priority haben als der Rest (default ist 32768). STP Priority Werte werden immer modulo 4096 konfiguriert.
Frage ist das bei dir so korrekt konfiguriert ?
Fehlt das kann jeder bleibige Switch die Root Rolle kapern allein aufgrund sein Bridge Mac Adresse was dann zu einem STP Recalculation Prozess im ganzen Netz führt mit kurzzeitigem Stillstand.
Genau das was bei dir oben passiert. Du erkennst es an den zyklischen Topology Changes ! Diese dürfen in einem stabilen STP Netz niemals auftreten solange kein Switch komplett ausgefallen ist.
Es ist also essentiell wichtig den STP Root und auch Backup Root Switch mit entsprechenden globalen Priority Werten zu versehen !
Wichtig auch: Ist BPDU Guard konfiguriert ?
All das was wichtig ist hast du leider nicht angegeben.
Du solltest nie mit unterschiedlicher VLAN Priorities arbeiten. Das schafft nur Probleme wie oben, da dann der Root Switch VLAN abhängig ist. Keine gute Idee... Deshalb oben ja auch der Hinweis auch die globale STP Priority.
Die STP Hierarchie sollte immer strikt sein com Core zum Access !
Zudem sind deine Werte falsch. Die Priority Parameter können Prinzipien bedingt niemals diese Werte annehmen:
Sind immer die höchsten 4 Bits der Bridge ID und die können niemals solche Werte haben (Binärsystem !)
Die Fehler kommen über die Port Channel 57 und 60.
Möglich das hier auf den Member Links des LAGs fehlerhaft falsche Parameter oder Priorities kommen.
Der Port geht in den Blocking Mode und weil dann der Root Switch Port wechselt, was er nie machen dürfte wenn Root und Backup Root nicht komplett ausfallen !
Blocking passiert bei kurzzeitigen Loops. Du solltest also auch die Konsitenz der VLANs und der Native VLANs auf dem LAG einmal an beiden Enden ebenfalls genau prüfen.
Vermutlich eine Kombination aus unsauberer STP Konfig und Loops in einigen VLANs. Besonders 128.
Ohne genaue Kenntnis der Konfig kommt man aber nicht weiter und ist zum Raten verdammt.
Die STP Hierarchie sollte immer strikt sein com Core zum Access !
Zudem sind deine Werte falsch. Die Priority Parameter können Prinzipien bedingt niemals diese Werte annehmen:
Sind immer die höchsten 4 Bits der Bridge ID und die können niemals solche Werte haben (Binärsystem !)
BPDU Guard ist auf alle Geräten aktiv ja:
Aber nicht auf den Access Switches wo es wichtig ist !Der Switch wurde vor einiger Zeit neu hinzugefügt.
Deshalb nochmals die wichtige Frage: "Gibt es noch andere Switches außer Cisco (auch Cisco SoHo Modelle) im Netz oder ist das ein reines Catalysten oder Nexus Netzwerk ?"Die Fehler kommen über die Port Channel 57 und 60.
Möglich das hier auf den Member Links des LAGs fehlerhaft falsche Parameter oder Priorities kommen.
Der Port geht in den Blocking Mode und weil dann der Root Switch Port wechselt, was er nie machen dürfte wenn Root und Backup Root nicht komplett ausfallen !
Blocking passiert bei kurzzeitigen Loops. Du solltest also auch die Konsitenz der VLANs und der Native VLANs auf dem LAG einmal an beiden Enden ebenfalls genau prüfen.
Vermutlich eine Kombination aus unsauberer STP Konfig und Loops in einigen VLANs. Besonders 128.
Ohne genaue Kenntnis der Konfig kommt man aber nicht weiter und ist zum Raten verdammt.
Das große Problem sind die nicht konsistenden Priorities ! Die sind mit Sicherheit die Ursache.
Nur einzig der Core Switch darf ein "spanning-tree vlan 1.4096 priority 4096" haben **nicht der oder die Access Switches !
Dort belässt man alles auf Default 32768. Wenn dort z.B. spanning-tree vlan 1,128 priority 4096 konfiguriert ist dann hast du wieder einen Priority Pat im VLAN 1 und 128 und dann entscheidet die Mac Adresse über den Root Switch was natürlich kontraproduktiv ist und bei redundanten Links zu einer permanenten Topo Change bei Ausfall führt.
Abgesehen davon ist die statische Port Channel Konfig auch keine besonders intelligente Idee.
Es ist immer besser den Mode auf active zu setzen um LACP zu machen und die Part Channel dynamisch zu überwachen. Abgesehen davon bringt der LACP Mode einen eigenen Loop Detection Algrithmus mit der LAGs vor kurzzeitigen Loops und damit STP Problemen bei einsetigem Link Ausfall schützt.
Vermutlich sind es diese vielen kleinen Fehler einer unsauberen Konfig die im Endeffekt dieses Resultat haben.
Nur einzig der Core Switch darf ein "spanning-tree vlan 1.4096 priority 4096" haben **nicht der oder die Access Switches !
Dort belässt man alles auf Default 32768. Wenn dort z.B. spanning-tree vlan 1,128 priority 4096 konfiguriert ist dann hast du wieder einen Priority Pat im VLAN 1 und 128 und dann entscheidet die Mac Adresse über den Root Switch was natürlich kontraproduktiv ist und bei redundanten Links zu einer permanenten Topo Change bei Ausfall führt.
Abgesehen davon ist die statische Port Channel Konfig auch keine besonders intelligente Idee.
Es ist immer besser den Mode auf active zu setzen um LACP zu machen und die Part Channel dynamisch zu überwachen. Abgesehen davon bringt der LACP Mode einen eigenen Loop Detection Algrithmus mit der LAGs vor kurzzeitigen Loops und damit STP Problemen bei einsetigem Link Ausfall schützt.
Vermutlich sind es diese vielen kleinen Fehler einer unsauberen Konfig die im Endeffekt dieses Resultat haben.