Troubleshooting

1. Verify SNMP Trap Version and Credential Configuration

  • Confirm whether the device is sending SNMP traps using version v1, v2, or v3.
  • For SNMPv1 and v2: No encryption; the gateway can directly interpret Trap OIDs.
  • For SNMPv3:
    • If using default credentials, ensure the device matches the gateway’s predefined credentials.
    • If using custom credentials, verify they are properly Base64-encoded and configured in the gateway.
    • See Custom SNMPv3 Credential Configuration for more details.

2. Verify trap in exclusion list

We need to check in two areas to confirm whether a trap is in the exclusion list or not.

  1. Client Level SNMP Trap Configuration
  2. Global Level Exclusion

How to check if the trap is excluded in Client Level SNMP Trap Configuration

Check if there is any SNMP Trap configuration at client level (Setup -> Monitoring -> SNMP Traps Configuration) got created. If yes, please check whether they excluded the specific trap OID’s for either on all the devices or specific devices. Please check whether the trap OID is in exclude list or not.

How to check if the trap is in Global Exclusion List

Some of the trap definition itself says that ignore trap so we need to check the trap definition whether trap itself is ignored or not.

Example trap definition:

{
  "oid": "1.3.6.1.4.1.232.165.0.3",
  "trapName": "CPQPOWER-MIB::trapInformation",
  "currentState": "Ok",
  "excludeTrap": "Yes"
}

How do query the gateway database to get trap definitions?

  1. Connect to Gateway CLI.
  2. Connect to postgresql db in the gateway using psql -U vistara
  3. It will prompt for password and password is vistara
  4. Execute the following command to check the definition of specific trap OID. Syntax: select * from snmp_trap_definition_no where data->>'oid'='{Provide the snmp trap OID}'; Example: select * from snmp_trap_definition_no where data→>'oid'='1.3.6.1.4.1.232.165.0.3';

3. Verify if traps are being received by the gateway by analysing the vprobe.log

Following are the steps to verify whether traps are being received to the gateway by analysing the vprobe.log

  1. Login to the gateway CLI with sudo su and enter GCLI
  2. Add the following flag to enable logs.
  3. Flag add snmptrap.log on 30
  4. Click Exit to exit form GCLI.
  5. Grep the vprobe logs with below string grep 'Trap received: IP Address -' /var/log/app/vprobe.log

Example : Trap received: IP Address - 172.29.0.97 TrapOid - 1.3.6.1.4.1.30065.3.2.0.3

If you find the above string with trap OID, then SNMP trap was received to the gateway properly. Even if gateway received the trap and we didn’t see the trap in UI then, check if it is in dropping silently at gateway end (follow the above step to verify).

Check if trap was converted to an alert

If a trap was received by the Gateway and you want to verify whether it was converted into an alert, check the vprobe logs using the following command:

grep 'Sending trap alert: IP Address - {ipofdevice}' /var/log/app/vprobe.log

Example: Sending trap alert: IP Address - 192.168.3.230 TrapOid - 1.3.6.1.4.1.789.0.85

Capture Packets to Verify SNMP Trap Delivery

If no SNMP traps appear in the Gateway logs, capture network packets to confirm whether the traps are reaching the Gateway.

Classic Gateway

Run the following command on the Classic Gateway CLI:

tcpdump -v "ip host {ipaddress} && udp port 162" -s 3000 -w /home/ruser/snmptrap.pcap

Example


tcpdump -v "ip host 10.1.48.110 && udp port 162" -s 3000 -w /home/ruser/snmptrap.pcap

This command captures SNMP trap traffic sent to UDP port 162 from the specified IP address and writes it to a .pcap file.

NextGen Gateway

  1. SSH into the Gateway node and switch to the root user
sudo su
  1. Check if the NextGen Gateway pod is running

kubectl get pod <podName> -n <namespace>

  1. If the pod is running, launch a debug container
kubectl debug -it nextgen-gw-0 \
--image=us-docker.pkg.dev/opsramp-registry/gateway-cluster-images/gateway-debugger:1.0.0 \
--share-processes -- /bin/bash
  1. Once inside the debug container, run the following command to capture SNMP traps:
tcpdump -v "ip host {ipaddress} && udp port 11162" -s 3000 -w /home/ruser/snmptrap.pcap

Example: tcpdump -v "ip host 10.1.48.110 && udp port 11162" -s 3000 -w /home/ruser/snmptrap.pcap

  1. Press Ctrl+C to stop the capture once you’ve collected sufficient data.
  2. Download the .pcap file and open it using Wireshark to verify that SNMP traps from the device are reaching the Gateway.

Frequently Asked Questions

  1. Why there is mismatch in the SNMP traps?

If same trap is generated within 30 mins then that trap will be dropped at gateway end.

  1. Does OpsRamp generate repeat alerts if the same trap(with the Different state) is received within 30 minutes?

Yes

  1. Does OpsRamp generate direct Ok alerts without critical/warning ?

Yes, In case handler = “I”

  1. Why is OpsRamp treating these traps as direct OK alerts without any Critical/Warning state?

In some cases, customers send test traps to validate whether OpsRamp is correctly receiving and processing SNMP traps.

  • These test traps are not intended to represent actual fault conditions.
  • As such, the trap state (e.g., ok, debug, informational, critical, or warning) is not evaluated.
  • Instead, the focus is on confirming the integration pipeline from the device to OpsRamp.

To support this behavior, these traps are defined in the platform with a handler set to:

  • handler = “I”

This instructs OpsRamp to treat the trap as informational, and the platform generates a direct OK alert without requiring a preceding critical or warning state. This ensures a smooth testing experience without raising false-positive alerts.

  1. In NextGen Gateway, which IP needs to be configured in end device to send SNMP traps?

Configure the external IP of the UDP service on the end device to send traps to the Gateway. In this example, the ip which we need to configure on end device is 172.25.252.147.

  1. In the OpsRamp tool, what are the metric name and component name for an SNMP trap alert?

The metric name is SNMP TRAP, and the component name is the corresponding OID.The OID may be the SNMP trap OID or the recovery varbind oid based on the definition defined in the OpsRamp.

  1. In the OpsRamp tool, what are the subject and description for an SNMP trap alert if the trap definition is not available in OpsRamp?

If a trap definition is not available in OpsRamp, the SNMP trap alert will have the subject ‘ is critical’.