SNMP (Simple Network Management Protocol)

Introduction

SNMP is an Application layer protocol that began its life in the late 1980s having been based on the original SGMP (Simple Gateway Management Protocol). SNMP was to be replaced by a solution based on the CMIS/CMIP (Common Management Information Service/Protocol) architecture but this never happened, instead SNMP became ubiquitous throughout the network world and has now undergone several revisions.

SNMP uses the term nodes when referring to devices within the SNMP framework. The Management Node has software that is used for SNMP management and monitoring purposes. The Managed Node runs an Agent process that responds to requests from a Management Node. There are five components to SNMP:

Manager - Management Node issues commands and receives information from the node Agents.
Agent - sits within the node and communicates with the Manager. There are two types of agent:
- Extendible Agents - modular and open to new data.
- Monolithic Agents - cannot be modified because it has been fixed to specific hardware for speed purposes.
Protocol - used to issue and receive SNMP commands and information.
Management Information Base (MIB) - the database of information stored by the network node or element being managed
Managed Nodes - the network devices being managed.

This can be illustrated as follows:

Management Information Base (MIB)

The MIB is a map of device information that has been organised hierarchically as objects in a tree-like structure. This database is really a dictionary of readable objects used as a code book when putting together SNMP messages about specific objects and their characteristics. So the MIB contains the name, the OID, the data type, read/write permissions, and a description for each object in an SNMP agent. The object contains characteristics that can include the status of a port, a name, variables used in the device configuration etc. The objects and these characteristics sit within the tree structure like leaves connected to branches. An Object Identifier (OID) is used to distinguish one object and one characteristic from other objects and characteristics when sending and receiving messages.

The OID structure has a strict form based on the Structure of Management Information (SMI) defined in RFC 1155. This version is SMIv1 and is a set of rules that lay out the format used to define objects and is a subset of CCITT X.208 ASN.1. ASN.1 is the acronym for Abstact Syntax Notation One (ASN.1). SNMP messages and in particular some data types are also defined by ASN.1 (e.g. OID, 32-bit Signed Integer, Octet String and Null). The Application data types were defined in SMIv1 especially for SNMP. Also, datatypes such as Counter (rolling 32-bit unsigned integer), IpAddress, Gauge (unsigned 32-bit integer that tops out) and TimeTicks (32-bit unsigned integer that rolls over after 497 days) were defined in SMIv1. ASN.1 is a generic programming language akin to 'C'. Using ASN.1 means that programmers may use any language they choose rather than use the data types provided by the programming language. ASN.1 notation is used instead in order to maintain compatibility. ASN.1 also includes CCITT X.209 Basic Encoding Rules (BER) to ensure that the data is encoded (or compiled) on the wire in a consistent way. ASN.1 allows for complex data types such as grouping different data types into a sequence of data fields. ASN.1 also provides SNMP PDUs such as GetRequest and SetRequest which are complex application data types and these are wrapped up within in the SNMP header for transportation across the network.

The OID is a string of numbers separated by dots e.g. .1.3.6.4.674.4.1.9.9.276.0.1. Each OID has a text label within the MIB in order to identify it on the Manager, plus the OID will have a parameter associated with this object called an Instance Value. This instance value may be a string, an 8-bit integer, 32-bit integer signed or unsigned etc. This value is tagged onto the end of the OID, for example if an SNMP GET command is issued for the OID .1.3.6.4.674.4.1.9.9.276.0.1, then it might return the value 2 e.g. .1.3.6.4.674.4.1.9.9.276.0.1.2.

The managed node normally has a number of MIBs that it can use. Each MIB is designed for particular elements e.g. you may have a MIB purely focussed on the physical stucture or chassis of the device, or you may have a MIB for Syslog.

Messages

There are five main messages used and these are:

GET - the Manager uses this to obtain specific MIB variable information from a device element. It therefore contains the OID and its value.
GET-NEXT - the Manager uses this to obtain the next lexical variable information.
SET - the Manager uses this to SET a value of a specific variable.
GET-RESPONSE - the agent receives the OID information and uses this to look up the specific information within one of the elements' MIBs and then responds to the Manager's SET, GET and GET-NEXT requests with the GET-RESPONSE that may contain the relevant information or it may contain an error message if the information is unavailable.
TRAP - this is sent by an Agent to the Manager should an event occur. The events that instigate the TRAP messages can be configured, plus a TRAP can contain an OID and a value to aid in clarification.

In order for a Management Node to send requests and receive data from an Agent, each must belong to the same Community. A Community Name needs to be shared by the Manager and the Agent and was originally designed as a crude form of security. A Community Profile is configured to include the Community Name and the privilege which can be Read Only or Read/Write. Common community names are public with a 'Read Only' privilege, and private with a Read/Write privilege. Even though these names may be changed, they are still sent as clear text within SNMP datagrams and are therefore insecure.

A TRAP message is distinct from the other message types in that it is unsolicited. The TRAP message is sent by the Agent to the Management Node when an event occurs. The Management Node must be configured within the Agent and both Agent and Manager need to contain the same Community Profile. The Manager can choose to throttle Traps if they reach a certain number. The Manager can also be configured to only receive Traps for certain conditions. The Manager is also used to perform certain alerting actions such as relaying the Trap message contents to a log, or email, or SMS.

IP/UDP ports

Within IP, the PDU packets are sent using UDP as the transport. The manager sends PDUs using any source port however the destination port on the agent is 161. The agent responds on port 161. Trap PDUs are sent by the agent on any source port, however the destination port on the manager has to be 162.

The PDUs used by SNMP mirror the commands.

SNMP v1

Version 1 was put together in 1988 and was designed to operate over IP, IPX, CLNS and AppleTalk DDP.

The SNMP datagram adheres to ASN.1 notation in its structure and is a sequence of datatypes. This sequence appears after the UDP header. The meaning of the SNMP structure above is detailed next and you will see that it is a sequence of ASN.1 datatypes:

Seq - For SNMP the Sequence number is 0x30.
Len - The Length is the length of the whole SNMP datagram in bytes which can vary depending on the content.
Int - The next datatype is of type Integer 0x02. This will be the SNMP version number.
Len - The Length of this next datatype is 1 byte.
Ver - The SNMP version number. For version 1 this value is 0x00.
Str - The next datatype is of type String 0x04. This will be the community name.
Len - The length of this datatype in bytes is variable depending on the community string being used.
Community - This contains the community string.
PDU Type - The PDU type can be one of the following:
- 0xA0 - GetRequest
- 0xA1 - GetNextRequest
- 0xA2 - GetResponse
- 0xA3 - SetRequest
- 0xA4 - Trap
Len - The length of the PDU.
Int - The next datatype is of type Integer 0x02. This integer will give the length of the Request ID.
Len - The length of the Request ID is 4 bytes.
Request ID - This number is the ID of the request and is used by the recipient to distinguish one request from another.
Int - The next datatype is of type Integer 0x02. This integer will give the length of the Error Status.
Len - The length of the Error Status is 1 byte.
Error Status - The Error Status value is 0 for GetRequest, however for GetResponse the following codes are used:

RFC 1155 - Structure and identification of management information for TCP/IP-based internets (SMI). This replaces the original RFC 1065.

RFC 1213 - Management information base for network management of TCP/IP-based internets. This RFC describes MIB2 which supplanted MIB1 described in RFC 1156, which itself replaced the original RFC 1066.

RFC 1157 - A simple network management protocol. This replaces the original RFC 1067.

SNMP v2c

Version 2 included security for the protocol using the concept of a complex party-based system. In addition, version 2 provided a new message called GETBULKREQUEST that allowed bulk information to be gathered at once rather than have multiple GET-NEXT requests.

Home

Disclaimer