OpenNMS Docker部署后SNMPv3轮询正常，陷阱/通知无法工作求助

Hey there, let's troubleshoot why your SNMPv3 traps and inform notifications aren't working with your Docker-deployed OpenNMS setup. Since SNMPv3 polling is already functional, we know the core SNMPv3 configuration is valid—but traps have unique quirks, especially when dealing with Docker networking. Here are the key areas to check:

SNMP traps use UDP port 162 by default, and Docker doesn't expose ports automatically. Make sure your container run command or docker-compose.yml explicitly maps the UDP port from the host to the container:

# Example run command snippet
docker run -d ... -p 162:162/udp ... opennms/opennms

Also, verify your host firewall allows incoming UDP traffic on port 162—traps from external devices will get blocked otherwise.

The trap-sending device's SNMPv3 configuration must align perfectly with what's in your trapd-configuration.xml:

• Security name: trapuser is case-sensitive—ensure the sender uses the exact same string
• Security level: Your config sets security-level="3" (which maps to authPriv). The sender must be configured to use this level (not authNoPriv or noAuthNoPriv)
• Auth details: Match the SHA protocol and authsecret passphrase exactly on the sending device
• Privacy details: Same rule applies to AES protocol and privsecret passphrase—no typos or mismatched encryption types

Jump into your OpenNMS container to check trapd logs—they'll often tell you exactly where things are breaking:

docker exec -it <your-opennms-container-name> tail -f /var/log/opennms/trapd.log

Look for entries like:

• "Failed to decode SNMPv3 trap" (points to encryption/passphrase mismatches)
• "Unknown security name" (security name doesn't match)
• "No UDP listener on port 162" (port mapping issue)

Informs require a response from OpenNMS, so:

• The sending device must target the correct IP/port (either the container's internal IP or your host's IP with the mapped UDP 162 port)
• Ensure network routes and firewalls allow bidirectional traffic between OpenNMS and the trap sender—blocked return packets will cause informs to fail

Some SNMPv3 implementations require matching engine IDs between the trap sender and receiver. You can find OpenNMS's engine ID in /opt/opennms/etc/snmp-config.xml inside the container. Confirm the sending device uses the same engine ID, or is configured to auto-detect it.

After working through these checks, re-test sending a trap/inform and monitor the trapd logs. If issues persist, share the exact trap-sending command you used and any relevant log lines—this will help narrow down the problem further.

内容的提问来源于stack exchange，提问作者Luke Strong