SNMP is a wonderful, sometimes maddening management protocol. It can provide monitoring, powerful trending, and alerting when things go wrong on the network. But too much of anything can be bad, and SNMP is no exception. When not properly managed, SNMP itself can become problematic.
Most seasoned network admins buy into basic best practices like disabling SNMP when not in use on host devices, changing strings occasionally, and using ACLs to control who can use SNMP so resources like router CPUs don’t get DOS’d by the very protocol meant to manage the environment.
But sometimes other SNMP-related issues creep in when we get sloppy. It’s easy for multiple admins to set up eval copies of SNMP-based config management or monitoring software without coordinating the polling cycles of each. Or to perhaps set up a special monitoring instance that’s meant to use SNMP to help pinpoint some specific problem, without implementing common-sense safeguards (like we don’t want to SNMP-read our core routing tables every 10 minutes). Worst, these tools are easy to put in place and forget about, which means our SNMP traffic can get out of hand and become problematic.
Is your own SNMP house in order?