Simple Network Management Protocol (SNMP) is an application protocol offering network management services in the Internet Protocol suite. SNMP is defined in several RFCs published beginning in 1990. During the last few years SNMP has been adopted by numerous vendors of network equipment as a main or secondary management interface.
SNMP defines a client/server relationship. The client program (called the network manager) makes virtual connections to a server program (called the SNMP agent) executing on a remote network device. The data base controlled by the SNMP agent is referred to as the SNMP Management Information Base (MIB), and is a standard set of statistical and control values. SNMP additionally allows the extension of these standard values with values specific to a particular agent through the use of private MIBs.
Directives, issued by the network manager client to an SNMP agent, consist of the identifiers of SNMP variables (referred to as MIB object identifiers or MIB variables) along with instructions to either get the value for the identifier, or set the identifier to a new value.
Through the use of private MIB variables, SNMP agents can be tailored for a myriad of specific devices, such as network bridges, gateways, and routers. The definitions of MIB variables supported by a particular agent are incorporated in descriptor files, written in Abstract Syntax Notation (ASN.1) format, made available to network management client programs so that they can become aware of these MIB variables and their usage.
SNMP has several strengths. Its biggest strength is arguably its widespread popularity. SNMP agents are available for network devices ranging from computers, to bridges, to modems, to printers. The fact that SNMP exists with such support gives considerable credence to its reason for existence; SNMP has become interoperable.
Additionally, SNMP is a flexible and extensible management protocol. Because SNMP agents can be extended to cover device specific data, and because a clear mechanism exists for upgrading network management client programs to interface with special agent capabilities (through the use of ASN.1 files), SNMP can take on numerous jobs specific to device classes such as printers, routers, and bridges, thereby providing a standard mechanism of network control and monitoring.
Several weaknesses of SNMP can be identified. Despite its name, (i.e. "Simple" Network Management Protocol), SNMP is a highly complicated protocol to implement. By the admission of its designers, a more apt name might be "Moderate Network Management Protocol", although even this seems generous in light of SNMP's highly complicated encoding rules. Also, SNMP is not a particularly efficient protocol. Bandwidth is wasted with needless information, such as the SNMP version (transmitted in every SNMP message) and multiple length and data descriptors scattered throughout each message. The way that SNMP variables are identified (as byte strings, where each byte corresponds to a particular node in the MIB database) leads to needlessly large data handles that consume substantial parts of each SNMP message.
The above complaints, while fair, cannot reasonably be used to detract from the aforementioned strengths of SNMP. While complicated encoding rules frustrate programmers who must deal with them, it is easily argued that end users of the protocol aren't concerned with the complexity of the algorithms that decode their data. As for complaints about SNMP efficiency, it has been shown to work well enough, given the nature of network administration activities.
One criticism of SNMP cannot be dismissed so easily: SNMP has generally lacked focus on why it is useful. Neither the governing RFC's nor other explanatory references describe why SNMP is better than more traditional network management tools such as "ping", "rsh", and "netstat". Consider: the design of SNMP agents difficult. Equally difficult is the administration of these many agents and their managers, which typically entail individual configuration and possible maintenance. Why is SNMP all that much better than, say, telnet protocol? Does the elaborateness of SNMP justify its usefulness? Or can simple telnet driver programs, which periodically log into network devices to gather statistics and apply control, achieve the same end?
In part, this criticism has been aggravated by SNMP management program vendors, who create systems where SNMP is merely an alternative to remote shells rather than a new way of analyzing and managing networks. Many SNMP vendors seem to see network management activities in terms of GUI's with point and click controls instead of automated systems for configuring devices, gathering data, and conduct corrective procedures on large networks.
Faced with the above criticism of SNMP, one tendency is to admit that there are alternatives to SNMP, but these alternatives are supplanted by the general popularity and interoperability of SNMP. This tendency should be rejected in favor of a much better argument for SNMP; a point made by the remainder of this paper is that there ARE NO current alternatives to SNMP, at least for certain types of network administrative functions. While the protocol itself may be less than perfect, SNMP provides the ONLY way to efficaciously manage large networks.
The lack of understanding about SNMP's usefulness is partly attributable to a basic flaw in the philosophy of many SNMP management programs as follows: Most vendors implement network managers with the idea that a user's primary interested is in the data associated with particular network devices. But the truth is, this data is easily acquired by other means (such as with "netstat" and "rsh" Unix programs). The truly pertinent information about the network is the DIFFERENCES between devices irrespective of their current state. As will be examined in this paper, SNMP affords the only mechanism currently available to process these differences rapidly on networks of scale, since SNMP avoids the processing burden of remote login and execution.
See also: Table of Contents and SNMX Base Distribution Files.