The Info List - SNMP

--- Advertisement ---


SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) is an Internet-standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.

SNMP is widely used in network management for network monitoring . SNMP exposes management data in the form of variables on the managed systems organized in a management information base (MIB) which describe the system status and configuration. These variables can then be remotely queried (and, in some circumstances, manipulated) by managing applications.

Three significant versions of SNMP have been developed and deployed. SNMPv1 is the original version of the protocol. More recent versions, SNMPv2c and SNMPv3, feature improvements in performance, flexibility and security.

SNMP is a component of the Internet Protocol Suite as defined by the Internet Engineering Task Force (IETF). It consists of a set of standards for network management, including an application layer protocol, a database schema , and a set of data objects .


* 1 Overview and basic concepts * 2 Management information base * 3 Protocol details

* 4 Development and usage

* 4.1 Version 1 * 4.2 Version 2

* 4.3 SNMPv1 "> Principle of SNMP Communication

In typical uses of SNMP, one or more administrative computers called managers have the task of monitoring or managing a group of hosts or devices on a computer network . Each managed system executes a software component called an agent which reports information via SNMP to the manager.

An SNMP-managed network consists of three key components:

* Managed device * Agent — software which runs on managed devices * Network management station (NMS) — software which runs on the manager

A managed device is a network node that implements an SNMP interface that allows unidirectional (read-only) or bidirectional (read and write) access to node-specific information. Managed devices exchange node-specific information with the NMSs. Sometimes called network elements, the managed devices can be any type of device, including, but not limited to, routers , access servers , switches , cable modems , bridges , hubs , IP telephones , IP video cameras , computer hosts , and printers .

An agent is a network-management software module that resides on a managed device. An agent has local knowledge of management information and translates that information to or from an SNMP-specific form.

A network management station (NMS) executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs may exist on any managed network.


Main article: Management information base

SNMP agents expose management data on the managed systems as variables. The protocol also permits active management tasks, such as modifying and applying a new configuration through remote modification of these variables. The variables accessible via SNMP are organized in hierarchies. SNMP itself does not define which information (which variables) a managed system should offer. Rather, SNMP uses an extensible design which allows applications to define their own hierarchies and metadata. These hierarchies, and other metadata (such as type and description of the variable), are described by management information bases (MIBs). MIBs describe the structure of the management data of a device subsystem; they use a hierarchical namespace containing object identifiers (OID). Each OID identifies a variable that can be read or set via SNMP. MIBs use the notation defined by Structure of Management Information Version 2.0 (SMIv2, RFC 2578), a subset of ASN.1 .


SNMP operates in the Application Layer of the Internet Protocol Suite ( Layer 7 of the OSI model ). The SNMP agent receives requests on UDP port 161. The manager may send requests from any available source port to port 161 in the agent. The agent response will be sent back to the source port on the manager. The manager receives notifications (Traps and InformRequests ) on port 162. The agent may generate notifications from any available port. When used with Transport Layer Security or Datagram Transport Layer Security requests are received on port 10161 and traps are sent to port 10162.

SNMPv1 specifies five core protocol data units (PDUs). Two other PDUs, GetBulkRequest and InformRequest were added in SNMPv2 and the Report PDU was added in SNMPv3.

All SNMP PDUs are constructed as follows:

IP header UDP header version community PDU-type request-id error-status error-index variable bindings

