If you're SNMP trap is received from the OpenNMS server, you can then start looking in trapd.log of your OpenNMS server and verify if community settings for the IP is correct.Use tcpdump to see if the SNMP trap from your Nexus arrives on the OpenNMS server by looking at traffic with target port 162 with protocol UDP.Make sure you don't have a firewall on your OpenNMS server which blocks traffic to 162/UDP, e.g.Ensure OpenNMS has Trapd enabled and is listening on the right interfaces, e.g.I would try to debug the problem with the following steps: With a system that supports and integrates events received from syslog messages and SNMP traps, you have a unified solution that delivers. We wanted to mention SNMP traps here because some of the tools we’re about to present can also be used as trap receivers. The communication is initialized by the Nexus device and OpenNMS is the listener for the traps. These traps are sent to what we refer to as a trap receiver in the SNMP world. So trying to debug the problem not getting SNMP Traps with snmpget or snmpwalk does not help in the first place. Your monitoring application with OpenNMS needs to have a listener running on port 162/UDP, called SNMP Traps or SNMP Informs. The second one is, your Nexus device can send messages to your monitoring application. The Nexus device has an SNMP agent running which is listening on port 161/UDP. This is what you do when you issue a snmpwalk or snmpget command.
The monitoring application sends requests to your Nexus device. Ok, first of all, there are two concepts with SNMP, the first one is polling for data to get data from sensors or discover elements from your device.