Topologie Spanning Tree change from StackPort1

Unanswered Question
Mar 16th, 2010

Hello,

I have a stack of 6 x switches with StackWise 3750, I have a problem of topology spanning-tree changes frequently on some but not all VLANs.
The source of the topology change is the interface StackPort1.

Can you tell me what is the reason for this change? Problem IOS Bug?

Here is the output of

sh spanning-tree vlan 201 active detail

VLAN0201 is executing the rstp compatible Spanning Tree protocol

Bridge Identifier has priority 32768, sysid 201, address 0014.f297.0900

Configured hello time 2, max age 20, forward delay 15, transmit hold-count 6

Current root has priority 32969, address 000f.9060.6a00

Root port is 504 (Port-channel3), cost of root path is 3

Topology change flag not set, detected flag not set

Number of topology changes 70 last change occurred 5d23h ago

from StackPort1

Times: hold 1, topology change 35, notification 2

hello 2, max age 20, forward delay 15

Timers: hello 0, topology change 0, notification 0, aging 300

Thank you for response

David MAZELLY

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 2.9 (6 ratings)
Loading.
tyler.g.west Mon, 04/18/2011 - 20:34

I have the same problem with a 3750 stack I have.  I wish somebody knew the answer to this question.

Mohamed Sobair Mon, 04/18/2011 - 23:38

Hi,

The Stack Port in the 3750 Stack is used also to Synchronize STP information between memeber of Stack Switches. These TCNs originally not generated from the stack port , however the Stack forwards and Sync these recieved Topology Change notifications to the member of Stack Switches.

You dont have to worry about that, its normal behaviour. you just need to check the underline port which generate the TCNs and figure out why it does.

Regards,

Mohamed

tyler.g.west Tue, 04/19/2011 - 07:26

But synchronizing TCNs and reporting a TCN in the show output appear to be two different things.  The way you describe it, it seems like you are saying that, if a TCN is generated from a stack member then the show output will show it coming from the stack port on the master.  There are two problems with this.  1)  There seems to be no way to view spanning-tree statistics for an individual stack member so you cannot track down the originating port.  2)  I have a 3750 stack sitting right beside of the one in question running the same software that reports TCNs from the actual interface of the member switch and not across the stack port.  The documentation on the 3750 clearly states that the stack operates as a single bridge in the spanning-tree topology.

I'm curious as to what you base your information on.  Do you have a document that you can link me and others to that are seeing this?  Because I can't find any way of tracking down the TCN to the originating port when it says it sees it across the stack port.

Mohamed Sobair Wed, 04/20/2011 - 00:47

Hi Tylor,

You have a good point here, I also based my answers on previous reading and documentation and I am happy that we are discussing the symtom your describing.

Ok, my previous answer was based on answer from Cisco's Expert (Francois Tallet). but it was on different case, however all must lead to the same point.

I have had different issue before, but when discussed , Francois stated that the Stack port is used to sync STP information, I agree with you that logically all STP Switch members of Sack should be viewed as a single Switch , however, Physicall , still for those members , the Stack ports forward and Synch STP information between member of Stack and it provides a good sense since those switches to operate as a single domain, because of the Stack.

Other Point, You can still figure out the original port which generating the TCNs, if you trace it Switch by Switch , the exact port on specific stack member switch should reveal the exact port generating STP TCNs. You just need to repeat what you are doing on all switches, but you need a down time and make every switch as standalone and figure it out, Or else if its not a practical solution,, without the need of that, you can check from the logs on the Master of the Stack which interface mostly flaps and thus generating Topology Change Notifications.

Let me know your concerns,

Regards,

Mohamed

barmason Thu, 10/20/2011 - 10:20

The best way to quickly find the actual physical source port is from the stack master, issue 'session x' into each of the other stack members.  Then when you issue the 'show spanning-tree detail | i from|exec|occur' command from the perspective of each stack member you will find the actual port where the TCN was sourced.

HTH

farhan_p2000 Fri, 01/30/2015 - 13:02

Logging in to the member switches and checking the interface generating TCN does help.

 

Thanks

&

Regards,

Farhan Patel

John Rumball Fri, 02/12/2016 - 06:29

I am having the same problem with a 2 switch stack comprising a WS-C3750-48P and a WS-C3750-48TS both running 12.2(55)SE5.

I have traced ongoing TCNs to this stack and have followed the direction above to "session x" into each switch to locate the offending port.  What's odd is, when on the master, it shows the TCN source port as being StackPort1, but on the second switch it shows TCNs coming from StackPort2. It's a vicious cycle.

Of note, also, is that the logs on this stack show constant %STACKMGR-4-STACK_LINK_CHANGE: messages, implying instability in the stacking connections.

Any ideas on how to stop the TCNs from flooding my STP topology?

Thanks.

John

Actions

This Discussion