Question & Answer
Question
MTTrapd probe : SNMPv3 traps lost : How are traps dropped?
Cause
SNMPv3 uses a security model which must be adhered to
Answer
SNMPv3 traps must conform to the SNMPv3 standard and be sent and received correctly:
The SNMP (MTTrapd) probe will silently drop traps if they fail to meet the probes property settings and do not adhere to the SNMPv3 standard.
For example, if a probe is configured as follows:
Port : 1621
Protocol : 'ALL'
PersistentDir : '$OMNIHOME/var/ericsson-snmpv3'
ConfPath : '$OMNIHOME/var/ericsson-snmpv3/conf'
NoNameResolution : 1
With the mttrapd.conf set to:
createUser -e 800000020109840311 shauser SHA shapassword DES despassword
The probe is able to receive traps from a device using the given engineid [800000020109840311].
For example, all of these commands will work when sent from the same host:
- snmptrap -e 800000020109840311 -v3 -u shauser -a SHA -A shapassword -x DES -X despassword -l authPriv UDP:localhost:1621 0 authenticationFailure.0
- snmptrap -e 800000020109840311 -v3 -u shauser-l authNoPriv UDP:localhost:1621 0 authenticationFailure.0
- snmptrap -e 800000020109840311 -v3 -u shauser -l NoauthNoPriv UDP:localhost:1621 0 authenticationFailure.0
However, if the same trap is sent from another host, which has a different localtime, the trap will be dropped silently.
Therefore it is important to ensure that the engineid is unique for all trap senders.
Other reasons for traps being discarded:
- The trap queue is full
- The trap protocol is not set correctly
- The trap is misconfigured and does not include the uptime
- The auto-generated mttrapd.conf file in the PersistentDir was not remove before updating the mttrapd.conf file in the ConfPath directory
- Other unauthorised trap senders are using the same engineid
You can check EngineID's and IP Addresses using this log command in the rulesfile:
log(warn,"SNMPV3Check:" + $contextEngineID + ":" + $IPaddress )
At the very least, each IP Address should have a unique EngineID.
Although there may be more than one EngineID for each IP Address.
If a specific IP Address is identified as dropping traps for no apparent reason, check the traps being dropped and compare with the traps that are accepted. Pay attention to the Engine Time field, as well as the authentication level for the traps.
For example, four traps are seen with all the same details accept:
trap#1 : security = NoauthNoPriv : engine time = 1111111111
trap#2 : security = authNoPriv : engine time = 1111111112
trap#3 : security = authPriv : engine time = 1111111113
trap#4 : security = authNoPriv : engine time = 99999999
If trap#4 is not seen, then the issue is with the engine time.
Ask the devices administrator why the trap is sent with an incorrect engine time.
If trap#3 is not seen check the mttrapd.conf has the correct settings, and clear the PersistentDir mttrapd.conf file before starting the probe.
If only trap#1 is seen, check that the mttrapd.conf has the correct settings, and clear the PersistentDir mttrapd.conf file before starting the probe. When traps are sent with user/security errors, the client application sending the traps may log the issue.
If the problem is not resolved, please refer to Support's Guide to the MTTrapd probe, to see what other replication methods are available.
Note: Captured SNMPv3 traps should not be resent, without first restarting the probe, since from the probes perspective the trap was already processed.
Related Information
[{"Product":{"code":"SSSHTQ","label":"Tivoli Netcool\/OMNIbus"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"SNMP Probe","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"7.4.0;8.1.0","Edition":"Edition Independent","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21626348