The seven SNMP protocol data unit (PDU) types are as follows: GetRequest A manager-to-agent request to retrieve the value of a variable or list of variables. Desired variables are specified in variable bindings (values are not used). Retrieval of the specified variable values is to be done as an atomic operation by the agent. A Response with current values is returned. SetRequest A manager-to-agent request to change the value of a variable or list of variables. Variable bindings are specified in the body of the request. Changes to all specified variables are to be made as an atomic operation by the agent. A Response with (current) new values for the variables is returned. GetNextRequest A manager-to-agent request to discover available variables and their values. Returns a Response with variable binding for the lexicographically next variable in the MIB. The entire MIB of an agent can be walked by iterative application of GetNextRequest starting at OID 0. Rows of a table can be read by specifying column OIDs in the variable bindings of the request. GetBulkRequest Optimized version of GetNextRequest. A manager-to-agent request for multiple iterations of GetNextRequest. Returns a Response with multiple variable bindings walked from the variable binding or bindings in the request. PDU specific non-repeaters and max-repetitions fields are used to control response behavior. GetBulkRequest was introduced in SNMPv2. Response Returns variable bindings and acknowledgement from agent to manager for GetRequest, SetRequest, GetNextRequest, GetBulkRequest and InformRequest. Error reporting is provided by error-status and error-index fields. Although it was used as a response to both gets and sets, this PDU was called GetResponse in SNMPv1. Trap Asynchronous notification from agent to manager. SNMP traps enable an agent to notify the management station of significant events by way of an unsolicited SNMP message. Includes current sysUpTime value, an OID identifying the type of trap and optional variable bindings. Destination addressing for traps is determined in an application-specific manner typically through trap configuration variables in the MIB. The format of the trap message was changed in SNMPv2 and the PDU was renamed SNMPv2-Trap. While in classic communication the client always actively requests information from the server, SNMP allows the additional use of so-called "traps". These are data packages that are sent from the SNMP agent to the manager without being explicitly requested InformRequest Acknowledged asynchronous notification. This PDU was introduced in SNMPv2 and was originally defined as manager to manager communication. Later implementations have loosened the original definition to allow agent to manager communications. Manager-to-manager notifications were already possible in SNMPv1 (using a Trap), but as SNMP commonly runs over UDP where delivery is not assured and dropped packets are not reported, delivery of a Trap was not guaranteed. InformRequest fixes this by sending back an acknowledgement on receipt.



SNMP version 1 (SNMPv1) is the initial implementation of the SNMP protocol. SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS), Apple Talk
Datagram-Delivery Protocol (DDP), and Novell Internet Packet Exchange (IPX). SNMPv1 is widely used and is the de facto network-management protocol in the Internet community.

The first Requests for Comments (RFC)s for SNMP, now known as SNMPv1, appeared in 1988:

* RFC 1065 — Structure and identification of management information for TCP/IP-based internets * RFC 1066 — Management information base for network management of TCP/IP-based internets * RFC 1067 — A simple network management protocol

These protocols were obsoleted by:

* RFC 1155 — Structure and identification of management information for TCP/IP-based internets * RFC 1156 — Management information base for network management of TCP/IP-based internets * RFC 1157 — A simple network management protocol

After a short time, RFC 1156 (MIB-1) was replaced by the more often used:

* RFC 1213 — Version 2 of management information base (MIB-2) for network management of TCP/IP-based internets

Version 1 has been criticized for its poor security. Authentication of clients is performed only by a "community string", in effect a type of password, which is transmitted in cleartext. The '80s design of SNMPv1 was done by a group of collaborators who viewed the officially sponsored OSI/IETF/NSF (National Science Foundation) effort (HEMS/CMIS/CMIP) as both unimplementable in the computing platforms of the time as well as potentially unworkable. SNMP was approved based on a belief that it was an interim protocol needed for taking steps towards large scale deployment of the Internet and its commercialization. In that time period Internet-standard authentication/security was both a dream and discouraged by focused protocol design groups.


SNMPv2 (RFC 1441–RFC 1452), revises version 1 and includes improvements in the areas of performance, security, confidentiality, and manager-to-manager communications. It introduced GetBulkRequest, an alternative to iterative GetNextRequests for retrieving large amounts of management data in a single request. However, the new party-based security system in SNMPv2, viewed by many as overly complex, was not widely accepted. This version of SNMP reached the Proposed Standard level of maturity, but was deemed obsoleted by later versions.

Community-Based Simple Network Management Protocol version 2, or SNMPv2c, is defined in RFC 1901–RFC 1908. SNMPv2c comprises SNMPv2 without the controversial new SNMP v2 security model, using instead the simple community-based security scheme of SNMPv1. This version is one of relatively few standards to meet the IETF's Draft Standard maturity level, and was widely considered the de facto SNMPv2 standard. It too was later obsoleted, by SNMPv3.

