SNMP has several versions that an agent can communicate over. SNMPv1 was the first version of the protocol. It featured get, set, and trap operations. The standard defined scalar data objects as well as tabular objects. It also featured the getnext operation that can be used to iterate over tables of data objects.

The security model related with SNMPv1 is relatively unsophisticated. A get, set, or getnext request is authenticated based on the IP address of the manager and the community string that it uses. All SNMP devices communicating over SNMPv1 use a community string for verifying the request—whether none, only get, or both get and set operations can be performed. By default, the private community string allows both reading and writing of information, and the public community string allows reading only.

SNMP version 2 introduced improvements in terms of performance and security. Instead of using get and getnext, it had a getbulk operation. This allows the retrieval of all entries in a table in a single operation. It also introduces an inform packet— this is a trap that must be acknowledged by the manager. This avoids a problem where a trap is not received by a manager because a single UDP packet failed to reach its destination. This version also introduced the party-based security model, which did not gain wide acceptance as it was very complex.

The most common version 2 implementation is SNMPv2c—Community-Based Simple Network Management protocol 2. It uses features of version 2 without implementing the new security model, instead using the community string mechanism that was introduced in SNMPv1.

The User-Based Network Management Protocol version 2, or SNMPv2u, is another variant of SNMP version 2. It includes changes in security, but also does not include all of the security features originally developed for SNMPv2. SNMP version 3 features an improved security model with authentication, privacy, and access control. This version introduced much better security than that available in SNMPv2, and one of its security frameworks uses the functionality from SNMPv2u. This standard is now gaining more attention than SNMPv2; mostly because it offers better security without the high level of complexity that SNMPv2 introduced.

Most SNMP server implementations that come with operating systems support SNMPv1, SNMPv2c, and SNMPv3. Some devices support only SNMPv1 and others also offer SNMPv2. Packets from different SNMP versions are incompatible, so a device only using SNMPv1 will not recognize SNMPv2c packet. However, an application that knows both SNMPv1 and SNMPv2 will understand an SNMPv1 packet.

In many cases, devices that are used across your network will offer a different subset of versions that they support. There are two strategies that can be used to work in such an environment:

Often SNMP managers allow configuring which version of the protocol should be used for specific devices.

SNMP uses Object Identifiers (OIDs) to identify data objects that it refers to. They define an object uniquely for a specified SNMP agent. They are identified by using a hierarchical definition, in a fashion similar to how Internet domains work.

Object identifiers are a series of numbers separated by a period. Each number represents a part of the tree. Often, the first number in the series is also preceded by a period to indicate that this is an OID; this is not necessary, though. An example OID can be .1.3.6.1.2.1.1.5.0, which maps to the system name of a machine.

As it is very hard to memorize, read, and compare OIDs written as series of numbers, there is also a standard of naming and describing the object tree.

The standard is called Management Information Base (MIB) and it defines how various parameters are defined—both how they are named and what types of values these objects might return. Each MIB definition is a text file written in a subset of ASN.1 (Abstract Syntax Notation One) notation. A file can describe a small or large subset of the MIB trees.

As of now, the latest standard is MIB SMIv2 and it defines all commonly used attributes along with additional information that can be used for visualization applications.

MIB files describe fields that are used in SNMP. They define parent nodes in a hierarchy, numeric identifier, and the type of data that this field is associated with. SNMP uses the following basic data types:

In many cases, a field is returned as an enumeration type integer—this means that some predefined numbers represent several predefined values. A good example might be the ifType field when defining network interfaces, as it specifies type of a network interface. Some examples can be 23 for PPP4 connection or 6 for Ethernet interfaces.

An example OID is .1.3.6.1.2.1.1.5.0. The following table describes each element, both as a string and as the corresponding numbers:

The string representation of this OID is iso.org.dod.internet.mgmt.mib-2.system.sysName.0. Often, it is also referred to as SNMPv2-MIB::sysName.0.

The .1.3.6.1.2.1 part of the OID defines root elements for all MIB-2 standardized parameters. This means that all standard SNMP parameters that various devices use are under this OID node or its descendants. This node is also called SNMPv2-MIB namespace, therefore, the SNMPv2-MIB::sysName.0 OID also maps to the same object.

