Simple Network Management Protocol (SNMP) is a protocol used for network management, i.e. to monitor and configure devices on IP networks. I have been working on many network management products over the years, and most of them were related with SNMP one way or another, so I tend to take SNMP knowledge for granted. So, for those of you that need an introduction (or a dive-in) or just looking for a quick-reference on the SNMP principles, I wrote the below, hoping it will be useful.
So, what is SNMP? Technically speaking, SNMP:
is an application–layer protocol defined by the Internet Architecture Board of the Internet Engineering Task Force (IETF).
is a term used to refer to all parts required for exchanging management information between network devices. These parts include an application layer protocol, a database schema, and a set of data objects.
is part of the Transmission Control Protocol ⁄ Internet Protocol (TCP⁄IP) protocol suite.
With this protocol, one can monitor and configure networks and devices.
It is used on Internet Protocol (IP) networks, to monitor devices such as servers, printers, hubs, switches, routers etc.
It is used also in non-IP telecom networks, such as PDH, SDH, etc. again to monitor and configure devices such as Multiplexers, Radio Relays etc.
It exposes management data in the form of variables on the managed systems, which describe the system configuration, status and performance. These variables can then be queried (and sometimes set) by managing applications, enabling applications to:
Monitor network performance,
Audit network usage,
Detect network faults,
Detect inappropriate access,
Configure remote devices.
This protocol is one of the widely accepted and used management protocols. Devices that typically support it include routers, switches, servers, workstations, printers, modem racks, and much-much more.
Most of the professional–grade or carrier-grade devices come with bundled SNMP capabilities. The capability has to be enabled and configured to allow remote monitoring and configuration. Almost all Network Operators implement some sort of SNMP management solution to monitor and in some cases configure the devices in their network.
Most of the home devices are also SNMP-capable, although only monitoring is usually possible via this protocol. Such home devices include modems, PCs, laptops etc. But, although this protocol is so popular, there are very few homes that monitor their devices due to lack of an wide-spread out-of-the-box solution for SNMP monitoring running on home PCs or even better Mobile Phones.
SNMP target is to be deployed on the largest possible number of network devices, to enable end-to-end monitoring of networks. Therefore, it was designed with the following principles:
Have minimal impact on the managed nodes, e.g. consume minimum CPU and RAM, etc.
Have minimal transport requirements, e.g. consume minimum bandwidth to transfer information from the devices to the Network Manager.
Be easy to implement, e.g. contain simple commands and structures that will be easily developed by equipment manufacturers
Be resilient , i.e. continue working when most other network applications fail.
Since it was introduced back in 1988, new features have been introduced with new versions being standardized and released.
SNMPv2c is the most popular version of the protocol, defined in RFC 1901, RFC 1905, RFC 1906, RFC 2578. v2c introduced new features in the areas of protocol packet types, transport mappings, MIB structure elements.
SNMPv3 is the latest and secure version of the protocol defined by RFC 1905, RFC 1906, RFC 3411, RFC 3412, RFC 3414, RFC 3415.
The most implemented versions are v1 and v2c. The latest version, v3, has not been widely adopted due to the impact on the managed nodes resources, i.e. it consumes more CPU and Memory. Nevertheless, due to its increased security features, it has seen some catching up lately with newer devices.
As of 2004 the IETF has designated the v3 as the current standard version and considers it as a full Internet standard, which the highest maturity level for an RFC. IETF considers earlier versions to be obsolete or “Historic”.
In practice, most devices support v2c while it is very common to have devices and management systems supporting multiple versions: typically v1, v2c, and v3.
This flexibility has been made possible by the wide-spread usage of open-source libraries which are mature enough to support all these versions.
The first release (v1) has been criticized for its poor security as it was basically password-based with the password transmitted in clear-text. This password was named “community string”. This is possibly due to the fact that v1 was designed in 1988, when security was considered as not really needed or exotic in networks.
The first attempts to improve the security mechanism included in v1 were not a success. These attempts were included in SNMPv2u and SNMPv2, that due to complexity or because they were considered as interim solutions were never adopted by the industry. Instead, the de-facto SNMPv2 is now v2c that uses the same security mechanism as v1.
Security comes at a cost, and in the SNMP case the cost was increased complexity and resource usage (CPU, Memory). This is why SNMP v3 has not seen yet the wide-spread implementation anticipated.
The real improvement in security came with SNMPv3 that added cryptographic security. Each v3 message contains security parameters which are encoded as an octet string, thus supporting:
Confidentiality – Encryption of packets to prevent snooping by an unauthorized source.
Integrity – Message integrity to ensure that a packet has not been tampered with in transit including an optional packet replay protection mechanism.
Authentication – Mechanism to verify that the message is from a valid source.
The following list contains the most frequently used terms with SNMP not only from a Standards point of view but also from the Operators and Equipment Manufacturers viewpoint:
Network Element: a device in the network that can be managed.
SNMP Agent: a software running within a Network Element, to enable management.
Element Manager: a computer or server used to manage devices
Network Manager: a computer or server used to manage devices end-to-end
SNMP Manager: a software running within a Element Manager or Network Manager entity, that monitors and configures devices. This is usually a branded software.
Management Information Base (MIB) : a collection of information for managing Network Elements, structured hierarchically, i.e. in trees.
Object Identifier (OID) The MIB comprises of variables that store values related with statistics or control of the Network Element it resides. These variables are identified by the unique OIDs
SNMP Commands: a simple set of commands that enable communications between SNMP Manager and SNMP Agent. Commands include: GET, GET NEXT, GET BULK, SET, TRAPS, INFORM etc.
If you feel confused with the above terms and especially if you are trying to understand the difference between a Network Manager and an SNMP Manager, don’t worry. Although confusing at first, as you continue reading everything will come in place.
In the following paragraphs, the above terms are explained in detail with diagrams.
How SNMP works
Although it is difficult to get an overview of how protocol works by just reading the standards, things are really simple.
On a typical usage scenario, one or more computers, called Network Managers or sometimes Element Managers, have the task of monitoring or managing a group of devices, called Network Elements.
Simple Architecture Diagram: SNMP Manager and SNMP Agent
The Network Element
We call Network Element any type of device capable of communicating over the network.
Network Elements include, but are not limited to, routers, access servers, switches, bridges, hubs, IP telephones, IP video cameras, Microwave Links, DSLAMs, computer hosts, and printers.
To support SNMP, each Network Element must contain a software component called SNMP-Agent, which runs all the time and communicates via SNMP with the Network Manager.
SNMP Agents contained in Network Elements, perform two main tasks:
They expose data concerning the configuration, status and performance of the Network Element they reside, as variables.
They send notifications concerning status change and faults of the Network Element they reside.
The SNMP-Agent has local access and therefore knowledge of the Network Elements internal configuration, status and performance. This information is translated to SNMP specific form from the usually proprietary structure of the Network Element software.
The SNMP interface of the Agent allows unidirectional (read-only) or bidirectional (read-write) access to Network Element-specific information. This information is exchanged with the Network Manager.
The SNMP Agent uses an information database called Management Information Base (MIB) to store and retrieve information related with the status, performance and configuration of the Network Element it resides.
The Network Manager
We call Network Manager a computer or server capable of managing Network Elements (i.e. devices) over an IP network.
Network Managers include, but are not limited to, PCs running standalone software open-source software, Servers running specialized software that provide User Interface over a Web Browser or dedicated Windows/Java applications.
The SNMP Manager is usually branded open-source or commercial software, like Solarwind, SNMPc, openNMS, PRTG etc.
To support SNMP, the Network Manager must contain software called SNMP Manager, which runs all the time and communicates via SNMP with the Network Elements. SNMP Managers perform three main tasks:
They request & receive data concerning the configuration, status and performance of the Network Element they manage.
They sometimes edit the configuration of the Network Element they manage.
They receive notifications concerning status change and faults of the Network Element they manage.
The SNMP protocol permits active management tasks to be performed from the SNMP Manager, i.e. to modify and apply a new configuration to an SNMP Agent. This can be done by editing the exposed data (variables) of the SNMP Agent.
These configuration variables but also the status, performance ones are organized in hierarchies. These hierarchies, and other metadata (such as type and description of the variable), are described by SNMP MIBs, the so-called Management Information Bases. SNMP Managers need to be aware of the SNMP MIBs supported by the SNMP Agents in order to be able to communicate.
A closer look at SNMP
If you feel like you want to dig deeper to see how it works and how the functions described in the overview are implemented, I recommend you continue reading!
What is an SNMP Manager?
The SNMP manager is a separate entity that is responsible to communicate with the SNMP agent implemented within network devices. A manager is software dedicated for network management typically running in a computer (PC or Server). Key functions include:
Queries SNMP agents, i.e. requests information
Gets responses from SNMP agents, i.e. collects information.
Sets variables in SNMP agents, i.e. configures devices
Acknowledges asynchronous events from SNMP agents, i.e. collects alarms and notifications
What is an SNMP Agent?
The SNMP agent is a software program that is packaged within the network element. Activating the agent allows it to start collecting the management information database from the device locally and makes it available to the SNMP manager, when it is queried for.
The agents can be based on open-source libraries like the netSNMP Agent or they can be proprietary implementations. This is done typically by some equipment vendors. Key functions:
Collects management information about its local environment and stores it in the MIB.
When a request comes from the SNMP Manager, it retrieves management information from the MIB to send back as a response.
When requested from the SNMP Manager, it updates management information in the MIB concerning the configuration of the device it resides.
Signals an event or fault to the SNMP manager via traps.
Acts as a proxy for some non–SNMP manageable network nodes.
What is the Management Information Base (MIB)?
Every SNMP agent maintains an information database describing the managed device parameters and holding their latest or sometimes historical values.
The SNMP manager must know the structure of this database, to be able to request from the agent specific information. This commonly shared database between the Agent and the Manager is called Management Information Base (MIB).
The MIB is maintained, i.e. filled with data, in the Network Element. There is no copy of it in the SNMP Manager. The SNMP Manager uses the MIB structure to request specific information but when the SNMP Manager receives responses from the SNMP Agent, it translates the information received in a structure better suited to be stored in databases running on computers, i.e. SQL databases such as Oracle, mySQL, Postgres etc.
We have two types of MIBs:
Standard or public MIBs
The standard MIBs allow Equipment Manufacturers to make sure that their equipment can be managed from day one by Commercial Of-The-Shelf (COTS) Network Managers. This is possible because the popular Network Managers support almost all standard MIBs.
What happens if the standard MIBs do not include variables for a statistical or control values used specifically by a device? The standard is flexible enough to allow the Equipment Manufacturers to create their own private MIBs that the SNMP Agents and Managers can use.
Summarizing, MIB files are the set of questions that a SNMP Manager can ask the SNMP Agent. The SNMP Agent collects these data locally and stores it, as defined in the MIB. So, the SNMP Manager should be aware of these standard and private questions for every type of agent.
Is the MIB part of SNMP?
Although we sometimes use the term SNMP to refer to both the protocol and the information database, if we want to be accurate, the protocol itself does not define which information (which variables) a Network Element should offer.
The protocol uses an extensible design, where the available information is defined by management information bases (MIBs).
MIB structure and Object Identifiers (OIDs)
So, how are the MIBs internally structured and what is the use of OIDs?
MIBs use a standard notation for OIDs, defined by ASN.1.
The MIB is a collection of information for managing Network Elements. The MIB comprises of variables that store values related with statistics or control of the Network Element it resides. We call these variables Managed Objects and we identify them by an Object Identifier or shorter Object ID (or OID).
MIBs actually use a hierarchical namespace containing object identifiers (OID). Each OID identifies a variable that can be read or set via SNMP. As every Object ID is organized hierarchically in the MIB, we can represent the MIB hierarchy in a tree structure with individual variable identifiers.
SNMP MIBs are structured as hierarchies.
A typical object ID will be a dotted list of integers. For example, the OID in RFC1213 for “sysDescr” is .184.108.40.206.220.127.116.11
What are the OID types?
Each OID is unique and denotes specific characteristics of a managed device. When queried for, the return value of each identifier could be different e.g. Text, Number, Counter, etc.
We can have two OID types in a MIB, scalar and tabular.
A Scalar Object defines a single object instance, meaning that the result can be only one, e.g. the device’s vendor name.
The Tabular Object on the other hand is a table that groups together related OIDs, and therefore it may have multiple results for a particular Object. An example is CPU utilization of a Quad Processor. In this case we will have four values, structured in a table or matrix.
What are the SNMP ports?
Being the part of IP protocol suite, the SNMP messages are wrapped as User Datagram Protocol (UDP) and intern wrapped and transmitted in the Internet Protocol. The default SNMP ports are:
UDP port 161.
UDP port 162 (for traps).
This is how the SNMP Manager uses the default ports during communication:
Sends requestsfromany available source port (GET, GETNEXT, GETBULK, SET)
Sends requeststoUDP port 161 in the Agent (GET, GETNEXT, GETBULK, SET).
Receives responses on the same source port he send the request (RESPONSE).
Receives notifications on UDP port 162 (TRAPS and INFORM).
This is how the SNMP Agent uses the default ports during communication:
Receives requests on UDP port 161 (GET, GETNEXT, GETBULK, SET).
Sends responses back to the source port of the manager (RESPONSE).
Generates notifications from any available port (TRAPS and INFORM).
Sends the notifications to UDP port 162 of the Manager (TRAPS and INFORM).
Note that when used with Transport Layer Security or Datagram Transport Layer Security requests are received on port 10161 and traps are sent to port 10162.
Non-default ports: for SNMP Agents that support non-default ports, alternative solutions must be implemented, such as SNMP proxies that listen at non-default ports and forward the communication to the default ports given above.
What are the Basic Commands of SNMP?
The success and popularity of this protocol must be attributed at least partly to the simplicity in information exchange. The basic set of commands is simple and concise, as you can see below.
Commands that a SNMP-Manager can send:
GET: The GET operation is a request sent by the Manager to the Agent. It is performed to retrieve one or more values from the Network Element.
GET NEXT: This operation is similar to the GET. The significant difference is that the GET NEXT operation retrieves the value of the next OID in the MIB tree.
GET BULK: The GETBULK operation is used to retrieve voluminous data from large MIB tables.
SET: This operation is used by the Managers to modify or assign the value of a variable in the MIB of the Network Element. The SET operation is sent from the Manager to Agent.
Commands that a SNMP Agent can send:
TRAPS: Unlike the above commands which are initiated from the SNMP Manager, TRAPS are initiated by the Agents. It is a signal to the Manager by the Agent on the occurrence of an event.
INFORM: This command is similar to the TRAP initiated by the SNMP Agent. The difference is that INFORM includes confirmation from the Manager on receiving the message.
RESPONSE: It is the command used to carry back the value(s) or signal of actions directed by the SNMP Manager.