Topologie Spanning Tree change from StackPort1

[david.mazelly]

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

[tyler.g.west]

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

[Mohamed Sobair]

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]

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]

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]

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]

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

Thanks

&

Regards,

Farhan Patel

[N3t W0rK3r]

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

[vishalkanojia.v]

login into every switch member and execute below command u will get which port is generating TCNs frequently,

example:

punts004-2#sh spanning-tree detail | i ieee|occur|from|exec
 VLAN0010 is executing the ieee compatible Spanning Tree protocol
  Number of topology changes 3 last change occurred 4d12h ago
 VLAN0020 is executing the ieee compatible Spanning Tree protocol
  Number of topology changes 3 last change occurred 4d12h ago
 VLAN0030 is executing the ieee compatible Spanning Tree protocol
  Number of topology changes 27 last change occurred 01:43:17 ago
          from GigabitEthernet2/0/12
 VLAN0040 is executing the ieee compatible Spanning Tree protocol
  Number of topology changes 5 last change occurred 4d12h ago
 VLAN0050 is executing the ieee compatible Spanning Tree protocol
  Number of topology changes 5 last change occurred 4d12h ago
 VLAN0060 is executing the ieee compatible Spanning Tree protocol
  Number of topology changes 3700 last change occurred 00:03:57 ago
          from GigabitEthernet2/0/28

see above example and u will see in switch member 2 port GigabitEthernet2/0/28 in vlan60 is flapping a lot, chk this port.