The MIB tree has a few major nodes that are the base for many other sub-trees that might be significant to you under various circumstances:

The most important node is .1.3.6.1.2.1, which is used by all SNMP-aware devices to report information. This part of the MIB tree is the root node for majority of standard objects. It is also mandatory for all SNMP-enabled devices to provide at least basic part of information in this sub-tree. For example, information such as contact information, location, system name, and type should be provided by all SNMP-aware devices.

SNMP can be used to retrieve different kinds of information. They are usually grouped into various categories. All categories also have corresponding aliases that they are usually referenced with, in order to avoid putting entire structure along every OID definition or MIB name. All applications that offer communication over SNMP allow specifying attributes using both OID and MIB names. Let's go over a few of the most important sections of the MIB tree.

Information in IF-MIB, IP-MIB, IPv6-MIB, RFC1213-MIB, IP-FORWARD-MIB, TCP-MIB, and UDP-MIB describes network connectivity: interfaces, IP configuration, routing, forwarding, and TCP and UDP protocols. They support querying of the current configuration as well as the currently active and listening sockets.

Data contained in SNMPv2-MIB and HOST-RESOURCES-MIB describes system information and current parameters. It can contain information on disk storage, current processes, installed applications, and the hardware that the computer is running on.

Various operating systems come with different SNMP applications. Many hardware vendors also offer additional software that manages multiple machines using SNMP; for example, HP OpenView or Sun Management Center. For this and the following sections, the Net-SNMP package, available from http://net-snmp.sourceforge.net/ will be used.

Binaries for Microsoft Windows can be downloaded from the project's file repository at: http://sourceforge.net/projects/net-snmp/files/net-snmp%20binaries/

Installers for 32-bit and 64-bit processors can be downloaded and Net-SNMP is installed in C:Usr by default, having binaries such as snmpget.exe in C:Usrin.

This package is included in all Linux distributions and works with almost all Unix operating systems.

In order to install this package on Ubuntu Linux, we need to run the following command:

apt-get install snmp

For yum-based Linux distributions, the package is called net-snmp and the command to install it is:

yum install net-snmp

Despite being named differently, both are actually packages for SNMP handling based on the Net-SNMP package.

The Net-SNMP project homepage also offers binaries for several platforms, including HP-UX and Fedora Linux. Fedora packages should also work on Red Hat Enterprise Linux systems.

It is also possible to build everything from source for Unix operating systems such as AIX, HP-UX, and Solaris. Exact instructions are provided on the project page.

After a successful installation, we should be able to run any SNMP-related command like snmpget and check the Net-SNMP version by doing the following:

root@ubuntu:~# snmpget -V
NET-SNMP version: 5.3.1

Assuming we have a host with an SNMP agent set up and it accepts SNMP protocol version 1, we can now try to communicate with it and query a few parameters:

root@ubuntu:~# snmpget -v 1 -c public 192.168.2.2  iso.org.dod.internet.mgmt.mib-2.system.sysName.0
SNMPv2-MIB::sysName.0 = STRING: WAG354G

As you can see, the device returned that the system name is WAG354G. This is actually a Linksys/Cisco router and the only way to access its information is over the web interface or SNMP.

The Net-SNMP package comes with a couple of useful commands that can be used to check current values as well as perform a dump of part of whole MIB tree. These vary from simple tools used to query a single attribute to very complex ones that print out a df-like report of partitions on a remote system. There are also commands for displaying tables and for setting parameters remotely.

Throughout this section and the next one, we'll mainly use SNMP version 1, because it is supported by almost all SNMP-enabled devices. When using SNMP in production, it's better to check which devices accept SNMP versions and use the latest one that a device handles correctly.

The first command that is worth getting familiar with is snmpget. This allows you to query a single attribute or multiple attributes, over SNMP.

The syntax of the command is as follows:

snmpget [options] IP-address OID [OID] ...

All Net-SNMP commands accept a huge amount of parameters. The following are the ones we will be using throughout this chapter, or those worth knowing:

