SNMPv3 Traps are rejected by SNMP Manager after Device Reboot

Answered Question
May 25th, 2008

Device is configured with SNMPv3 AuthNoPriv.

Proper User and Groups have been set up.

SNMP Get requests/responses as well as Traps are all send/received properly until the Cisco device reboots.

After the Cisco device reboots, Traps from the device are rejected by the SNMP Manager for unknown reasons.

SNMP Traps are sent by the Cisco device as can be seen in sniffer traces, but the SNMP Engine in the Manager drops/rejects them.

It's presumed that this is due to the snmpEngineBoots has incremented by one and snmpEngineTime has been reset upon reboot, however, it's hard to discern whether this is a Cisco-side problem, SNMP-Manager-side problem or perhaps configuration problem.

Any assistance would be appreciated.

Note: Once the SNMP manager performs a Get request to the rebooted device, traps after that get request are sent are received properly, but if no SNMP Get is performed, Traps are all rejected!

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 8 years 6 months ago

I can't reproduce. We use Net-SNMP 5.4.1 on our FreeBSD server in the lab. I configured a switch to send v3 traps to this server. I generated a config change trap, and verified it showed up in the log. I then reloaded this switch. When it came back up, I sent another trap, and it still showed up in the log.

To configure Net-SNMP, I added a createUser token to /var/net-snmp/snmptrapd.conf, then restarted snmptrapd:

createUser -e ENGINEID USERNAME MD5 PASSWORD

I then edited /usr/local/share/snmp/snmptrapd.conf, and added:

authUser log USERNAME

That's pretty much all I have in that file. Everything works as it should.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joe Clarke Sun, 05/25/2008 - 21:46

Sounds to me like you might be right regarding the reason for the drop (the digest would not be calculated directly on the manager). The GET will trigger a report from the agent which will most likely update the manager's cache.

What manager are you using? Have you contacted that vendor to get their take on things?

wbenton-0 Mon, 05/26/2008 - 00:19

We're running a Red Hat Linux v2.6.9-42.ELsmp with NET-SNMP version: 5.4.1 installed.

Like I said, once an SNMP Get is performed from the manager, everything sync's up, but until the SNMP Get request goes out, all traps are rejected.

I've looked for such a bug but have yet to run across any information related to my problem.

Correct Answer
Joe Clarke Mon, 05/26/2008 - 10:13

I can't reproduce. We use Net-SNMP 5.4.1 on our FreeBSD server in the lab. I configured a switch to send v3 traps to this server. I generated a config change trap, and verified it showed up in the log. I then reloaded this switch. When it came back up, I sent another trap, and it still showed up in the log.

To configure Net-SNMP, I added a createUser token to /var/net-snmp/snmptrapd.conf, then restarted snmptrapd:

createUser -e ENGINEID USERNAME MD5 PASSWORD

I then edited /usr/local/share/snmp/snmptrapd.conf, and added:

authUser log USERNAME

That's pretty much all I have in that file. Everything works as it should.

wbenton-0 Mon, 05/26/2008 - 16:35

Thank you,

Looking at the config of the server our engineers set up, it looks to be a mis-configuration.

They placed the createUser token in /usr/local/share/snmp/snmptrapd.conf instead of /var/net-snmp/snmptrapd.conf.

I'll have them set it up properly and if I don't reply further, consider this issue closed!

Actions

This Discussion