cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2088
Views
0
Helpful
4
Replies

SNMPv3 Traps are rejected by SNMP Manager after Device Reboot

wbenton-0
Level 1
Level 1

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!

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

4 Replies 4

Joe Clarke
Cisco Employee
Cisco Employee

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?

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.

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.

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!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: