Shulou(Shulou.com)06/01 Report--

Getting started with SNMP Protocol

1. Introduction

TCP/IP-based network management consists of three components:

1) A management information base MIB (Management Information Base). The management information base contains all the parameters that can be queried and modified for all agent processes. RFC1213 [McCloghrie and Rose 1991] defines the second version of MIB, called MIB-II.

2) A set of common structures and representations about MIB. It is called Management Information structure SMI (Structure of Management Information). This is defined in RFC 1155 [Rose and McCloghrie 1990]. For example, SMI defines a counter as a non-negative integer with a count range of 0,4294967295, and when it reaches its maximum, it starts counting from 0.

3) the communication protocol between the management process and the agent process is called simple Network Management Protocol SNMP (Simple Network Management Protocol). In RFC 1157 [Case et al. Defined in 1990]. SNMP includes the format of Datagram exchange and so on. Although a variety of protocols can be used at the transport layer, the most frequently used protocol in SNMP is UDP.

2. Overview of SNMP protocol

Simple Network Management Protocol (SNMP:Simple Network Management Protocol) is a set of network management protocols defined by the Internet Engineering Task Force (IETF:Internet Engineering Task Force). The protocol is based on simple Gateway Monitoring Protocol (SGMP:Simple Gateway Monitor Protocol). With SNMP, a management workstation can remotely manage all network devices that support this protocol, including monitoring network status, modifying network device configuration, receiving network event warnings, and so on. Although SNMP was originally aimed at IP-based network management, it has also been successfully used in telephone network management as an industry standard.

3. The development history of SNMP.

SNMP has gone through a relatively long process of development, and so far there have been three versions. SNMPv2 is the most widely used nowadays.

The first version of SNMP, called SNMPv1, was released in 1989.

L released a supplement to SNMP in 1991-RMON (Remote Network Monitoring, remote network monitoring). RMON extends the functions of SNMP, including the management of LAN and the management of devices attached to these networks. Note: RMON does not modify or add the SNMP protocol itself and SMI, but increases the ability of SNMP to monitor the subnet, monitors the entire subnet as an individual, and provides a new MIB library and related MIB behavior.

An upgraded version of SNMPv1 was proposed in 1993, SNMPv2.

L SNMPv2 was officially released in 1995, v2 added the function of SNMPv1 and defined how to use SNMP in OSI-based networks. At the same time, RMON expanded to RMONv2 this year.

When SNMPv3 was released in 1998, a series of documents defined the security of SNMP and defined the overall structure for future improvements. SNMPv3 can be used with v2 and v1.

4. The working principle of SNMP

SNMP adopts a special client / server model, that is, the agent / management station model. The management and maintenance of the network is accomplished through the interaction between the management workstation and the SNMP agent. Each SNMP slave agent is responsible for answering various queries from the SNMP management workstation (master agent) about MIB definition information.

The application scenario of SNMP is shown in figure 1:

The management station and the agent use MIB to unify the interface, and MIB defines the managed objects in the device. Both the management station and the agent implement the corresponding MIB objects, so that the two sides can identify each other's data and realize communication. The management station requests the data defined in the MIB from the agent. After identification, the agent converts the relevant status or parameters and other data provided by the management equipment into the format defined by MIB, and finally returns the information to the management station to complete a management operation.

5. Message types of SNMP

Five message types are defined in SNMP: Get-Request, Get-Response, Get-Next-Request, Set-Request, and Trap.

(1) Get-Request, Get-Next-Request and Get-Response

The SNMP management station uses the Get-Request message to retrieve information from the network device that owns the SNMP agent, while the SNMP agent responds with the Get-Response message. Get-Next- Request is used in combination with Get-Request to query column elements in specific table objects.

(2) the Set-Request SNMP management station can use Set-Request to remotely configure network devices (including device names, device attributes, delete devices or make a device attribute valid / invalid, etc.).

(3) the Trap SNMP agent uses Trap to send unsolicited messages to the SNMP management station, which is generally used to describe the occurrence of an event, such as interface UP/DOWN,IP address change.

Among the above five messages, Get-Request, Get-Next-Request and Set-Request are sent by the management station to port 161on the agent side; the latter two kinds of Get-Response and Trap are sent to the management process by the agent process, in which the Trap message is sent to port 162of the management process, and all the data is encapsulated by UDP.

The SNMP workflow is shown in figure 2:

6. The message format of SNMP

The SNMP agent and the management station communicate through standard messages in the SNMP protocol, each of which is a separate Datagram. SNMP uses UDP (user Datagram Protocol) as the layer 4 protocol (transport protocol) for connectionless operations. The SNMP message consists of two parts: the SNMP header and the protocol data unit PDU.

