Skip to content

Traps configuration

A trap service is a simple server that can handle SNMP traps sent by SNMP agents.

Basic configuration fields

  • communities: communities used for version 1 and 2c of the SNMP. The default one is public.
  • usernameSecrets: names of the SNMPv3 secrets to use for authenticating incoming traps. See SNMPv3 configuration for details.

Configuration

Traps configuration is kept in the traps section of values.yaml:

traps:
  communities:
    1:
      - public
    2c:
      - public
      - homelab
  usernameSecrets:
    - secretv3
    - sc4snmp-homesecure-sha-des
  logLevel: "WARN"
  loadBalancerIP: 10.202.4.202

To apply changes, restart the trap deployment:

microk8s kubectl rollout restart deployment snmp-splunk-connect-for-snmp-trap -n sc4snmp

Info

The name of the deployment can differ based on the helm installation name. This can be checked with the following command: 

microk8s kubectl get deployments -n sc4snmp

Traps configuration is stored in the traps-config.yaml file:

communities:
  1:
    - public
  2c:
    - public
    - homelab
usernameSecrets:
  - secretv3
  - sc4snmp-homesecure-sha-des

To apply changes, run the following command inside the docker_compose directory:

sudo docker compose up -d

SNMPv3 security engine ID

In SNMPv3, every trap receiver must know the Security Engine ID of each sending device in advance. The receiver uses this ID together with the USM username, auth key, and priv key to authenticate incoming traps. Without the correct engine ID pre-registered, pysnmp rejects the trap before it even checks credentials.

Define all engine IDs under traps.securityEngineId in values.yaml:

traps:
  securityEngineId:
    - "80003a8c04"

By default, it is set to a one-element list: 80003a8c04.

The securityEngineID is a substitute of the -e variable in snmptrap. The following is an example of an SNMPv3 trap:

snmptrap -v3 -e 80003a8c04 -l authPriv -u snmp-poller -a SHA -A PASSWORD1 -x AES -X PASSWORD1 10.202.13.233 '' 1.3.6.1.2.1.2.2.1.1.1

Set the engine IDs in .env:

SNMP_V3_SECURITY_ENGINE_ID=80003a8c04,aab123456

Engine ID Discovery

If you are managing a large amount of traps agents it is possible to enable engine id discovery mode. The Engine ID Discovery feature automatically extracts the engine ID from each incoming SNMPv3 raw datagram and dynamically registers it with the SNMP engine, so the trap can be authenticated on the fly. The engine ID is only registered if the username matches a known user and stored in database.

traps:
  discoverEngineId: "true"

DISCOVER_ENGINE_ID=true

Info

It is recommended to enable this feature only during the initial setup of the traps receiver. Once the engine IDs for all required devices in the network have been collected, disable the feature to prevent unwanted engine ID registration and to improve trap processing efficiency by eliminating the overhead of extracting the engine ID from every incoming message.

Advanced configuration

Aggregate traps

In case you want to see traps events collected as one event inside Splunk:

traps:
  aggregateTrapsEvents: "true"

Set in .env:

SPLUNK_AGGREGATE_TRAPS_EVENTS=true

Define external gateway for traps

Using MetalLB LoadBalancer

If you use SC4SNMP on a multinode setup, configure loadBalancerIP. loadBalancerIP should be an IP assigned from your MetalLB address pool in the same subnet as your cluster nodes can reach.

traps:
  loadBalancerIP: 10.202.4.202

If you have enabled IPv6 dual-stack, provide both IPv4 and IPv6 addresses as a comma-separated list:

traps:
  loadBalancerIP: 10.202.4.202,2001:0DB8:AC10:FE01:0000:0000:0000:0001

Using NodePort

For single-node clusters or simple setups without a load balancer:

traps:
  service:
    type: NodePort
    externalTrafficPolicy: Cluster
    nodePort: 30000

Using Cloud Load Balancer

You can also deploy the traps receiver without MetalLB or NodePort, using Kubernetes Service annotations supported by your cloud platform. For example, on AWS EKS you can enable an AWS Network Load Balancer with annotations:

traps:
  service:
    usemetallb: false
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-type: external
      service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
      service.beta.kubernetes.io/aws-load-balancer-scheme: internal

In docker compose, the trap server is exposed directly on the host network. There is no load balancer or service abstraction layer — port mapping is handled by Docker and configured via the TRAPS_PORT variable in .env.

Traps port

The traps service port is controlled by the Kubernetes service configuration. By default, the trap receiver listens on UDP port 162. To expose a different port externally, adjust the service definition in values.yaml:

traps:
  service:
    type: NodePort
    nodePort: 30162

To change the external port exposed for the traps server, set in .env:

TRAPS_PORT=162

Define number of traps replicas

Set the number of trap receiver pod replicas in values.yaml:

traps:
  replicaCount: 2

Set the number of worker-trap container replicas in .env:

WORKER_TRAP_REPLICAS=2

Define debug level

Set the log level for the trap receiver in values.yaml:

traps:
  logLevel: "DEBUG"

Accepted values: DEBUG, INFO, WARNING, ERROR, CRITICAL, FATAL.

Set the log level for the trap container in .env:

TRAP_LOG_LEVEL=DEBUG

Accepted values: DEBUG, INFO, WARNING, ERROR, CRITICAL, FATAL.