SNMP Technology White Paper
SNMP Technology White Paper
1/16
Table of Contents
1 Overview......................................................................................................................................... 3 1.1 Background.......................................................................................................................... 3 1.2 Benefits ................................................................................................................................ 3 2 Technical Characteristics ............................................................................................................... 4 2.1 SNMP Network Structure..................................................................................................... 4 2.1.1 Introduction to NMS .................................................................................................. 4 2.1.2 Introduction to Agent ................................................................................................. 4 2.1.3 Introduction to MIB .................................................................................................... 5 2.2 SNMP Versions.................................................................................................................... 7 2.2.1 SNMPv1 .................................................................................................................... 7 2.2.2 SNMPv2c .................................................................................................................. 7 2.2.3 SNMPv3 .................................................................................................................... 7 2.3 SNMP Operations ................................................................................................................ 8 2.4 SNMP Messages ................................................................................................................. 9 2.4.1 SNMPv1 Message .................................................................................................... 9 2.4.2 SNMPv2c Message................................................................................................. 10 2.4.3 SNMPv3 Message .................................................................................................. 10 2.5 SNMP Mechanism ............................................................................................................. 12 2.5.1 SNMPv1 and SNMPv2c Mechanism ...................................................................... 12 2.5.2 SNMPv3 Mechanism............................................................................................... 14 3 H3Cs Implementation of SNMP................................................................................................... 15 4 Application Scenarios ................................................................................................................... 16 4.1 Network Diagram ............................................................................................................... 16 4.2 Networking Environment.................................................................................................... 16 5 References ................................................................................................................................... 16
2/16
1 Overview
1.1 Background
With the fast development of the Internet, two problems were introduced:
z
The increase of networks and network devices makes it hard for the administrators to monitor the status of all the devices in time, and find and correct network faults.
Network devices may be from different vendors. If each vendor provides an independent set of management interfaces (for example, command lines), network management may become more and more complicated.
To solve the above mentioned problems, a set of standards (SNMP) covering service, protocol and management information base (MIB) is introduced.
1.2 Benefits
SNMP is an application-layer protocol between an NMS and several agents. It defines the standardized management framework, common languages in
communication, security and access control mechanisms used in monitoring and managing devices in a network. The administrators can query device information, modify device parameters, monitor device status, and enable automatic detection of network faults and generation of reports by using SNMP. SNMP features the following advantages:
z z
TCP/IP-based standard protocol, with UDP as the transportation layer protocol. Automatic network management. The administrators can search and modify information, find and diagnose network problems, plan for network growth, and generate reports on network nodes.
Shielding of the physical differences between various devices, realizing automatic management of products from different vendors. Offering only the basic set of functions, SNMP makes the management tasks independent of both the physical features of the managed devices and the underlying networking technology. Thus, SNMP achieves effective management of devices from different vendors.
3/16
Combination of simple request-reply mode and active notification mode, timeout and retransmission mechanism.
Few packet types and simple packet format, which facilitates resolution and implementation.
Authentication and privacy mechanisms provided in SNMpv3, which enhances security by user based and view based access control function.
2 Technical Characteristics
2.1 SNMP Network Structure
An SNMP enabled network comprises Network Management Station (NMS), Agent and MIB.
4/16
2. MIB view
MIB view is a sub-set of MIB. You can bind a community name/username with a MIB view when configuring an agent, thus to control the MIB objects that NMS can access. You can configure the objects in the MIB view as excluded or included; excluded indicates that not all the nodes on the subtree are included in the current MIB view, and included indicates that the current MIB includes all the nodes on the subtree.
5/16
4. Subtree mask
A subtree OID used with a subtree mask defines a view subtree. A subtree mask is in hexadecimal format. After it is converted to binary bits, each bit corresponds to a node of the OID, where:
z
1 means full match, that is, the OID of the MIB object to be accessed must be identical to the subtree OID.
0 means wildcard match, that is, the OID of the MIB object to be accessed can be different from the subtree OID.
For example, provided the subtree mask 0xDB (11011011 in binary) and the subtree OID 1.3.6.1.6.1.2.1, their relationship is as shown in Figure 3 . The view determined by them includes all the nodes under the subtree whose OID is 1.3.*.1.6.*.2.1, where * represents any number.
6/16
Note:
z
If the number of bits in the subtree mask is greater than the number of nodes of the OID, the excessive bits of the subtree mask will be ignored during subtree mask-OID matching.
If the number of bits in the subtree mask is smaller than the number of nodes of the OID, the short bits of the subtree mask will be set to 1 during subtree maskOID matching.
If no subtree mask is specified, the default subtree mask (all ones) will be used for mask-OID matching.
2.2.1 SNMPv1
SNMPv1 is the first version of the SNMP protocol, providing a minimum network management function. The Structure of Management Information (SMI) and MIB of SNMPv1 are rather simple and have many security defects. SNMPv1 uses community name for authentication. A community name plays a similar role as a password and can be used to control access from NMS to Agent. SNMP packets with community names that do not pass the authentication on the device are simply discarded.
2.2.2 SNMPv2c
SNMPv2c also uses community name for authentication. Compatible with SNMPv1, it extends the functions of SNMPv1. SNMPv2c provides more operation modes such as GetBulk; it supports more data types such as Counter32; and it provides various error codes, thus being able to distinguish errors in more detail.
2.2.3 SNMPv3
By adopting User-based Security Model (USM) and View-based Access Control (VACM) technologies, SNMPv3 enhances security. USM offers authentication and privacy functions; while VACM controls users access to specific MIBs.
7/16
1. USM
USM introduces the concepts of username and group. You can set the authentication and privacy functions. The former is used to authenticate the validity of the sending end of the authentication packets, preventing access of illegal users; the latter is used to encrypt packets between the NMS and Agent, preventing the packets from being intercepted. USM ensures a more secure communication between SNMP NMS and SNMP Agent by authentication with privacy, authentication without privacy, or no authentication no privacy.
2. VACM
VACM defines the five elements: groups, security level, contexts, MIB views, and access policy. These five elements together control users access to management information. Only a user with access rights can manage the objects. You can define different groups on the same SNMP entity; these groups are bound with MIB views. In addition, you can define multiple users in one group. When a user accesses the management information, he can access only the objects defined by the corresponding MIB view.
Get operation: The Get operation is a request sent by the NMS to the agent to retrieve one or more values from the agent.
GetNext operation: The GetNext operation is a request sent by the NMS to retrieve the value of the next OID in the tree.
Set operation: The Set operation is a request sent by the NMS to the agent to set one or more values of the agent.
Response operation: The Response operation is a response sent by the agent to the NMS.
Trap operation: The Trap operation is an unsolicited response sent by the agent to notify the NMS of the events occurred.
The device sends the first four kinds of packets to UDP port 161, and the agent sends traps to UDP port 162. By using two different port numbers, a single device can act
Hangzhou H3C Technologies Co., Ltd. 8/16
The above figure indicates that an SNMP message is composed of Version, Community, and SNMP PDU. The following describes the main fields in an SNMP message:
z z
Version: SNMP version. Community: Community name, used for the authentication between an agent and the NMS. Community name falls into read and write. If NMS performs Get or GetNext operation, read community name is used for authentication; if NMS performs Set operation, write community name is used for authentication.
Request ID: It is used to match a response to a request. SNMP assigns a unique ID to each request.
Error status: It is used in a response to indicate the errors when the agent processes the request, including noError, tooBig, noSuchName, badValue, readOnly, and genErr.
9/16
Error index: Provides the information of the variables that caused the error when an error occurs.
z z z z
Variable bindings: It is composed of a variable name and value. enterprise: Type of the device that generates traps. Agent addr: Address of the device that generates traps. Generic trap: It includes coldStart, warmStart, linkDown, linkup,
Specific trap: Specific trap information of a vendor. Time stamp: The amount of time between the time when the SNMP entity sending this message reinitialized and the time when traps were generated, that is, the value of sysUpTime.
Compared with SNMPv1, GetBulk packets are added in SNMPv2c. GetBulk operation corresponds to GetNext operation. In a GetBulk operation, the setting of Non repeaters and Max repetitions parameters enables NMS to obtain data of many managed objects from an agent. In SNMPv2c, trap message format is different from that in SNMPv1. SNMPv2c trap PDU adopts the format of SNMPv1 Get/GetNext/Set PDU, and sysUpTime and snmpTrapOID are used as variables in variable bindings to create a packet.
10/16
The entire SNMPv3 message can be authenticated, and EngineID, ContextName, and PDU are encrypted. RequestID, MaxSize, Flags, SecurityModel and
SecurityParameters form the SNMPv3 message header. The following describes the main fields in an SNMPv3 message:
z z
RequestID: Request ID. MaxSize: The maximum size of the message that the sender of the message can contain and the maximum size of the message that the sender of the message can receive.
Flags: Message flag which occupies one byte. Only the lowest three bytes are valid. 0x0 indicates no authentication no privacy, 0x1 indicates authentication without privacy, 0x3 indicates authentication with privacy, and 0x4 indicates to send a report PDU.
SecurityModel: Message security model, in the range 0 to 3. 0 indicates any model, 1 indicates SNMPv1 security model, 2 indicates SNMPv2c security model, and 3 indicates SNMPv3 security model.
ContextEngineID: Uniquely identifies an SNMP entity. For a message received, this field decides how this message will be processed; for a message sent, this field is provided by the sender.
ContextName: Identifies a context. Each contextName must be unique within an SNMP entity.
AuthoritativeEngineID: Specifies the snmpEngineID of the authoritative SNMP engine involved in the exchange of the message, used for identification, authentication and encryption for an SNMP entity. This field refers to the source for a trap, response, or report, and to the destination for a Get, GetNext, GetBulk, or Set operation.
11/16
AuthoritativeEngineBoots: Specifies the snmpEngineBoots value at the authoritative SNMP engine involved in the exchange of the message. It indicates the number of times that this SNMP engine has initialized or reinitialized itself since its initial configuration.
AuthoritativeEngineTime:
Specifies
the
snmpEngineTime
value
at
the
authoritative SNMP engine involved in the exchange of the message. It is used for time window check.
z
UserName: Specifies the user (principal) on whose behalf the message is being exchanged. Usernames configured on NMS and Agent must be the same.
AuthenticationParameters: A key used in authentication calculation. If no authentication is performed, this field is null.
PrivacyParameters: A parameter used in privacy calculation. For example, the value used for generating the initialization vector (IV) in the DES CBC algorithm. If no privacy is adopted, this field is null.
1. Get operation
NMS wants to obtain the value of the node sysName of a managed device (the sysName object is in the accessible view), using public as the read community name: (1) NMS sends a Get request to Agent. The main fields in the request are set as follows: version to 1, community to public, name 1 in variable bindings in the PDU to sysName.0. (2) Agent sends a get response to NMS to tell NMS whether the values are successfully obtained. If succeeded, the field Value1 in Variable bindings in the response PDU is the device name (for example, Agent010-H3C); if failed, the reason for the error is filled into the Error status field, and error location is filled into the Error index field.
12/16
2. GetNext operation
NMS wants to obtain the value of the node sysLocation next to node sysName of a managed device (the sysName and sysLocation objects are in the accessible view), using public as the read community name: (1) NMS sends a GetNext request to Agent. The main fields in the request are set as follows: Version to 1, Community to public, and Name 1 in variable bindings in the PDU to sysName.0. (2) Agent sends NMS a GetNext response. If succeeded, the value of Name 1 in Variable bindings in the response PDU is the next node sysLocation.0 of node sysName.0, and the value of Value 1 is, for example, Beijing China; if failed, the reason for the error will be added to the Error status field, and position will be added to the Error index field.
3. Set operation
NMS wants to set the value of node sysName of the managed device to Device01, using private as the read community name: (1) NMS sends a Set request to Agent. The main fields in the request are set as follows: Version to 1, Community to private, Name 1 in variable bindings in the PDU to sysName.0, and Value1 to Device01.
13/16
(2)
Agent sends NMS a Set response. If succeeded, the value of Value1 in Variable bindings in the response PDU is the new name of the device (for example, Device01); if failed, the reason for the error will be added to the Error status field, and position will be added to the Error index field.
4. Trap operation
If abnormalities occur on a device, Agent will notify NMS by sending unsolicited traps. For example, if the cable on a port of the device is plugged out, Agent will send a linkDown trap to NMS. In the trap, the value of the Version field is 1, that of the Community field is public, that of the enterprise field is the value of sysObjectID.0 (for example, enterprises.25506), that of the Generic trap field is linkDown, and the Variable bindings field contains the interface information.
AuthoritativeEngineID, AuthoritativeEngineBoots, and AuthoritativeEngineTime. (2) Agent processes the request, and sends a report, which contains the values of the above parameters.
Hangzhou H3C Technologies Co., Ltd. 14/16
(3)
NMS sends a Get request again to Agent. In the request, the main fields are set as follows: Version to 3, the parameter values obtained in step 2 are added to the corresponding fields, the value of Name1 field in Variable bindings in the PDU to sysname.0, AuthenticationParameters is calculated by the configured authentication algorithm, PrivacyParameters is calculated by the configured encryption algorithm, and encrypt the PDU data using the configured privacy protocol.
(4)
Agent authenticates the Get request first. If the Get request passes the authentication, Agent will decrypt the PDU. If decryption succeeds, Agent will obtain the value of sysName.0, and fill the value of the field Value1 in Variable bindings in the response PDU with the device name (for example, Agent010). If authentication or decryption fails, or obtaining parameter values fails, the error reason will be filled into the Error status field, and the error location will be filled into the Error index field. At last, Agent will encrypt the PDU, set the parameters contextEngineID, contextName, AuthoritativeEngineID,
15/16
4 Application Scenarios
4.1 Network Diagram
NMS 1.1.1.1/24
IP network
H3C Agent 1.1.1.3/24
5 References
z z z z z z
RFC 1157 RFC 2578 RFC 2579 RFC 3411 RFC 3412 RFC 3415
Copyright 2008 Hangzhou H3C Technologies Co., Ltd. All rights reserved. No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of Hangzhou H3C Technologies Co., Ltd. The information in this document is subject to change without notice.
16/16