SNMP has developed to become the most widely used network management protocol. The currently applied versions mainly include SNMP v1, SNMP v2c and SNMP v3. The main differences between the versions are in the definition of information, the operation of communication protocols and the security mechanism. At the same time, two extensions of SNMP applications, RMON (Remote Network Monitoring) and RMON2, have also appeared.
From the perspective of the physical layer, using SNMP to manage the network should include: network management station (NMS), agent (Agent), and proxy server (proxy). In network management, at least one NMS is required to issue instructions and receive notification information. Agents can respond to requests from management nodes and can also proactively generate notification information. There can be one or more Agents in network management. Proxy forwards SNMP requests and notification messages between different networks or different versions.
From the perspective of the protocol layer, SNMP includes: SMI (Structure of Management Information, Management Information Structure) and MIB (Management Information Base, Management Information Base). SMI is a subset of ASN.1 (Abstract SyntaxNotation one). SMI stipulates that elements, custom data types and macros in ASN.1 can be used in SNMP. These elements, data types, macros and Other related syntaxes can be used to define MIBs in SNMP. MIB is an abstract description of manageable objects in Agent. In SNMP, MIB is organized and viewed in a tree structure. Each node in the tree is called an OID (Object Identifier). It is organized in a manner similar to a website domain name, and each node is represented by a certificate, such as 1.3. 6.4.
SNMP is an application layer protocol belonging to the TCP/IP protocol stack, similar to HTTP and FTP protocols. It's just that the SNMP transport layer uses the UDP protocol.
In SNMP v1, a simple authentication mode from NMS to Agent is provided - Community. NMS needs to provide the Community string when sending a request to Agent. The Agent needs to check after receiving the string. Is it consistent with the local one? There are obvious security risks due to the use of clear text to transfer Community.
In 1996, IETF released SNMP v2c (Community-BasedSNMP v2). This version defined communication between management stations based on v1. All support distributed network management, but in terms of security mechanism Same as v1.
In 1998, IETF released SNMP v3, which expanded security (user-based security model and view-based access control model) and management mechanisms based on SNMP v2. In terms of security, the v3 version adds security parameters to protocol messages, allowing encrypted transmission and mandatory verification of messages. It is a secure protocol. SNMP v3 uses the modular idea to define each component module in the protocol, improves the protocol architecture, and most importantly, remains compatible with SNMP v1 and SNMP v2.
The agent in SNMP is mainly responsible for uploading information. In addition to the level functions of the SNMP protocol, NMS also has the ability to log and notify information that has been sent and received. recording, management and configuration functions, and can provide a graphical configuration and management interface.
In order to realize these functions, SNMP contains a series of operation commands, mainly including:
Reading commands: Get series commands, NMS sends requests for collection management like Agent information.
Set command: Set command, NMs writes the data carried in the message to the Agent.
Alarm function: Trap series, Agent actively sends alarm/event message information to NMS.
Figure 13-1
1. Get operation
Get operation is an operation actively initiated by NMS. In addition to the Get request flag, the outgoing message also includes the OID name and value pair to be requested, and the management object information is transferred in the form of binding of this name and value pair. Of course, the value corresponding to OID in the Get operation is NILL.
2. Get-Next operation
The Get-Next operation is similar to the Get function. The difference is that the queried information is not the OID information bound in the message but the next one of the object. OID information (if the next OID information is readable). For example, NMS wants to collect the information of sysLocation, the next node of sysName on the Agent side. In the request message, it is sysName.0, and the returned message is bound to sysLocation.0 and value.
3. The Get-Bulk operation
is actually a collection of multiple Get-Next operations. This is a newly added operation method in SNMP v2.
4. Set operation
Set operation can set parameters for OID with writable permissions to achieve parameter management, configuration and control of the device. Different from the Get operation binding variables, Set needs to bind the value of the corresponding OID setting.
5. Get-Response
Get-Response is a response to the Get and Set commands of NMS. Depending on the command and the parameters in the command, the corresponding return variable is bound. information and error status information (indicating the success or failure of command execution), etc.
6. Trap series
Trap is a mechanism for Agent to proactively report important events to NMS. For such reports, NMS does not need to respond to Agent. The content in the trap information indicates what happened at what time and where.
1、SMI
SMI is an information module defined in ASN.1 syntax in SNMP and is a subset of ASN.1. These modules contain many SNMP-specific macros, custom data types and rules, etc. There are three main purposes for defining these macros, data types, and rules: one is to represent and define unique data types in SNMP applications; the other is to simplify the definition method of management objects; the third is to allocate the object identifier space and management objects in SNMP Coding method. SNMP is based on these information modules defined in RFC documents to standardize the protocol, allowing various organizations, enterprises and individuals to maintain consistency when defining management objects.
In SNMP, two versions of SMI are actually defined, namely SMI v1 defined in RFC 1151 and SMI v2 defined in RFC 2578. In SMI v1, several data types, rule descriptions, OBJECT-TYPE macros, etc. are simply defined. In SMI v2, all related content is completely organized in a modular definition manner.
The basic data types defined in SMI v1 are:
INTEGER: It is actually a 32-bit integer.
OCTET STRING: 0 or more 8-bit characters (single byte), which can represent text characters or physical addresses. The value range is 0 to 65535.
OBJECT IDENTIFIER: OID expressed in dotted decimal notation.
NULL: It is only defined in SMI v1 and is no longer used in SMI v2.
SEQUENCE: Definition list.
SEQUENCE OF: Define the table.
In SMI v2, the scope restrictions and updates for the above data types are further clarified, and the BITS type is also introduced.
Custom data types in SMI v1 include:
NetworkAddress (network address), which can be a network address family other than the Internet,
NetworkAddress::= CHOICE {Internet IPAddress}
32-bit IP address, expressed in network byte order
IPAddress::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4))
Counter type value grows in one direction. After reaching the maximum, it returns to 0 and starts counting again (after Agent restarts It will also be reset to 0), mainly used to count the number of bytes sent and received by the interface
Counter::= [APPLICATION 1] IMPLICIT INTEGER (0.. 4294967295)
The Gauge type value can be increased or decreased, and remains at the maximum value when it reaches the maximum value. For example, the rate of the interface in the router can be expressed by this type
Gauge::= [APPLICATION 2]IMPLICIT INTEGER (0 .. 4294967295)
TimeTicks uses 0.01 seconds for timing, indicating the time interval between two time points. Requires the timing base to be stated in the description.
TimeTicks::= [APPLICATION 3] IMPLICIT INTEGER (0.. 4294967295)
Opaque encodes other ASN.1 types The value is encapsulated twice. For backward compatibility, this type is also defined in SMIv2 and is not recommended.
Opaque ：：= [APPLICATION 4 ] IMPLICIT OCTET STRING
The custom data types that have changed in SMI v2 compared to SMI v1 are:
Gauge32 and Gauge are actually the same. Gauge32 and Unsigned32 share the same application type tag, therefore their encoding is essentially identical..
Gauge32 ::= [APPLICATION 2 ] IMPLICIT INTEGER (0 .. 4294967295)
Unsigned32 ::= [APPLICATION 2 ] IMPLICIT INTEGER (0 .. 4294967295)
Counter64 is a larger range of Counter, there are 64: 2^64-1 (0..18446744073709551615). Counter32 is used in the standard MIB module only when the counter returns to 0 in less than 1 hour.
Counter64::= [APPLICATION6] IMPLICIT INTEGER (0..18446744073709551615)
The IPAddress type is still retained in SMI v2 and has no changes. However, it does not apply to the 128-bit address of IPv6. A further explanation of Counter32: The current count value has a clear meaning only when there is an initial value and a recorded change.
From the perspective of MIB, SMI is a charter that directly guides the definition of MIB, defines the data type and syntax of MIB, and allocates OID space for management objects in MIB.
2, MIB
MIB is a collection of management information. It is organized according to the agreement based on business needs or network management standards. A structured text file written with rules and definition syntax.
Each management object in the management information base (MIB) needs to clearly describe all its attributes, including name, description, data type and other information. The contents of these properties can be identified by communicating parties through the object's unique identifier (OID). In other words, MIB is a bridge for communication between NMS and Agent. Only when Agent implements the MIB and NMS knows the MIB can the two work together correctly to implement corresponding management functions. Only after the MIB is imported into NMS can NMS know all the details of the objects to be managed. If the management object defined in the MIB is implemented in the agent, the agent supports the MIB.
An Agent can implement multiple MIBs, and each MIB can contain more or less management objects. There are no clear requirements. MIB is mainly composed of two parts. One part is the standard management object defined by the International Organization for Standardization, including MIB-I (RFC1156) and MIB-II (RFC1213). All devices connected to the network support general and basic management objects, which are defined in the standard MIB. The other part is the private MIB customized by major manufacturers, organizations or individuals. These private MIBs are customized by manufacturers according to the needs of device management, and objects that need to be managed that are not in the standard MIB. The private MIB is defined under the node enterprises (1.3.6.1.4.1).
The standard MIB divides the management objects into 10 groups, which are 10 branches in the MIB tree. They are: System, Interfaces, AT (Address Translation, the status is deprecated, indicating that the next version will not Using), IP, ICMP, TCP, UDP, EGP, Transmission, SNMP, their parent node is 1.3.6.1.2.1 (mib-2). The management objects in these 10 groups are one of the most important parts of network management.
System group: Mainly used to describe Agent system level information. Including sysName, sysLocation, sysDescr, sysServices, sysUpTime, sysContact, sysObjectID, etc. These OIDs provide information such as the name, location, and online time of the device, which are very important in network management. In actual environments, this information cannot be updated in time and is easily ignored.
Interfaces group: This group is used to provide all interface information of network devices. Including interface type, interface description, interface rate, interface status, etc.
AT group: Address translation group. This group of times is a table object that implements the mapping relationship between network addresses and physical addresses. By traversing the table, the correspondence between the IP address and the MAC address can be obtained.
IP group: defines the management object of IP layer related information. These objects include IP packets, error information, address information, routing information, and address mapping information.
ICMP group: This group defines 26 scalar objects that describe the sending and receiving of various ICMP messages. They are all of Counter type. These objects can easily provide the message sending and receiving rate and the rate of various ICMP message types (requests, responses).
TCP group: This group mainly includes: TCP retransmission policy for configuration management, objects with the longest and shortest retransmission time, and link rejected requests for performance management. Objects such as the number of transfer records between TCP communication states, the total number of retransmissions, and the total number of receiving errors, technical objects for sending and receiving TCP data segments that may be used for billing management, and tcpConnTable table objects that may be used for security management. By analyzing the records in this table Get the remote IP, port number, status and other information, and track suspicious links from the remote end.
UDP group: This group includes objects that can be used for performance and accounting management of counting objects for receiving and sending UDP packets, error report counting objects, and related information such as ports and IP addresses. .
EGP (Exterior Gateway Protocol) group: EGP is a protocol used to exchange routing information between autonomous systems (neighbors). This group includes the egpNeighTable table object for various information such as neighbor running status for user failure management, the domain number of the local autonomous system for user configuration management, the rate of EGP messages entering and leaving the local entity for performance management, and the error count object.
Transmission group: The function of this group is to provide corresponding management information according to different transmission media. This group is quite special. MIB-II does not define clear management objects under this branch. Instead, the corresponding interface type is added to the reorganization when a certain transmission medium needs to be managed.
SNMP group: This group defines objects related to SNMP in detail. For example, statistics on the number of different types of errors that can be used for fault management, whether trap authentication failures generate message objects that can be used for configuration management, and statistics on the number of various messages sent and received that can be used for performance management.
In SNMP, all management objects are organized in a tree structure, and the management objects are embodied as nodes in the tree, and this Trees are maintained and managed by relevant international standardization organizations. Through this structured and hierarchical organization, it is very convenient to manage and expand objects. This management and expansion is reflected in the allocation of nodes.
Enterprises, organizations or individuals have the right to apply for nodes from international organizations to become a branch in the tree structure. After successfully applying for a node, you can freely allocate other nodes under the branch to meet its monitoring or management business needs.
OID number, also called MIB number. MIB is actually an ASN.1 module composed of OIDs, which is embodied in a tree structure in reality. There are many standard MIBs on the Internet. SNMP defines MIB-I, MIB-II, etc., and also includes MIBs defined by enterprises, organizations, and individuals. As shown below.
In the OID tree, only the top-level root node does not have a specific number and can be regarded as a virtual node. The other nodes have unique numbers at the same level for distinction. .
The next-level nodes at the top are ccitt (0) managed by CCITT (the current ITU-T) and ISO (1) managed by ISO.
There are many sub-nodes under the internet node. Directory (1) is reserved and may be used for OSI directory services in the future. mgmt(2) is the responsibility of the IAB and is used to define standard management objects in RFC, which are actually MIB-I and MIB-II. experimental(3) is also managed by the IAB and is used to define management objects of the experimental nature of the internet. Private (4) and the lower-level node enterprises (1) are allocated and managed by IANA. The enterprises (1) node is mainly used for allocation to various enterprises or organizations.
The OID tree structure is shown in Figure 13-2 below.
Figure 13-2
You will find in RFC 2578 Compared with the data types defined in SNMP, when configuring monitoring item options in Zabbix, it is recommended that the Type of information and Store value options be configured as shown in the following table.
SNMP Type |
Description Description |
Recommended monitoring item options in Zabbix |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
INTEGER |
Signed 32 is an integer |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
STRING |
Any binary or text data, can be multiple lines |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ##OID | ## SNMP Object Identifier, expressed in dotted decimal
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| IPv4 Address |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| One-way growth value (0 .. 4294967295), after reaching the maximum, it returns to 0 and starts counting again | Numeric Unsigned, decimal
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| The value can be increased or decreased (0 .. 4294967295), and remains at the maximum value when reaching the maximum value | Numeric Unsigned, decimal
| ##Counter64||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The value grows in one direction until it reaches the maximum value and then starts counting from 0 again (0.. 18446744073709551615) |
##Numeric Unsigned, decimal |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Numeric Unsigned , decimal |
|
The above is the detailed content of What are the network devices that Zabbix 3.0 monitors?. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
