Edge Delta SNMP Trap Source

The SNMP Trap source node enables Edge Delta to receive and process SNMP trap notifications from network devices and infrastructure components.

Overview

The SNMP Trap source node enables Edge Delta to receive and process SNMP trap notifications sent from network devices, servers, applications, and infrastructure components. It acts as a trap receiver (trap daemon) that listens for unsolicited SNMP notifications over UDP, supporting SNMPv1, SNMPv2c, and SNMPv3 trap formats. This allows you to capture real-time alerts and events from your entire infrastructure without actively polling devices. Unlike the SNMP Pull source which actively polls devices at intervals, SNMP Trap passively receives notifications when devices detect events.

AI Team: Configure this source using the SNMP Trap connector for streamlined setup in AI Team.

  • outgoing_data_types: log

The SNMP Trap source node is ideal for:

  • Network Device Monitoring: Receive alerts from routers, switches, firewalls, and wireless controllers
  • Infrastructure Alerting: Capture temperature, power, and hardware failure notifications
  • Application Event Collection: Gather custom traps from SNMP-enabled applications
  • Security Event Monitoring: Collect authentication failures and security violations
  • Environmental Monitoring: Receive alerts from UPS systems, cooling units, and sensors

Field Mapping

The SNMP Trap source node extracts and maps the following fields from incoming trap messages:

SNMP FieldAttribute NameDescription
Versionsnmp.versionSNMP version (1 or 2c)
PDU Typesnmp.pdu.typeProtocol Data Unit type (Trap, SNMPv2Trap)
Source IPnetwork.peer.ipIP address of the trap sender
Variablessnmp.varbindsVariable bindings as OID-value pairs
Variable Countsnmp.variables.countNumber of variables in the trap
Request IDsnmp.request.idRequest identifier (v2c only)
Enterprise OIDsnmp.enterprise_oidEnterprise identifier (v1 only)
Generic Trapsnmp.generic_trapGeneric trap type number (v1 only)
Generic Trap Namesnmp.generic_trap_nameHuman-readable trap type (v1 only)
Specific Trapsnmp.specific_trapEnterprise-specific trap number (v1 only)
Agent Addresssnmp.agent.addressAgent IP address (v1 only)
Trap OIDsnmp.trap_oidCombined trap identifier (v1 only)

SNMP Version Selection

The SNMP Trap source node supports multiple protocol versions to accommodate different security and compatibility requirements:

SNMP v1:

  • Legacy protocol with basic trap support
  • Simple community-based authentication
  • Widely supported across older network devices
  • Suitable for legacy infrastructure monitoring

SNMP v2c (default):

  • Enhanced trap format with inform capability
  • Community-based authentication using a shared password
  • Widely supported across network devices
  • Suitable for internal networks with basic security needs

SNMP v3:

  • Enhanced security with user-based authentication
  • Supports encryption for data privacy (AES, DES)
  • Multiple authentication protocols (MD5, SHA family)
  • Authoritative engine ID for secure trap ingestion
  • Recommended for production environments and sensitive data
  • Required when monitoring across untrusted networks

Choose v1 or v2c for quick setup and legacy device compatibility. Use v3 when security is a priority or when compliance requirements mandate encrypted communications.

Trap Type Mapping

SNMPv1 generic trap types are automatically mapped to descriptive names:

Generic TrapNameDescription
0coldStartAgent reinitialized with configuration changes
1warmStartAgent reinitialized without configuration changes
2linkDownNetwork interface went down
3linkUpNetwork interface came up
4authenticationFailureAuthentication attempt failed
5egpNeighborLossEGP neighbor relationship lost
6enterpriseSpecificVendor-specific trap

Example Configurations

Basic Configuration

This minimal configuration uses all default settings to receive SNMP traps. The node automatically listens on the standard SNMP trap port and accepts traps from any source.

nodes:
- name: snmp_trap_receiver
  type: snmp_trap_input

Custom Port Configuration

For environments where the standard trap port is unavailable or when running without elevated privileges, specify a custom port above 1024.

nodes:
- name: snmp_trap_custom_port
  type: snmp_trap_input
  port: 1162
  listen: "0.0.0.0"
  transport: udp

Advanced Configuration with Community String

This configuration demonstrates advanced options including community string validation and specific network interface binding.

nodes:
- name: snmp_trap_secure
  type: snmp_trap_input
  port: 162
  listen: "10.0.0.100"
  transport: udp
  community: "secret-community"
  source_metadata: true

SNMPv3 Secure Configuration

This configuration demonstrates enterprise-grade SNMPv3 trap reception with authentication and encryption. It includes SHA-256 authentication and AES-256 encryption for secure trap ingestion from devices across untrusted networks.

nodes:
- name: snmp_trap_v3_secure
  type: snmp_trap_input
  port: 162
  listen: "0.0.0.0"
  transport: udp
  version: v3
  user: snmp_admin
  security_level: auth_priv
  auth_type: sha256
  auth_password: my_auth_password
  privacy_type: aes256
  privacy_password: my_priv_password
  engine_id: "80001f8880c6127623566ce6a064"

Example Output

When SNMP traps are received, they are parsed and converted into structured log items. Below are examples showing the raw trap sent and the resulting processed data item.

SNMPv2c Cold Start Trap

Raw trap sent:

snmptrap -v 2c -c public <edge-delta-host> '' \
  1.3.6.1.6.3.1.1.5.1 \
  1.3.6.1.6.3.1.1.5.1 s "coldStart trap from router"

Processed data item in pipeline:

{
  "_type": "log",
  "timestamp": 1756958216967,
  "body": "SNMP 2c trap from 10.244.0.20",
  "resource": {
    "ed.source.name": "snmp_trap_receiver",
    "ed.source.type": "snmp_trap_input",
    "host.ip": "172.19.0.2",
    "host.name": "edge-delta-agent",
    "service.name": ""
  },
  "attributes": {
    "network.peer.ip": "10.244.0.20",
    "snmp.pdu.type": "SNMPv2Trap",
    "snmp.request.id": 2112302011,
    "snmp.varbinds": {
      ".1.3.6.1.2.1.1.3.0": {
        "centiseconds": 3522368,
        "duration": "9h47m3.68s",
        "seconds": 35223.68
      },
      ".1.3.6.1.6.3.1.1.4.1.0": ".1.3.6.1.6.3.1.1.5.1",
      ".1.3.6.1.6.3.1.1.5.1": "coldStart trap from router"
    },
    "snmp.variables.count": 3,
    "snmp.version": "2c"
  },
  "observed_timestamp": 1756958216990
}

SNMPv1 Enterprise-Specific Trap

Raw trap sent:

snmptrap -v 1 -c public <edge-delta-host> \
  1.3.6.1.4.1.9 192.168.1.1 6 33 100 \
  1.3.6.1.2.1.2.2.1.1 i 1

Processed data item in pipeline:

{
  "_type": "log",
  "timestamp": 1756958229890,
  "body": "SNMP trap enterpriseSpecific from 10.244.0.20",
  "resource": {
    "ed.source.name": "snmp_trap_receiver",
    "ed.source.type": "snmp_trap_input",
    "host.ip": "172.19.0.2",
    "host.name": "edge-delta-agent",
    "service.name": ""
  },
  "attributes": {
    "network.peer.ip": "10.244.0.20",
    "snmp.agent.address": "192.168.1.1",
    "snmp.enterprise_oid": ".1.3.6.1.4.1.9",
    "snmp.generic_trap": 6,
    "snmp.generic_trap_name": "enterpriseSpecific",
    "snmp.pdu.type": "Trap",
    "snmp.specific_trap": 33,
    "snmp.trap_oid": ".1.3.6.1.4.1.9.0.33",
    "snmp.varbinds": {
      ".1.3.6.1.2.1.2.2.1.1": 1
    },
    "snmp.variables.count": 1,
    "snmp.version": "1"
  },
  "observed_timestamp": 1756958229910
}

Temperature Alert Trap

Raw trap sent:

snmptrap -v 2c -c public <edge-delta-host> '' \
  1.3.6.1.4.1.9.9.13.1.3.0.2 \
  1.3.6.1.4.1.9.9.13.1.3.0.2 s "Temperature threshold exceeded: 85C"

Processed data item in pipeline:

{
  "_type": "log",
  "timestamp": 1756958222627,
  "body": "SNMP 2c trap from 10.244.0.20",
  "resource": {
    "ed.source.name": "snmp_trap_receiver",
    "ed.source.type": "snmp_trap_input",
    "host.ip": "172.19.0.2",
    "host.name": "edge-delta-agent",
    "service.name": ""
  },
  "attributes": {
    "network.peer.ip": "10.244.0.20",
    "snmp.pdu.type": "SNMPv2Trap",
    "snmp.request.id": 786929287,
    "snmp.varbinds": {
      ".1.3.6.1.2.1.1.3.0": {
        "centiseconds": 3522935,
        "duration": "9h47m9.35s",
        "seconds": 35229.35
      },
      ".1.3.6.1.4.1.9.9.13.1.3.0.2": "Temperature threshold exceeded: 85C",
      ".1.3.6.1.6.3.1.1.4.1.0": ".1.3.6.1.4.1.9.9.13.1.3.0.2"
    },
    "snmp.variables.count": 3,
    "snmp.version": "2c"
  },
  "observed_timestamp": 1756958222650
}

Required Parameters

name

A descriptive name for the node. This is the name that will appear in pipeline builder and you can reference this node in the YAML using the name. It must be unique across all nodes. It is a YAML list element so it begins with a - and a space followed by the string. It is a required parameter for all nodes.

nodes:
  - name: <node name>
    type: <node type>

type: snmp_trap_input

The type parameter specifies the type of node being configured. It is specified as a string from a closed list of node types. It is a required parameter.

nodes:
  - name: <node name>
    type: <node type>

Optional Parameters

port

The port parameter specifies the UDP port to listen on for incoming SNMP traps. The standard SNMP trap port is 162, but this requires elevated privileges. Common alternative ports include 1162 for unprivileged operation. If not specified, the node uses its default port configuration.

It is specified as an integer and is optional.

nodes:
  - name: <node name>
    type: snmp_trap_input
    port: 1162

listen

The listen parameter specifies the IP address to bind to for listening. Use “0.0.0.0” to listen on all network interfaces, or specify a particular IP address to restrict trap reception to a specific interface. Default is “0.0.0.0”.

It is specified as a string and is optional.

nodes:
  - name: <node name>
    type: snmp_trap_input
    listen: "0.0.0.0"

transport

The transport parameter specifies the transport protocol for receiving traps. SNMP traps are always sent via UDP according to the SNMP specification. This parameter defaults to “udp” and should not be changed.

It is specified as a string and is optional.

nodes:
  - name: <node name>
    type: snmp_trap_input
    transport: udp

version

The version parameter specifies the SNMP protocol version to use. Valid options are:

  • v1: SNMP version 1
  • v2c: SNMP version 2c (default)
  • v3: SNMP version 3 with enhanced security

It is specified as a string and is optional.

nodes:
  - name: <node name>
    type: snmp_trap_input
    version: v2c

community

The community parameter specifies the SNMP community string to validate incoming traps. If set, only traps with matching community strings will be accepted. If not specified, traps with any community string are accepted. This provides basic authentication for trap sources. This parameter is required when using SNMP v1 or v2c.

It is specified as a string and is optional when using v3.

nodes:
  - name: <node name>
    type: snmp_trap_input
    community: "public"

user

The user parameter specifies the SNMP v3 username. This parameter is required when using SNMP version 3. It is specified as a string.

nodes:
  - name: <node name>
    type: snmp_trap_input
    version: v3
    user: snmp_user

security_level

The security_level parameter specifies the security level for SNMP v3. Options include:

  • no_auth_no_priv: No authentication or encryption (default)
  • auth_no_priv: Authentication only
  • auth_priv: Authentication and encryption

It is specified as a string and is optional (v3 only).

nodes:
  - name: <node name>
    type: snmp_trap_input
    version: v3
    user: snmp_user
    security_level: auth_priv

auth_type

The auth_type parameter specifies the authentication protocol for SNMP v3. Options include:

  • md5: MD5 authentication (default)
  • sha: SHA-1 authentication
  • sha224: SHA-224 authentication
  • sha256: SHA-256 authentication
  • sha384: SHA-384 authentication
  • sha512: SHA-512 authentication

It is specified as a string and is optional (v3 only).

nodes:
  - name: <node name>
    type: snmp_trap_input
    version: v3
    user: snmp_user
    security_level: auth_priv
    auth_type: sha256

