1. Verify SNMP Trap Version and Credentials

• Check SNMP Trap Version:
  Ensure your device is sending SNMP traps using the correct version (v1, v2, or v3).
  • SNMPv1/v2: No encryption; the Gateway can directly interpret Trap OIDs.
  • SNMPv3:
    • If using predefined credentials, confirm the device matches the Gateway’s credentials.
    • If using custom credentials, verify they are Base64-encoded and properly configured in the Gateway.
      See Custom SNMPv3 Credential Configuration for details.

2. Check Trap Exclusion Lists

Traps may be excluded at two levels:

• Client Level:
  Go to Setup → Monitoring → SNMP Traps Configuration. Check if the specific trap OID is excluded for all or specific devices.
• Global Level:
  Some trap definitions are set to be ignored by default. Review the trap definition to see if it is excluded.

Example trap definition:

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

Check trap definitions in the Gateway database

To check trap definitions in the Gateway database, contact OpsRamp Support.

3. Check Gateway Logs (vprobe.log) for Trap Reception

To confirm if traps are being received by the Gateway:

1. Log in to the Gateway CLI with sudo su and enter GCLI.
2. Add the following flag to enable logs: flag add snmptrap.log on 30
3. Click exit command to exit from the GCLI.
4. Search the vprobe logs:

grep 'Trap received: IP Address -' /var/log/app/vprobe.log

Example log entry

Trap received: `IP Address - 172.29.0.97 TrapOid - 1.3.6.1.4.1.30065.3.2.0.3

If you see the trap OID in the logs, the Gateway received the trap. If the trap is not visible in the UI, verify whether it is being silently dropped (see exclusion steps above).

Check if a trap converted to an alert

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

4. Capture Packets to Verify SNMP Trap Delivery

If SNMP traps do not appear in the Gateway logs, capture network packets to verify delivery.

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

Note: Replace the ipaddress with the end device IP.

This 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 root:

sudo su

2. Check if the NextGen Gateway pod is running:

kubectl get pod <podName> -n <namespace>

Here, replace with your actual pod name and with the namespace where the gateway is deployed (default is usually default).

3. Launch a debug container:

  kubectl debug -it nextgen-gw-0 \
  --image=us-docker.pkg.dev/opsramp-registry/gateway-cluster-images/gat \
  --share-processes -- /bin/bash

Configure Custom SNMPv3 Credentials in NextGen Gateway

• Create a YAML file (e.g., snmp_trap_v3_creds.yml) at:

/home/gateway-admin/

• Add the credentials in this format:

 snmp_trap_v3_credentials: |-
  base64EncodedCredKey1
  base64EncodedCredKey2
  base64EncodedCredKey3

• Retrieve the chart version, run helm list -n <namespace>
• Upgrade the NextGen Gateway chart:

helm upgrade nextgen-gw oci://us-docker.pkg.dev/opsramp-registry/gateway-cluster-charts/nextgen-gw \
  --version <chart_version> -f snmp_trap_v3_creds.yml \
  -n <namespace> --reuse-values

• Restart the Gateway pod, kubectl delete pod nextgen-gw-0 -n <namespace>

5. Inside the debug container,

     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

6. Press Ctrl+C to stop the capture.
7. Download the .pcap file and open it with a packet analyzer to verify SNMP traps are reaching the Gateway.

Frequently Asked Questions

1. What happens if the same trap is generated within 30 minutes?
If the same trap is received within 30 minutes, it will be dropped by the Gateway.

2. Can I use custom SNMPv3 credentials?
Yes.

3. Are informational traps supported?
Yes, if the handler is set to “I”.

4. How does OpsRamp handle test traps sent by customers?
Customers may send test traps to validate SNMP trap processing. These are not treated as actual fault conditions.

• The trap state (ok, debug, informational, critical, warning) is not evaluated.
• The focus is on confirming the integration pipeline.
• These traps are defined with handler = "I", so OpsRamp treats them as informational and generates a direct OK alert, avoiding false positives.

5. How do I configure the end device to send traps to the Gateway?
Configure the external IP of the UDP service on the end device to send traps to the Gateway. For example, set the device to send traps to 172.25.252.147.

6. What is the metric and component name for SNMP traps?
The metric name and component name correspond to the SNMP trap OID or the recovery varbind OID, as defined in OpsRamp.

7. What happens if a trap definition is not available in OpsRamp?
If a trap definition is missing, the SNMP trap alert will have the subject ‘ is critical’.

8. Can I use varbinds to define severities and healing alerts?
Yes.

• OpsRamp supports using varbinds to define severity mappings and healing alerts.
• Some vendor MIBs define specific varbinds for severity, which can be referenced in trap configurations.
• Only varbinds that clearly represent severity or status are considered for mapping.
• If a varbind contains a large descriptive value or is highly dynamic, substring mapping is not supported.

Examples:

"panSystemDescription": "up"
"panSystemDescription": "down"
"panSystemDescription": 1
"panSystemDescription": 2

If a varbind contains a long or dynamic value, it cannot be used for substring-based severity mapping.

×