|"Port(s)||161, 162 (Trap)|
|"Port(s)||10161, 10162 (Trap)|
|"Internet protocol suite|
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 behaviour. 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.
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, at all times, a software component called an agent which reports information via SNMP to the manager.
An SNMP-managed network consists of three key components:
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.
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:
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.["citation needed]
The first "Requests for Comments (RFC)s for SNMP, now known as SNMPv1, appeared in 1988:
These protocols were obsoleted by:
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.["citation needed]
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.["citation needed]
As presently specified, SNMPv2c 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 2576 defines two possible SNMPv1/v2c coexistence strategies: proxy agents and bilingual network-management systems.
An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as follows:
Setmessages to the SNMPv1 agent unchanged.
GetNextmessages 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 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.
||This section is in a list format that may be better presented using "prose. (September 2016)|
Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic security, it looks much different due to new textual conventions, concepts, and terminology.
SNMPv3 primarily added security and remote configuration enhancements to SNMP. Due to lack of security with the use of SNMP, network administrators were using other means, such as telnet for configuration, accounting, and fault management.
SNMPv3 addresses issues related to the large-scale deployment of SNMP, accounting, and fault management. Currently, SNMP is predominantly used for monitoring and performance management.
SNMPv3 defines a secure version of SNMP and also facilitates remote configuration of the SNMP entities.
SNMPv3 provides a secure environment for the management of systems covering the following:
SNMPv3 focuses on two main aspects, namely security and administration. The security aspect is addressed by offering both strong authentication and data encryption for privacy. The administration aspect is focused on two parts, namely notification originators and proxy forwarders.
SNMPv3 defines a number of security-related capabilities. The initial specifications defined the USM and VACM, which were later followed by a transport security model that provided support for SNMPv3 over SSH and SNMPv3 over TLS and DTLS.
Security has been the biggest weakness of SNMP since the beginning. Authentication in SNMP Versions 1 and 2 amounts to nothing more than a password (community string) sent in clear text between a manager and agent.
Each SNMPv3 message contains security parameters which are encoded as an octet string. The meaning of these security parameters depends on the security model being used.
SNMPv3 provides important security features:
As of 2004[update] 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.["not in citation given]
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.["citation needed]
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. (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. (December 2015) ("Learn how and when to remove this template message)|
A "challenge-response handshake was not used to improve security because:
||This section possibly contains "original research. (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.
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.
|Wikiversity has learning resources about Simple Network Management Protocol|