I noticed once in one common network jumps in broadcast traffic, I was able to detect naturally quickly, since I had previously set up monitoring via graphs and triggers using Zabbix. I looked at the graphs of broadcast traffic from the ports of the main switch, from here it was clear where he started to go, and so we determined the chain to the client switch and port. In the Zabbix monitoring system, it is convenient to configure triggers that trigger when the limit of broadcast traffic is exceeded and report this on the screen, email to the administrator, etc.
Naturally, loop protection on all switches was turned on (but the flood in my case was not from the loop):
enable loopdetect
config loopdetect ports 1-24 state enabled
config loopdetect recover_timer 600 interval 10 mode port-based
show loopdetect
Broadcast storm control was also enabled:
config traffic control 1-24 broadcast enable action drop threshold 64 countdown 5 time_interval 5
You can view the traffic on the ports with the command (for example, from port 1 to port 24, from here you can see which port the broadcast is from):
show packet port 1-24
An example of disabling and enabling a port:
config ports 11 state disable
config ports 11 state enable
show ports
show ports description
Through the ACL, you can also completely block broadcast traffic, but in this case, users will not be able to receive IP addresses via DHCP (only manually registered IP addresses will work):
create access_profile ethernet destination_mac ff-ff-ff-ff-ff-ff profile_id 7
config access_profile profile_id 7 add access_id auto_assign ethernet destination_mac ff-ff-ff-ff-ff-ff port 1-24 deny
At the time of a broadcast flood, users connected to the shared network may or may not have the Internet working at all, switches usually have an increased processor load, etc., therefore it must be limited in advance to all possible suitable functions on all switches.
See also my articles:
SNMP OID and MIB for interfaces
Installing and Configuring Zabbix Server