In the actual network transmission environment, the length of the SNMP message depends on the coding method used. SNMP uniformly adopts the coding rules of BER (Basic Encoding Rule), while the formal SNMP specification uses ASN.1 syntax, Abastract Syntax Notation v1, that is, Abstract Syntax description language. These two concepts will be further introduced in the later practice, as long as we have a little understanding here, it does not hinder our analysis of the agreement itself. Here's a brief explanation of the BER coding rules:

As the basic coding rule of ANS.1, BER describes how specific ANS.1 objects are encoded as bitstreams and transmitted over the network. The BER coding rule consists of three parts:

Several basic data types are defined in SNMP, with some changes in v1 and v2 versions, as detailed in the corresponding RFC documentation. Here we introduce only a few of the most common types:

L INTEGER: an integer

L OCTER STRING: 0 or more 8bit bytes, each with a value between 0x255

L DisplayString:0 or multiple 8bit bytes, each byte must be an ASCII code. In MIB-II, all variables of this type cannot exceed 255characters (0 characters can)

L NULL: indicates that the related variable has no value

L IpAddress:4 byte-long OCTER STRING that represents the IP address in network byte order

L PhyAddress:6 byte long OCTER STRING, which represents the physical address

L Counter: a non-negative integer that can be incremented from 0 to 232-1 (). Return to 0 after reaching the maximum

L TimeTicks: time counter, incremented in 0.01s. Different variables can have different increments. So when defining this type of variable, we need to make the increment range.

L SEQUENCE: similar to the structure in C language

L SEQUENCE OF: a vector. See the detailed introduction to ANS.1 syntax below.

The SNMP message is encapsulated in the UDP message at the transport layer, and UDP is based on the IP network, so we can get a complete message description structure, as shown in the following figure:

The PDU type actually contains two bytes, the first of which represents the real type of PDU, and the second represents the total number of bytes occupied by subsequent messages. For SNMPv1, the value of this field is as follows:

Table 1 PDU types

PDU Typ

Name

0

Get-request

one

Get-next-request

two

Get-response

three

Set-request

four

Trap

That is, the type of trap is 4. However, in the data message, this field is generally expressed as ax, where x takes [0Jing 4], that is, a0~a3 represents the corresponding get, set and other operations, and A4 represents the trap message. Except for the exception of the type field, all other fields are encoded by BER:

Analysis of message format of actual combat exercise

The Trap message format is somewhat different from the structure shown in figure 5 above. Here we only analyze the Trap message format of SNMPv1 and SNMPv2. The front part of the trap message is the same, except in the PDU protocol data unit part.

SNMPv1 Trap message

The format of the Trap message for SNMPv1 is as follows:

Note: except for the PDU type and PDU length fields, each of the following fields is BER encoded.

The "trap type" can take the following values, where 0per6 is the defined specific trap,7 and its subsequent types are customized by the vendor

Table 2 trap type, name and description information

Trap Typ

Name

Description information

0

ColdStart

The agent process initializes itself

one

WarmStart

The agent process reinitializes itself

two

LinkDown

An interface has changed from a working state to a failure state (the first variable in the message identifies the interface)

three

LinkUp

An interface has changed from fault state to working state (the first variable in the message identifies this interface)

four

AuthenticationFailure

Received a message from an invalid community from the SNMP management process

five

EgpNeighborLoss

An EGP neighbor has become a failure state (the first variable in the message contains the IP address of the neighbor)

six

EnterpriseSpecific

Look for trap information in this particular code snippet

Through the wireshark packet grabbing tool, capture the following SNMP message, and then analyze it carefully.

SNMPv1 original message content:

00 23 5a 9e 58 b9 00 4c41 49 50 55 08 0045 00 00 48 00 00 40 00 40 11 a54e c0 a8 0a 01 c0 a8 0a 05 0c 00 00 a2 00 34 ff e0 30 2a 02 01 00 04 06 70 75 62 6c 69 63 a4 1d 06 0a 2b 06 01 04 01 bf 08 03 02 0a 40 04 c0 a8 0a 01 02 01 00 02 01 00 4301 0e 30 00

Purpose MAC:00 23 5a 9e 58 b9

Source MAC:00 4c 41 49 50 55

Protocol type: 08 00, IP Datagram

IP head: 45 00 00 48 00 00 40 00 40 11 a5 4e c0a8 0a 01 c0a8 0a 05 0c

UDP header: 0c 00 00 a2 00 34 ff e0

The rest are SNMP messages, so let's analyze them one by one against the previous message structure.

N 30 indicates that the SNMP message is the SEQUENCE type of ASN.1

N 2a indicates that the total length of the SNMP message is 42 (0x2a) bytes. The length of the message represented by this field starts from the first byte after it until the end of the message.

N 02 01 00 represents the version number, which shows that it is indeed BER encoded. 02 indicates that the field is of type INTEGER; 01 indicates that the field occupies 1 byte; 00 indicates the version number, and the value is "version number-1"

N 04 06 70 75 62 6c 69 63 denotes the group name, 04 indicates that the field is of type OCTET STRING, 06 indicates that the field occupies 6 bytes, and 70 75 62 6c 69 63 indicates the hexadecimal form of ANSII code of the group name, here is "public"

