Simple Network Management Protocol: Difference between revisions

Simple Network Management Protocol (SNMP) is a UDP-based network protocol. It is used mostly in network management systems to monitor network-attached devices for conditions that warrant administrative attention. 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]

SNMP exposes management data in the form of variables on the managed systems, which describe the system configuration. These variables can then be queried (and sometimes set) by managing applications.

Overview and basic concepts

In typical SNMP use, one or more administrative computers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system (also called Slave) executes, at all times, a software component called an agent (see below) which reports information via SNMP to the managing systems (also called Masters).

Essentially, SNMP agents expose management data on the managed systems (Slaves) as variables (such as "free memory", "system name", "number of running processes", "default route"). But the protocol also permits active management tasks, such as modifying and applying a new configuration. The managing system (Master) can retrieve the information through the GET, GETNEXT and GETBULK protocol operations or the agent (which is on Slave) will send data without being asked using TRAP or INFORM protocol operations. SNMPv3 INFORM messages are valuable because they provide a reliable way for this data to be acknowledged by the management system, which is important because SNMP is a UDP-based protocol. Management systems can also send configuration updates or controlling requests through the SET protocol operation to actively manage a system. Configuration and control operations are used only when changes are needed to the network infrastructure. The monitoring operations are usually performed on a regular basis.

The variables accessible via SNMP are organized in hierarchies. These hierarchies, and other metadata (such as type and description of the variable), are described by Management Information Bases (MIBs).

The SNMP protocol operates in the Application Layer of the Internet Protocol Suite (Layer 7 of the OSI model). Typically, SNMP uses UDP ports 161 for the agent and 162 for the manager. The manager may send requests from any available source port to port 161 in the agent (destination port). The agent response will be sent back to the source port. The manager typically receives notifications (TRAPs and INFORMs) on port 162. The agent may generate notifications from any available port.

Basic components

An SNMP-managed network consists of three key components:

• Managed device = Slave device
• Agent = software which runs on Slave device
• Network management system (NMS) = software which runs on Master