auth_password

The auth_password parameter specifies the authentication password for SNMP v3. This parameter is required when security_level includes authentication (auth_no_priv or auth_priv).

It is specified as a string and is optional (v3 only).

nodes:
  - name: <node name>
    type: snmp_trap_input
    version: v3
    user: snmp_user
    security_level: auth_priv
    auth_type: sha256
    auth_password: my_auth_password

privacy_type

The privacy_type parameter specifies the encryption protocol for SNMP v3. Options include:

  • des: DES encryption (default)
  • aes: AES-128 encryption
  • aes192: AES-192 encryption
  • aes256: AES-256 encryption
  • aes192c: AES-192 with CFB mode
  • aes256c: AES-256 with CFB mode

It is specified as a string and is optional (v3 only).

nodes:
  - name: <node name>
    type: snmp_trap_input
    version: v3
    user: snmp_user
    security_level: auth_priv
    privacy_type: aes256

privacy_password

The privacy_password parameter specifies the encryption password for SNMP v3. This parameter is required when security_level is auth_priv.

It is specified as a string and is optional (v3 only).

nodes:
  - name: <node name>
    type: snmp_trap_input
    version: v3
    user: snmp_user
    security_level: auth_priv
    privacy_type: aes256
    privacy_password: my_priv_password

engine_id

The engine_id parameter specifies the server’s authoritative engine ID for SNMP v3 trap reception. The engine ID is a unique identifier that establishes the authority for the SNMP agent receiving traps. If not specified, an engine ID will be auto-generated based on the server’s configuration.

The engine ID should be provided as a hexadecimal string. It is specified as a string and is optional (v3 only).

nodes:
  - name: <node name>
    type: snmp_trap_input
    version: v3
    user: snmp_user
    security_level: auth_priv
    auth_type: sha256
    auth_password: my_auth_password
    privacy_type: aes256
    privacy_password: my_priv_password
    engine_id: "80001f8880c6127623566ce6a064"

rate_limit

The rate_limit parameter enables you to control data ingestion based on system resource usage. This advanced setting helps prevent source nodes from overwhelming the agent by automatically throttling or stopping data collection when CPU or memory thresholds are exceeded.

Use rate limiting to prevent runaway log collection from overwhelming the agent in high-volume sources, protect agent stability in resource-constrained environments with limited CPU/memory, automatically throttle during bursty traffic patterns, and ensure fair resource allocation across source nodes in multi-tenant deployments.

When rate limiting triggers, pull-based sources (File, S3, HTTP Pull) stop fetching new data, push-based sources (HTTP, TCP, UDP, OTLP) reject incoming data, and stream-based sources (Kafka, Pub/Sub) pause consumption. Rate limiting operates at the source node level, where each source with rate limiting enabled independently monitors and enforces its own thresholds.

Configuration Steps:

  1. Click Add New in the Rate Limit section
  2. Click Add New for Evaluation Policy
  3. Select Policy Type:
  • CPU Usage: Monitors CPU consumption and rate limits when usage exceeds defined thresholds. Use for CPU-intensive sources like file parsing or complex transformations.
  • Memory Usage: Monitors memory consumption and rate limits when usage exceeds defined thresholds. Use for memory-intensive sources like large message buffers or caching.
  • AND (composite): Combines multiple sub-policies with AND logic. All sub-policies must be true simultaneously to trigger rate limiting. Use when you want conservative rate limiting (both CPU and memory must be high).
  • OR (composite): Combines multiple sub-policies with OR logic. Any sub-policy can trigger rate limiting. Use when you want aggressive rate limiting (either CPU or memory being high triggers).
  1. Select Evaluation Mode. Choose how the policy behaves when thresholds are exceeded:
  • Enforce (default): Actively applies rate limiting when thresholds are met. Pull-based sources (File, S3, HTTP Pull) stop fetching new data, push-based sources (HTTP, TCP, UDP, OTLP) reject incoming data, and stream-based sources (Kafka, Pub/Sub) pause consumption. Use in production to protect agent resources.
  • Monitor: Logs when rate limiting would occur without actually limiting data flow. Use for testing thresholds before enforcing them in production.
  • Passthrough: Disables rate limiting entirely while keeping the configuration in place. Use to temporarily disable rate limiting without removing configuration.
  1. Set Absolute Limits and Relative Limits (for CPU Usage and Memory Usage policies)