The -O option allows us to retrieve values without MIB shortcuts being applied. Therefore, we can see the entire branch. It also allows us to change the output so that only values along with data types are printed out, instead of the object names themselves.

# snmpget O ef -v 1 -c public rtr SNMPv2-MIB::sysObjectID.0 .iso.org.dod.internet.mgmt.mib-2.system.sysObjectID.0 = OID: .iso.org.dod.internet.private.enterprises.ucdavis.ucdSnmpAgent.linux

All of these options can also be used with other Net-SNMP commands.

Net-SNMP also offers a command to iterate through entire or part of MIB tree. The snmpwalk command accepts the same options as shown earlier. Most versions of Net-SNMP's snmpwalk command do not need to be passed any OID to work. For older versions in order to list the entire tree .1 can be specified as OID.

The following command will list entire MIB tree of a SNMPv1 agent:

root@ubuntu:~# snmpwalk -v 1 -c public 192.168.2.2

Depending on the underlying operating system and the SNMP agent itself, the actual data will be different. Please note that if the device is not on a local network, then this operation might take a long time to complete.

In order to retrieve only a part of the MIB tree, simply pass the prefix of the tree you are interested in. For example:

root@ubuntu:~# snmpwalk -v 1 -c public 192.168.2.2 1.3.6.1.2.1.1

The previous command will limit the query to iso.org.dod.internet.mgmt.mib-2.system node along with all its children. It will also be completed much faster than querying the entire tree.

Walking over a part of a tree is mainly useful when trying to check which objects are available on a remote device that does not respond quickly to SNMP requests—either because of network lag or the computations required for some objects. It is also commonly used to find out what values are available in a specific part of the MIB tree.

Another useful utility is the snmptable command. This allows you to list various SNMP tables and shows them in a human readable form. The syntax is as follows:

snmptable [options] IP-address OIDprefix

For example, to list all TCP/IP connections, the following command can be used:

root@:~# snmptable -v 1 -c public 192.168.2.2 tcpConnTable SNMP table: TCP-MIB::tcpConnTable
connState connLocalAddress connLPort connRemAddress connRPort
listen 0.0.0.0 23 0.0.0.0 0
listen 0.0.0.0 80 0.0.0.0 0
listen 0.0.0.0 199 0.0.0.0 0

Net-SNMP also allows you to set new object values which can be used to reconfigure various devices. The snmpset command can be used to perform this. The syntax is as follows:

snmpset [options] IP-address OID type value [OID type value] ...

The command accepts all the standard options, just like the snmpget command. A single command invocation can be used to set more than one parameter by specifying more than one set of OIDs to set. Each set operation needs to specify the new value along with the data type it should be set to.

The value type can be one of the following:

Most common types are String, Integer, and OID. The first two require you to pass the number of a text that the object's value should be set to. Setting the OID type of the object requires that you either provide the full OID identifier or a string that can be matched by the MIB definitions.

An example of the code which can be used to set a system's contact name and hostname is as follows:

root@ubuntu:~# snmpset -v 2c -c private 192.168.2.2  SNMPv2-MIB::sysContact.0 s [email protected]  SNMPv2-MIB::sysName.0 s RTR
SNMPv2-MIB::sysContact.0 = STRING: [email protected]
SNMPv2-MIB::sysName.0 = STRING: RTR

Some attributes cannot be set via SNMP. It is not possible to modify objects that are used for monitoring the system. These usually include IP address configuration, counters, or diagnostic information—for example TCP/UDP connection tables, process lists, installed applications, and performance counters. Many devices tend to support command-line administration over SNMP and, in this case, the parameters might be read-only.

MIB definitions specify which attributes are explicitly read-only. Using a graphical tool to find out which attributes can be modified will ease the experience of automatic device configuration over the SNMP protocol.

The previous section talked about how to communicate with SNMP agents. If you have a network device such as a router or WiFi, WiMax, or DSL gateway, it will most likely already come with a built-in SNMP agent.

The next step is to set up SNMP agent on one or more computers so that we can use SNMP to monitor servers or workstations. This way, the majority of the networked equipment will allow querying data and/or monitoring from a single machine using SNMP protocol.

