Every company wants to reduce IT costs, but relying on SNMP to automate IT processes is yesterday’s news. Here are five reasons cited by IT managers in recent conversations with STAnalytics as to why they would not want to use SNMP for automation.
1. Incompatibility
Wouldn’t you think that an application layer program that begins with the word SIMPLE would at least be easy to implement? But in fact, SNMP sometimes seems as difficult to deploy as a small space station. A big problem is that no two vendors (or even two products from the same vendor) implement SNMP the same way, in terms of which data are available and how they are accessed. It often takes a lot of fiddling and twiddling to get SNMP-based systems to work correctly. In an age of rapidly increasing scale, the costs are becoming too significant to ignore.
2. Vulnerability
Among the biggest fans of SNMP are the hackers and network bugs. Every since it was designed, invaders enjoyed the ease of running any arbitrary code on target systems. In the first version of SNMP, known as SNMPv1, trap message handling and manager-to-agent request messages were found to be seriously flawed. The next version, SNMPv2 was not much better. Like its predecessor, it did not include any security features, such as encryption or authentication.
The primary danger with SNMP is that it allows basic system configuration information to be attained. For instance, hackers could determine what network adapters are available on the client during the logon sequence. The security flaws were so serious that a scathing report was published by CERT in 2002 and subsequently Microsoft advised users to disable SNMP on all Windows operating systems.
SNMP v3 did address the security concerns, for example, by allowing device reconfiguration via their community strings to provide basic security/authentication on a network topology. These strings provide broadcasted handshaking to insure a device can communicate via SNMP with other devices.
These strings provide broadcasted handshaking to insure a device can communicate via SNMP with other devices. Currently, though, there are no standards around community strings and in many cases no one configures these within the enterprise. Furthermore, most vendors either used the older versions of SNMP or never configured the new version throughout their entire system.
3. Scalability
The world’s largest network is the Internet. Today, it is hard to remember how small it was when it started. Any network protocol must take into account the possibility of massive expansion of the network and be designed to handle an increasing number of agents in a single manager system. But everyone realizes that one of the most significant shortcomings of SNMP is its inability to manage continuously expand networks. According to a recent white paper published by Cisco, “Attempts to modify the SNMP protocol to solve these problems have not been very successful as it involves a large effort to migrate the installed base to the changed version. A number of alternative NMPs such as RMI interfaces, CORBA and Http have been attempted to overcome the problems with SNMP. However, these interfaces lack the standardization effort and simplicity of the usage that SNMP provides. So currently, every application develops models to achieve the desired level of scalability on its own.”[1]
4. Data Collaboration
Did you ever hear the joke about two guys, sweating and struggling to push a table through the door of a house? One of them commented, “Wow! It is so hard to push this table into the house.” His friend was all startled. “Into the house?” he exclaimed. “I thought that we were trying to push it out!”
This is sometimes the story with SNMP. While it defines specific message formats and metadata elements, it doesn’t provide a way to automatically aggregate and correlate information. This means that two devices can report information about the same entity and not ever have the data aligned with one other.
5. Immediacy
Finally, if you are not yet convinced of the flaws of SNMP, consider this: The most common method used to gather data from devices that support SNMP is to poll them. Fundamentally, a polled architecture is hard to scale without introducing latency. So you’re faced with either having old and potentially inaccurate data, or with flooding your network (and pounding devices) with SNMP polls and responses. Neither of these are a good choice. We don’t poll Facebook for changes, Google Alerts can tell us immediately when something new is available. So why should we be using polling to gather information on our IT systems?
Conclusions
SNMP was developed in 1988. It is certainly the most popular network management protocol and it is invaluable for managing individual systems. But for the purposes of broad-based automation, it is inefficient, insecure and, frankly, old-fashioned.
[1] SNMP Over SIP for Network Management, Cisco Systems, January 1st, 2010