User-Based Simple Network Management Protocol version 2, or SNMPv2u, is defined in RFC 1909–RFC 1910. This is a compromise that attempts to offer greater security than SNMPv1, but without incurring the high complexity of SNMPv2. A variant of this was commercialized as SNMP v2*, and the mechanism was eventually adopted as one of two security frameworks in SNMP v3.

SNMPV1 "> the IETF
recognizes Simple Network Management Protocol version 3 as defined by RFC 3411–RFC 3418 (also known as STD0062) as the current standard version of SNMP. The IETF
has designated SNMPv3 a full Internet standard , the highest maturity level for an RFC. It considers earlier versions to be obsolete (designating them variously "Historic" or "Obsolete").

In practice, SNMP implementations often support multiple versions: typically SNMPv1, SNMPv2c, and SNMPv3.


SNMP implementations vary across platform vendors. In some cases, SNMP is an added feature, and is not taken seriously enough to be an element of the core design. Some major equipment vendors tend to over-extend their proprietary command line interface (CLI) centric configuration and control systems.

SNMP's seemingly simple tree structure and linear indexing may not always be understood well enough within the internal data structures that are elements of a platform's basic design. Consequently, processing SNMP queries on certain data sets may result in higher CPU utilization than necessary. One example of this would be large routing tables, such as BGP or IGP .

Some SNMP values (especially tabular values) require specific knowledge of table indexing schemes, and these index values are not necessarily consistent across platforms. This can cause correlation issues when fetching information from multiple devices that may not employ the same table indexing scheme (for example fetching disk utilization metrics, where a specific disk identifier is different across platforms.)


This section POSSIBLY CONTAINS ORIGINAL RESEARCH . Please improve it by verifying the claims made and adding inline citations . Statements consisting only of original research should be removed. (April 2010) (Learn how and when to remove this template message )

Modular devices may dynamically increase or decrease their SNMP indices (a.k.a. instances) whenever slotted hardware is added or removed. Although this is most common with hardware, virtual interfaces have the same effect. Index values are typically assigned at boot time and remain fixed until the next reboot. Hardware or virtual entities added while the device is 'live' may have their indices assigned at the end of the existing range and possibly reassigned at the next reboot. Network inventory and monitoring tools need to have the device update capability by properly reacting to the cold start trap from the device reboot in order to avoid corruption and mismatch of polled data.

Index assignments for a SNMP device instance may change from poll to poll mostly as a result of changes initiated by the system administrator. If information is needed for a particular interface, it is imperative to determine the SNMP index before retrieving the data needed. Generally, a description table like ifDescr will map a user friendly name like Serial 0/1 (Blade 0, port 1) to an SNMP index. However, this is not necessarily the case for a specific SNMP value, and can be arbitrary for an SNMP implementation.


This section NEEDS ADDITIONAL CITATIONS FOR VERIFICATION . Please help improve this article by adding citations to reliable sources . Unsourced material may be challenged and removed. (December 2015) (Learn how and when to remove this template message )

* SNMP versions 1 and 2c are subject to packet sniffing of the clear text community string from the network traffic, or guessing the community strings. * SNMP version 3 may be subject to brute force and dictionary attacks for guessing the authentication keys, or encryption keys, if these keys are generated from short (weak) passwords, or passwords that can be found in a dictionary. SNMPv3 allows both providing random uniformly distributed cryptographic keys, and generating cryptographic keys from password supplied by user, in which case caution is advised, and the risks are higher. The risk of guessing authentication strings is negligible, considering that for MD5- and SHA1-based authentication protocols the length of such a string is 96 bits, therefore the probability to successfully forge an authenticator is vanishingly small. Probability of finding two messages with the same authenticator is greater, but it still requires a pool of 248 valid messages to choose from, so it is not overly concerning, given the usage model (hard to accumulate that many messages for the same destination within the message lifetime of 5 minutes). With the acceptance of the HMAC-SHA-2 Authentication Protocol for USM, risks are even lower.

A challenge-response handshake was not used to improve security because:

