Spanning Tree Probleme

Hallo,

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

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.

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

Content-ID: 614283

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

Ausgedruckt am: 21.11.2024 um 17: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.

Servas

Frage: Eine neue Konfig oder ist die bereits seit "Ewigkeiten" so gelaufen?

Hallo und danke für deine Hilfe.

Die Werte sind auf beiden Switchen pro VLAN identisch:

VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 4097
Bridge ID Priority 4097 (priority 4096 sys-id-ext 1)

VLAN0128
Spanning tree enabled protocol rstp
Root ID Priority 4224
Bridge ID Priority 4224 (priority 4096 sys-id-ext 128)

Es handelt sich um ein reines Catalyst Netzwerk.

BPDU Guard ist auf alle Geräten aktiv ja:

Core:
Switch is in rapid-pvst mode
Root bridge for: xxxxxxxxxxxxxxxxxxxx
Extended system ID is enabled
Portfast Default is disabled
Portfast Edge BPDU Guard Default is enabled
Portfast Edge BPDU Filter Default is disabled
Loopguard Default is enabled
PVST Simulation Default is enabled but inactive in rapid-pvst mode
Bridge Assurance is enabled
EtherChannel misconfig guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short

Access Switch:
sh spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: none
EtherChannel misconfig guard is enabled
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is enabled
UplinkFast is disabled
BackboneFast is disabled

Der Switch wurde vor einiger Zeit neu hinzugefügt. Allerdings nicht von mir die Geräte stehen im Ausland.

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 !)

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.

Also die Priority Werte an sich sind alle gleich und setzen sich zusammen aus der ID 4096 plus system ext ID daher 4097 für vlan1 und 4224 für vlan 128

Habe BPDU Guard auf dem betroffenen Switch aktiviert, dachte es wäre bereits aktiv.

Es sidn wie gesagt nur Cisco Switche der Catalyst Serie im Netz aktiv.

Wenn ich die priority auf dem Core global setze, dürfte es ja zu keinem (kurzen) Ausfall des Netzwekrs kommen,. da der COre eh schon Root ist. Oder sollte ich da lieber auf einen geeigneten Zeitpunkt warten?

MfG

Ich hatte eben die Port-Channel Nummer in dem Text auf eine nicht vorhandene Angepasst um keine echten Werte zu posten. Habe das dann bei weiteren Posts übersehen. Der Port-Channel 57 ist überall konfiguriert:

spanning-tree mode rapid-pvst
spanning-tree loopguard default
spanning-tree logging
spanning-tree portfast bpduguard default
spanning-tree extend system-id
spanning-tree vlan 1,128 priority 4096
errdisable recovery cause udld
errdisable recovery cause bpduguard
errdisable recovery cause security-violation
errdisable recovery cause channel-misconfig
errdisable recovery cause pagp-flap
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
errdisable recovery cause gbic-invalid
errdisable recovery cause psecure-violation
errdisable recovery cause dhcp-rate-limit
errdisable recovery cause vmps
errdisable recovery cause storm-control
errdisable recovery cause arp-inspection
errdisable recovery interval 60

!
redundancy
mode sso
!
!
transceiver type all
monitoring
vlan dot1q tag native
lldp run

!
!
interface Port-channel57
switchport trunk native vlan xxx
switchport mode trunk
switchport nonegotiate
!

!
interface GigabitEthernet1/0/1
description FW01
switchport access vlan 128
switchport mode access
logging event link-status
no cdp enable
storm-control broadcast level pps 100
storm-control multicast level bps 100k
storm-control action shutdown
storm-control action trap
spanning-tree bpduguard enable
!
interface GigabitEthernet1/0/2
description FW11
switchport access vlan 128
switchport mode access
logging event link-status
no cdp enable
storm-control broadcast level pps 100
storm-control multicast level bps 100k
storm-control action shutdown
storm-control action trap
spanning-tree bpduguard enable
!

!
interface GigabitEthernet1/1/3
description TRUNK_TO_CORE_1/1/2
switchport trunk native vlan XXX
switchport mode trunk
switchport nonegotiate
logging event link-status
channel-group 57 mode on
!
interface GigabitEthernet1/1/4
description TRUNK_TO_CORE_2/1/2
switchport trunk native vlan XXX
switchport mode trunk
switchport nonegotiate
logging event link-status
channel-group 57 mode on
!

Konfig Core:

spanning-tree mode rapid-pvst
spanning-tree loopguard default
spanning-tree logging
spanning-tree portfast edge bpduguard default
spanning-tree extend system-id
spanning-tree vlan 1-4094 priority 4096
!
redundancy
mode sso
!
!
vlan 128
name xxxxx

!
interface Port-channel57
description 0 (Remote Te1/1/3-4 - Local Te1-2/1/2)
switchport
switchport trunk native vlan xxx
switchport mode trunk
switchport nonegotiate
!

!
interface TenGigabitEthernet1/1/2
description - Po57 member (Remote Te1/1/3)
switchport trunk native vlan xxx
switchport mode trunk
switchport nonegotiate
udld port aggressive
channel-group 57 mode on
!

!
interface TenGigabitEthernet2/1/2
description - Po57 member (Remote Te1/1/4)
switchport trunk native vlan xxx
switchport mode trunk
switchport nonegotiate
udld port aggressive
channel-group 57 mode on
!
!
interface Vlan1
no ip address
shutdown
!
interface Vlan128
ip address 10.xxxxx1 255.255.255xxx

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.

Moin,

habe deine Punkte angepasst, bis jetzt sieht es gut aus. Was ich aber nicht nachvollziehen kann, selbst bei gleicher VLAN Priority sollte der Core doch trotzdem root bleiben, da er definitiv eine niedrigere MAC Adresse hat, als die Access-Switche.

Moin, leider zu voreilig.

Das Problem tritt bei VLAN 1 immer noch auf. Das auch, obwohl ich die Priority manuell auf 61440 gesetzt habe.

VLAN128 ist bis jetzt ruhig.

sh spanning-tree bridge priority
VLAN0001 61441
VLAN0128 32896

Core:
sh spanning-tree bridge priority
VLAN0001 4097
VLAN0128 4224