Note: If you specify both absolute and relative limits, the system evaluates both conditions and rate limiting triggers when either condition is met (OR logic). For example, if you set absolute limit to 1.0 CPU cores and relative limit to 50%, rate limiting triggers when the source uses either 1 full core OR 50% of available CPU, whichever happens first.

  • For CPU Absolute Limits: Enter value in full core units:

    • 0.1 = one-tenth of a CPU core
    • 0.5 = half a CPU core
    • 1.0 = one full CPU core
    • 2.0 = two full CPU cores
  • For CPU Relative Limits: Enter percentage of total available CPU (0-100):

    • 50 = 50% of available CPU
    • 75 = 75% of available CPU
    • 85 = 85% of available CPU
  • For Memory Absolute Limits: Enter value in bytes

    • 104857600 = 100Mi (100 × 1024 × 1024)
    • 536870912 = 512Mi (512 × 1024 × 1024)
    • 1073741824 = 1Gi (1 × 1024 × 1024 × 1024)
  • For Memory Relative Limits: Enter percentage of total available memory (0-100)

    • 60 = 60% of available memory
    • 75 = 75% of available memory
    • 80 = 80% of available memory
  1. Set Refresh Interval (for CPU Usage and Memory Usage policies). Specify how frequently the system checks resource usage:
  • Recommended Values:
    • 10s to 30s for most use cases
    • 5s to 10s for high-volume sources requiring quick response
    • 1m or higher for stable, low-volume sources

The system fetches current CPU/memory usage at the specified refresh interval and uses that value for evaluation until the next refresh. Shorter intervals provide more responsive rate limiting but incur slightly higher overhead, while longer intervals are more efficient but slower to react to sudden resource spikes.

The GUI generates YAML as follows:

# Simple CPU-based rate limiting
nodes:
  - name: <node name>
    type: <node type>
    rate_limit:
      evaluation_policy:
        policy_type: cpu_usage
        evaluation_mode: enforce
        absolute_limit: 0.5  # Limit to half a CPU core
        refresh_interval: 10s
# Simple memory-based rate limiting
nodes:
  - name: <node name>
    type: <node type>
    rate_limit:
      evaluation_policy:
        policy_type: memory_usage
        evaluation_mode: enforce
        absolute_limit: 536870912  # 512Mi in bytes
        refresh_interval: 30s

Composite Policies (AND / OR)

When using AND or OR policy types, you define sub-policies instead of limits. Sub-policies must be siblings (at the same level)—do not nest sub-policies within other sub-policies. Each sub-policy is independently evaluated, and the parent policy’s evaluation mode applies to the composite result.

  • AND Logic: All sub-policies must evaluate to true at the same time to trigger rate limiting. Use when you want conservative rate limiting (limit only when CPU AND memory are both high).
  • OR Logic: Any sub-policy evaluating to true triggers rate limiting. Use when you want aggressive protection (limit when either CPU OR memory is high).

Configuration Steps:

  1. Select AND (composite) or OR (composite) as the Policy Type
  2. Choose the Evaluation Mode (typically Enforce)
  3. Click Add New under Sub-Policies to add the first condition
  4. Configure the first sub-policy by selecting policy type (CPU Usage or Memory Usage), selecting evaluation mode, setting absolute and/or relative limits, and setting refresh interval
  5. In the parent policy (not within the child), click Add New again to add a sibling sub-policy
  6. Configure additional sub-policies following the same pattern

The GUI generates YAML as follows:

# AND composite policy - both CPU AND memory must exceed limits
nodes:
  - name: <node name>
    type: <node type>
    rate_limit:
      evaluation_policy:
        policy_type: and
        evaluation_mode: enforce
        sub_policies:
          # First sub-policy (sibling)
          - policy_type: cpu_usage
            evaluation_mode: enforce
            absolute_limit: 0.75  # Limit to 75% of one core
            refresh_interval: 15s
          # Second sub-policy (sibling)
          - policy_type: memory_usage
            evaluation_mode: enforce
            absolute_limit: 1073741824  # 1Gi in bytes
            refresh_interval: 15s
