Simple Network Management Protocol (SNMP) is an application layer protocol of the TCP/IP protocol suite. Developed in 1988 and adopted by the Internet Architecture Board (IAB) as a short-term solution for network management; SNMP has flourished in the Internet age due to its simplicity, and SNMPv2 was released in 1992 to enhance SNMPv1 security and functionality. Now, there is an SNMPv3 version.
A complete set of SNMP system mainly includes management information base (MIB), management information structure (SMI) and SNMP message protocol.
(1) Management Information Base MIB: Any managed resource is represented as an object, which is called a managed object. MIB is a collection of managed objects. It defines a series of properties of the managed object: the name of the object, the access rights of the object, and the data type of the object. Each SNMP device (Agent) has its own MIB. MIB can also be regarded as a communication bridge between NMS (Network Management System) and Agent. The relationship between them is shown in Figure 1.
Figure 1 Relationship between NMS Agent and MIB
The names used for variables in MIB files are taken from the object identifier namespace managed by ISO and ITU. It is a hierarchical tree structure. As shown in Figure 2, the first level has three nodes: ccitt, iso, iso-ccitt. The low-level object IDs are assigned by the relevant organizations, respectively. An identifier for a particular object can be obtained by taking the path from the root to the object. The general network device takes the object content under the iso node. For example, the MIB variable named ipInReceives under the namespace ip node is assigned the number value 3, so the variable name is:
iso.org.dod.internet.mgmt.mib.ip.ipInReceives
The corresponding digital representation (object identifier OID, which uniquely identifies a MIB object) is:
1.3.6.1.2.1.4.3
Figure 2 MIB tree structure
When the network management protocol uses MIB variables in the message, a suffix should be added after each variable name as an instance of the variable. For example, the instance number of ipInReceives is expressed as: 1.3.6.1.2.1.4.3.0.
It should be noted that the OID of the management object in the MIB needs to be dynamically determined, such as the IP routing table. In order to specify the next hop of the address 202.120.86.71, we can refer to such an instance:
iso.org.dod.internet.mgmt.mib.ip.ipRouteTable.ipRouteEntry.ipRouteNextHop.202.120.86.71, the corresponding number is expressed as: 1.3.6.1.2.1.4.21.1.7.202.120.86.71
For this instance of dynamic object identification, since it cannot be converted to a pre-specified Readkey name, which conflicts with the product architecture of Flyneigh (the variable Readkey needs to be dynamically generated), it is not considered to be supported for the time being.
(2) Management Information Structure (SMI)
SMI defines the organization, composition, and identification of information used by the SNMP framework. It also lays the foundation for describing MIB objects and describing how protocols exchange information.
Data types defined by SMI:
◆ Simple type (simple)
Integer: The integer type is a signed integer from -2,147,483,648 to 2,147,483,647
octet string: A string is an ordered sequence of 0~65535 bytes
OBJECT IDENTIFIER: from the set of object identifiers assigned according to ASN.1 rules
◆ Simple-constructed
SEQUENCE is used for lists. This data type is similar to "structure" in most programming languages. A SEQUENCE consists of 0 or more elements, each of which is another ASN.1 data type
SEQUENCE OF type is used for tables. This data type is similar to "array" in most programming languages. A table consists of zero or more elements, each of which is another ASN.1 data type.
◆ Application type (application-wide)
IpAddress: The IP address in network order. Because it is a 32-bit value, it is defined as 4 bytes;
counter: The counter is a non-negative integer that increments to the maximum value and then returns to zero. The counters defined in SNMPv1 are 32-bit, that is, the maximum value is 4, 294, 967, 295;
Gauge : Also a non-negative integer, it can be incremented or decremented, but remains at the maximum value when it reaches the maximum value, the maximum value is 232-1;
time ticks: is a time unit that represents the time calculated in units of 0.01 seconds;
SNMP messages
The structure of the SNMP message is as follows: (before encoding)
| version number |
| group name |
| Protocol Data Unit PDU |
SNMP has 5 types of messages, so there are 5 PDUs. The seventh point will introduce the 5 types of SNMP protocol data units in detail.
1 5 kinds of protocol data units of SNMP
SNMP specifies five protocol data unit PDUs (that is, SNMP messages) for exchange between management processes and agents.
get-request operation: Extract one or more parameter values from the agent process.
get-next-request operation: Extract the next parameter value immediately following the current parameter value from the agent process.
set-request operation: Set one or more parameter values of the agent process.
get-response operation: Returns one or more parameter values. This operation is issued by the agent process, and it is the response operation of the previous three operations. Trap operation: A message actively sent by the agent process to notify the management process that something has happened.
The first three operations are sent by the management process to the agent process, and the last two operations are sent by the agent process to the management process. For the sake of simplicity, the first three operations will be called get, get-next and set operations from now on. Figure 1 describes these five message operations of SNMP. Note that on the agent side the well-known port 161 is used to receive get or set messages, while on the manager side the well-known port 162 is used for trap messages.
Figure 1 Five types of message operations of SNMP
Figure 2 shows the SNMP message format of five operations encapsulated into UDP datagrams. It can be seen that an SNMP message consists of three parts, namely the public SNMP header, the get/set header, the trap header, and the variable binding.
(1) There are three fields in the public SNMP header :
Version
The version number written in the version field is minus 1, and 0 should be written for SNMP (ie SNMPV1).
Community The community
is a string, which is used as the plaintext password between the management process and the agent process, and the 6-character "public" is commonly used.
PDU type
Fill in a number from 0 to 4 according to the type of PDU, and the corresponding relationship is shown in Table 2.
Table 2 PDU types
-
PDU type
name
0
get-request
1
get-next-request
2
get-response
3
set-request
4
trap
(2) get/set header
request identifier (request ID)
This is an integer value set by the management process. The proxy process also returns this request identifier when sending the get-response message. The management process can send get messages to many agents at the same time. These messages are all transmitted using UDP, and the ones sent first may arrive later. Setting the request identifier enables the management process to identify which request message the returned response message is for.
The error status (error status)
is filled with a number from 0 to 5 when the agent process replies, see the description in Table 3
Table 3 Error state description
| error status |
name |
illustrate |
| 0 |
noError |
everything is normal |
| 1 |
tooBig |
The agent was unable to fit the answer into an SNMP message |
| 2 |
noSuchName |
Operation specifies a variable that does not exist |
| 3 |
badValue |
A set operation specified an invalid value or invalid syntax |
| 4 |
readOnly |
A management process attempted to modify a read-only variable |
| 5 |
genErr |
some other error |
Error index (error index)
When there is an error of noSuchName, badValue or readOnly, an integer set by the agent process when answering, it indicates the offset of the variable with error in the variable list.
(3) Trap header
The enterprise (enterprise)
fills in the object identifier of the network device of the trap message. This object identifier must be on a subtree below the enterprise node {1.3.6.1.4.1} on the object naming tree of Figure 3.
trap type
The official name of this field is generic-trap, and it is divided into 7 types in Table 4.
| trap type |
name |
illustrate |
| 0 |
coldStart |
The agent is initialized |
| 1 |
warmStart |
The agent was reinitialized |
| 2 |
linkDown |
An interface changes from a working state to a failed state |
| 3 |
linkUp |
An interface changes from a failed state to a working state |
| 4 |
authenticationFailure |
A message with an invalid community was received from the SNMP management process |
| 5 |
egpNeighborLoss |
An EGP neighbor router becomes faulty |
| 6 |
enterpriseSpecific |
Delegate custom events, which need to be specified with the following "specific code" |
When using types 2, 3, and 5 above, the first variable in the variable part after the message shall identify the interface of the response.
The specific code (specific-code)
indicates the custom time of the agent (if the trap type is 6), otherwise it is 0.
Timestamp (timestamp)
indicates the time from the initialization of the agent process to the occurrence of the event reported by the trap, in units of 10ms. For example a timestamp of 1908 indicates that this time occurred 1908ms after the agent was initialized.
(4) Variable bindings (variable-bindings)
specify the name and corresponding value of one or more variables. In a get or get-next message, the value of the variable shall be ignored.
Representation of management variables
管理变量表示管理对象类型在某一时刻的值（或称该类型的实例），SNMP以管理变量作为操作对象。
管理变量的表示方法是这样规定的：形如x.y，其中x是管理对象的object identifer。y是能唯一确定对象类型值的一组数字，在非表型变量中为0，在表型变量中是这个表的索引，比如接口表中的接口号，或路由表中的目的网络地址等等 。如：在MIB文件里定义了ipAdEntNetMask这一管理对象，其object identifier为1.3.6.1.1.5.6.1.3它是个路由表中的一项，它的一个实例就是路由表中某一行的子网掩码，如果这行的索引、目的网络地址为129.102.1.0。则这个变量名是：1.3.6.1.1.5.6.1.3.129.102.1.0。在以后的说明中，为了方便，把唯一确定管理变量的一组数字，也就是x.y中的y称作实例。
SNMP的运行过程
驻留在被管设备上的AGENT从UDP端口161接受来自网管站的串行化报文，经解码、团体名验证、分析得到管理变量在MIB树中对应的节点，从相应的模块中得到管理变量的值，再形成响应报文，编码发送回网管站。网管站得到响应报文后，再经同样的处理，最终显示结果。
下面根据RFC1157详细介绍Agent接受到报文后采取的动作：
首先解码生成用内部数据结构表示的报文，解码依据ASN.1的基本编码规则，如果在此过程中出现错误导致解码失败则丢弃该报文，不做进一步处理。
第二步：将报文中的版本号取出，如果与本Agent支持的SNMP版本不一致，则丢弃该报文，不做进一步处理。当前北研的数据通信产品只支持SNMP版本1。
第三步：将报文中的团体名取出，此团体名由发出请求的网管站填写。如与本设备认可的团体名不符，则丢弃该报文，不做进一步处理，同时产生一个陷阱报文。SNMPv1只提供了较弱的安全措施，在版本3中这一功能将大大加强。
第四步：从通过验证的ASN.1对象中提出协议数据单元PDU，如果失败，丢弃报文，不做进一不处理。否则处理PDU，结果将产生一个报文，该报文的发送目的地址应同收到报文的源地址一致。
根据不同的PDU，SNMP协议实体将做不同的处理：
1.1 GetRequest PDU
第一种情况：如果PDU中的变量名在本地维护的MIB树中不存在,则接受到这个PDU的协议实体将向发出者发送一个GetResponse报文，其中的PDU与源PDU只有一点不同：将ERROR-STATUS置为noSuchName,并在ERROR-INDEX中指出产生该变量在变量LIST中的位置。
第二种情况：如果本地协议实体将产生的响应报文的长度大于本地长度限制，将向该PDU的发出者发送一个GetResponse报文，该PDU除了ERROR-STATUS置为tooBig，ERROR-INDEX置为0以外，与源PDU相同。
第三种情况：如果本地协议实体因为其他原因不能产生正确的响应报文，将向该PDU的发出者发送一个GetResponse报文，该PDU除了ERROR-STATUS置为genErr，ERROR-INDEX置为出错变量在变量LIST中的位置，其余与源PDU相同。
第四中情况：如果上面的情况都没有发生，则本地协议实体向该PDU的发出者发送一个GetResponse报文，该PDU中将包含变量名和相应值的对偶表，ERROR-STATUS为noError,ERROR-INDEX为0，request-id域的值应与收到PDU的request-id相同。
1.2 GetNextRequest PDU
GetNextRequest PDU的最重要的功能是表的遍历，这种操作受到了前面所说的管理变量的表示方法的支持，从而可以访问一组相关的变量，就好象他们在一个表内。
下面通过一个例子解释表遍历的过程：
被管设备维护如下路由表：
Destination NextHop Metric
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
假设网管站欲取得这张路由表的信息，该表的索引是目的网络地址。
网管站向被管设备发送一个GetNextRequest PDU,其中的受管对象的标识如下
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
SNMP agent响应如下GetResponse PDU:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
网管站继续：
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
agent响应：
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
值得注意的是agent必须能够确定下一个管理变量名，以保证所有变量能被取到且只被取到一次。
网管站继续：
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
agent 响应：
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
网管站继续
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
这时因为路由表中所有的行都被取遍，agent因返回路由表对象的下一字典后继即该管理对象在MIB树中的后序遍历的直接后继。这里应是nettoMediaIndex，管理对象的OBJECT IDENTIFIER。这个响应通知网管站对表的遍历已经完成。
1.3 GetResponse PDU
GetResponse PDU只有当受到getRequest GetNextRequest SetRequest才由协议实体产生，网管站收到这个PDU后，应显示其结果。
1.4 SetRequest PDU
SetRequest PDU除了PDU类型标识以外，和GetRequest相同，当需要对被管变量进行写操作时，网管站侧的协议实体将生成该PDU。
对SetRequest的响应将根据下面情况分别处理：
如果是关于一个只读变量的设置请求，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为noSuchName, error index的值是错误变量在变量list中的位置。
如果被管设备上的协议实体收到的PDU中的变量对偶中的值，类型、长度不符和要求，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为badValue, error index的值是错误变量在变量list中的位置。
如果需要产生的GetReponse报文长度超过了本地限制，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为tooBig, error index的值是0。
If the SET fails due to other reasons, the protocol entity that receives the PDU generates a GetReponse message, and sets the error status to genErr, and the value of the error index is the position of the error variable in the variable list.
If any of the above conditions are not met, the agent will set the management variable to the corresponding value in the received PDU, which can often change the running state of the managed device. At the same time, a GetResponse PDU is generated, in which the error status is set to noError, and the value of the error index is 0.
1.5 Trap PDU
Trap PDU has the following form
| OBJECT IDENTIFIER of the system that generated the trap
|
| IP address of the system |
| common type |
| specific type |
| Timestamp |
| Variable dual table |
Trap is a message that the managed device actively sends to the network management station when it encounters an emergency. After receiving the trap PDU, the network management station shall display the contents of the variable dual table. Some commonly used trap types are cold start, warm start, link state change, etc.