OK, so assume you have a topology like:
SW1
/ \
/ \
/ \
PC A--SW2-----SW3--PC B
For some reason there is a bridging loop, STP is disabled or someone applied a filter in the wrong place or such.
PC A wants to communicate with PC B. It first ARPs for the MAC of PC B, the destination is a broadcast with MAC ffff.ffff.ffff. So the frame goes to both SW1 and SW3. The SRC MAC is PC A. SW1 then floods the frame towards SW3 and SW3 will flood the frame coming from SW2 to SW1.
SW1 and SW3 learned the MAC of PC A when the first frame came in. When the second one comes in from the opposite direction it has to relearn it. Because these events occur so fast and repeatedly you will see log messages complaining about MAC flapping. Something like "MAC FLAP 0000.0000.0001 is flapping between Gi0/24 and Gi0/23". This is a good sign that you have a loop.
What you could do then is to try to trace this MAC. Try looking in the ARP cache of a device in the same subnet and see what IP this device has. So with the MAC you could try to trace it with sh mac-address-table or with the IP maybe you have a list with all IPs and where they are connected.
If the host gets a IP address from a DHCP server you could also try there to find where the host is coming from. If you have option 82 enabled that would be a great help.
Other signs are that the CLI will be very sluggish. CPU load will be very high. Switches do almost everything in ASICs so if a switch has a CPU load over 50% it's probably not good. You should implement SNMP monitoring and watch for high CPU load. Also look for the MAC flap messages. If the switches have a loop the LEDs will probably be blinking like crazy.
Things you could do to protect against loops:
- Enable STP! (duh)
- SNMP monitoring of CPU load
- Enable SNMP traps for certain events like STP topology changes
- Enable storm control on the ports to limit broadcast
- Don't span your VLANs too much in your L2 topology
- Enable port security and limit number of MAC addresses per port
- Enable Option82 if you run DHCP
Use spanning-tree portfast, and spanning-tree bpduguard enable on each switchport. Root guard is unnecessary on ports with this configuration, because bpduguard will err-disable the port when you receive any bpdus.
Use root guard on links to other switches, which are not planned for the primary or secondary stp root role.
Best Answer
Spanning-tree is the protocol designed to detect and prevent loops. bpduguard is intended for access ports -- ports connected to end users/machines (a single node.) A port configured for bpduguard gets disabled upon receiving a bpdu -- any bpdu.[1][2] As such, enabling this feature on a port headed to a simple switch (aka "hub") is asking for trouble, the instant anyone connected to that "hub" sends a bpdu, the 2960 will disable the port leading to it -- cutting off the "hub" and everything connected to it.
The best option is to simply let spanning-tree on the 2960 work like normal. If you want the port to pass traffic immediately on link -- thus bypassing the normal stp discovery phase -- enable portfast. But otherwise, leave bpduguard off.
[1] https://supportforums.cisco.com/document/45136/importance-bpdu-guard-and-bpdu-filter
[2] http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10586-65.html