Wir betreiben hier mehrere Cisco 2960S-Stacks und haben seit einiger Zeit regelmäßige Spanning Tree-TCNs (Topology Change Notifications).
Wenn Sie show spanning-tree detail verwenden , um zur Quelle des TCN zu gelangen, stammen sie von verschiedenen 2960S-Stack-Mitgliedern.
Da die Konfiguration von älteren Switches übertragen wurde, werden die Ports als Trunks konfiguriert, wobei das Daten-VLAN das native VLAN und die VoIP-VLANs als im Trunk markiert sind. Ich weiß, heute wäre die richtige Konfiguration der Zugriff auf den Switchport-Modus in Kombination mit dem Switchport-Voice-VLAN - aber im Moment ist es so.
Ein Teil des Problems beruhte auf der Tatsache, dass einige Ports nur als portfast und nicht als portfast-Trunk konfiguriert wurden. Dies muss behoben werden, da der Befehl portfast only nicht auf Ports im Trunk-Modus angewendet wird. Einige Ports sind jedoch als portschneller Trunk konfiguriert , der nach meinem Verständnis der Cisco-Dokumentation das Generieren von TCNs bei Verbindungsänderungen vermeiden sollte.
Leider tun sie das.
Durch Ausführen von show spanning-tree interface Gi1 / 0 / x portfast wird portfast für alle VLANs auf dieser Schnittstelle aktiviert. Show Spanning Tree-Details zusammen mit show logging zeigen jedoch, dass diese Schnittstellen tatsächlich die Quelle für die Spanning Tree-Änderungen sind.
Es wird sichergestellt, dass keine "speziellen" Geräte an diese Ports angeschlossen sind, sondern nur VoIP-Telefone und Desktop-Workstations.
Der Versionslauf ist 12.2 (55) SE3, die Geräte sind 2960S-48LPS-L und 2960S-48FPS-L.
Auf der Suche nach bekannten Fehlern gab es in einer 12.1-Version für 3550-Switches einen Fehler, der ein solches Verhalten verursachte, aber dies ist das falsche Gerät und eine viel ältere Version, und ich denke, jemand hätte diesen Fehler schon einmal erleben sollen.
Irgendeine Idee, wo man suchen soll, was man probieren soll?
Antworten:
Dieser Beitrag ist älter, daher bin ich mir nicht sicher, ob dieses Problem immer noch auftritt. Ich würde gerne die Dokumentation sehen, auf die Sie sich auch bezüglich des Befehls portfast trunk beziehen. Die Portfast-Trunk-Konfiguration sollte auf Hosts angewendet werden, mit denen Sie Trunking durchführen, z. B. einen ESX-Host oder einen Load Balancer. Für Switch-to-Switch sollte diese Konfiguration nicht vorhanden sein.
Es gibt viele Informationen, die ich sehen müsste, um die Topologie und den Spanning-Tree-Modus, in dem Sie ausgeführt werden (PVST +, RPVST + oder MST), besser zu verstehen. Ich vermute nach dem, was ich gelesen habe, dass Sie PVST + ausführen. Ich möchte zunächst mit der Ausgabe von show spanning-tree vlan x detail und einem Ausschnitt dieses TCN beginnen, den Sie sehen. Ich würde auch gerne show run | sehen Ich überspanne.
Ich vermute, Sie haben möglicherweise einen oder mehrere Ports, die flattern, und die TCN-Nachricht sollte uns direkt zum Täter führen.
Sie haben also ein VoIP-Telefon an einen Switchport angeschlossen, der als Switchport Access VLAN konfiguriert ist, und Computer / Hosts, die an andere Switchports mit Switchport Access VLAN angeschlossen sind? Ja, Sie wissen, dass Sie es für Switchport Voice VLAN einrichten können. Da ich jedoch ohne das Switchport-Voice-VLAN eingerichtet bin, sehe ich kein Problem mit TCNs.
TCNs werden generiert, wenn ein Port von einem Status in einen anderen wechselt, sofern Sie die Prioritätswerte nicht ändern.
quelle
Obwohl diese Frage ziemlich alt ist, kann es sein, dass jemand sie findet, während er das gleiche Problem googelt. Hier kommt unsere "Lösung":
Wir konnten die Ursache des Problems nicht herausfinden, da das Problem nicht reproduzierbar war und nur etwa einmal am Tag auf verschiedenen Access-Ports auftrat, wobei ungefähr 500 Access-Ports mit genau derselben Konfiguration verwendet wurden.
Nach dem Update aller 2960 auf eine Version aus der 15.x-Zeile verschwanden die Probleme. Die Konfiguration hat sich nicht geändert, daher scheint sie in einer der dazwischen liegenden Versionen stillschweigend behoben worden zu sein.
quelle