# OR composite policy - either CPU OR memory can trigger
nodes:
  - name: <node name>
    type: <node type>
    rate_limit:
      evaluation_policy:
        policy_type: or
        evaluation_mode: enforce
        sub_policies:
          - policy_type: cpu_usage
            evaluation_mode: enforce
            relative_limit: 85  # 85% of available CPU
            refresh_interval: 20s
          - policy_type: memory_usage
            evaluation_mode: enforce
            relative_limit: 80  # 80% of available memory
            refresh_interval: 20s
# Monitor mode for testing thresholds
nodes:
  - name: <node name>
    type: <node type>
    rate_limit:
      evaluation_policy:
        policy_type: memory_usage
        evaluation_mode: monitor  # Only logs, doesn't limit
        relative_limit: 70  # Test at 70% before enforcing
        refresh_interval: 30s

source_metadata

This option is used to define which detected resources and attributes to add to each data item as it is ingested by Edge Delta. You can select:

  • Required Only: This option includes the minimum required resources and attributes for Edge Delta to operate.
  • Default: This option includes the required resources and attributes plus those selected by Edge Delta
  • High: This option includes the required resources and attributes along with a larger selection of common optional fields.
  • Custom: With this option selected, you can choose which attributes and resources to include. The required fields are selected by default and can’t be unchecked.

Based on your selection in the GUI, the source_metadata YAML is populated as two dictionaries (resource_attributes and attributes) with Boolean values.

See Choose Data Item Metadata for more information on selecting metadata.

Advanced Configuration

SNMP v3 Configuration

SNMP v3 provides enhanced security for trap reception with user-based authentication and optional encryption. The following example demonstrates a complete v3 configuration:

nodes:
- name: snmp_trap_v3
  type: snmp_trap_input
  port: 162
  listen: "0.0.0.0"
  transport: udp
  version: v3
  user: trap_admin
  security_level: auth_priv
  auth_type: sha256
  auth_password: secure_auth_pass_123
  privacy_type: aes256
  privacy_password: secure_priv_pass_456
  engine_id: "80001f8880c6127623566ce6a064"

SNMP v3 Security Parameters

user

The SNMP v3 username (required for v3).

security_level

The security level for SNMP v3. Options include:

  • no_auth_no_priv: No authentication or encryption (default)
  • auth_no_priv: Authentication only
  • auth_priv: Authentication and encryption (recommended)
auth_type

Authentication protocol. Options include:

  • md5: MD5 authentication (default)
  • sha: SHA-1 authentication
  • sha224: SHA-224 authentication
  • sha256: SHA-256 authentication (recommended)
  • sha384: SHA-384 authentication
  • sha512: SHA-512 authentication
auth_password

Authentication password (required when security_level includes auth).

privacy_type

Encryption protocol. Options include:

  • des: DES encryption (default)
  • aes: AES-128 encryption
  • aes192: AES-192 encryption
  • aes256: AES-256 encryption (recommended)
  • aes192c: AES-192 with CFB mode
  • aes256c: AES-256 with CFB mode
privacy_password

Encryption password (required when security_level is auth_priv).

engine_id

The authoritative engine ID for SNMP v3. This is a unique hexadecimal identifier that establishes the authority for the SNMP agent receiving traps. If not specified, an engine ID will be auto-generated. For devices sending traps, you may need to configure this engine ID on the trap source to match the receiving agent.

Configuring SNMP Trap Sources

Cisco IOS/IOS-XE Configuration

Configure Cisco devices to send SNMP traps to Edge Delta. The snmp-server host command specifies the trap destination, while snmp-server enable traps controls which trap types are sent.

snmp-server host <edge-delta-host> version 2c public udp-port 1162
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps envmon fan shutdown supply temperature status
snmp-server enable traps cpu threshold
snmp-server enable traps memory bufferpeak
snmp-server enable traps config

This configuration sends authentication, environmental, CPU, memory, and configuration change traps to Edge Delta. The traps use SNMPv2c format with the “public” community string.

Juniper Junos Configuration

Configure Juniper devices to forward SNMP traps for system events and chassis alarms. The trap-group defines the destination and trap categories, while trap-options controls which specific events generate traps.

set snmp trap-group edge-delta version v2
set snmp trap-group edge-delta targets <edge-delta-host> port 1162
set snmp trap-group edge-delta categories authentication
set snmp trap-group edge-delta categories chassis
set snmp trap-group edge-delta categories link
set snmp trap-group edge-delta categories remote-operations
set snmp trap-options source-address lo0

