Krunal,
i would say tht the issue is STP, this might include many causes including L1 and L2, i will try to add the following statements i used to tshoot any STP related issues, as you know there is no procedureal way to tshoot STP, but we have to follow some best practises...
1) First, verify that currently the proper switch is STP root for all VLANs, as you have alredy done this. Then enable root guard on Root/Core switch on all uplink ports to the distribution layer switches.
Excellent doc that details root guard. See the section titled ” What Is the Difference Between STP BPDU Guard and STP Root Guard?” for clarification on the difference. You want root guard on the root and bpdu guard on the access layer. You do not want root guard on the port channel between core switches running HSRP. Only on the uplinks to other switches that you do NOT want to become spanning tree root.
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800ae96b.shtml
2) Enable loop guard on all distribution/access layer switches
3) Enable BPDU guard on all distribution/access layer switches
4) Enable UDLD aggressive on all fiber uplinksUnidirectional links can cause spanning tree loops. UDLD Aggressive will prevent this by shutting down a unidirectional link.
4.1) assure that all ten gig ports TX and RX connected correctly between peers...
5) Prune unnecessary VLANs off your trunks
6) assure that the customer doesnt make any tuning to the STP timers, as this could cause the loops as well...
6.1) assure that all Switches running RSTP, and check the trunks allowed Vlan list, using the command "show interface trunk", and makesure about the trunk allowed list on both ends of the trunk port... assure that both ends of the trunk allow the same list of vlans...
7) Enable mac-address move notification (if applicable) using >>> mac-address-table notification mac-move
Check the switch log for mac’s flapping between interfaces. These are the ports that are participating in the loop. Trace the MAC back to its source. Look for:
A link flapping on a upstream switch, causing spanning tree TCNs and Spanning Tree reconvergence. This should be used in conjunction with step 3 below.
A unidirectional link on an upstream switch causing the loop.
A hub or switch connected to a portfast enabled access port where this mac is learned. Shut this port down and see if this breaks the loop.
8)Check for TCNs
While the loop is occurring, if you see excessive TCNs you need to trace the TCNs (topology change notifications) to the source .
To do this, start from the core and run the following commands:
SW#show spanning-tree detail | inc ieee|occurr|from|is exec
The output from this command will show you the port the last TCN was received on and the time which it was received.
Look for the port that received a TCN in the last few seconds.
here is an example:
SW#sh spanning-tree detail | i ieee|occur|from|is exec
VLAN0001 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 187927 last change occurred 00:01 ago <-time rec'd
from Port-Channel12 <--interface that received the TCN
You will want to follow this port until the port that receives the TCN is an access port, or until the switch in question is generating TCNs but not receiving them. If you find an access port receiving TCNs, shut it down.
If you find a switch generating TCNs, you will want to look for two ports in a spanning tree forwarding state for the same VLAN. If you find two ports in a forwarding state, shut one port down and see if this breaks the loop. Check for a unidirectional link or excessive link flaps.
HTH
Regards
Inayath
