Translated from: Example
Key words: SNMP, MIB, OID, agent, NMs
Abstract: With the rapid development of network technology, the number of network devices is increasing, and the types of devices are also diverse. How can we effectively manage these devices? We can achieve this through the SNMP function. This article focuses on the basic concepts, working principles, and main applications of SNMP.
Abbreviations:
Abbreviations |
Full English name |
Explanation |
MiB |
Management Information Base |
Management Information Library |
NMs |
Network Management Station |
Network Management site |
Oid |
Object Identifier |
Object Identifier |
SNMP |
Simple Network Management Protocol |
Simple Network Management Protocol |
SMI |
Structure of Management Information |
Management Information Structure |
USM |
User-based security model |
User-based security model |
Vacm |
View-Based Access Control Model |
View-Based Access Control Model |
PDU |
Protocol Data Unit |
Protocol Data Unit |
Contents
1 Overview
1.1 Background
1.2 technical advantages
2. Features
2.1 SNMP Network Architecture
2.1.1 NMS Overview
2.1.2 agent Overview
2.1.3 MIB Overview
2.2 SNMP Version
2.2.1 SNMPv1
2.2.2 snmpv2c
2.2.3 SNMPv3
2.3 SNMP operations
2.4 SNMP Packets
2.4.1 SNMPv1 packets
2.4.2 snmpv2c packets
2.4.3 SNMPv3 packets
2.5 principles of SNMP
2.5.1 implementation mechanism of SNMPv1 and snmpv2c
2.5.2 SNMPv3 Implementation Mechanism
3 Technical Features of H3C implementation
4 typical networking Cases
4.1 networking Diagram
4.2 Networking Environment
5 Appendix
5.1 related Protocols
5.2 references
1 Overview 1.1 Background
Today, the Internet is getting closer and closer to people's lives and work, but with the popularization of the Internet, there are two major problems:
L The network scale increases gradually, and the number of network devices increases accordingly. It is difficult for the network administrator to monitor the status of all devices in a timely manner and to detect and fix faults.
L network devices may come from different vendors. If each vendor provides an independent management interface (such as a command line interface), network management becomes more and more complex.
To solve the above two problems, a set of standards (SNMP) covering services, protocols and management information databases are developed.
1.2 technical advantages
SNMP is the communication protocol between the management process (NMS) and the Agent process (agent. It specifies the standardized management framework for device Monitoring and Management in the network environment, the public language of communication, and the corresponding security and access control mechanisms. Network administrators can use SNMP to query device information, modify device parameter values, monitor device status, automatically detect network faults, and generate reports.
SNMP has the following technical advantages:
L standard protocol based on TCP/IP Internet, the transport layer protocol generally uses UDP.
L automated network management. Network administrators can use the SNMP platform to retrieve information, modify information, discover faults, complete fault diagnosis, plan capacity, and generate reports on nodes on the network.
L shield physical differences between different devices to achieve automated management of products of different vendors. SNMP only provides the most basic function set, so that management tasks are independent of the physical characteristics and actual network types of managed devices, so as to manage devices of different vendors.
L simple request-response methods are combined with active notification methods, and there is a timeout and retransmission mechanism.
L The number of packets is small, and the message format is simple, which facilitates resolution and implementation.
L SNMPv3 provides authentication and encryption security mechanisms, as well as user-and view-based access control functions, enhancing security.
2 feature introduction 2.1 SNMP Network Architecture
The SNMP network architecture consists of NMS, agent, and MIB.
2.1.1 NMS Overview
NMS is a network manager and a system that uses the SNMP protocol to manage and monitor network devices. NMS can be a server dedicated for network management or an application that executes management functions on a device.
NMS can send a request to the agent to query or modify one or more specific parameter values. At the same time, NMS can receive the trap information actively sent by the agent to know the current status of the managed device.
2.1.2 agent Overview
An agent is an application module in a network device. It is used to maintain information data of the managed device, respond to NMS requests, and report management data to the NMs that sends the request.
After receiving the NMS request information, the agent completes the query or modification operation and sends the operation result to NMs to complete the response. In addition, when a device fails or other events occur, the agent sends the trap information to NMs to notify the current status of the device.
2.1.3 MIB Overview 1. MIB
Any managed resource is represented as an object called a managed object. MiB is a collection of managed objects. It defines a series of attributes of the managed object: Object Name, object access permission, and object data type. Each agent has its own MIB. MiB can also be seen as an interface between NMs and Agent. Through this interface, NMS can perform read/write operations on every managed object in the agent, this allows you to manage and monitor devices. The relationship between NMS, agent, and MIB is shown in 1.
Figure 1 Relationship Between NMS, agent, and MIB
2. MIB View
The MIB view is a collection of MIB. When you configure the agent, you can bind the group name/user name to the MIB view to restrict the MIB objects that NMs can access. You can configure the objects in the MIB view as excluded or included. Excluded indicates that the current view does not include all the nodes of the MIB subtree; pinned ded indicates that the current view includes all nodes of the MIB subtree.
3. OID and subtree
MiB are stored in a tree structure. The node of the tree indicates the managed object, which can be uniquely identified by a path starting from the root. This path is called OID ). 2. The management object system can be uniquely identified by a string of numbers {1.3.6.1.2.1.1}, which are system oid.
The subtree can be identified by the oId of the child root node. For example, the oId of the subtree with private as the root node is private -- {1.3.6.1.4 }.
Figure 2 MIB Tree Structure
4. subtree mask
The subtree mask can be used with the subtree oid to determine the range of a view. The subtree mask is represented in hexadecimal format. After being converted to binary, each bit corresponds to a section in the oId,
L 1 indicates exact match, that is, the value of the corresponding section of the node oid to be accessed must be equal to that of the MIB object subtree OID;
L 0 indicates the wildcard, that is, the value of the corresponding section of the node oid to be accessed and the MIB object subtree OID can be different.
For example, if the subtree mask is 0xdb (the binary format is 11011011) and the subtree oid is 1.3.6.1.6.1.2.1, the corresponding relationship 3 is shown. The determined view includes that the subtree oid is 1. 3. *. 1. 6. *. 2.1 (* indicates any number) All nodes under the subtree.
Figure 3 Relationship Between subtree OID and subtree mask
& Note:
L if the number of bits in the subtree mask is greater than the number of bars in the subtree OID, the first part of the subtree mask is aligned with the first part of the subtree oid, the second bit is aligned with the second section. Similarly, the extra bit in the subtree mask will be ignored.
L if the number of bits in the subtree mask is smaller than the number of bars in the subtree OID, the first part of the subtree mask is aligned with the first part of the subtree oid, the second bit is aligned with the second section, and so on. The bit that is insufficient in the subtree mask is automatically set to 1;
L if the sub-tree mask is not specified, use the default sub-tree mask (full 1 ).
2.2 SNMP Version
SNMP mainly includes the most common versions of SNMPv1, snmpv2c, and SNMPv3.
2.2.1 SNMPv1
SNMPv1 is the first version of the SNMP protocol and provides the minimum network management function. SMI and MIB of SNMPv1 are simple and have many security defects.
SNMPv1 adopts Group Name authentication. The group name acts like a password to restrict NMS access to the agent. If the group name carried by the SNMP message is not recognized by NMS/agent, the message will be discarded.
2.2.2 snmpv2c
Snmpv2c also adopts Group Name authentication. SNMPv1 is compatible with SNMPv1, while SNMPv1 is expanded: it provides more operation types (GETBULK operations, etc.); supports more data types (counter32, etc ); provides a richer set of error codes for better error segmentation.
2.2.3 SNMPv3
SNMPv3 is mainly enhanced in terms of security. It adopts USM and vacm technologies. USM provides authentication and encryption functions. vacm determines whether a user is allowed to access a specific MIB object and the access method.
1. USM (based on the user's security model)
USM introduces the concepts of user names and groups, and supports authentication and encryption. Authentication is used to verify the legality of the message sender to avoid unauthorized user access. encryption is used to encrypt the packets transmitted between NMs and the agent to avoid eavesdropping. By combining functions such as authentication and encryption, You can provide higher security for communication between NMs and the agent.
2. vacm (View-Based Access Control Model)
Vacm technology defines five elements: group, security level, context, MIB view, and access policy. These elements determine whether a user has access permissions, only users with access permissions can manage operation objects. Different groups can be defined on the same SNMP object. The group is bound to the MIB view, and multiple users can be defined in the group. When using a user name for access, you can only access the objects defined in the corresponding MIB view.
2.3 SNMP operations
SNMP supports the following basic operations:
L get operation: NMS uses this operation to obtain one or more parameter values from the agent.
L getnext operation: NMS uses this operation to obtain the next parameter value of one or more parameters from the agent.
L set operation: NMS uses this operation to set one or more agent parameter values.
L response operation: the agent returns one or more parameter values. This operation is the response of the first three operations.
L trap operation: an action actively sent by the agent to notify NMS of some events.
During the first four operations, the device uses UDP to send packets over port 161. During the trap operation, the device uses UDP to send packets over port 162. Because different port numbers are used for sending and receiving, a device can be used as agent and NMS at the same time.
2.4 SNMP Packets
The following message formats are defined based on different SNMP versions and operations:
2.4.1 SNMPv1 packets
Figure 4 SNMPv1 Message format
As shown in figure 4, an SNMP message consists of version, community, and snmp pdu. The main fields in the message are defined as follows:
L version: SNMP version.
L community: group name, used for authentication between the agent and NMS. The group name can be readable or writable. If the get or getnext operation is performed, the group name can be read for authentication. If the set operation is performed, the group name can be written for authentication.
L request ID: Used to match requests and responses. SNMP assigns a globally unique ID to each request.
L error status: indicates the status of the request, including noerror, toobig, nosuchname, badvalue, readonly, and generr.
L error index: Error index. When an exception occurs, provide information about the variables that cause the exception in the variable binding list (variable bindings.
L variable bindings: Variable binding list, which consists of variable names and variable value pairs.
L Enterprise: the type of the trap source (the device that generates the trap information.
L agent ADDR: the address of the trap source.
L Generic Trap: common trap types, including coldstart, warmstart, linkdown, linkup, authenticationfailure, egpneighborloss, and isespecific.
L specific trap: Private Enterprise trap information.
L Time Stamp: the duration between the last time the network entity was reinitialized and the trap was generated, that is, the value of the sysuptime object.
2.4.2 snmpv2c packets
Figure 5 snmpv2c Message format
Compared with SNMPv1, snmpv2c adds the GETBULK operation message. The basic operation type corresponding to the GETBULK operation is the getnext operation. By setting the non repeaters and Max repetitions parameters, You can efficiently obtain a large amount of management object data from the agent.
Snmpv2c modifies the Trap Message format. Snmpv2c trap pud adopts the SNMPv1 get/getnext/set PDU format, and uses sysuptime and snmptrapoid as variables in variable bindings to construct packets.
2.4.3 SNMPv3 packets
SNMPv3 modifies the message format, but the PDU format is consistent with that of snmpv2c. Figure 6 lists only the message formats.
Figure 6 SNMPv3 Message format
The authentication mechanism can be used for the entire SNMPv3 message and the engineid, contextname, and PDU message body are encrypted. Requestid, maxsize, flags, securitymodel, and securityparameters constitute the SNMPv3 message header.
The main fields in the message are defined as follows:
L requestid: the serial number of the request message.
L maxsize: the maximum number of bytes that a message sender can receive.
L flags: indicates the message identifier, which occupies one byte. Only the minimum three bits are valid. For example, 0x0 indicates no authentication or encryption, 0x1 indicates that authentication is not encrypted, and 0x3 indicates that authentication is encrypted, 0x4 indicates the report PDU flag.
L securitymodel: Security Model Value of the message. The value ranges from 0 ~ 3. 0 indicates any model, 1 indicates that the SNMPv1 security model is used, 2 indicates that the snmpv2c security model is used, and 3 indicates that the SNMPv3 security model is used.
L contextengineid: uniquely identifies an SNMP entity. This field is used to determine how a message is processed. For a message to be sent, this field is provided by the application when a message request is sent.
L contextname: uniquely identifies a specific context within the scope of the associated context engine.
Securityparameters also includes the following main fields:
L authoritativeengineid: The snmpengineid of the authoritative SNMP in message exchange. It is used to identify, authenticate, and encrypt SNMP entities. The value is the snmpengineid of the source in trap, response, and report, and the snmpengineid of the target in get, getnext, GETBULK, and set.
L authoritativeengineboots: snmpengineboots of the authoritative SNMP in message exchange. Indicates the number of times the SNMP engine has been initialized or reinitialized since the first configuration.
L authoritativeenginetime: The snmpenginetime of the authoritative SNMP in message exchange, used for Time Window judgment.
L Username: User name. The message indicates that the user is being exchanged. The NMs and Agent user names must be consistent.
L authenticationparameters: authentication parameter, the key required for authentication operation. If authentication is not used, it is null.
L privacyparameters: the encryption parameter used in the encryption operation, such as the value used to form the initial value IV in the des CBC algorithm. Null if encryption is not used.
2.5 SNMP principles 2.5.1 implementation mechanism of SNMPv1 and snmpv2c
The implementation mechanisms of SNMPv1 and snmpv2c are basically the same. snmpv2c enriches error codes and adds the GETBULK operation. The following describes the implementation mechanism of SNMPv1/snmpv2c by running get, getnext, and set operations in the SNMPv1 environment.
1. Get operation
NMS wants to obtain the sysname value of the MIB node of the managed device (the sysname object is in the allowed access view) and uses public as the readable group name. The procedure is as follows:
(1) NMS sends a GET request to the agent. The main field of the request message will be set to: the value of the version field is 1, and the value of the Community field is public, the name1 field value in variable bindings in PDU is sysname.0.
(2) The agent sends a Get Response to NMS, indicating whether the response is obtained successfully. If successful, the value of the value1 field in variable bindings in the response PDU is the name of the device (such as the Agent010-H3C); if the acquisition fails, enter the cause of the error in the error Status field, fill in the error location information in error index.
Figure 7 get operation
2. getnext operation
NMS wants to obtain the value of syslocation of the next node of the managed device MIB node sysname (both sysname and syslocation objects are allowed to access the view) and uses public as the readable group name. The procedure is as follows:
(1) NMS sends a getnext request to the agent. The main field of the request message will be set to: the value of the version field is 1, and the value of the Community field is public, the name1 field value in variable bindings in PDU is sysname.0.
(2) The agent sends a getnext response to NMS. If successful, the name1 field value in variable bindings in response PDU is syslocation.0, the next node of sysname.0, and the value of the value1 field is (such as Beijing China). If the acquisition fails, fill in the error cause in the error Status field, and fill in the error location information in the error index.
Figure 8 getnext operation
3. Set operation
NMS wants to set the sysname value of the MIB node of the managed device to device01 and use private as the writeable group name. The process is as follows:
(1) NMS sends a set request to the agent. The main field of the request message will be set to: the value of the version field is 1, and the value of the Community field is private, in PDU, The name1 field in variable bindings is sysname.0, And the value1 field is set to device01.
(2) Whether the set response sent by the agent to NMS is set successfully. If the setting succeeds, set the value of value1 in variable bindings of response PDU to the new device name (for example, device01). If the setting fails, set the error cause in the error Status field, fill in the error location information in error index.
Figure 9 set operation
4. Trap Operation
When the device needs to notify NMS of some exceptions, the agent will actively send a trap packet. For example, the agent sends a linkdown Trap Message to NMS when the network cable of a port of the device is pulled out. The value of the version field is 1, the value of the Community field is public, the enterprise field in the PDU is the value of sysobjectid.0 (for example, enterprises.25506), and the value of the Generic Trap field is linkdown, the variable bindings field carries information about the interface.
Figure 10 Trap Operation
2.5.2 SNMPv3 Implementation Mechanism
The implementation mechanism of each SNMPv3 operation is basically the same as that of SNMPv1 and snmpv2c. The main difference is that SNMPv3 adds new authentication, encryption, and decryption processes. The following describes how SNMPv3 implements the get operation using authentication and encryption methods. The process is as follows:
(1) NMS first sends a GET request without any authentication or encryption parameters. The flags field is set to 0x4, to obtain the values of contextengineid, contextname, authoritativeengineid, authoritativeengineboots, authoritativeenginetime, and other related parameters.
(2) The agent parses the message, sends the report message, and carries the values of the preceding parameters.
(3) NMS sends a GET request to the agent again. The main field of the request message will be set to: the value of the version field is 3, and (2) the obtained parameter value will be filled in the corresponding field, the name1 field value in variable bindings in PDU is sysname.0, and authenticationparameters is calculated based on the configured authentication algorithm, and privacyparameters is calculated using the configured encryption algorithm, and uses the configured encryption algorithm to encrypt the PDU data.
(4) The agent first authenticates the message and decrypts the PDU message after passing the authentication. After decryption is successful, get the value of the sysname.0 object, and enter the value of the value1 field in variable bindings in the response PDU as the device name (for example, agent010 ). If authentication, decryption, or parameter value retrieval fail, enter the error cause in the error Status field and the error location in the error index field. Encrypt the PDU, set contextengineid, contextname, authoritativeengineid, authoritativeengineboots, authoritativeenginetime, authenticationparameters, privacyparameters, and other parameters to send response packets.
Figure 11 SNMPv3 get operation
3 Technical Features of H3C implementation
H3C devices support SNMPv1, snmpv2c, and SNMPv3 versions. To be compatible with SNMPv3, SNMPv1 and snmpv2c versions can also configure groups, users, and views, you only need to set the group name parameter on the NMS side to the user name configured on the device. You can make multiple versions at the same time, but they must be consistent with the NMS version.
4 typical networking cases 4.1 networking Diagram
Figure 12 typical SNMP networking
4.2 Networking Environment
The device manufacturers in the network are different, and the device models are also different. You need to monitor and manage the operation of the network and devices.
5 Appendix 5.1 related agreements
L rfc1155
L rfc2578
L rfc2579
L rfc3411
L rfc3412
L rfc3414
L rfc3415
5.2 references
L "SNMP configuration" in "system volume"
L "SNMP Command" in "system volume"