* SNMPv3 (like other SNMP protocol versions) is a stateless protocol, and it has been designed with minimal amount of interactions between the agent and the manager. Thus introducing a challenge-response handshake for each command would impose a burden on the agent (and possibly on the network itself) that the protocol designers deemed excessive and unacceptable. The reader is referred here to the original SNMP book by Marshall Rose for the SNMP design criteria and rationale. * Just like in the approach chosen by the SNMPv3 USM authentication protocol, a challenge-response approach would require shared secrets. If those secrets are cryptographically strong – then both approaches are likely to withstand an attack. And if those secrets are derived from short, guessable, or brute-force-able strings (such as weak passwords), an adversary that monitors the exchange can mount an offline attack and break the security – determine the generating short secret. There is no difference in vulnerability between SNMPv3 USM authentication and a hypothetical challenge-response: when short secrets are used – both can be broken. There are some similarities between challenge-response approaches that use keyed cryptographic one-way functions, and USM authentication protocol. * Although SNMP works over TCP and other protocols, it is most commonly used over UDP that is connectionless – both for performance reasons, and to minimize the additional load on a potentially troubled network that protocols like TCP impose. The design of the Simple Network Management Protocol was optimized for repairing sick networks, rather than doing heavy things with perfectly healthy ones. Any protocol that does not use security – such as SNMPv1 and SNMPv2c – is vulnerable to IP spoofing attacks, whether it runs over TCP or UDP, and is a subject to bypassing device access lists that might have been implemented to restrict SNMP access. SNMPv3 security mechanisms such as USM or TSM prevent a successful attack. It would be pointless to employ SNMPv3 VACM (View-based Access Control) without securing messages with USM or TSM, for the reasons given above. * SNMP's powerful configuration (write) capabilities are not being fully utilized by many vendors, partly because of a lack of security in SNMP versions before SNMPv3, and partly because many devices simply are not capable of being configured via individual MIB object changes. Requirements of SNMP Set operation are not easy to implement correctly, and many vendors chose to omit support for Set – probably to lower their development cost and reduce the code size, among other reasons. * SNMP tops the list of the SANS Institute 's Common Default Configuration Issues with the issue of default SNMP community strings set to ‘public’ and ‘private’ and was number ten on the SANS Top 10 Most Critical Internet Security Threats for the year 2000.


This section POSSIBLY CONTAINS ORIGINAL RESEARCH . Please improve it by verifying the claims made and adding inline citations . Statements consisting only of original research should be removed. (April 2010) (Learn how and when to remove this template message )

SNMP by itself is simply a protocol for collecting and organizing information about managed devices (network and device monitoring), and modifying that information on these devices, causing change in their behavior (network management). Most toolsets implementing SNMP offer some form of discovery mechanism, a standardized collection of data common to most platforms and devices, to get a new user or implementor started. One of these features is often a form of automatic discovery, where new devices discovered in the network are polled automatically. For SNMPv1 and SNMPv2c, this presents a security risk, in that SNMP read communities will be broadcast in cleartext to the target device. SNMPv3 mitigates this risk, however it does not protect against traffic analysis and potential network topology discovery by an adversary. While security requirements and risk profiles vary from organization to organization, care should be taken when using a feature like automatic discovery, especially in mixed-tenant datacenters, server hosting and colocation facilities, and similar environments.


* RFC 1155 (STD 16) — Structure and Identification of Management Information for the TCP/IP-based Internets * RFC 1156 (Historic) — Management Information Base for Network Management of TCP/IP-based internets * RFC 1157 (Historic) — A Simple Network Management Protocol (SNMP) * RFC 1213 (STD 17) — Management Information Base for Network Management of TCP/IP-based internets: MIB-II * RFC 1452 (Informational) — Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework (Obsoleted by RFC 1908) * RFC 1901 (Experimental) — Introduction to Community-based SNMPv2 * RFC 1902 (Draft Standard) — Structure of Management Information for SNMPv2 (Obsoleted by RFC 2578) * RFC 1908 (Standards Track) — Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework * RFC 2570 (Informational) — Introduction to Version 3 of the Internet-standard Network Management Framework (Obsoleted by RFC 3410) * RFC 2578 (STD 58) — Structure of Management Information Version 2 (SMIv2) * RFC 3410 (Informational) — Introduction and Applicability Statements for Internet Standard Management Framework