N a4 1d where the "4" in A4 indicates that this is a trap message, A4 is also called the label tag of the message, and 1D indicates that there are 29 (0x1d) bytes of data behind it.

N 06 0a 2b 06 01 04 01 bf 08 03 02 0a enterprise OID logo. 06 indicates that the field is an object identifier, OBJECT IDENTIFIER;0a indicates that the field occupies 10 (0x0a) bytes; OID about SNMP is encoded in a strange way: for example, 1.3.6.1.2... . Take the first two numbers as x and y, respectively. 40*x+y when coding, where xencoding 1 is no more than 3, so the result is 40 percent 1 percent 3 percent 43, which means hexadecimal 2b. Therefore, the enterprise OID code here is 1.3.6.1.4.1.8072.3.2.10

N 40 04 c0 a8 0a 01 also 40 indicates that the field is of type OCTET STRING; 04 indicates that the IP address occupies 4 bytes; the IP address is 192.168.10.1

N 02 01 00, where 00 indicates that the trap type is coldStart

N 02 01 00, where 00 means that the trap we specified, that is, specific-trap is also of coldStart type.

N 43 01 0e 43 is of type TimeTicks; 01 indicates that the field occupies 1 byte; 0e is a decimal 14 indicating a time label of 0.14 seconds, where the time counter is incremented by 0.01s.

N 3000 30 indicates that the encoding type of the key-value value pair is SEQUENCE;00, which means that the field occupies 0 bytes, that is, there is no such field.

SNMPv2 Trap message

The Trap message format of SNMPv2 is shown in figure 8:

Similarly, except that the trap type and message length are standard network byte order, the other protocol fields are also BER encoding. We can see that the v2 version of trap message is developing to a unified message format, which is very similar to ordinary SNMP request and response messages.

SNMPv2 original message content:

00 23 5a 9e 58 b9 00 4c41 49 50 55 08 00 45 0000 7b 0000 40 00 40 11 a5 1b c0 a8 0a 01 c0 a8 0a 05 0c 0100 a2 00 67 04 bb 30 5d 02 0101 04 06 70 75 62 6c 69 63 a7 50 02 04 17 73 2c fb 02 0100 02 0100 3042 30 0d 06 08 2b 06 01 02 0101 03 00 43 01 0e 30 17 06 0a2b 06 01 06 03 0101 04 0100 06 09 2b 06 01 06 03 0101 05 01 30 18 06 0a2b 06 01 06 03 0101 04 03 0006 0a2b 06 01 04 01 bf 08 03 02 0a

Purpose MAC:00 23 5a 9e 58 b9

Source MAC:00 4c 41 49 50 55

Protocol type: 08 0010 IP message

IP head: 45 00 00 7b 00 00 40 00 40 11 a5 1b c0a8 0a 01 c0a8 0a 05

UDP header: 0c 01 00 a2 00 67 04 bb

The rest are all SNMP messages. Let's make a simple agreement here:

Xx dimension type; xx dimension length; xx dimension real data.

In this way, the above string of raw data will be easier to analyze, J.

N 305d the encoding mode of the whole SNMP message is 30, that is, the SEQUENCE type, and the message length is 93 (0x5d) bytes.

N 02 01 01 version 01 v2 version

N 04 06 70 75 62 6c 69 63 group name 70 75 62 6c 69 63 that is "public" in English

N a7 50 A7 indicates that the trap type is 7, that is, the manufacturer's custom trap;50 indicates that the PDU section occupies 80 (0x50) bytes.

N 02 04 17 73 2c fb request ID is 17 73 2c fb decimal 393424123

N 02 01 00 error status 0

N 02 01 00 error index 0

N 30 42 "variable name-value" versus encoding type 30, that is, SEQUENCE type; the total byte 0x42 of "variable name-value", that is 66 bytes

N 300 d 06 08 2b 06 01 01 01 0300 43 01 0e the first "name-value" to the section encoding mode 30 is the SEQUENCE type; the first "name-value" to the total length 0x0dline 13 bytes; the first variable name encoding type 0x06, time tag; the first variable name occupies 0x08 bytes; the first variable name 2b 06 01 01 0300, 1.3.6.1.2.1.1.3.0; the first variable value is 0x0e, that is, 14

N 30 17 06 0a 2b 06 06 03 01 01 04 01 0006 09 2b 06 06 03 01 01 05 01 the second "name-value" pair; variable name 1.3.6.1.3.1.4.1.0; variable value 1.3.6.1.3.1.1.5.1

N 30 18 06 0a 2b 06 06 03 01 01 03 03 03 0006 0a 2b 06 01 01 bf 08 03 02 0a third name-value pair; variable name 1.3.6.1.3.1.1.4.3.0; variable value 1.3.6.1.1.8072.3.2.10

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.