Linux Net-SNMP Configuration

Configure Linux systems to send traps using snmpd and snmptrapd. The configuration enables standard system traps and custom application traps.

# /etc/snmp/snmpd.conf
trap2sink <edge-delta-host>:1162 public
authtrapenable 1
linkUpDownNotifications yes
defaultMonitors yes

After configuration, restart snmpd:

sudo systemctl restart snmpd

To send custom traps from applications or scripts:

# Send a custom application trap
snmptrap -v 2c -c public <edge-delta-host>:1162 '' \
  1.3.6.1.4.1.YOUR_ENTERPRISE_OID.1.1 \
  1.3.6.1.4.1.YOUR_ENTERPRISE_OID.1.1.1 s "Application error occurred" \
  1.3.6.1.4.1.YOUR_ENTERPRISE_OID.1.1.2 i 500

VMware ESXi Configuration

Configure ESXi hosts to send SNMP traps for hardware and virtual machine events:

# Enable SNMP
esxcli system snmp set --enable true

# Configure trap destination
esxcli system snmp set --targets <edge-delta-host>@1162/public

# Set community string
esxcli system snmp set --communities public

# Enable specific trap types
esxcli system snmp set --hwsrc sensors
esxcli system snmp set --loglevel info

Windows SNMP Service

Configure Windows Server to send SNMP traps:

  1. Install SNMP Service via Server Manager or PowerShell:
Install-WindowsFeature SNMP-Service -IncludeManagementTools
  1. Configure trap destination via Registry or PowerShell:
# Add trap destination
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\TrapConfiguration\public" `
  -Name "1" -Value "<edge-delta-host>:1162" -PropertyType String

# Restart service
Restart-Service SNMP

Application Integration

Python with pysnmp

Send custom traps from Python applications:

from pysnmp.hlapi import *
from pysnmp.proto import rfc1902

def send_trap(message, severity):
    error_indication, error_status, error_index, var_binds = next(
        sendNotification(
            SnmpEngine(),
            CommunityData('public'),
            UdpTransportTarget(('<edge-delta-host>', 1162)),
            ContextData(),
            'trap',
            NotificationType(
                ObjectIdentity('1.3.6.1.4.1.YOUR_OID.1.1')
            ).addVarBinds(
                ('1.3.6.1.4.1.YOUR_OID.1.1.1', OctetString(message)),
                ('1.3.6.1.4.1.YOUR_OID.1.1.2', Integer32(severity))
            )
        )
    )

    if error_indication:
        print(f'Trap failed: {error_indication}')

# Usage
send_trap("Database connection pool exhausted", 3)
send_trap("Backup completed successfully", 6)

Java with SNMP4J

Send traps from Java applications:

import org.snmp4j.*;
import org.snmp4j.mp.*;
import org.snmp4j.smi.*;
import org.snmp4j.transport.*;

public class TrapSender {
    public static void sendTrap(String message) throws IOException {
        TransportMapping transport = new DefaultUdpTransportMapping();
        Snmp snmp = new Snmp(transport);
        transport.listen();

        CommunityTarget target = new CommunityTarget();
        target.setCommunity(new OctetString("public"));
        target.setAddress(new UdpAddress("<edge-delta-host>/1162"));
        target.setVersion(SnmpConstants.version2c);

        PDU pdu = new PDU();
        pdu.setType(PDU.TRAP);
        pdu.add(new VariableBinding(SnmpConstants.sysUpTime,
            new TimeTicks(System.currentTimeMillis() / 10)));
        pdu.add(new VariableBinding(SnmpConstants.snmpTrapOID,
            new OID("1.3.6.1.4.1.YOUR_OID.1.1")));
        pdu.add(new VariableBinding(new OID("1.3.6.1.4.1.YOUR_OID.1.1.1"),
            new OctetString(message)));

        snmp.send(pdu, target);
        snmp.close();
    }
}

Testing SNMP Trap Configuration

After configuring your devices, test trap delivery using these methods:

Using snmptrap Command