* STD 62

* RFC 3411 — An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks * RFC 3412 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) * RFC 3413 — Simple Network Management Protocol (SNMP) Applications * RFC 3414 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) * RFC 3415 — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) * RFC 3416 — Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) * RFC 3417 — Transport Mappings for the Simple Network Management Protocol (SNMP) * RFC 3418 — Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)

* RFC 3430 (Experimental) — Simple Network Management Protocol (SNMP) over Transmission Control Protocol
Transmission Control Protocol
(TCP) Transport Mapping * RFC 3584 (BCP 74) — Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework * RFC 3826 (Proposed) — The Advanced Encryption
Standard (AES) Cipher Algorithm in the SNMP User-based Security Model * RFC 4789 (Proposed) — Simple Network Management Protocol (SNMP) over IEEE 802 Networks * RFC 5343 (STD 78) — Simple Network Management Protocol (SNMP) Context EngineID Discovery * RFC 5590 (STD 78) — Transport Subsystem for the Simple Network Management Protocol (SNMP) * RFC 5591 (STD 78) — Transport Security Model for the Simple Network Management Protocol (SNMP) * RFC 5592 (Proposed) — Secure Shell
Secure Shell
Transport Model for the Simple Network Management Protocol (SNMP) * RFC 5608 (Proposed) — Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models. * RFC 6353 (STD 78) — Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) * RFC 7630 (Standards Track) — HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3


* AgentX , a subagent protocol for SNMP * CMIP over TCP/IP (CMOT) * Common management information protocol (CMIP), a management protocol by ISO/OSI used by telecommunications devices * Common management information service (CMIS) * IEC 62379 * Management information base (MIB) * Net-SNMP , an open source reference implementation of SNMP * Netconf
, a protocol which is an XML-based configuration protocol for network equipment * Network monitoring comparison * Object identifier (OID) * Remote monitoring (RMON) * Simple Gateway Monitoring Protocol (SGMP), an obsolete protocol replaced by SNMP * SNMP simulator


* ^ A B C Douglas R. Mauro & Kevin J. Schmidt. (2001). Essential SNMP (1st ed.). Sebastopol, CA: O’Reilly & Associates. * ^ RFC 3411 — An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks * ^ RFC 6353 Section 10 * ^ J. Case; K. McCloghrie; M. Rose; S. Waldbusser (April 1993). "RFC 1448 – Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)". Internet Engineering Task Force. An InformRequest-PDU is generated and transmitted at the request an application in a SNMPv2 entity acting in a manager role, that wishes to notify another application (in a SNMPv2 entity also acting in a manager role) of information in the MIB View of a party local to the sending application. * ^ D. Levi; P. Meyer; B. Stewart (April 1999). "RFC 2573 – SNMP Applications". Internet Engineering Task Force. * ^ A B "SNMP Inform Requests". Cisco. Retrieved 2011-12-09. * ^ "Understanding the SNMP Implementation in JUNOS Software". Juniper Networks. Retrieved 2013-02-11. * ^ A B "Security in SNMPv3 versus SNMPv1 or v2c" (PDF). Archived from the original (PDF) on 2013-04-29. * ^ A B C "RFC Search Detail: Standards Track snmpv2 RFCs". The RFC Editor. Retrieved 2014-02-24. * ^ In This Issue: SNMP Version 3 The Simple Times ISSN 1060-6084 * ^ David Zeltserman (1999). A Practical Guide to SNMPv3 and Network Management. Upper Saddle River, NJ: Prentice Hall PTR. * ^ "SNMPv3". Cisco Systems. Archived from the original on 2011-07-19. * ^ "SNMP Version 3". Institute of Operating Systems and Computer Networks. Retrieved 2010-05-07. * ^ RFC Editor List of current Internet Standards (STDs) * ^ RFC 3584 "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework" * ^ "SNMP Research presentations in favor of standards-based management over proprietary CLIs". SNMP Research. Retrieved 2010-10-12. * ^ http://www.cisco.com/c/en/us/support/docs/ip/simple-network