When it comes to network management protocols, the Simple Network Management Protocol (SNMP) is probably one of the best known. It is commonly used in networks and several applications internally support SNMP for monitoring purposes.
In this section, we will only provide a short overview of SNMP because its full workings are beyond the scope of this book.
SNMP stores information in a virtual database called a Management Information Base (MIB). The database is hierarchical (tree-structured) and entries are addressed through object identifiers (OID). The following SNMP table output shows this structure:
.1.3.6.1.2.1.25.3.8.1.1.1 = INTEGER: 1 .1.3.6.1.2.1.25.3.8.1.1.2 = INTEGER: 2 .1.3.6.1.2.1.25.3.8.1.2.1 = STRING: "/" .1.3.6.1.2.1.25.3.8.1.2.2 = STRING: "/boot" .1.3.6.1.2.1.25.3.8.1.3.1 = "" .1.3.6.1.2.1.25.3.8.1.3.2 = "" .1.3.6.1.2.1.25.3.8.1.4.1 = OID: .1.3.6.1.2.1.25.3.9.23 .1.3.6.1.2.1.25.3.8.1.4.2 = OID: .1.3.6.1.2.1.25.3.9.23 .1.3.6.1.2.1.25.3.8.1.5.1 = INTEGER: readWrite(1) .1.3.6.1.2.1.25.3.8.1.5.2 = INTEGER: readWrite(1) .1.3.6.1.2.1.25.3.8.1.6.1 = INTEGER: true(1) .1.3.6.1.2.1.25.3.8.1.6.2 = INTEGER: false(2)
The number to the left represent the OIDs, the data to the right are the actual values of that OID. If you look at the OIDs to the left, you can see the actual tree structure:
.1.3.6.1.2.1.25.3.8.1.
\--1
\--1
\--2
\--2
\--1
\--2Generally an organization that has an SNMP agent will publish an MIB-Module for their product and this is used on the management station to map the OIDs to human readable equivalents and perform some basic sanity checks on the format of data returned.
SNMPv1 is the original SNMP protocol defined in the late 1980s. One of the main design goals for SNMP was to keep it simple and easy to implement. Due to this decision, SNMPv1 gained widespread commercial relevance and today most manageable network equipment supports at least SNMPv1.
By keeping it simple on the agent (network equipment) side, more complex tasks were left to the clients.
SNMPv1 had 5 core protocol data units (PDUs) for getting and setting data as well as sending out alerts. These are:
The GetRequest and GetNextRequest units are used to retrieving data from an agent but they can only retrieve one data point at a time, so retrieving interface statistics on a large network device requires many GetRequests or GetNextRequests to be sent to the device.
With the SetRequest unit, data can be set on the device. This is typically used to change configurations (e.g. on Cisco routers/swtiches), or for sending commands to a network device (e.g. ping).
The Response unit is sent by the SNMP agent to the management station as a response to a Get or Set request.
Traps are initiated from the SNMP agent to send immediate alerts to the defined management station. They include information about:
Who is sending the trap
What occurred
When it occurred
Additional information as OID/value pairs
Cacti itself does not handle SNMP traps. There are several plugins available for adding this functionality to Cacti.
SNMPv1 does not have any encryption and only uses a community string to identify the management station, and even then it is transmitted in clear text. As a result, SNMPv1 is a very insecure protocol because SetRequests can be used to reconfigure network equipment if improperly configured.
Modern network equipment allows the definition of access lists for requests to the SNMP agent which should be used in order to reduce security issues.
SNMPv2 addresses some of the shortcomings of the SNMPv1 protocol by introducing two new protocol data units: GetBulkRequests and InformRequest.
The GetBulkRequest unit allows a single GetRequest to retrieve numerous OIDs from an SNMP agent without the need to send several GetRequests. This is particularly useful for retrieving large amounts of objects such as a list of all interfaces of a network device.
The Inform unit addresses the unreliability of the Trap unit, which sends a unidirectional trap. In contrast to this, Informs provide a mechanism to send reliable events from the agent to the management station, which is then acknowledged with a response so that the notification is confirmed by the agent.
With SNMPv2 there was also an update to the MIB definition, which was enhanced to support more data types such as IPv6 addresses, Octet strings and 64-bit counters.