Structure and Identification of Management Information for TCP/IP-based Internets SNMP Traps
https://www.rfc-editor.org/rfc/rfc1157#section-3
3. The SNMP Architecture
Implicit in the SNMP architectural model is a collection of network
management stations and network elements. Network management
stations execute management applications which monitor and control
network elements. Network elements are devices such as hosts,
gateways, terminal servers, and the like, which have management
agents responsible for performing the network management functions
requested by the network management stations. The Simple Network
Management Protocol (SNMP) is used to communicate management
information between the network management stations and the agents in
the network elements.
3.2.6.3. Identification of Object Instances
The type-specific naming of object instances is defined below for a
number of classes of object types. Instances of an object type to
which none of the following naming conventions are applicable are
named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
said object type in the MIB definition.
For example, suppose one wanted to identify an instance of the
variable sysDescr The object class for sysDescr is:
iso org dod internet mgmt mib system sysDescr
1 3 6 1 2 1 1 1
Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
appended an instance sub-identifier of 0. That is, 1.3.6.1.2.1.1.1.0
identifies the one and only instance of sysDescr.
https://www.rfc-editor.org/rfc/rfc1155
Structure and Identification of Management Information for TCP/IP-based Internets
https://www.rfc-editor.org/rfc/rfc1156
Management Information Base for Network Management of TCP/IP-based internets
https://www.rfc-editor.org/rfc/rfc1157
A Simple Network Management Protocol (SNMP)
https://www.rfc-editor.org/rfc/rfc1158
Management Information Base for Network Management
of TCP/IP-based internets:
MIB-II
https://www.rfc-editor.org/rfc/rfc1155
Structure and Identification of Management Information for TCP/IP-based Internets
This memo specifies a Standard Protocol for the Internet community. Its status is "Recommended". TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification. The Internet Activities Board recommends that all IP and TCP implementations be network manageable. This implies implementation of the Internet MIB (RFC-1156) and at least one of the two recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095). It should be noted that, at this time, SNMP is a full Internet standard and CMOT is a draft standard. See also the Host and Gateway Requirements RFCs for more specific information on the applicability of this standard.
-v 1 TRAP-PARAMETERS:
enterprise-oid agent trap-type specific-type uptime [OID TYPE VALUE]...
or
-v 2 TRAP-PARAMETERS:
uptime trapoid [OID TYPE VALUE] ...
什么是SNMP？为什么需要SNMP？ - 华为 https://info.support.huawei.com/info-finder/encyclopedia/zh/SNMP.html
SNMP版本
SNMP有三种版本：SNMPv1，SNMPv2c和SNMPv3。
- SNMPv1：SNMP的第一个版本，它提供了一种监控和管理计算机网络的系统方法，它基于团体名认证，安全性较差，且返回报文的错误码也较少。它在RFC 1155和RFC 1157中定义。
- SNMPv2c：第二个版本SNMPv2c引入了GetBulk和Inform操作，支持更多的标准错误码信息，支持更多的数据类型。它在RFC 1901，RFC 1905和RFC 1906中定义。
- SNMPv3：鉴于SNMPv2c在安全性方面没有得到改善，IETF颁布了SNMPv3版本，提供了基于USM（User Security Module）的认证加密和基于VACM（View-based Access Control Model）的访问控制，是迄今为止最安全的版本。SNMPv3在RFC 1905，RFC 1906，RFC 2571，RFC 2572，RFC 2574和RFC 2575中定义。
SNMP端口
SNMP端口是SNMP通信端点，SNMP消息传输通过UDP进行，通常使用UDP端口号161/162。有时也使用传输层安全性（TLS）或数据报传输层安全性（DTLS）协议，端口使用情况如下表所示。
|
过程 |
协议 |
端口号 |
|---|---|---|
|
代理进程接收请求信息 |
UDP协议 |
161 |
|
NMS与代理进程之间的通信 |
UDP协议 |
161 |
|
NMS接收通知信息 |
UDP协议 |
162 |
|
代理进程生成通知信息 |
- |
任何可用的端口 |
|
接收请求信息 |
TLS/DTLS |
10161 |
|
接收通知信息 |
TLS/DTLS |
10162 |
SNMP如何工作？
一旦网络中启动SNMP协议，NMS作为整个网络的网管中心，会对设备进行管理。每个被管理设备都包含驻留在设备上的Agent、多个被管对象和MIB，NMS通过与运行在被管理设备上的Agent交互，由Agent通过对设备端的MIB的操作，完成NMS的指令。SNMP的工作原理是将协议数据单元（也称为SNMP GET请求）发送到响应SNMP的网络设备。用户通过网络监控工具可以跟踪所有通信过程，并从SNMP获取数据。
SNMP规定了几个操作类型来完成各组件之间的信息交换，如下表所示：
|
操作类型 |
描述 |
备注 |
|---|---|---|
|
Get |
Get操作可以从Agent中提取一个或多个参数值。 |
- |
|
GetNext |
GetNext操作可以从Agent中按照字典序提取下一个参数值。 |
- |
|
Set |
Set操作可以设置Agent的一个或多个参数值。 |
- |
|
Response |
Response操作可以返回一个或多个参数值。这个操作是由Agent发出的，它是GetRequest、GetNextRequest、SetRequest和GetBulkRequest四种操作的响应操作。Agent接收到来自NMS的Get/Set指令后，通过MIB完成相应的查询/修改操作，然后利用Response操作将信息回应给NMS。 |
- |
|
Trap |
Trap信息是Agent主动向NMS发出的信息，告知管理进程设备端出现的情况。 |
- |
|
GetBulk |
GetBulk操作实现了NMS对被管理设备的信息群查询。 |
SNMPv1版本不支持GetBulk操作 |
|
Inform |
InformRequest也是被管理设备向NMS主动发送告警。与Trap告警不同的是，被管理设备发送Inform告警后，需要NMS回复InformResponse来进行确认。 |
SNMPv1版本不支持Inform操作 |
SNMP Traps
SNMP Traps是指SNMP Agent主动将设备产生的告警或事件上报给NMS，以便网络管理员及时了解设备当前运行的状态。
SNMP Agent上报SNMP Traps有两种方式：Trap和Inform。Trap和Inform的区别在于，SNMP Agent通过Inform向NMS发送告警或事件后，NMS需要回复InformResponse进行确认。
Trap操作工作原理
Trap不属于NMS对被管理设备的基本操作，它是被管理设备的自发行为。当被管理设备达到告警的触发条件时，会通过SNMP Agent向NMS发送Trap消息，告知设备侧出现的异常情况，便于网络管理人员及时处理。例如被管理设备热启动后，SNMP Agent会向NMS发送warmStart的Trap。
这种Trap信息是受限制的。只有在设备端的模块达到模块预定义的告警触发条件时，SNMP Agent才会向管理进程报告。这种方法的好处是仅在严重事件发生时才发送Trap信息，减少报文交互产生的流量。
Inform操作工作原理
Inform操作也是被管理设备向NMS主动发送告警。与Trap告警不同的是，被管理设备发送Inform告警后，需要NMS进行接收确认。如果被管理设备没有收到确认信息则：
- 将告警或事件暂时保存在Inform缓存中。
- 重复发送该告警或事件，直到NMS确认收到该告警或者发送次数达到最大重传次数。
- 被管设备上会生成相应的告警或事件日志。
NetEngine AR 产品文档 https://support.huawei.com/hedex/hdx.do?docid=EDOC1100087046&id=ZH-CN_TASK_0177878325&lang=zh
版本演进
1990年5月，RFC 1157定义了SNMP的第一个版本SNMPv1。RFC 1157提供了一种监控和管理计算机网络的系统方法。SNMPv1基于团体名认证，安全性较差，且返回报文的错误码也较少。
1996年，IETF颁布了RFC 1901，定义了SNMP的第二个版本SNMPv2c。SNMPv2c中引入了GetBulk和Inform操作，支持更多的标准错误码信息，支持更多的数据类型（Counter64、Counter32）。
鉴于SNMPv2c在安全性方面没有得到改善，IETF又颁布了SNMPv3的版本，提供了基于USM（User Security Module）的认证加密和基于VACM（View-based Access Control Model）的访问控制。
发送trap
-
用于发送trap的命令：
snmptrap -v 1 -c public 127.0.0.1 '.1.3.6.1.6.3.1.1.5.3' '0.0.0.0' 6 33 '55' .1.3.6.1.6.3.1.1.5.3 s "teststring000" -
接收到的trap:
15:48:18 2011/07/26 .1.3.6.1.6.3.1.1.5.3.0.33 Normal "General event" localhost - ZBXTRAP 127.0.0.1 127.0.0.1 -
测试监控项的值:
15:48:18 2011/07/26 .1.3.6.1.6.3.1.1.5.3.0.33 Normal "General event" localhost - 127.0.0.1
Trap Handlers
The snmptrapd utility also has the ability to execute other programs on the reception of a trap. This is controlled by the traphandle directive, with the syntax
traphandle OID command
Notice, that this only takes an OID to determine which trap (or notification) is received. This means that SNMPv1 traps, which have a trap type and specific type, need to be represented in SNMPv2 format, which is described in RFC 2089.
Matching SNMPv1 OIDs
SNMPv1 traps fall into two broad categories: generic and enterprise specific. Generic traps use trap types 0 through 5, and do not use the specific type. To match a generic trap, the traphandle OID should be the SNMPv2-MIB::snmpTraps OID, with an additional final OID of the trap type + 1. For example, to match linkDown traps (trap type 2), the correct OID would be "1.3.6.1.6.3.1.1.5.3" (or SNMPv2-MIB::snmpTraps.3, which is also IF-MIB::linkDown).
SNMPv2-MIB::snmpTraps 1.3.6.1.6.3.1.1.5 SNMPv2-MIB::coldStart 1.3.6.1.6.3.1.1.5.1 SNMPv2-MIB::warmStart 1.3.6.1.6.3.1.1.5.2 IF-MIB::linkDown 1.3.6.1.6.3.1.1.5.3 IF-MIB::linkUp 1.3.6.1.6.3.1.1.5.4 SNMPv2-MIB::authenticationFailure 1.3.6.1.6.3.1.1.5.5
When the trap type is 6, the trap is an enterprise specific trap. When matching these traps, the traphandle OID is constructed using the enterprise OID and specific type specified in the trap. Earlier in the tutorial, we sent a SNMPv1 enterprise specific trap with an enterprise OID of UCD-TRAP-TEST-MIB::demotraps, a trap type of 6 and a specific type of 17. To match this trap type, the traphandle OID should be the enterprise OID, plus 0, plus the specific type. So the correct OID would be ".1.3.6.1.4.1.2021.13.990.0.17" (or UCD-TRAP-TEST-MIB::demoTrap).
Matching SNMPv2 OIDs
SNMPv2 traps and informs are much easier, because they include the correct OID in the SNMPv2-MIB::snmpTrapOID.0 variable in the trap.
Example handler script
The command specifies a command to be executed by snmptrapd upon reception by the command. This command is executed with the data of the trap as its standard input. The first line is the host name, the second the IP address of the trap sender, and the following lines consists of an OID VALUE pair with the data from the received trap.
A simple shell script to be called from snmptrapd is the following:
#!/bin/sh
read host
read ip
vars=
while read oid val
do
if [ "$vars" = "" ]
then
vars="$oid = $val"
else
vars="$vars, $oid = $val"
fi
done
echo trap: $1 $host $ip $vars
Now, given the following sample snmptrapd.conf file,
# the generic traps traphandle SNMPv2-MIB::coldStart /home/nba/bin/traps cold traphandle SNMPv2-MIB::warmStart /home/nba/bin/traps warm traphandle IF-MIB::linkDown /home/nba/bin/traps down traphandle IF-MIB::linkUp /home/nba/bin/traps up traphandle SNMPv2-MIB::authenticationFailure /home/nba/bin/traps auth # this one is deprecated traphandle .1.3.6.1.6.3.1.1.5.6 /home/nba/bin/traps egp-neighbor-loss # enterprise specific traps traphandle UCD-TRAP-TEST-MIB::demoTrap /home/nba/bin/traps demo-trap traphandle UCD-NOTIFICATION-TEST-MIB::demoNotif /home/nba/bin/traps demo-notif
The following snmptrap invocation, to issue a generic Link down trap (OID 1.3.6.1.6.3.1.1.5.3),
% snmptrap -v 1 -c public localhost TRAP-TEST-MIB::demotraps localhost 2 0 "" \
IF-MIB::ifIndex i 1
results in the following output from snmptrapd:
1999-11-13 12:46:49 localhost [127.0.0.1] TRAP-TEST-MIB::traps:
Link Down Trap (0) Uptime: 1 day, 18:54:46.27
IF-MIB::ifIndex.0 = 1
and the following output from the handler:
trap: down localhost 127.0.0.1 SNMPv2-MIB::sysUpTime = 1:18:54:46.27, SNMPv2-MIB::snmpTrapOID = IF-MIB::linkDown, IF-MIB::ifIndex.0 = 1, SNMPv2-MIB::snmpTrapEnterprise = TRAP-TEST-MIB::traps
and issuing our enterprise specific trap (.1.3.6.1.4.1.2021.13.990.0.17) gives this output from our handler:
trap: demoTrap localhost 127.0.0.1 SNMPv2-MIB::sysUpTime = 1:19:00:48.01, SNMPv2-MIB::snmpTrapOID = UCD-TRAP-TEST-MIB::demoTrap, SNMPv2-MIB::sysLocation.0 = "just here", SNMPv2-MIB::snmpTrapEnterprise = UCD-TRAP-TEST-MIB::traps
and finally our enterprise specific notification:
trap: demoNotif localhost 127.0.0.1 SNMPv2-MIB::sysUpTime.0 = 1:19:02:06.33, SNMPv2-MIB::snmpTrapOID.0 = UCD-NOTIFICATION-TEST-MIB::demoNotif, SNMPv2-MIB::sysLocation.0 = "just here"
rfc1157 https://datatracker.ietf.org/doc/html/rfc1157/#section-4.1.6
4.1.6. The Trap-PDU The form of the Trap-PDU is: Trap-PDU ::= [4] IMPLICIT SEQUENCE { enterprise -- type of object generating -- trap, see sysObjectID in [5] OBJECT IDENTIFIER, agent-addr -- address of object generating NetworkAddress, -- trap generic-trap -- generic trap type INTEGER { coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4), egpNeighborLoss(5), enterpriseSpecific(6) }, specific-trap -- specific code, present even INTEGER, -- if generic-trap is not -- enterpriseSpecific time-stamp -- time elapsed between the last TimeTicks, -- (re)initialization of the network -- entity and the generation of the trap variable-bindings -- "interesting" information VarBindList } The Trap-PDU is generated by a protocol entity only at the request of the SNMP application entity. The means by which an SNMP application entity selects the destination addresses of the SNMP application entities is implementation-specific. Upon receipt of the Trap-PDU, the receiving protocol entity presents its contents to its SNMP application entity. Case, Fedor, Schoffstall, & Davin [Page 27]
RFC 1157 SNMP May 1990 The significance of the variable-bindings component of the Trap-PDU is implementation-specific. Interpretations of the value of the generic-trap field are: 4.1.6.1. The coldStart Trap A coldStart(0) trap signifies that the sending protocol entity is reinitializing itself such that the agent's configuration or the protocol entity implementation may be altered. 4.1.6.2. The warmStart Trap A warmStart(1) trap signifies that the sending protocol entity is reinitializing itself such that neither the agent configuration nor the protocol entity implementation is altered. 4.1.6.3. The linkDown Trap A linkDown(2) trap signifies that the sending protocol entity recognizes a failure in one of the communication links represented in the agent's configuration. The Trap-PDU of type linkDown contains as the first element of its variable-bindings, the name and value of the ifIndex instance for the affected interface. 4.1.6.4. The linkUp Trap A linkUp(3) trap signifies that the sending protocol entity recognizes that one of the communication links represented in the agent's configuration has come up. The Trap-PDU of type linkUp contains as the first element of its variable-bindings, the name and value of the ifIndex instance for the affected interface. 4.1.6.5. The authenticationFailure Trap An authenticationFailure(4) trap signifies that the sending protocol entity is the addressee of a protocol message that is not properly authenticated. While implementations of the SNMP must be capable of generating this trap, they must also be capable of suppressing the emission of such traps via an implementation-specific mechanism. 4.1.6.6. The egpNeighborLoss Trap An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom Case, Fedor, Schoffstall, & Davin [Page 28]
RFC 1157 SNMP May 1990 the sending protocol entity was an EGP peer has been marked down and the peer relationship no longer obtains. The Trap-PDU of type egpNeighborLoss contains as the first element of its variable-bindings, the name and value of the egpNeighAddr instance for the affected neighbor. 4.1.6.7. The enterpriseSpecific Trap A enterpriseSpecific(6) trap signifies that the sending protocol entity recognizes that some enterprise-specific event has occurred. The specific-trap field identifies the particular trap which occurred.
rfc1907 https://datatracker.ietf.org/doc/html/rfc1907
Understanding Simple Network Management Protocol (SNMP) Traps - Cisco https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/7244-snmp-trap.html
Introduction
This document provides an introduction to SNMP traps. It shows how SNMP traps are used and the role they play in the management of a data network.
SNMP traps enable an agent to notify the management station of significant events by way of an unsolicited SNMP message.
In this diagram, the setup on the left shows a network management system that polls information and gets a response. The setup on the right shows an agent that sends an unsolicited or asynchronous trap to the network management system (NMS).
Use SNMP Traps
SNMPv1 (Simple Network Management Protocol) and SNMPv2c, along with the associated Management Information Base (MIB), encourage trap-directed notification.
The idea behind trap-directed notification is that if a manager is responsible for a large number of devices, and each device has a large number of objects, it is impractical for the manager to poll or request information from every object on every device. The solution is for each agent on the managed device to notify the manager without solicitation. It does this by sending a message known as a trap of the event.
After the manager receives the event, the manager displays it and can choose to take an action based on the event. For instance, the manager can poll the agent directly, or poll other associated device agents to get a better understanding of the event.
Trap-directed notification can result in substantial savings of network and agent resources by eliminating the need for frivolous SNMP requests. However, it is not possible to totally eliminate SNMP polling. SNMP requests are required for discovery and topology changes. In addition, a managed device agent can not send a trap, if the device has had a catastrophic outage.
SNMPv1 traps are defined in RFC 1157, with these fields:
-
Enterprise—Identifies the type of managed object that generates the trap.
-
Agent address—Provides the address of the managed object that generates the trap.
-
Generic trap type—Indicates one of a number of generic trap types.
-
Specific trap code—Indicates one of a number of specific trap codes.
-
Time stamp—Provides the amount of time that has elapsed between the last network reinitialization and generation of the trap.
-
Variable bindings—The data field of the trap that contains PDU. Each variable binding associates a particular MIB object instance with its current value.
Standard generic traps are: coldStart, warmStart, linkDown, linkUp, authenticationFailure, egpNeighborLoss. For generic SNMPv1 traps, Enterprise field contains value of sysObjectID 
of the device that sends trap. For vendor specific traps, Generic trap type field is set to enterpriseSpecific(6). Cisco implemented its own specific traps in a non-conventional way. Instead of having the trap Enterprise field still the sysObjectID and having the Specific trap code to identify all specific traps supported by all Cisco devices, Cisco implemented trap identification using various trap Enterprise and Specific trap code fields. You can see the actual values from the SNMP Object Navigator . Also, Cisco redefined some generic traps in CISCO-GENERAL-TRAPS MIB with the addition of more bound variables. For these traps, Generic trap type is kept the same and not set to enterpriseSpecific(6).
In SNMPv2c trap is defined as NOTIFICATION and formatted differently compared to SNMPv1. It has these parameters:
-
sysUpTime—This is the same as Time stamp in SNMPv1 trap.
-
snmpTrapOID
—Trap identification field. For generic traps, values are defined in RFC 1907, for vendor specific traps snmpTrapOID is essentially a concatenation of the SNMPv1 Enterprise parameter and two additional sub-identifiers, '0', and the SNMPv1 Specific trap code parameter. -
VarBindList—This is a list of variable-bindings.
In order for a management system to understand a trap sent to it by an agent, the management system must know what the object identifier (OID) defines. Therefore, it must have the MIB for that trap loaded. This provides the correct OID information so that the network management system can understand the traps sent to it.
For traps that are supported by Cisco devices in specific MIBs, refer to the Cisco SNMP Object Navigator . This lists the traps available for a specific MIB. In order to receive one of these traps, your Cisco IOS® Software Release must support the MIB listed. In order to find out which MIBs are supported on your Cisco device, visit www.cisco.com/go/mibs . The MIB must be loaded into your network management system. This is commonly referred to as compiling. See your Network Management System (for instance, HP OpenView or NetView) user guide about MIB compiling on your NMS platform. Also refer to SNMP: Frequently Asked Questions About MIBs and MIB Compilers and Loading MIBs.
Additionally, a device does not send a trap to a network management system unless it is configured to do so. A device must know that it should send a trap. The trap destination is usually defined by an IP address, but can be a host name, if the device is set up to query a Domain Name System (DNS) server. In later versions of Cisco IOS software, device administrators can choose which traps they would like send. For information on how to configure a Cisco device for SNMP, and how to send traps, refer to correspondent device configuration guides and Basic Dial NMS Implementation Guide, Cisco IOS SNMP Traps Supported and How to Configure Them and How-To Support and Configure Cisco CatalystOS SNMP Traps.
Note: The manager typically receives SNMP notifications (TRAPs and INFORMs) on UDP port number 162.
Examples of Traps Sent by Cisco IOS
This section contains some examples of traps sent by Cisco IOS, taken with debug snmp packet.
SNMPv1 generic trap, redefined by Cisco:
Nov 21 07:44:17: %LINK-3-UPDOWN: Interface Loopback1, changed state to up 4d23h: SNMP: Queuing packet to 172.17.246.162 4d23h: SNMP: V1 Trap, ent products.45, addr 172.17.246.9, gentrap 3, spectrap 0 ifEntry.1.23 = 23 ifEntry.2.23 = Loopback1 ifEntry.3.23 = 24 lifEntry.20.23 = up
This output shows the Cisco redefined linkUp trap from CISCO-GENERAL-TRAPS MIB with four bound variables. It has these fields:
-
Enterprise = products.45 (sysObjectID
of the device sending trap, in this example, it is c7507 router) -
Generic trap type = 3 (linkUp)
-
Specific trap code = 0
SNMPv1 Cisco specific trap:
4d23h: SNMP: Queuing packet to 172.17.246.162 4d23h: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 172.17.246.9, gentrap 6, spectrap 1 clogHistoryEntry.2.954 = LINK clogHistoryEntry.3.954 = 4 clogHistoryEntry.4.954 = UPDOWN clogHistoryEntry.5.954 = Interface Loopback1, changed state to up clogHistoryEntry.6.954 = 43021184
This output shows the Cisco specific clogMessageGenerated trap from CISCO-SYSLOG-MIB with five bound variables. It has these fields:
-
Enterprise = Enterprise value of clogMessageGenerated trap
-
Generic trap type = 6 (enterpriseSpecific)
-
Specific trap code = 1 (specific trap code of clogMessageGenerated)
SNMPv2c Cisco specific trap:
4d23h: SNMP: Queuing packet to 172.17.246.162 4d23h: SNMP: V2 Trap, reqid 2, errstat 0, erridx 0 sysUpTime.0 = 43053404 snmpTrapOID.0 = clogHistoryEntry.2.958 = SYS clogHistoryEntry.3.958 = 6 clogHistoryEntry.4.958 = CONFIG_I clogHistoryEntry.5.958 = Configured from console by vty0 (10.10.10.10) clogHistoryEntry.6.958 = 43053403
This output shows the Cisco specific ciscoConfigManEvent SNMPv2c notification from CISCO-CONFIG-MAN-MIB with three bound variables:
This trap can be used if there has been any changes done to the device's configuration. The values of last two components determine if a show command was issued or if the configuration was touched.
6506E#term mon 6506E#debug snmp packet SNMP packet debugging is on 6506E#sh run Building configuration... ... 6506E# 19:24:18: SNMP: Queuing packet to 10.198.28.80 19:24:18: SNMP: V2 Trap, reqid 2, errstat 0, erridx 0 sysUpTime.0 = 6981747 snmpTrapOID.0 = ciscoConfigManMIB.2.0.1 ccmHistoryEventEntry.3.100 = 1 !--- 1 -> commandLine. Executed via CLI. ccmHistoryEventEntry.4.100 = 3 !--- 3 -> running ccmHistoryEventEntry.5.100 = 2 !--- 2 -> commandSource. Show command was executed.
6506E#term mon 6506E#debug snmp packet SNMP packet debugging is on 6506E#conf t Enter configuration commands, one per line. End with CNTL/Z. 6506E(config)#exit 22:57:37: SNMP: Queuing packet to 10.198.28.80 22:57:37: SNMP: V2 Trap, reqid 2, errstat 0, erridx 0 sysUpTime.0 = 8261709 snmpTrapOID.0 = ciscoConfigManMIB.2.0.1 ccmHistoryEventEntry.3.108 = 1 !--- 1 -> commandLine. Executed via CLI. ccmHistoryEventEntry.4.108 = 2 !--- 2 -> commandSource ccmHistoryEventEntry.5.108 = 3 !--- 3 -> running. Change was destined to the running configuration.
IP数据报
UDP数据报
SNMP报文
公共SNMP首部get/set首部get/set变量部分
IP首部UDP首部"版本
（0）"共同体"PDU类型
（0-3）"请求标识"差错状态
（0-5）"差错索引名称值名称值...
"PDU类型
（4）"企业代理地址"trap类型
（0-6）"特定代码时间戳名称值...
trap首部有意义的变量
SNMP报文的格式
PDU类型名称差错状态名称描述
0get-request0noError没有进程
1get-nextrequest1tooBig代理进程无法把响应放在一个SNMP消息中发送
2get-response2noSuchName操作一个不存在的变量
3set-request3badValueset操作的值或语义有错误
4trap4readOnly管理进程试图修改一个只读变量
SNMP报文中的PDU类型5genErr其他错误
SNMP差错状态的值
trap类型名称描述
0clodStart代理进程对自己初始化
1warmStart代理进程对自己重新初始化
2linkDown"一个接口从影工作状态变为故障状态，
报文中的第一个变量标识次接口"
3linkUp"一个接口从影故障状态变为工作状态，
报文中的第一个变量标识次接口"
4authenticationFailure从SNMP管理进程收到无效共同体的报文
5egpNeighborLoss一个FGP邻站已变为故障状态。报文中的第一个变量包含此邻站的IP地址
6enterpriseSpecific在这个特定的代码段中查找trap信息
trap的类型
第25章 SNMP:简单网络管理协议_《TCP/IP详解 卷1：协议》_即时通讯网(52im.net) _即时通讯开发者社区! http://docs.52im.net/extend/docs/book/tcpip/vol1/25/
What is SNMP? | SNMP Tutorial – Protocol – Monitoring – Agent https://www.manageengine.com/network-monitoring/what-is-snmp.html
SNMP tutorial
This tutorial is an effort to explain in brief about
- What is SNMP?
- What are the basic SNMP components and their functionalities?
- SNMP basic commands
- How a typical SNMP communication happens?
- SNMP versions (SNMP v1, v2 and v3)
What is SNMP?
Simple Network Management Protocol (SNMP) is an application–layer protocol defined by the Internet Architecture Board (IAB) in RFC1157 for exchanging management information between network devices. It is a part of Transmission Control Protocol⁄Internet Protocol (TCP⁄IP) protocol suite.
SNMP is one of the widely accepted network protocols to manage and monitor network elements. Most of the professional–grade network elements come with bundled SNMP agent. These agents have to be enabled and configured to communicate with the network monitoring tools or network management system (NMS).
SNMP basic components and their functionalities
- SNMP Manager
- Managed devices
- SNMP agent
- Management Information Database Otherwise called as Management Information Base (MIB)
SNMP Manager:
A manager or management system is a separate entity that is responsible to communicate with the SNMP agent implemented network devices. This is typically a computer that is used to run one or more network management systems.
- Queries agents
- Gets responses from agents
- Sets variables in agents
- Acknowledges asynchronous events from agents
Managed Devices:
A managed device or the network element is a part of the network that requires some form of monitoring and management e.g. routers, switches, servers, workstations, printers, UPSs, etc...
SNMP Agent:
The agent is a program that is packaged within the network element. Enabling the agent allows it to collect the management information database from the device locally and makes it available to the SNMP manager, when it is queried for. These agents could be standard (e.g. Net-SNMP) or specific to a vendor (e.g. HP insight agent)
- Collects management information about its local environment
- Stores and retrieves management information as defined in the MIB.
- Signals an event to the manager.
- Acts as a proxy for some non–SNMP manageable network node.
Management Information database or Management Information Base (MIB)
Every SNMP agent maintains an information database describing the managed device parameters. The SNMP manager uses this database to request the agent for specific information and further translates the information as needed for the Network Management System (NMS). This commonly shared database between the Agent and the Manager is called Management Information Base (MIB).
Typically these MIB contains standard set of statistical and control values defined for hardware nodes on a network. SNMP also allows the extension of these standard values with values specific to a particular agent through the use of private MIBs.
In short, MIB files are the set of questions that a SNMP Manager can ask the agent. Agent collects these data locally and stores it, as defined in the MIB. So, the SNMP Manager should be aware of these standard and private questions for every type of agent.
SNMP MIB Browser and SNMP Walk Tool
ManageEngine's Suite of Free Tools includes a SNMP MIB Browser which helps to Load/unload MIBs and fetch MIB data of SNMP(v1, v2c, v3) agents. SNMP MIB Browser is a complete tool for monitoring SNMP enabled devices and servers. You can load, view multiple MIB modules and perform GET, GETNEXT and SET SNMP operations. This tool is easy to use and allows you to view, configure and parse SNMP traps. You can also perform SNMP operations from Windows and Linux devices.
MIB structure and Object Identifier (Object ID or OID)
Management Information Base (MIB) is a collection of Information for managing network element. The MIBs comprises of managed objects identified by the name Object Identifier (Object ID or OID).
Each Identifier is unique and denotes specific characteristics of a managed device. When queried for, the return value of each identifier could be different e.g. Text, Number, Counter, etc...
There are two types of Managed Object or Object ID: Scalar and Tabular. They could be better understandable with an example
Scalar: Device’s vendor name, the result can be only one. (As definition says: "Scalar Object define a single object instance")
Tabular: CPU utilization of a Quad Processor, this would give me a result for each CPU separately, means there will be 4 results for that particular Object ID. (As definition says: "Tabular object defines multiple related object instance that are grouped together in MIB tables")
Every Object ID is organized hierarchically in MIB. The MIB hierarchy can be represented in a tree structure with individual variable identifier.
A typical object ID will be a dotted list of integers. For example, the OID in RFC1213 for "sysDescr" is .1.3.6.1.2.1.1.1
Basic commands of SNMP
The simplicity in information exchange has made the SNMP as widely accepted protocol. The main reason being concise set of commands, here are they listed below:
- GET: The GET operation is a request sent by the manager to the managed device. It is performed to retrieve one or more values from the managed device.
- GET NEXT: This operation is similar to the GET. The significant difference is that the GET NEXT operation retrieves the value of the next OID in the MIB tree.
- GET BULK: The GETBULK operation is used to retrieve voluminous data from large MIB table.
- SET: This operation is used by the managers to modify or assign the value of the Managed device.
- TRAPS: Unlike the above commands which are initiated from the SNMP Manager, TRAPS are initiated by the Agents. It is a signal to the SNMP Manager by the Agent on the occurrence of an event.
- INFORM: This command is similar to the TRAP initiated by the Agent, additionally INFORM includes confirmation from the SNMP manager on receiving the message.
- RESPONSE: It is the command used to carry back the value(s) or signal of actions directed by the SNMP Manager.
SNMP Traps:
Typical SNMP communication
Being the part of TCP⁄ IP protocol suite, the SNMP messages are wrapped as User Datagram Protocol (UDP) and intern wrapped and transmitted in the Internet Protocol. The following diagram will illustrate the four–layer model developed by Department of Defense (DoD).
GET⁄ GET NEXT⁄ GET BULK⁄ SET
TRAP
INFORM
SNMP versions
Since the inception SNMP, has gone through significant upgrades. However SNMP Protocol v1 and v2c are the most implemented versions of SNMP. Support to SNMP Protocol v3 has recently started catching up as it is more secured when compare to its older versions, but still it has not reached considerable market share.
SNMPv1:
This is the first version of SNMP protocol, which is defined in RFCs 1155 and 1157
SNMPv2c:
This is the revised protocol, which includes enhancements of SNMPv1 in the areas of protocol packet types, transport mappings, MIB structure elements but using the existing SNMPv1 administration structure ("community based" and hence SNMPv2c). It is defined in RFC 1901, RFC 1905, RFC 1906, RFC 2578.
SNMPv3:
SNMPv3 defines the secure version of the SNMP. SNMPv3 protocol also facilitates remote network monitoring configuration of the SNMP entities. It is defined by RFC 1905, RFC 1906, RFC 3411, RFC 3412, RFC 3414, RFC 3415.
Though each version had matured towards rich functionalities, additional emphasis was given to the security aspect on each upgrade. Here is a small clip on each editions security aspect.
| SNMP v1 | Community–based security |
| SNMP v2c | Community–based security |
| SNMP v2u | User–based security |
| SNMP v2 | Party–based security |
| SNMP v3 | User–based security |
Other useful links
- How to Install and configure Windows device for SNMP?
- How to Install and configure Linux device for SNMP?
- How to Install and configure Solaris device for SNMP?
- How to configure SNMP Agents?
- How to process SNMP Traps?
简单网络管理协议_百度百科 https://baike.baidu.com/item/简单网络管理协议/2986113
- 中文名
- 简单网络管理协议
- 外文名
- SNMP
- 作 用
- IP网络管理网络节点
- 网络层次
- 应用层
-
SMI定义了SNMP框架所用信息的组织和标识，为MIB定义管理对象及使用管理对象提供模板。
-
MIB定义了可以通过SNMP进行访问的管理对象的集合。
-
SNMP协议是应用层协议，定义了网络管理者如何对代理进程的MIB对象进行读写操作。
-
网络管理系统（NMS，Network-management systems）
-
被管理的设备（managed device）
-
代理者（agent）
-
自动化网络管理。网络管理员可以利用SNMP平台在网络上的节点检索信息、修改信息、发现故障、完成故障诊断、进行容量规划和生成报告。
-
屏蔽不同设备的物理差异，实现对不同厂商产品的自动化管理。SNMP只提供最基本的功能集，使得管理任务与被管设备的物理特性和实际网络类型相对独立，从而实现对不同厂商设备的管理。
-
简单的请求—应答方式和主动通告方式相结合，并有超时和重传机制。
-
报文种类少，报文格式简单，方便解析，易于实现。
-
SNMPv3版本提供了认证和加密安全机制，以及基于用户和视图的访问控制功能，增强了安全性。
主代理
子代理
管理站
第一版
第二版
第三版
什么是SNMP - 华为 https://support.huawei.com/enterprise/zh/doc/EDOC1100087025
技术支持 
文档中心 交换机 数据中心交换机 CloudEngine 58&68&78&88&98 配置调测 技术指导
什么是SNMP？
简介
简单网络管理协议SNMP（Simple Network Management Protocol）用于网络设备的管理。网络设备种类多种多样，不同设备厂商提供的管理接口（如命令行接口）各不相同，这使得网络管理变得愈发复杂。为解决这一问题，SNMP应运而生。SNMP作为广泛应用于TCP/IP网络的网络管理标准协议，提供了统一的接口，从而实现了不同种类和厂商的网络设备之间的统一管理。
SNMP协议分为三个版本：SNMPv1、SNMPv2c和SNMPv3。
- SNMPv1是SNMP协议的最初版本，提供最小限度的网络管理功能。SNMPv1基于团体名认证，安全性较差，且返回报文的错误码也较少。
- SNMPv2c也采用团体名认证。在SNMPv1版本的基础上引入了GetBulk和Inform操作，支持更多的标准错误码信息，支持更多的数据类型（Counter64、Counter32）。
- SNMPv3主要在安全性方面进行了增强，提供了基于USM（User Security Module）的认证加密和基于VACM（View-based Access Control Model）的访问控制。SNMPv3版本支持的操作和SNMPv2c版本支持的操作一样。
SNMP系统组成
SNMP系统由网络管理系统NMS（Network Management System）、SNMP Agent、被管对象Management object和管理信息库MIB（Management Information Base）四部分组成。NMS作为整个网络的网管中心，对设备进行管理。
每个被管理设备中都包含驻留在设备上的SNMP Agent进程、MIB和多个被管对象。NMS通过与运行在被管理设备上的SNMP Agent交互，由SNMP Agent通过对设备端的MIB进行操作，完成NMS的指令。
NMS
NMS是网络中的管理者，是一个采用SNMP协议对网络设备进行管理/监视的系统，运行在NMS服务器上。
-
NMS可以向设备上的SNMP Agent发出请求，查询或修改一个或多个具体的参数值。
-
NMS可以接收设备上的SNMP Agent主动发送的SNMP Traps，以获知被管理设备当前的状态。
SNMP Agent
-
SNMP Agent接收到NMS的请求信息后，通过MIB表完成相应指令后，并把操作结果响应给NMS。
-
当设备发生故障或者其它事件时，设备会通过SNMP Agent主动发送SNMP Traps给NMS，向NMS报告设备当前的状态变化。
Managed Object
Managed object指被管理对象。每一个设备可能包含多个被管理对象，被管理对象可以是设备中的某个硬件，也可以是在硬件、软件（如路由选择协议）上配置的参数集合。
MIB
MIB是一个数据库，指明了被管理设备所维护的变量。MIB在数据库中定义了被管理设备的一系列属性：对象的名称、对象的状态、对象的访问权限和对象的数据类型等。MIB也可以看作是NMS和SNMP Agent之间的一个接口，通过这个接口，NMS对被管理设备所维护的变量进行查询/设置操作。
MIB是以树状结构进行存储的，如图1-2所示。树的节点表示被管理对象，它可以用从根开始的一条路径唯一地识别，这条路径就称为OID，如system的OID为1.3.6.1.2.1.1，interfaces的OID为1.3.6.1.2.1.2。
子树可以用该子树根节点的OID来标识。如以private为根节点的子树的OID为private的OID——{1.3.6.1.4}。
用户可以配置MIB视图来限制NMS能够访问的MIB对象。MIB视图是MIB的子集合，用户可以将MIB视图内的对象配置为exclude或include。exclude表示当前视图不包含该MIB子树的所有节点；include表示当前视图包含该MIB子树的所有节点。
SNMP查询
SNMP查询是指NMS主动向SNMP Agent发送查询请求，如图1-3所示。SNMP Agent接收到查询请求后，通过MIB表完成相应指令，并将结果反馈给NMS。
SNMP查询操作有三种：Get、GetNext和GetBulk。SNMPv1版本不支持GetBulk操作。
- Get操作：NMS使用该操作从SNMP Agent中获取一个或多个参数值。
- GetNext操作：NMS使用该操作从SNMP Agent中获取一个或多个参数的下一个参数值。
-
GetBulk操作：基于GetNext实现，相当于连续执行多次GetNext操作。在NMS上可以设置被管理设备在一次GetBulk报文交互时，执行GetNext操作的次数。
SNMP查询操作的报文
SNMPv1和SNMPv2c查询报文格式如图1-4所示。SNMPv1和SNMPv2c的报文主要由版本、团体名、SNMP PDU组成。各类SNMP操作的报文封装在SNMP PDU中。
报文中的主要字段如下：
- 版本：表示SNMP的版本，如果是SNMPv1报文则对应字段值为0，SNMPv2c则为1。
- 团体名：用于在SNMP Agent与NMS之间完成认证，字符串形式，用户可自行定义。团体名包括“read”和“write”两种，执行SNMP查询操作时，采用“read”团体名进行认证；执行SNMP设置操作时，则采用“write”团体名进行认证。
- Request ID：用于匹配请求和响应，SNMP给每个请求分配全局唯一的ID。
- Non repeaters/Max repetitions：GetBulk操作基于GetNext操作实现，相当于多次执行GetNext操作，这两个参数用于设置执行GetNext操作次数。
- Error status：用于表示在处理请求时出现的状况。
- Error index：差错索引。当出现异常情况时，提供变量绑定列表（Variable bindings）中导致异常的变量的信息。
- Variable bindings：变量绑定列表，由变量名和变量值对组成。
通过捕获报文工具获取设备发送的SNMPv2c版本Get请求报文如图1-5所示，SNMPv2c版本GetNext请求报文如图1-6所示。SNMPv2c版本GetBulk请求报文如图1-7所示。
SNMPv3查询报文格式如图1-8所示，SNMPv3报文主要由版本、MsgID、MaxSize、Flags、Security Model、Security Parameters、Context EngineID、Context Name和SNMP PDU组成。SNMPv3报文的SNMP PDU的格式与SNMPv2c的一致。SNMPv3版本的报文可以使用鉴权机制，会对Context EngineID、Context Name和SNMP PDU进行加密。
报文中的主要字段定义如下：
- 版本：表示SNMP的版本，如果是SNMPv3报文则对应字段值为3。
- MsgID：请求报文的序列号。
- MaxSize：消息发送者所能够容纳的消息最大字节，同时也表明了发送者能够接收到的最大字节数。
- Flags：消息标识位，占一个字节，有三个特征位：reportableFlag，privFlag和authFlag。
- reportableFlag=1，在能够导致Report PDU生成的情况下，SNMPv3报文接收方必须向发送方发送Report PDU；reportableFlag=0，SNMPv3报文接收方不发送Report PDU。只有在SNMP PDU部分不能被解密时（比如由于密钥错误导致解密失败等）才会用到Report。
- privFlag=1，对SNMPv3报文进行加密；privFlag=0，不对SNMPv3报文进行加密。
- authFlag=1，对SNMPv3报文进行鉴权；authFlag=0，不对SNMPv3报文进行鉴权。
除了privFlag=1，authFlag=0的情况外，其他任意组合都可以，所以在配置SNMPv3的安全级别的时候需要注意：如果用户组是privacy级别，用户和告警主机就必须是privacy级别；用户组是authentication级别，用户和告警主机可以是privacy或者authentication级别。
- SecurityModel：消息采用的安全模型，发送方和接收方必须采用相同的安全模型。
- SecurityParameters：安全参数，包含SNMP实体引擎的相关信息、用户名、鉴权参数、加密参数等安全信息。
- Context EngineID：SNMP唯一标识符，和PDU类型一起决定应该发往哪个应用程序。
-
Context Name：用于确定Context EngineID对被管理设备的MIB视图。
SNMPv3提供了鉴权机制，推荐用户使用SNMPv3版本。通过捕获报文工具获取设备发送的SNMPv3版本加密的Get请求报文如图1-9所示，SNMPv3版本不加密的Get请求报文如图1-10所示。
SNMP查询操作的工作原理
不同版本的SNMP查询操作的工作原理基本一致，唯一的区别是SNMPv3版本增加了身份验证和加密处理。下面以SNMPv2c版本的Get操作为例介绍SNMP查询操作的工作原理。
假定NMS想要获取被管理设备MIB节点sysContact的值，使用可读团体名为public，过程如下所示：
-
NMS：向SNMP Agent发送Get请求报文。报文中各字段的设置如下：版本号为所使用的SNMP版本；团体名为public；PDU中PDU类型为Get类型，绑定变量填入MIB节点名sysContact。
-
SNMP Agent：首先对报文中携带版本号和团体名进行认证，认证成功后，SNMP Agent根据请求查询MIB中的sysContact节点，得到sysContact的值并将其封装到Response报文中的PDU，向NMS发送响应；如果查询不成功，SNMP Agent会向NMS发送出错响应。
SNMP设置
SNMP设置是指NMS主动向SNMP Agent发送对设备进行Set操作的请求，如图1-11所示。SNMP Agent接收到Set请求后，通过MIB表完成相应指令，并将结果反馈给NMS。
SNMP设置操作只有一种Set，NMS使用该操作可设置SNMP Agent中的一个或多个参数值。
SNMP Set操作的报文
SNMPv1和SNMPv2c的Set操作报文格式如图1-12所示。一般情况下，SNMPv3的Set操作信息是经过加密封装在SNMP PDU中，其格式与SNMPv2c的Set操作报文格式一致。
报文中主要字段的含义如下：
- Request ID：用于匹配请求和响应，SNMP给每个请求分配全局唯一的ID。
- Error status：用于表示在处理请求时出现的状况。
- Error index：差错索引。当出现异常情况时，提供变量绑定列表（Variable bindings）中导致异常的变量的信息。
- Variable bindings：变量绑定列表，由变量名和变量值对组成。
通过捕获报文工具获取设备发送的SNMPv2c版本Set请求报文如图1-13所示。
SNMP Set操作的工作原理
不同版本的SNMP Set操作的工作原理基本一致，唯一的区别是SNMPv3版本增加了身份验证和加密处理。下面以SNMPv3版本的Set操作为例介绍SNMP Set操作的工作原理。
假定NMS想要设置被管理设备MIB节点sysName的值为HUAWEI，过程如下所示：
- NMS：向Agent发送不带安全参数的Set请求报文，向SNMP Agent获取Context EngineID、Context Name和安全参数（SNMP实体引擎的相关信息）。
- SNMP Agent：响应NMS的请求，并向NMS反馈请求的参数。
- NMS：再次向SNMP Agent发送Set请求，报文中各字段的设置如下：
- 版本：SNMPv3
- 报文头数据：指明采用鉴权、加密方式。
- 安全参数：NMS通过配置的算法计算出鉴权参数和加密参数。将这些参数和获取的安全参数填入相应字段。
- PDU：将获取的Context EngineID和Context Name填入相应字段，PDU类型设置为Set，绑定变量填入MIB节点名sysName和需要设置的值HUAWEI，并使用已配置的加密算法对PDU进行加密。
-
SNMP Agent：首先对报文中携带版本号和团体名进行认证，认证成功后，SNMP Agent根据请求设置管理变量在管理信息库MIB中对应的节点，设置成功后向NMS发送响应；如果设置不成功，Agent会向NMS发送出错响应。
SNMP Traps
SNMP Traps是指SNMP Agent主动将设备产生的告警或事件上报给NMS，以便网络管理员及时了解设备当前运行的状态。
SNMP Agent上报SNMP Traps有两种方式：Trap和Inform。SNMPv1版本不支持Inform。Trap和Inform的区别在于，SNMP Agent通过Inform向NMS发送告警或事件后，NMS需要回复InformResponse进行确认，如图1-14所示。
SNMP Traps报文格式
SNMPv1的Trap操作报文格式如图1-15所示，Trap PDU由PDU type、enterprise、Agent addr、Generic trap、Specific trap、Time stamp和Variable bindings组成。
报文中的主要字段定义如下：
- enterprise：Trap源（生成Trap的设备）的类型。
- Agent addr：Trap源的地址。
- Generic trap：通用Trap类型，包括coldStart、warmStart、linkDown、linkUp、authenticationFailure、egpNeighborLoss、enterpriseSpecific。
- Specific trap：企业私有Trap信息。
- Time stamp：上次重新初始化网络实体和产生Trap之间所持续的时间。
- Variable bindings：变量绑定列表，由变量名和变量值对组成。
通过捕获报文工具获取设备发送的SNMPv1版本Trap报文如图1-16所示。
SNMPv2c的Trap操作的报文格式和Inform操作的报文格式如图1-17所示。一般情况下，SNMPv3的Trap操作或inform操作是经过加密封装在SNMP PDU中，其格式与SNMPv2c的Trap操作或inform操作的报文格式一致。
报文中的主要字段定义如下：
- Request ID：用于匹配请求和响应，SNMP给每个请求分配全局唯一的ID。
- Variable bindings：变量绑定列表，由变量名和变量值对组成。
通过捕获报文工具获取设备发送的SNMPv2版本Trap报文如图1-18所示，SNMPv2版本Inform报文如图1-19所示。
SNMP Traps工作原理
Trap操作工作原理
Trap不属于NMS对被管理设备的基本操作，它是被管理设备的自发行为。当被管理设备达到告警的触发条件时，会通过SNMP Agent向NMS发送Trap消息，告知设备侧出现的异常情况，便于网络管理人员及时处理。例如被管理设备热启动后，SNMP Agent会向NMS发送warmStart的Trap。
这种Trap信息是受限制的。只有在设备端的模块达到模块预定义的告警触发条件时，SNMP Agent才会向管理进程报告。这种方法的好处是仅在严重事件发生时才发送Trap信息，减少报文交互产生的流量。
Inform操作工作原理
Inform操作也是被管理设备向NMS主动发送告警。与Trap告警不同的是，被管理设备发送Inform告警后，需要NMS进行接收确认。如果被管理设备没有收到确认信息则：
- 将告警或事件暂时保存在Inform缓存中。
- 重复发送该告警或事件，直到NMS确认收到该告警或者发送次数达到最大重传次数。
- 被管设备上会生成相应的告警或事件日志。
由此可知，使用Inform操作会占用较多的系统资源。
SNMP端口号
SNMP报文是普通的UDP报文，协议中规定有两个默认端口号：
- 端口号161：NMS发送Get、GetNext、GetBulk和Set操作请求以及SNMP Agent响应这些请求操作时，使用该端口号。
该端口号支持用户配置，但是需要保证NMS发送请求报文使用的端口号与SNMP Agent响应请求报文使用的端口号要一致。
- 端口号162：SNMP Agent向NMS发送Trap或Inform时，使用该端口号。
该端口号支持用户配置，但是需要保证SNMP Agent发送Trap或Inform的端口号与NMS监听Trap或Inform的端口号要一致。
使用SNMP的相关信息
如果您想了解如何配置或使用SNMP，可参考以下产品文档：
S12700 V200R013C00 配置指南-网络管理与监控中的SNMP章节
CloudEngine 12800, 12800E V200R005C10 配置指南-网络管理与监控中的SNMP章节
无线接入控制器(AC和FITAP) V200R010C00 配置指南(命令行)-网络管理与监控配置中的SNMP章节
HUAWEI USG6000, USG9500, NGFW Module V500R005C00 产品文档-管理员指南-系统中的SNMP章节
AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, AR3600 V200R010 产品文档 配置指南（命令行）-网络管理与监控配置指南中的SNMP章节
NE20E-S V8R10C10SPC500 产品文档-配置-系统管理中的SNMP章节
NE40E V8R10C10SPC500 产品文档-配置-系统管理中的SNMP章节
SNMP配置任务概览 - S12700 V200R013C00 配置指南-网络管理与监控 - 华为 https://support.huawei.com/enterprise/zh/doc/EDOC1100065721/683404d4
|
特性 |
功能描述 |
|---|---|
|
访问控制 |
访问控制主要用来限制管理设备的用户的权限。通过该功能可以限制指定的用户管理设备上的指定节点，从而提升精细化管理。 |
|
认证加密 |
认证加密主要是通过对网管和被管理设备传送的报文进行认证和加密，避免数据报文被窃取或篡改，从而提升数据传输的安全性。 |
|
错误码 |
错误码用来标识特定的故障现象，有助于管理员快速定位和解决故障，因此错误码越丰富越有利于管理员对设备进行管理。 |
|
Trap告警 |
Trap告警是被管理设备主动向网管发送告警。以便管理员能够及时发现设备的异常。 被管理设备发送Trap告警后，不需要网管进行接收确认。 |
|
Inform告警 |
Inform告警也是被管理设备向网管主动发送告警。 被管理设备发送Inform告警后，需要网管进行接收确认。 |
|
GetBulk |
GetBulk主要方便管理员进行批量的Get-Next操作。网络规模较大时，以节省管理员的工作量，提升管理效率。 |
网管重启后可以接收到重启期间发送的Inform告警。
|
特性 |
SNMPv1 |
SNMPv2c |
SNMPv3 |
|---|---|---|---|
|
访问控制 |
基于团体名和MIB View进行访问控制 |
基于团体名和MIB View进行访问控制 |
基于用户、用户组和MIB view进行访问控制 |
|
认证加密 |
基于团体名的认证 |
基于团体名的认证 |
支持认证和加密，认证和加密的方式如下： 认证：
加密：
|
|
错误码 |
支持6个错误码 |
支持16个错误码 |
支持16个错误码 |
|
Trap告警 |
支持 |
支持 |
支持 |
|
Inform告警 |
不支持 |
支持 |
支持 |
|
GetBulk |
不支持 |
支持 |
支持 |
|
版本 |
应用场景 |
|---|---|
|
SNMPv1 |
适用于小型网络，组网简单，对网络安全性要求不高或者网络环境本身比较安全，且比较稳定的网络，比如校园网，小型企业网。 |
|
SNMPv2c |
适用于大中型网络，对网络安全性要求不高或者网络环境本身比较安全（比如VPN网络），但业务比较繁忙，有可能发生流量拥塞的网络。 通过配置Inform告警可以确保被管理设备发送的告警能够被网管收到。 |
|
SNMPv3 |
适用于各种规模的网络，尤其是对网络的安全性要求较高，确保合法的管理员才能对网络设备进行管理的网络。比如网管和被管理设备间的通信数据需要在公网上进行传输。 |
如果用户是统一规划建设新网络，建议根据上面的应用场景选择SNMP协议的版本。如果用户是网络扩建或升级，建议用户根据网管使用的版本选择在设备上配置对应的SNMP协议版本，保证设备和网管的通信。
什么是SNMP？
简介
简单网络管理协议SNMP（Simple Network Management Protocol）用于网络设备的管理。网络设备种类多种多样，不同设备厂商提供的管理接口（如命令行接口）各不相同，这使得网络管理变得愈发复杂。为解决这一问题，SNMP应运而生。SNMP作为广泛应用于TCP/IP网络的网络管理标准协议，提供了统一的接口，从而实现了不同种类和厂商的网络设备之间的统一管理。
SNMP协议分为三个版本：SNMPv1、SNMPv2c和SNMPv3。
- SNMPv1是SNMP协议的最初版本，提供最小限度的网络管理功能。SNMPv1基于团体名认证，安全性较差，且返回报文的错误码也较少。
- SNMPv2c也采用团体名认证。在SNMPv1版本的基础上引入了GetBulk和Inform操作，支持更多的标准错误码信息，支持更多的数据类型（Counter64、Counter32）。
- SNMPv3主要在安全性方面进行了增强，提供了基于USM（User Security Module）的认证加密和基于VACM（View-based Access Control Model）的访问控制。SNMPv3版本支持的操作和SNMPv2c版本支持的操作一样。
SNMP系统组成
SNMP系统由网络管理系统NMS（Network Management System）、SNMP Agent、被管对象Management object和管理信息库MIB（Management Information Base）四部分组成。NMS作为整个网络的网管中心，对设备进行管理。
每个被管理设备中都包含驻留在设备上的SNMP Agent进程、MIB和多个被管对象。NMS通过与运行在被管理设备上的SNMP Agent交互，由SNMP Agent通过对设备端的MIB进行操作，完成NMS的指令。
NMS
NMS是网络中的管理者，是一个采用SNMP协议对网络设备进行管理/监视的系统，运行在NMS服务器上。
-
NMS可以向设备上的SNMP Agent发出请求，查询或修改一个或多个具体的参数值。
-
NMS可以接收设备上的SNMP Agent主动发送的SNMP Traps，以获知被管理设备当前的状态。
SNMP Agent
-
SNMP Agent接收到NMS的请求信息后，通过MIB表完成相应指令后，并把操作结果响应给NMS。
-
当设备发生故障或者其它事件时，设备会通过SNMP Agent主动发送SNMP Traps给NMS，向NMS报告设备当前的状态变化。
Managed Object
Managed object指被管理对象。每一个设备可能包含多个被管理对象，被管理对象可以是设备中的某个硬件，也可以是在硬件、软件（如路由选择协议）上配置的参数集合。
MIB
MIB是一个数据库，指明了被管理设备所维护的变量。MIB在数据库中定义了被管理设备的一系列属性：对象的名称、对象的状态、对象的访问权限和对象的数据类型等。MIB也可以看作是NMS和SNMP Agent之间的一个接口，通过这个接口，NMS对被管理设备所维护的变量进行查询/设置操作。
MIB是以树状结构进行存储的，如图1-2所示。树的节点表示被管理对象，它可以用从根开始的一条路径唯一地识别，这条路径就称为OID，如system的OID为1.3.6.1.2.1.1，interfaces的OID为1.3.6.1.2.1.2。
子树可以用该子树根节点的OID来标识。如以private为根节点的子树的OID为private的OID——{1.3.6.1.4}。
用户可以配置MIB视图来限制NMS能够访问的MIB对象。MIB视图是MIB的子集合，用户可以将MIB视图内的对象配置为exclude或include。exclude表示当前视图不包含该MIB子树的所有节点；include表示当前视图包含该MIB子树的所有节点。
SNMP查询
SNMP查询是指NMS主动向SNMP Agent发送查询请求，如图1-3所示。SNMP Agent接收到查询请求后，通过MIB表完成相应指令，并将结果反馈给NMS。
SNMP查询操作有三种：Get、GetNext和GetBulk。SNMPv1版本不支持GetBulk操作。
- Get操作：NMS使用该操作从SNMP Agent中获取一个或多个参数值。
- GetNext操作：NMS使用该操作从SNMP Agent中获取一个或多个参数的下一个参数值。
-
GetBulk操作：基于GetNext实现，相当于连续执行多次GetNext操作。在NMS上可以设置被管理设备在一次GetBulk报文交互时，执行GetNext操作的次数。
SNMP查询操作的报文
SNMPv1和SNMPv2c查询报文格式如图1-4所示。SNMPv1和SNMPv2c的报文主要由版本、团体名、SNMP PDU组成。各类SNMP操作的报文封装在SNMP PDU中。
报文中的主要字段如下：
- 版本：表示SNMP的版本，如果是SNMPv1报文则对应字段值为0，SNMPv2c则为1。
- 团体名：用于在SNMP Agent与NMS之间完成认证，字符串形式，用户可自行定义。团体名包括“read”和“write”两种，执行SNMP查询操作时，采用“read”团体名进行认证；执行SNMP设置操作时，则采用“write”团体名进行认证。
- Request ID：用于匹配请求和响应，SNMP给每个请求分配全局唯一的ID。
- Non repeaters/Max repetitions：GetBulk操作基于GetNext操作实现，相当于多次执行GetNext操作，这两个参数用于设置执行GetNext操作次数。
- Error status：用于表示在处理请求时出现的状况。
- Error index：差错索引。当出现异常情况时，提供变量绑定列表（Variable bindings）中导致异常的变量的信息。
- Variable bindings：变量绑定列表，由变量名和变量值对组成。
通过捕获报文工具获取设备发送的SNMPv2c版本Get请求报文如图1-5所示，SNMPv2c版本GetNext请求报文如图1-6所示。SNMPv2c版本GetBulk请求报文如图1-7所示。
SNMPv3查询报文格式如图1-8所示，SNMPv3报文主要由版本、MsgID、MaxSize、Flags、Security Model、Security Parameters、Context EngineID、Context Name和SNMP PDU组成。SNMPv3报文的SNMP PDU的格式与SNMPv2c的一致。SNMPv3版本的报文可以使用鉴权机制，会对Context EngineID、Context Name和SNMP PDU进行加密。
报文中的主要字段定义如下：
- 版本：表示SNMP的版本，如果是SNMPv3报文则对应字段值为3。
- MsgID：请求报文的序列号。
- MaxSize：消息发送者所能够容纳的消息最大字节，同时也表明了发送者能够接收到的最大字节数。
- Flags：消息标识位，占一个字节，有三个特征位：reportableFlag，privFlag和authFlag。
- reportableFlag=1，在能够导致Report PDU生成的情况下，SNMPv3报文接收方必须向发送方发送Report PDU；reportableFlag=0，SNMPv3报文接收方不发送Report PDU。只有在SNMP PDU部分不能被解密时（比如由于密钥错误导致解密失败等）才会用到Report。
- privFlag=1，对SNMPv3报文进行加密；privFlag=0，不对SNMPv3报文进行加密。
- authFlag=1，对SNMPv3报文进行鉴权；authFlag=0，不对SNMPv3报文进行鉴权。
除了privFlag=1，authFlag=0的情况外，其他任意组合都可以，所以在配置SNMPv3的安全级别的时候需要注意：如果用户组是privacy级别，用户和告警主机就必须是privacy级别；用户组是authentication级别，用户和告警主机可以是privacy或者authentication级别。
- SecurityModel：消息采用的安全模型，发送方和接收方必须采用相同的安全模型。
- SecurityParameters：安全参数，包含SNMP实体引擎的相关信息、用户名、鉴权参数、加密参数等安全信息。
- Context EngineID：SNMP唯一标识符，和PDU类型一起决定应该发往哪个应用程序。
-
Context Name：用于确定Context EngineID对被管理设备的MIB视图。
SNMPv3提供了鉴权机制，推荐用户使用SNMPv3版本。通过捕获报文工具获取设备发送的SNMPv3版本加密的Get请求报文如图1-9所示，SNMPv3版本不加密的Get请求报文如图1-10所示。
SNMP查询操作的工作原理
不同版本的SNMP查询操作的工作原理基本一致，唯一的区别是SNMPv3版本增加了身份验证和加密处理。下面以SNMPv2c版本的Get操作为例介绍SNMP查询操作的工作原理。
假定NMS想要获取被管理设备MIB节点sysContact的值，使用可读团体名为public，过程如下所示：
-
NMS：向SNMP Agent发送Get请求报文。报文中各字段的设置如下：版本号为所使用的SNMP版本；团体名为public；PDU中PDU类型为Get类型，绑定变量填入MIB节点名sysContact。
-
SNMP Agent：首先对报文中携带版本号和团体名进行认证，认证成功后，SNMP Agent根据请求查询MIB中的sysContact节点，得到sysContact的值并将其封装到Response报文中的PDU，向NMS发送响应；如果查询不成功，SNMP Agent会向NMS发送出错响应。
SNMP设置
SNMP设置是指NMS主动向SNMP Agent发送对设备进行Set操作的请求，如图1-11所示。SNMP Agent接收到Set请求后，通过MIB表完成相应指令，并将结果反馈给NMS。
SNMP设置操作只有一种Set，NMS使用该操作可设置SNMP Agent中的一个或多个参数值。
SNMP Set操作的报文
SNMPv1和SNMPv2c的Set操作报文格式如图1-12所示。一般情况下，SNMPv3的Set操作信息是经过加密封装在SNMP PDU中，其格式与SNMPv2c的Set操作报文格式一致。
报文中主要字段的含义如下：
- Request ID：用于匹配请求和响应，SNMP给每个请求分配全局唯一的ID。
- Error status：用于表示在处理请求时出现的状况。
- Error index：差错索引。当出现异常情况时，提供变量绑定列表（Variable bindings）中导致异常的变量的信息。
- Variable bindings：变量绑定列表，由变量名和变量值对组成。
通过捕获报文工具获取设备发送的SNMPv2c版本Set请求报文如图1-13所示。
SNMP Set操作的工作原理
不同版本的SNMP Set操作的工作原理基本一致，唯一的区别是SNMPv3版本增加了身份验证和加密处理。下面以SNMPv3版本的Set操作为例介绍SNMP Set操作的工作原理。
假定NMS想要设置被管理设备MIB节点sysName的值为HUAWEI，过程如下所示：
- NMS：向Agent发送不带安全参数的Set请求报文，向SNMP Agent获取Context EngineID、Context Name和安全参数（SNMP实体引擎的相关信息）。
- SNMP Agent：响应NMS的请求，并向NMS反馈请求的参数。
- NMS：再次向SNMP Agent发送Set请求，报文中各字段的设置如下：
- 版本：SNMPv3
- 报文头数据：指明采用鉴权、加密方式。
- 安全参数：NMS通过配置的算法计算出鉴权参数和加密参数。将这些参数和获取的安全参数填入相应字段。
- PDU：将获取的Context EngineID和Context Name填入相应字段，PDU类型设置为Set，绑定变量填入MIB节点名sysName和需要设置的值HUAWEI，并使用已配置的加密算法对PDU进行加密。
-
SNMP Agent：首先对报文中携带版本号和团体名进行认证，认证成功后，SNMP Agent根据请求设置管理变量在管理信息库MIB中对应的节点，设置成功后向NMS发送响应；如果设置不成功，Agent会向NMS发送出错响应。
SNMP Traps
SNMP Traps是指SNMP Agent主动将设备产生的告警或事件上报给NMS，以便网络管理员及时了解设备当前运行的状态。
SNMP Agent上报SNMP Traps有两种方式：Trap和Inform。SNMPv1版本不支持Inform。Trap和Inform的区别在于，SNMP Agent通过Inform向NMS发送告警或事件后，NMS需要回复InformResponse进行确认，如图1-14所示。
SNMP Traps报文格式
SNMPv1的Trap操作报文格式如图1-15所示，Trap PDU由PDU type、enterprise、Agent addr、Generic trap、Specific trap、Time stamp和Variable bindings组成。
报文中的主要字段定义如下：
- enterprise：Trap源（生成Trap的设备）的类型。
- Agent addr：Trap源的地址。
- Generic trap：通用Trap类型，包括coldStart、warmStart、linkDown、linkUp、authenticationFailure、egpNeighborLoss、enterpriseSpecific。
- Specific trap：企业私有Trap信息。
- Time stamp：上次重新初始化网络实体和产生Trap之间所持续的时间。
- Variable bindings：变量绑定列表，由变量名和变量值对组成。
通过捕获报文工具获取设备发送的SNMPv1版本Trap报文如图1-16所示。
SNMPv2c的Trap操作的报文格式和Inform操作的报文格式如图1-17所示。一般情况下，SNMPv3的Trap操作或inform操作是经过加密封装在SNMP PDU中，其格式与SNMPv2c的Trap操作或inform操作的报文格式一致。
报文中的主要字段定义如下：
- Request ID：用于匹配请求和响应，SNMP给每个请求分配全局唯一的ID。
- Variable bindings：变量绑定列表，由变量名和变量值对组成。
通过捕获报文工具获取设备发送的SNMPv2版本Trap报文如图1-18所示，SNMPv2版本Inform报文如图1-19所示。
SNMP Traps工作原理
Trap操作工作原理
Trap不属于NMS对被管理设备的基本操作，它是被管理设备的自发行为。当被管理设备达到告警的触发条件时，会通过SNMP Agent向NMS发送Trap消息，告知设备侧出现的异常情况，便于网络管理人员及时处理。例如被管理设备热启动后，SNMP Agent会向NMS发送warmStart的Trap。
这种Trap信息是受限制的。只有在设备端的模块达到模块预定义的告警触发条件时，SNMP Agent才会向管理进程报告。这种方法的好处是仅在严重事件发生时才发送Trap信息，减少报文交互产生的流量。
Inform操作工作原理
Inform操作也是被管理设备向NMS主动发送告警。与Trap告警不同的是，被管理设备发送Inform告警后，需要NMS进行接收确认。如果被管理设备没有收到确认信息则：
- 将告警或事件暂时保存在Inform缓存中。
- 重复发送该告警或事件，直到NMS确认收到该告警或者发送次数达到最大重传次数。
- 被管设备上会生成相应的告警或事件日志。
由此可知，使用Inform操作会占用较多的系统资源。
SNMP端口号
SNMP报文是普通的UDP报文，协议中规定有两个默认端口号：
- 端口号161：NMS发送Get、GetNext、GetBulk和Set操作请求以及SNMP Agent响应这些请求操作时，使用该端口号。
该端口号支持用户配置，但是需要保证NMS发送请求报文使用的端口号与SNMP Agent响应请求报文使用的端口号要一致。
- 端口号162：SNMP Agent向NMS发送Trap或Inform时，使用该端口号。
该端口号支持用户配置，但是需要保证SNMP Agent发送Trap或Inform的端口号与NMS监听Trap或Inform的端口号要一致。
使用SNMP的相关信息
如果您想了解如何配置或使用SNMP，可参考以下产品文档：
S12700 V200R013C00 配置指南-网络管理与监控中的SNMP章节
CloudEngine 12800, 12800E V200R005C10 配置指南-网络管理与监控中的SNMP章节
无线接入控制器(AC和FITAP) V200R010C00 配置指南(命令行)-网络管理与监控配置中的SNMP章节
HUAWEI USG6000, USG9500, NGFW Module V500R005C00 产品文档-管理员指南-系统中的SNMP章节
AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, AR3600 V200R010 产品文档 配置指南（命令行）-网络管理与监控配置指南中的SNMP章节
NE20E-S V8R10C10SPC500 产品文档-配置-系统管理中的SNMP章节
NE40E V8R10C10SPC500 产品文档-配置-系统管理中的SNMP章节
IP数据报UDP数据报SNMP报文公共SNMP首部get/set首部get/set变量部分IP首部UDP首部"版本（0）"共同体"PDU类型（0-3）"请求标识"差错状态（0-5）"差错索引名称值名称值..."PDU类型（4）"企业代理地址"trap类型（0-6）"特定代码时间戳名称值...trap首部有意义的变量SNMP报文的格式PDU类型名称差错状态名称描述0get-request0noError没有进程1get-nextrequest1tooBig代理进程无法把响应放在一个SNMP消息中发送2get-response2noSuchName操作一个不存在的变量3set-request3badValueset操作的值或语义有错误4trap4readOnly管理进程试图修改一个只读变量SNMP报文中的PDU类型5genErr其他错误SNMP差错状态的值trap类型名称描述0clodStart代理进程对自己初始化1warmStart2linkDown"一个接口从影工作状态变为故障状态，报文中的第一个变量标识次接口"3linkUp"一个接口从影故障状态变为工作状态，报文中的第一个变量标识次接口"4authenticationFailure从SNMP管理进程收到无效共同体的报文5egpNeighborLoss一个FGP邻站已变为故障状态。报文中的第一个变量包含此邻站的IP地址6enterpriseSpecific在这个特定的代码段总查找trap信息trap的类型
IP数据报UDP数据报SNMP报文公共SNMP首部get/set首部get/set变量部分IP首部UDP首部"版本（0）"共同体"PDU类型（0-3）"请求标识"差错状态（0-5）"差错索引名称值名称值..."PDU类型（4）"企业代理地址"trap类型（0-6）"特定代码时间戳名称值...trap首部有意义的变量SNMP报文的格式PDU类型名称差错状态名称描述0get-request0noError没有进程1get-nextrequest1tooBig代理进程无法把响应放在一个SNMP消息中发送2get-response2noSuchName操作一个不存在的变量3set-request3badValueset操作的值或语义有错误4trap4readOnly管理进程试图修改一个只读变量SNMP报文中的PDU类型5genErr其他错误SNMP差错状态的值trap类型名称描述0clodStart代理进程对自己初始化1warmStart代理进程对自己重新初始化2linkDown"一个接口从影工作状态变为故障状态，报文中的第一个变量标识次接口"3linkUp"一个接口从影故障状态变为工作状态，报文中的第一个变量标识次接口"4authenticationFailure从SNMP管理进程收到无效共同体的报文5egpNeighborLoss一个FGP邻站已变为故障状态。报文中的第一个变量包含此邻站的IP地址6enterpriseSpecific在这个特定的代码段总查找trap信息trap的类型
IP数据报UDP数据报SNMP报文公共SNMP首部get/set首部get/set变量部分IP首部UDP首部"版本（0）"共同体"PDU类型（0-3）"请求标识"差错状态（0-5）"差错索引名称值名称值..."PDU类型（4）"企业代理地址"trap类型（0-6）"特定代码时间戳名称值...trap首部有意义的变量SNMP报文的格式PDU类型名称差错状态名称描述0get-request0noError没有进程1get-nextrequest1tooBig代理进程无法把响应放在一个SNMP消息中发送2get-response2noSuchName操作一个不存在的变量3set-request3badValueset操作的值或语义有错误4trap4readOnly管理进程试图修改一个只读变量SNMP报文中的PDU类型5genErr其他错误SNMP差错状态的值trap类型名称描述0clodStart代理进程对自己初始化1warmStart代理进程对自己重新初始化2linkDown"一个接口从影工作状态变为故障状态，报文中的第一个变量标识次接口"3linkUp"一个接口从影故障状态变为工作状态，报文中的第一个变量标识次接口"4authenticationFailure从SNMP管理进程收到无效共同体的报文5egpNeighborLoss一个FGP邻站已变为故障状态。报文中的第一个变量包含此邻站的IP地址6enterpriseSpecific在这个特定的代码段中查找trap信息trap的类型
