If you have cam table instability and see frames multiple times, you likely have a loop. If that is the case, I would investigate for areas of your layer two network that does not have spanning-tree enabled.
let say a user connected a mini switch (hub) to a drop to connectect more systems but also loops the hub into its selft and brings the network to a crawl. Would that be cause by a broadcast storm to a loop. Would it be a loop even if the hub does not generate (BPDU's) but just passes traffic.
If it is a hub connected to multiple enterprise switch segments, it can forward bpdu's. So if the enterprise switch is producing bpdu's, it should break the loop. Now if you had a hub or switch connected to a single port on the enterprise switch, it would also produce a loop. If there was no way to break that loop, any frame that would be flooded or switched back into the enterprise network would cause a broadcast storm. However, the storm would be limited to the capacity of the enterprise switch port that it is connected to. In other words, the frames would not loop inside the enterprise switch network, but duplicates could be presented from the rogue device.
The best aproach for troubleshooting will be to isolate the problem to a determined group of switches, i will go directly into the core part of the network and start with the comand:
#sho mac address-table / sho mac-address-table (depending on the IOS).
From there you will note some duplicates over certain ports, that will lead you to section of the network where the problem is located.
Once you find out the access layer switch that is giving you more of the MAC adresses repeated over its port, i belive you can start checking out phisically on the user side to verify there is no rogue device attached to it.
Also try to keep record if the issue is being presented at a certain time of the day.
Even though i believe that the Spanning tree portion of the switch affected will take care of the broadcast storm getting into the core / distribiution part of your network.
BTW. try to enable some kind of port security at the access level so it will block those troubled ports.
Try to verify any errdsbl state ports also, and if you are allowed set some SNMP traps to detect any errors.
Any how the problem will be limited by some group of users screaming out at you via the phone... LOL
Hope this helps out.
In a properly configured core and workgroup switch environment, the Broadcast Storm from the beaconing rouge hub would be contained within the switch port. The switch impacted would have to deal with the chatter from a CPU perspective too so that could slow things down on other switchports on that switch.
The switch could also have default Cisco STP loop guard feature or UniDirectional Link Detection (UDLD) loop detection IOS features disabled manually that could storm scenarios if two ports on the dumb hub were both connected to switchports in the same switch or chassis or to a pair of switches making a triangle.
In switch config, look for "uplinkfast or portfast" on a given switchport and if you can validate the cable is actually ngt going to minihub. See link below
However I have seen very dumb hubs from Netgear or Linksys actually self correct and disable a port when two ports are connected to the same switch. So this scenario could be a defective hub that is beaconing that is a low cost hub that should be thrown in the trash bin. The MAC of the hub could be found with a probe easily if it's beaconing because it would flood the network with the same MAC all the time. and then the hub could be isolated as mentioned above.
So it could also be a misbehaving NIC adapter on a single PC crying out for help and beakoning please replace me! Or the PC could have malware virus trying to copy itself to any unprotected location that it can via known exploits.
Finally, if you have a miniswitch that has several MACs showing when a "switchport mode access" is configured on the Cisco switch (there should be only one MAC) and one of the MACs is being flooded then you found your problem.