A managed device is a network node that implements an SNMP interface that allows unidirectional (read-only) or bidirectional 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, bridges, hubs, IP telephones, 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 system (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.

The Internet management model

SNMP is part of the Internet network management architecture.

This article 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. (May 2009) (Learn how and when to remove this message)

This architecture is based on the interaction of many entities, as described in the following section.

As specified in Internet RFCs and other documents,^{[citation needed]} a network management system comprises:

• Network elements—Sometimes called managed devices, network elements are hardware devices such as computers, routers, and terminal servers that are connected to networks.
• Agents—Agents are software modules that reside in network elements. They collect and store management information such as the number of error packets received by a network element.
• Managed object—A managed object is a characteristic of something that can be managed. For example, a list of currently active TCP circuits in a particular host computer is a managed object. Managed objects differ from variables, which are particular object instances. Using our example, an object instance is a single active TCP circuit in a particular host computer. Managed objects can be scalar (defining a single object instance) or tabular (defining multiple, related instances).
• Management information base (MIB) -- A MIB is a collection of managed objects residing in a virtual information store. Collections of related managed objects are defined in specific MIB modules.
• Syntax notation—A syntax notation is a language used to describe a MIB's managed objects in a machine-independent format. Consistent use of a syntax notation allows different types of computers to share information. Internet management systems use a subset of the International Organization for Standardization's (ISO's) Open System Interconnection (OSI) Abstract Syntax Notation (ASN.1) to define both the packets exchanged by the management protocol and the objects that are to be managed.
• Structure of Management Information (SMI) -- The SMI defines the rules for describing management information. The SMI is defined using ASN.1.
• Network management stations (NMSs) -- Sometimes called consoles, these devices execute management applications that monitor and control network elements. Physically, NMSs are usually engineering workstation-caliber computers with fast CPUs, megapixel color displays, substantial memory, and abundant disk space. At least one NMS must be present in each managed environment.
• Parties—Newly defined in SNMPv2, a party is a logical SNMPv2 entity that can initiate or receive SNMPv2 communication. Each SNMPv2 party comprises a single, unique party identity, a logical network location, a single authentication protocol, and a single privacy protocol. SNMPv2 messages are communicated between two parties. An SNMPv2 entity can define multiple parties, each with different parameters. For example, different parties can use different authentication and/or privacy protocols.
• Management protocol—A management protocol is used to convey management information between agents and NMSs. SNMP is the Internet community's de facto standard management protocol.

Management Information Base (MIB)

SNMP itself does not define which information (which variables) a managed system should offer. Rather, SNMP uses an extensible design, where the available information is defined 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 ASN.1.

The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. The top-level MIB OIDs belong to different standards organizations, while lower-level object IDs are allocated by associated organizations. This model permits management across all layers of the OSI reference model, extending into applications such as databases, email, and the Java reference model, as MIBs can be defined for all such area-specific information and operations.

A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of specific characteristics of a managed device. Managed objects are made up of one or more object instances (identified by their OIDs), which are essentially variables.

Two types of managed objects exist:

• Scalar objects define a single object instance.
• Tabular objects define multiple related object instances that are grouped in MIB tables.

An example of a managed object is atInput, which is a scalar object that contains a single object instance, the integer value that indicates the total number of input AppleTalk packets on a router interface.

An object identifier (or object ID or OID) uniquely identifies a managed object in the MIB hierarchy.

Abstract Syntax Notation One (ASN.1)

In telecommunications and computer networking, Abstract Syntax Notation One (ASN.1) is a standard and flexible notation that describes data structures for representing, encoding, transmitting, and decoding data. It provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques and is a precise, formal notation that removes ambiguities.

ASN.1 is a joint ISO and ITU-T standard, originally defined in 1984 as part of CCITT X.409:1984. ASN.1 moved to its own standard, X.208, in 1988 due to wide applicability. The substantially revised 1995 version is covered by the X.680 series.

An adapted subset of ASN.1, Structure of Management Information (SMI), is specified in SNMP to define sets of related MIB objects; these sets are termed MIB modules.

Protocol details

SNMPv1 and SMI-specific data types

The SNMPv1 SMI specifies the use of a number of SMI-specific data types, which are divided into two categories:

• Simple data types
• Application-wide data types

Simple data types

Three simple data types are defined in the SNMPv1 SMI, all of which are unique values:

• The integer data type is a signed integer in the range of -2³¹ to 2³¹-1.
• Octet strings are ordered sequences of 0 to 65,535 octets.
• Object IDs come from the set of all object identifiers allocated according to the rules specified in ASN.1.

Application-wide data types

The following application-wide data types exist in the SNMPv1 SMI:

• Network addresses represent addresses from a particular protocol family. SMIv1 supports only 32-bit (IPv4) addresses (SMIv2 uses Octet Strings to represent addresses generically, and thus are usable in SMIv1 too. SMIv1 had an explicit IPv4 address datatype.)
• Counters are non-negative integers that increase until they reach a maximum value and then roll over to zero. SNMPv1 specifies a counter size of 32 bits.
• Gauges are non-negative integers that can increase or decrease between specified minimum and maximum values. Whenever the system property represented by the gauge is outside of that range, the value of the gauge itself will vary no further than the respective maximum or minimum, as specified in RFC 2578.
• Time ticks represent time since some event, measured in hundredths of a second.
• Opaques represent an arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the SMI.
• Integers represent signed integer-valued information. This data type redefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI.
• Unsigned integers represent unsigned integer-valued information, which is useful when values are always non-negative. This data type redefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI.

SNMPv1 MIB tables

The SNMPv1 SMI defines highly structured tables that are used to group the instances of a tabular object (that is, an object that contains multiple variables). Tables are composed of zero or more rows, which are indexed in a way that allows SNMP to retrieve or alter an entire row with a single Get, GetNext, or Set commands.

SNMPv2 and structure of management information

The SNMPv2 SMI is described in RFC 2578. It makes certain additions and enhancements to the SNMPv1 SMI-specific data types, such as including bit strings, network addresses, and counters. Bit strings are defined only in SNMPv2 and comprise zero or more named bits that specify a value. Network addresses represent an address from a particular protocol family. Counters are non-negative integers that increase until they reach a maximum value and then return to zero. In SNMPv1, a 32-bit counter size is specified. In SNMPv2, 32-bit and 64-bit counters are defined.

It specifies (in version 1) five core protocol data units (PDUs). Other PDUs were added in SNMPv2.

SNMPv2 SMI information modules

The SNMPv2 SMI also specifies information modules, which specify a group of related definitions. Three types of SMI information modules exist: MIB modules, compliance statements, and capability statements.

• MIB modules contain definitions of interrelated managed objects.
• Compliance statements provide a systematic way to describe a group of managed objects that must be implemented for conformance to a standard.
• Capability statements are used to indicate the precise level of support that an agent claims with respect to a MIB group. A NMS can adjust its behavior toward agents according to the capabilities statements associated with each agent.

SNMPv3

SNMPv3 is defined by RFC 3411–RFC 3418 (also known as 'STD0062'). SNMPv3 primarily added security and remote configuration enhancements to SNMP.^[2] SNMPv3 is the current standard version of SNMP as of 2004^[update]. The IETF has designated SNMPv3 a full Internet Standard,^[3] the highest maturity level for an RFC. It considers earlier versions to be obsolete (designating them "Historic").^[4] In December 1997 the "Simple Times" newsletter published several articles written by the SNMPv3 RFC editors explaining some of the ideas behind version 3 specifications.^[5]

SNMPv3 provides important security features:^[6]

• Message integrity to ensure that a packet has not been tampered with in transit.
• Authentication to verify that the message is from a valid source.
• Encryption of packets to prevent snooping by an unauthorized source.

Development and usage

Version 1

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), AppleTalk 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 RFCs 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 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 SNMP V1 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.

Version 2

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 GETBULK, an alternative to iterative GETNEXTs for retrieving large amounts of management data in a single request. However, the new party-based security system in SNMP v2, viewed by many as overly complex, was not widely accepted.

Community-Based Simple Network Management Protocol version 2, or SNMPv2c, is defined in RFC 1901–RFC 1908. In its initial stages, this was also informally known as SNMP v1.5. SNMP v2c comprises SNMP v2 without the controversial new SNMP v2 security model, using instead the simple community-based security scheme of SNMP v1. While officially only a "Draft Standard", this is widely considered the de facto SNMP v2 standard.

User-Based Simple Network Management Protocol version 2, or SNMP v2u, is defined in RFC 1909–RFC 1910. This is a compromise that attempts to offer greater security than SNMP v1, but without incurring the high complexity of SNMP v2. 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 & SNMPv2c interoperability

As presently specified, SNMPv2 is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2c messages use different header and protocol data unit (PDU) formats from SNMPv1 messages. SNMPv2c also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 1908 defines two possible SNMPv1/v2c coexistence strategies: proxy agents and bilingual network-management systems.

Proxy agents

A SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as follows:

• A SNMPv2 NMS issues a command intended for a SNMPv1 agent.
• The NMS sends the SNMP message to the SNMPv2 proxy agent.
• The proxy agent forwards Get, GetNext, and Set messages to the SNMPv1 agent unchanged.
• GetBulk messages are converted by the proxy agent to GetNext messages and then are forwarded to the SNMPv1 agent.

The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS.

Bilingual network-management system

Bilingual SNMPv2 network-management systems support both SNMPv1 and SNMPv2. To support this dual-management environment, a management application in the bilingual NMS must contact an agent. The NMS then examines information stored in a local database to determine whether the agent supports SNMPv1 or SNMPv2. Based on the information in the database, the NMS communicates with the agent using the appropriate version of SNMP.

Version 3

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 as of 2004^[update]. The IETF considers earlier versions as "Obsolete" or "Historical".

In practice, SNMP implementations often support multiple versions: typically SNMPv1, SNMPv2c, and SNMPv3. See RFC 3584 "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework".

SNMPv3 provides three important services: authentication, privacy and access control.

Autodiscovery

SNMP by itself is simply a protocol for collecting and organizing information. 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 your SNMP read communities will be broadcast in cleartext to the target device. While security requirements and risk profiles vary from organization to organization, care should be taken when using a feature like this, with special regard to common environments such as mixed-tenant datacenters, server hosting and colocation facilities, and similar environments.

Implementation issues

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.^[7]

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. As a result, 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.

Resource indexing

Modular devices may dynamically increase or decrease their SNMP indexes (aka 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 indexes 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 an SNMP device instance may change from poll to poll mostly as a result of changes initiated by the system admin. 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 a SNMP index.

Environmental monitoring

Server, rack and appliance operating temperatures and room humidity could be monitored remotely for SNMP-enabled HVAC devices.[1][2]

Security implications

• SNMP versions 1 and 2c are subject to packet sniffing of the clear text community string from the network traffic, because they do not implement encryption.
• All versions of SNMP are subject to brute force and dictionary attacks for guessing the community strings/authentication strings/authentication keys/encryption strings/encryption keys, because they do not implement a challenge-response handshake. Entropy is an important consideration when selecting keys, passwords and/or algorithms.
• Although SNMP works over TCP and other protocols, it is most commonly used over UDP that is connectionless and vulnerable to IP spoofing attacks. Thus, all versions are subject to bypassing device access lists that might have been implemented to restrict SNMP access, though SNMPv3's other security mechanisms should prevent a successful attack.
• SNMP's powerful configuration (write) capabilities are not being fully utilized by many vendors, partly due to lack of security in SNMP versions before SNMPv3 and partly due to the fact that many devices simply are not capable of being configured via individual mib object changes.
• 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. SNMPv2 is more secure than SNMPv1.

For more detail on SNMP security implications see the CERT SNMP Vulnerabilities FAQ

RFC references

• RFC 1155 (Standard 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 (Standard 17) — Management Information Base for Network Management of TCP/IP-based internets: MIB-II
• RFC 3410 (Informational) — Introduction and Applicability Statements for Internet Standard Management Framework
• RFC 3411 (Standard 62) — An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
• RFC 3412 (Standard 62) — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
• RFC 3413 (Standard 62) — Simple Network Management Protocol (SNMP) Application
• RFC 3414 (Standard 62) — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
• RFC 3415 (Standard 62) — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
• RFC 3416 (Standard 62) — Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
• RFC 3417 (Standard 62) — Transport Mappings for the Simple Network Management Protocol (SNMP)
• RFC 3418 (Standard 62) — Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
• RFC 3584 (Best Current Practice) — 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 5343 (Proposed) — Simple Network Management Protocol (SNMP) Context EngineID Discovery
• RFC 5590 (Proposed) — Transport Subsystem for the Simple Network Management Protocol (SNMP)
• RFC 5591 (Proposed) — Transport Security Model for the Simple Network Management Protocol (SNMP)
• RFC 5592 (Proposed) — 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.

See also

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

References

External links

• Good SNMP Programming starting point and reference
• Description of the SNMP packet breakdown
• SNMP FAQ part 1
• SNMP FAQ part 2
• SNMP products and technical articles
• Cisco's description of SNMP and how to use in their products
• Articles by SNMP Research
• SNMP: Simple? Network Management Protocol
• Emnico SNMP MIB Library: A comprehensive collection of SNMP MIBs
• SNMP v1, v2, and v3 Message Protocol Handy Reference (pdf)
• Industrial SNMP OPC Server
• Boundary protection guard enabling SNMP between security domains

Implementations

• Net-SNMP (Net-SNMP: Open source SNMP implementation)
• Netsnmpj: Open source SNMP for Java
• SnmpB: Open source MIB Browser
• OpenSNMP: multi-threaded SNMPv3 engine
• PySNMP: pure-Python module, BSD license
• Ruby SNMP: Open source SNMPv1 and v2 for Ruby
• iReasoning MIB Browser / SNMP Manager (Free)
• Net::SNMP : a pure Perl module that implements SNMPv1, v2 and v3 on IPv4 and IPv6
• SNMP4J - Free SNMP API for Java Managers and Agents
• Nstrument Snmp Library for .Net
• Snmp++/Agent++ Libraries
• SNMP Manager LoriotPro free edition
• BSNMP - mini SNMP daemon