Broadcaststorm trotz STP?

[FBDIMM]

Ich grüße euch liebe Community.

Trotz meines kürzlich erworbenen CCNAs bin ich mit den realen Netzwerken manchmal doch überfordert.

In einem aktuellen Fall bei einem Kunden, sind ohne Ende Cisco Switche der SF Serie verbaut, ca. 1100 Clients, alles ein fetter Layer 2 Bomber bis Access Ebene.

Von Core bis Access haben wir 5 Hops. Dazu noch WLAN APs auf PoE Switchen.

Nun läuft das Netzwerk mit RSTP, jedoch besteht das Problem dass es aus irgendeinem Grund gelegentlich Broadcast bzw. Multicaststürme gibt von "IGMP v2", was das ganze Netzwerk komplett lahmlegt.

Mein Verdacht ist, dass dort irgendwie ein Loop besteht in irgendeinem Teil des Netzwerks.

Aber wie kann das sein trotz Spanning Tree? Angeblich ist das ja die eierlegende Wollmilchsau, aber wo sind die Grenzen von STP, und wie gehe ich hier am besten vor?

BPDU Guard, Loopback detection oder Stormcontrol evtl. eine Lösung?

 

[Ma Lte]

Schau dir am besten genau die Topologie an und gleiche sie notfalls mit der Realität ab. Da manche Kunden an ihren Switchen auch gerne mal selber rum stöpseln, muss die Doku (sofern vorhanden) nicht aktuell sein. Wenn die da unwissentlich mehrere Loops rein gebaut haben, kann Spanning Tree da irgendwann auch nicht mehr viel machen. 

[Maniska]

Ich stolper gerade über

vor 8 Stunden schrieb FBDIMM:

gelegentlich

und frage mich ob man das irgendwie eingrenzen kann.

Was genau wird gemacht um das "lahmgelegte" Netzwerk wieder zu starten? Wenn es ein Loop ist, muss der ja irgendwo her kommen, und vor allem dann auch wieder "gehen". Was sagen die Logs? Wenn da nichts erkennbar ist und die Geräte auch sonst keine Probleme (halbdeffekter Switch ggf) haben:

Meine Vermutung geht in Richtung Schwarzbestand bzw. Schatten-IT (wollte uns nicht vor kurzen jemand die Vorzüge von Schatten-IT schmackhaft machen?). Ich würde im ersten Schritt schauen, ob auf den Switches MAC-Adressen auftauchen die "merkwürdig" aussehen und diese zurückverfolgen.

Wenn das Problem auch am Wochenende auftritt (und oft/verlässlich genug) mal die Segmente nacheinander abschalten und schauen ob man so die Quelle eingrenzen kann.

[tmp]

ja zu BPDU Guard.
spanning-tree portfast default
spanning-tree portfast bpduguard default

STP-Exkurs von jmdn, der das besser kennt ist als ich:
STP-Prioritäten können 0 bis 65536 sein.
Meistens geht 0 nicht, aber 4096. 4096 spart man sich aber für den schlechten Tag auf, an dem man root auf was anderes schieben muss. Ich hab bei den Beispielen den stp mode auf rapid-pvst, nicht rstp, aber das Prinzip bleibt gleich.

root ist also 8192 für alle VLANs:
spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree vlan 1-4094 priority 8192

alternate root ist der nächstniedrigste Wert 8192+4096=12288:
spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree vlan 1-4094 priority 12288

Alle Switche, die direkt zu root oder alternate root verbunden sind, sollten das auch zu dem jeweils anderem sein. Du baust also Dreiecke auf, sodass der Failover gut funktioniert. Diese direkt verbundenen Switche haben dann die nächstniedrigste Priorität.(12288+4096=16384).
spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree vlan 1-4094 priority 16384

Und jeder Switch des nächsten Hops nach demselben Prinzip (16384+4096=20480)
spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree vlan 1-4094 priority 20480

Und so weiter. Ziel ist es, dass möglichst jeder switch der topologie einen niedrigeren Wert hat als die default-32768. Wenn dann irgendjmd seinen Switch irgendwo ansteckt, hat dein Netzwerk immer noch eine niedrigere STP-Priorität. BPDU guard verhindert Broadcast-Stürme, wenn der fremde Switch STP nicht einmal kennt.

[FBDIMM]

Ich grüße euch Freunde.

Problem ist gefunden und war echt ätzend. Das Problem war das fehlende VLAN 1 auf der gesamten Cisco Infrastruktur. Dort ist noch ein älterer D Link SFP Switch verbaut gewesen welcher für Spanning-Tree das VLAN 1 zwingend benötigt, und dort befand sich auch ein Loop. Dort war eine 4er LAG zu einem anderen D-Link Switch, jedoch steigen unsere verwenden SFP Einschübe ab einer Anzahl von 3 in einer LAG aus, und somit wurde dort ein Loop gebaut weil die eine Strecke nicht in der LAG war. Sehr interessant.

 

Vielen Dank euch!