spanning tree issue

Unanswered Question
Jul 2nd, 2009

Can any one help me in identifying this issue. I have four core switches two in A side and two in B side.

A side running with

Ciso IOS

pvst

layer 3 and layer 2 switche

B side running with

CatOS

PVST+

layer 3 and layer 2 switches

In q site suddenly the whole network goes down for a minute or two and again it come back. When i traced the core switch I found its pointing to another switch which is creating a topology changes and when I traced the switch I did not find any topology change initiator.

bridge forward delay 15(15) sec

topology change initiator: 3/3

last topology change occured: Thu Jul 2 2009, 07:45:57

topology change FALSE

topology change time 35

topology change detected FALSE

topology change count 2508241

topology change last recvd. from 00-02-fd-7f-d4-b1

Here it tells me initiator is 3/3 which is a switch when I go to this switch I did not find the MAC 00-02-fd-7f-d4-b1 . Any thoughts ?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
xcz504d1114 Thu, 07/02/2009 - 08:44

Could be a flapping link (using UDLD can help prevent those), it could be processor utilization on your core caused by an ARP storm, it could simply be another device taking over as the root bridge, it could be a lot of things.

I would start with identifying your root bridge, and making sure he is set to be the primary, that will prevent unwanted devices from becoming the root and causing topology changes. You can do this by using "spanning-tree vlan X root primary" on whichever device you want as your primary, I would recommend setting a secondary as well. You can view the root priority by issuing "show spanning-tree vlan X root". The default value is 32768, the "root primary" command set changes it to 16384.

Keep in mind if you manually change the priority using the priority key-word, you change it in increments of 4096, and the lower the priority, the more likely it will be root.

If you already have the priority set, you might want to consider your spanning tree timers, spanning tree default timers are made for a topology diameter of 7, if you have a larger diameter than that, network delays can cause BPDU's to be delivered late and cause a topology change.

If it happens again, and you already have your priority set, quickly log in to your cores and do a "show proc cpu" and look at the processor utilization to verify something isn't sending broadcast storms or anything to eat up CPU cycles.

Setting the root bridge typically fixes these issues though.

HTH,

Craig

mazheralam Thu, 07/02/2009 - 10:19

Thanks Craig. Core switches are already defined with priority set and timers are as that of default setting. The maximum diameter is 7 now. Well I will check the processes at the time of slowness. Any other possiblity ??

A#sh spanning-tree vlan 1 root

Root Hello Max Fwd

Vlan Root ID Cost Time Age Dly Root Port

---------------- -------------------- --------- ----- --- --- -----------

VLAN0001 8192 00d0.02a6.c001 0 2 20 15

A#SH RUN | IN priority

spanning-tree vlan 1-107,109-4094 priority 8192

spanning-tree vlan 108 priority 8191

B#sh run | in priority

spanning-tree vlan 1-4094 priority 16384

xcz504d1114 Thu, 07/02/2009 - 10:35

How many VLAN's do you have? Some devices, such as 3508's only support 64 spanning tree instances, 3750's only support 128 spanning-tree instances.

With PVST and PVST+, each VLAN is a spanning tree isntance.

Unfortunately I think you might be to the point of tedious leg work. Going through your switches and verifying they all show the correct root, when the last time they saw a topology chagne etc. You can deduce where the problem occured and maybe find something in the logs of a device. Hopefully you have logging setup on all of your devices, and you are using date/time stamps. If not you should consider that :)

logging buffered

service timestamps log datetime

And having all of your devices pointing to an NTP helps a ton as well.

If I think of anything I will definately post.

Craig

mazheralam Thu, 07/02/2009 - 12:22

Thanks Craig for your reply.

well I will do this tedious job to find the root bridge. but I do have NTP setup and have logs with time stamp. Just there is again topology changes, I checked using the following command

sh spantree statistics 1/1 1

and its coming from a switch.. AFter that I stuck as that switch is fan out with two other switches and it does not tell me where from its originating and even number of topology changes.

If any other thoughts please post it. Thanks

mazheralam Thu, 07/02/2009 - 12:33

Just checked with all the switches and they are pointing to the the same rood bridge.

mazheralam Sun, 07/05/2009 - 08:32

Core switches are 6509, left two core switches are running with PVST, ciscoios, while right two are with pvst+, catos. There are some layer 3 stacks and layer 2 stacks of access switch.

Attachment: 

Actions

This Discussion