# Test SNMPv2c trap
snmptrap -v 2c -c public <edge-delta-host>:1162 '' \
  1.3.6.1.6.3.1.1.5.3 \
  1.3.6.1.6.3.1.1.5.3 s "Test trap from $(hostname)"

# Test SNMPv1 trap
snmptrap -v 1 -c public <edge-delta-host>:1162 \
  1.3.6.1.4.1.9 $(hostname -I | awk '{print $1}') 6 1 '' \
  1.3.6.1.2.1.1.5.0 s $(hostname)

Verify Receipt

Check Edge Delta Live Capture to confirm traps are being received and parsed correctly. Look for:

  • Correct source IP in network.peer.ip
  • Proper trap type identification
  • Complete varbind extraction
  • Accurate timestamp processing

Best Practices

Port Selection

When configuring the SNMP Trap source node, consider port accessibility and security requirements. The standard SNMP trap port 162 requires root or administrative privileges, which may not be available in containerized deployments or restricted environments. Using port 1162 or another port above 1024 allows the Edge Delta agent to run without elevated privileges while maintaining compatibility with most SNMP trap senders that support custom port configuration.

Security Considerations

SNMP traps are transmitted in clear text without encryption, making them vulnerable to interception and spoofing. While community strings provide basic authentication, they are also sent unencrypted and should not be considered secure. Implement network segmentation to isolate SNMP traffic from untrusted networks, and use firewall rules to restrict which devices can send traps to your Edge Delta agents. For sensitive environments, consider using dedicated VLANs or VPNs for SNMP traffic. Monitor for unusual trap patterns that might indicate spoofing attempts or compromised devices.

Trap Filtering and Processing

Not all SNMP traps require the same level of attention or retention. Configure your source devices to send only relevant traps to reduce noise and processing overhead. Use Edge Delta processors to filter, enrich, or route traps based on their type, severity, or source. For example, you might route critical hardware failure traps to immediate alerting while aggregating informational traps for trend analysis. Consider implementing rate limiting for high-volume trap sources to prevent overwhelming your pipeline during network events or misconfigurations.

Performance Optimization

SNMP traps use UDP for transport, which provides low overhead but no delivery guarantee. During high-volume events like network outages, trap storms can occur where devices send thousands of traps simultaneously. Configure appropriate buffer sizes in your Edge Delta agent to handle burst traffic without drops. Monitor the snmp.variables.count attribute to identify complex traps that might impact processing performance. For environments with numerous trap sources, consider deploying multiple Edge Delta agents and using anycast or load balancing to distribute the trap processing load.

Varbind Processing

SNMP traps contain variable bindings (varbinds) that carry the actual event data. These are stored in the snmp.varbinds attribute as OID-value pairs. The OIDs are typically long numeric strings that require MIB files for human-readable translation. Consider using OTTL functions or processors to map common OIDs to meaningful field names in your pipeline. For time-based values like uptime, Edge Delta automatically provides multiple formats (centiseconds, duration string, seconds) for flexibility in downstream processing.

Troubleshooting

Traps Not Received

If traps are not appearing in Live Capture, verify network connectivity between trap sources and the Edge Delta agent using ping or traceroute. Check firewall rules on both the source device and the Edge Delta host to ensure UDP traffic is allowed on the configured port. Confirm the Edge Delta agent has successfully started the SNMP trap listener by checking agent logs. Test with a simple snmptrap command from the same network segment to isolate network versus configuration issues.

Authentication Failures

When using community string validation, ensure the community string in your trap source configuration exactly matches the one configured in the Edge Delta node. Community strings are case-sensitive. Check device logs for authentication failure messages. If traps from some devices work but others don’t, verify all devices are configured with the correct community string.

Incomplete Varbind Data

If varbind data appears truncated or missing, check whether the trap source is sending complete information. Some devices may require additional configuration to include all relevant OIDs in their traps. Use packet capture tools like tcpdump or Wireshark to examine the raw trap packets and verify their content. Large traps with many varbinds may be fragmented at the network layer - ensure your network MTU settings accommodate the trap sizes.

Port Binding Issues

If the agent cannot bind to the specified port, verify no other process is using that port with netstat -uln | grep <port>. For ports below 1024, ensure the Edge Delta agent has appropriate privileges or switch to a higher port number. In Kubernetes environments, confirm the pod security context allows the specified port. Container runtime security policies may also restrict certain port ranges.