Let's start with various Unix boxes. The SNMP agent is a part of Net-SNMP and several distributions come with the command-line tools, libraries, and an SNMP agent—usually as optional packages.

In our case, we will install the SNMP agent on Ubuntu Linux. To do this we will run the following command:

apt-get install snmpd

This will cause the SNMP daemon from Net-SNMP to be installed. By default, the Ubuntu Linux SNMP agent which comes from the Net-SNMP package accepts connections on 127.0.0.1 only, which is the IP address that always reflects the same machine we are on. This is due to security reasons, in many cases, an SNMP agent is mainly used by tools like MRTG to gather usage statistics.

To change this we will need to either enter the IP address the SNMP agent should listen on or remove it completely from the /etc/default/snmpd file, using the SNMPDOPTS variable.

If the SNMP agent should listen on all available IP addresses, then the line should look similar to the following example:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid'

Changing this option requires restarting the SNMP agent by invoking the following command:

/etc/init.d/snmpd restart

After a successful installation, the SNMP agent should be up and running and doing a walk over the entire tree should produce some output.

To test the SNMP agent simply launch the following command on the same machine, assuming Net-SNMP command line tools are installed:

snmpwalk -v 1 -c public 127.0.0.1

The agent that we have just installed supports SNMPv1, SNMPv2c, and SNMPv3 protocol versions. It also features an extensive security model that you can configure in order to provide a more secure setup.

Net-SNMP agent allows you to define one or more OIDs along with all subnodes that can be retrieved by specific security groups. These groups can be mapped to specific communities that originate from all IPs, or specific IP addresses. Security groups are also mapped using SNMP versions used by the remote machine.

A sample configuration that only allows read-only access from all hosts is:

com2sec readonly default public
group readonlyGroup v1 readonly
group readonlyGroup v2c readonly
group readonlyGroup usm readonly
view all included .1 80
access readonlyGroup "" any noauth exact all none none
syslocation Home
syscontact Administrator <[email protected]>

The first line defines a mapping between community and readonly security group. The lines that follow assign readonlyGroup access rights to it. Then it is assigned access to read all objects from .1 OID node and its children. The last two lines indicate system administrator and location where the machines are stored.

For SNMPv3, it is also possible to specify one or more users by calling the snmpusm command. It allows real-time configuration of the user list for local or remote SNMPv3 agents.

SNMP can also be set up on all modern Microsoft Windows operating systems. As with Unix systems, the SNMP agent must be installed. In order to do this on Windows XP and 2003 Server, we need to go to the Control Panel first. Then we need to select the Add or Remove Programs applet and select Add/Remove Windows Components option. The following window will appear:

Next, we need to select Management and Monitoring Tools as shown in the preceding screenshot. We can also click the Details button and choose only the Simple Network Management Protocol. The WMI SNMP Provider makes it possible to retrieve SNMP parameters over WMI and can be left unchecked if you do not need it.

The Windows SNMP agent exports information about the system similar to other platforms. You can use it to query the underlying hardware, operating system version, and network configuration along with currently active connections. It is also possible to list active processes and monitor system load. The Windows SNMP agent also exports all installed applications along with security patches from Microsoft. This mechanism can be used to monitor whether all critical system patches are installed, or it may be used to monitor compliance with software licenses.

After a successful installation, we can go to the Administrative Tools folder and run the Services applet. When selecting the SNMP Service and choosing Properties, the service properties window along with SNMP configuration will appear:

The window has three additional tabs: Agent, Traps, and Security. The Agent tab allows us to configure which parts are exported over SNMP and lets us set up contact and location information.

The Security tab allows us to configure how SNMP information from this host can be accessed. The Windows SNMP agent offers support for SNMPv1 and SNMPv2c, so the security model is based on a community string and IP addresses for authentication.

The agent can either accept SNMP queries from all hosts or only specific hosts listed in the bottom part of the tab. It is also possibile to specify one or more readable and writable communities. By default, only queries on the public community string are accepted and these allow read-only access.

The Traps tab allows configuring Windows to send or forward traps to specific IP addresses and which SNMP community to use for communication.