SNMP(Simple Network Management Protocol) Trap is a very useful but difficult to understand protocol. Although the name is the Simple Network Management Protocol, it actually does not mean literally, especially when you see a string of weird numbers like .1.3.6.1.2.1.1.1.0, it will be a bit disappointing.
In any case, all network devices now need to support SNMP. And there are many open source network management systems now, so it is conducive to us learning and understanding SNMP. SNMP trap is a managed device that actively sends devices to the management server.abnormalThe situation can be seen as the process of the management server passively receiving. So there will be many tools that integrate snmptrap into its own tools to monitor network devices.
Francois Meehan posted on Sysadmin magazineOne articleIt is about integrating SNMP trap into Nagios. The general workflow is:
1. Snmptrapd receives the traps sent by network devices
2. snmptrapd calls snmptt(snmp trap translator)
3. The level of each trap is defined in snmptt, and what kind of trap is necessary to write to syslog
4. SEC (simple event correlator is an event collector) reads each event from syslog and processes the calling user's script.
5. The equivalent Nagios command line will be called according to the host name and trap level.
This process contains many layers, so it feels very complicated. Let's go deeper and see how snmptrapd works. This will simplify the use of snmptrap as much as possible.
snmptrapd fromOpen source softwareNet-SNMP. Net-SNMP has many uses, and of course using trap is also a very useful purpose. After snmptrapd receives the trap, it can call a user-defined script or command line to handle the trap. If you want to use this function, you need to set traphandle in the snmptrapd configuration file. The trap information format received by snmptrapd is:
1. The name of the host where the packet comes from.
2. IP address of the source of the packet.
3. Contents in the packet.
The job of traphandle is to read these contents and process them.
Trap information example:
192.168.10.20
RFC1213-MIB::sysUpTime.0 0:18:14:45.66
SNMPv2-MIB::snmpTrapOID.0 IF-MIB::linkDown
RFC1213-MIB::ifIndex.2 2
RFC1213-MIB::ifDescr.2 "Serial0/0"
RFC1213-MIB::ifType.2 ppp
OLD-CISCO-INTERFACES-MIB::locIfReason.2 "administratively down"
SNMP-COMMUNITY-MIB::snmpTrapAddress.0 192.168.10.20
SNMP-COMMUNITY-MIB::snmpTrapCommunity.0 "public"
SNMPv2-MIB::snmpTrapEnterprise.0 CISCO-SMI::ciscoProducts.186
Because snmptt translates the OID in the trap information, if it is not translated, then the trap information should look like
192.168.10.20
.1.3.6.1.2.1.1.3.0 0:18:13:59.95
.1.3.6.1.6.3.1.1.4.1.0 .1.3.6.1.6.3.1.1.5.3
.1.3.6.1.2.1.2.2.1.1.2 2
.1.3.6.1.2.1.2.2.1.2.2 "Serial0/0"
.1.3.6.1.2.1.2.2.1.3.2 ppp
.1.3.6.1.4.1.9.2.2.1.1.20.2 "administratively down"
.1.3.6.1.6.3.18.1.3.0 192.168.10.20
.1.3.6.1.6.3.18.1.4.0 "public"
.1.3.6.1.6.3.1.1.4.3.0 .1.3.6.1.4.1.9.1.186
This shows that snmptt has its own configuration file, which contains the OID and the corresponding attribute name, and is indexed using OID. If snmptt cannot find the corresponding OID in the configuration file, then snmptt cannot translate the information, and the information content we see is the original format.
The configuration file used by snmptt is called MIBs (Management Information Base Management Information Base). In the key indexed by MIBs with OID, you can quickly find the corresponding text form and warning level. Each MIB has its own fixed definition format, which contains a macro (to describe the content of the information to be displayed).
But why should MIBs exist? Is it not possible to directly use snmptrapd to complete the translation of OID to information?
1. MIBs can be defined and used by the user themselves. Because the contents of trap information definitions of each manufacturer must be different, if snmp is sufficiently scalable, it is necessary to support user-defined MIBs files. This is why MIBs exist.
2. It is also OK if snmptrapd completes the translation by itself, because if you search the OID message every time, thenperformanceThe impact is very large, so snmptrapd needs to read into MIBs. The problem arises. If you update MIBs, you must restart snmptrapd, which will definitely affect the reception of trap messages. Therefore, it is a very correct choice to exist as an independent demon.
The last thing to do is add traphandle. The handle will affect the reception performance of snmptrap, so the processing speed should be fast, because the handle may have hundreds of calls in 1 second.
In this way, the above processing process can be simplified:
1. snmptrapd receives trap information
2. snmptrapd calls handle (if you do not call existing commands, you can complete all the processing in the handle, and there is no following processing. Another step is saved, haha)
3. Just call the Nagios command line in the handle
This way the process is much simpler. You can also refer to this processing process when using snmptrap in the future.