05-25-2008 09:10 PM
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!
Solved! Go to Solution.
05-26-2008 10:13 AM
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.
05-25-2008 09:46 PM
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?
05-26-2008 12:19 AM
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.
05-26-2008 10:13 AM
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.
05-26-2008 04:35 PM
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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide