snmptrap - underlying config?

Question

I'm trying to get my Ubuntu LTS 16.04 server to send SNMPTraps to my HP OVO server. The reason for this is that there are legacy devices on the network that cannot send an SNMP warning upon failure, but can still be accessed through a network-connected card. Due to this, my Ubuntu server connects to that card to assess the failed nodes. I've achieved this already using Bash and Expect - so now what I want to do is send an snmptrap as part of my script. My question is:

Question

Does the snmptrap command require underlying configuration? Or does it work from the commandline the way we (or maybe just I) take the telnet command for granted?

I ask because I'm trying to achieve this on a corporate network, and currently my OVO Server doesn't receive the trap. So I want to narrow down if it's one of the several firewalls or if the issue is, as mentioned, an underlying configuration problem.

Context:

My expect script basically returns the status of each card managed by the network connected card back to bash as an array - 0 for OK 1 for didn't respond. So Bash does:

errors=$((expect ~/assets/connect))
for i in ${!errors[@]}:
do
    if [[ ${errors[$i]} -eq 1 ]]:
        then:
        snmptrap #stuff goes here; the relevant source IP is saved elsewhere & available - I want the SNMP trap to send a "node $i" down. 
    fi
done

Answer 1

snmptrap doesn't require any specific configurations.

To validate whether your script is sending traps, you can use tcpdump to watch traffic. SNMP traps are UDP and usually destined for port 162, so this will work:

tcpdump -i <interface> udp dst port 162

Then, in another screen or terminal, test your snmptrap command natively at first, then embedded in your script:

snmptrap -v 2c -c public ov.example.com '' 1.3.6.1.4.1.6032.1 1.3.6.1.4.1.6032.1 s "this is just a generic message" 

You should see output similar to:

14:52:32.966387 IP server.example.com.43066 > ov.example.com.snmp-trap:  V2Trap(114)  system.sysUpTime.0=31777102 S:1.1.4.1.0=E:6032.1 E:6032.1="this is just a generic message"

If you see the output in tcpdump, then you know snmptrap is working on the local host, as the packet is leaving the systemm. If that's the case, run the same tcpdump command on the receiver to see if they traps are being received. Filtering by host in this case can be handy if you're receiving traps from multiple sources:

tcpdump -i <interface> udp and src host <sender name/ip> dst port and dst port 162

If you don't see the packets on the receiver, but you see them leaving the sender, then there's something blocking them in the network.