SNMP Trap Handler: User Interface and Administration

The SNMP Trap Handler provides a comprehensive web-based interface for monitoring, filtering, and managing SNMP trap notifications from your network devices. This guide covers all aspects of the trap management interface, from real-time dashboard monitoring to advanced filter configuration and device resolution mapping.

---

Accessing the SNMP Trap Interface

Navigate to the SNMP Trap Handler interface through the rConfig main navigation:

Network Services → SNMP Traps

The interface is organized into five sections accessible via tabs:

• Dashboard: Real-time monitoring and trap activity overview
• Trap Filters: Configure rules to match and process specific traps
• Device Resolution: Map trap source IPs to rConfig device records
• Logs: Historical trap records and processing details
• Settings (V8.4.0+): Which SNMP versions are accepted, the v1/v2c community and the SNMPv3 users

---

Dashboard: Real-Time Monitoring

The SNMP Trap Dashboard provides at-a-glance visibility into trap reception, processing status, and system health.

Service Status Indicator

Service Status Panel: Displays current operational state of the SNMP Trap Handler service:

• Online (Green): Service running and receiving traps
• Port 162 Inactive (Yellow): Service running but not bound to standard port
• Offline (Red): Service not running or unreachable

Last Update Timestamp: Shows when the dashboard last refreshed data from the trap handler, confirming real-time communication between the UI and the background service.

View Docs Link: Quick access to trap handler documentation and configuration guides.

Configuration: Shows the host and port the handler is bound to. From V8.4.0 the community string is shown only as Set or Not set, never the value, and an SNMPv3 line shows how many v3 users are enabled (or Off).

Tip

If the service shows as “Inactive” but you’ve confirmed it’s running via Supervisor, verify the configured port matches between the service configuration and your network device trap settings.

Key Performance Metrics

The dashboard displays four primary metrics providing operational insights:

Traps Today:

• Total number of traps received since midnight
• Percentage change compared to previous day
• Positive change indicates increased trap volume (potential issues or expanded monitoring)
• Negative change suggests reduced activity (potential device connectivity issues)

Matched Filters:

• Number of traps that matched configured filter rules today
• Total number of filter rules currently configured
• Low match rate may indicate filters need refinement or new filters required

Config Downloads:

• Number of configuration backups triggered by trap-based automation
• Shows effectiveness of trap-driven backup workflows
• Useful for tracking event-driven configuration captures

Failed Processing:

• Count of traps that encountered processing errors
• Failure rate percentage of total traps received
• High failure rates require investigation via Logs section

Recent Trap Activity

Real-time table displaying the latest SNMP traps as they arrive:

Column	Description
Time	Timestamp when trap was received (timezone: server local time)
Source	IP address of device that sent the trap
Type	Trap classification (if matched to filter) or “Unknown Trap”
Status	Processing status: Received, Matched, Processed, Failed

Status Indicators:

• Received: Trap successfully received by handler
• Matched: Trap matched one or more configured filters
• Processed: Associated actions executed successfully
• Failed: Error occurred during trap processing

Unknown Trap Classification: Traps showing “Unknown Trap” have not matched any configured filters. This is normal for devices sending traps without filter rules configured, but frequent unknown traps from important devices suggest filters should be created.

Top Sources by Trap Volume

Visual chart displaying devices generating the highest trap volumes over the selected time period. Useful for identifying:

• Most active devices requiring filter configuration
• Potential trap storms from malfunctioning equipment
• Devices needing trap rate limiting or source filtering

No Device Activity: Displayed when no traps have been received or device resolution has not mapped trap sources to rConfig devices.

Filter Performance Analysis

Filter Match Statistics:

• Matched Traps: Count of traps successfully matched by filters
• Unmatched Traps: Count of traps with no filter match
• Match Rate: Percentage of total traps matching filters

Optimization Insight: Low match rates indicate opportunity to expand filter coverage. High match rates confirm effective filter configuration for your environment.

Processing Performance

Processing Metrics:

• Avg Processing Time: Mean time to process each trap (milliseconds)
• Actions Executed: Total number of automated actions triggered by matched traps
• Device Summary: Statistics on device resolution effectiveness

Performance Expectations:

• Processing times under 50ms: Excellent performance
• Processing times 50-200ms: Normal performance
• Processing times over 200ms: May indicate database optimization needed or complex filter actions

---

Trap Filters: Intelligent Trap Processing

Trap filters define rules that match incoming SNMP traps and trigger automated actions. Filters enable intelligent trap handling, transforming raw notifications into actionable workflows.

Understanding Trap Filters

What Filters Do:

Trap filters examine incoming SNMP traps against defined criteria (OID, vendor, source) and execute specified actions when matches occur. This automation enables:

• Selective Configuration Backups: Capture device config when “configuration changed” traps received
• Alert Routing: Send notifications for critical traps while ignoring routine events
• Event Correlation: Link trap events with configuration changes for audit trails
• Action Throttling: Prevent action overload using cooldown periods

Filter Matching Process:

1. Trap received from network device
2. Handler extracts trap OID and varbinds
3. Compares trap against all enabled filters
4. First matching filter triggers configured actions
5. Cooldown period prevents repeat action execution

Filter Management Table

The Filters table displays all configured trap filters with key attributes:

Column	Description
Name	Descriptive filter identifier
Description	Detailed purpose and use case
Trap OID	Object Identifier that filter matches
Vendor	Device manufacturer/platform
Status	Enabled/Disabled state
Actions	Edit or delete filter

Bulk Operations: Select multiple filters to enable, disable, or delete in a single operation.

Creating Trap Filters

Click Add to launch the trap filter creation form:

Basic Filter Configuration

Trap Type (Optional):

• Select from pre-configured trap examples imported from common vendor MIBs
• Auto-populates Name, Description, OID, and Vendor fields
• Useful for standard traps (linkDown, configChanged, authenticationFailure)
• Leave blank for custom or uncommon traps

Name (Required):

• Descriptive identifier for the filter
• Best practice: Include vendor, trap purpose, and action
• Example: “Cisco Config Change - Auto Backup”

Description:

• Detailed explanation of filter purpose and expected behavior
• Document business rationale and troubleshooting notes
• Example: “Triggers immediate configuration backup when Cisco device sends ciscoConfigManEvent trap. Used for audit compliance on production core routers.”

Trap OID (Required):

• Complete SNMP Object Identifier for the trap
• Must match trap OID from device exactly
• Example: 1.3.6.1.4.1.9.9.43.2.0.1 (Cisco config change)
• Use MIB browsers or vendor documentation to identify correct OIDs

Caution

OID Accuracy Critical: Trap OID must match exactly as sent by devices. Even minor differences (trailing zero, wrong prefix) prevent filter matching. Verify OIDs using trap logs before creating filters.

Vendor (Required):

• Select device manufacturer from dropdown
• Used for filter organization and reporting
• Helps identify vendor-specific trap patterns

Status:

• Enabled: Filter actively matches traps and executes actions
• Disabled: Filter stored but inactive (useful for testing or temporary suspension)

Advanced Filter Settings

Cooldown Override:

• Minimum time period (seconds) before filter can trigger again for the same device
• Prevents action overload during trap storms or rapid repeated events
• Default: 61 seconds (configurable via SNMP_TRAP_CONFIG_COOLDOWN environment variable)
• Lower values: More responsive but higher action frequency
• Higher values: Reduces action load but may miss legitimate events

Cooldown Use Cases:

• Configuration backup filters: 120-300 seconds (avoid backup storms)
• Critical alerts: 61-120 seconds (ensure timely notification)
• Routine monitoring: 300-600 seconds (reduce notification noise)

Action Configuration

Available Actions:

Select one or more actions to execute when the filter matches a trap:

• Download Device Configuration: Trigger an immediate config backup from the matched device
• Detailed Logging: Log comprehensive trap details and varbinds for deeper analysis
• Send Alert: Send notifications via configured channels (email, Slack, Teams)
• Webhook: POST trap data to an external HTTP endpoint
• Custom Script: Execute a custom PHP script or shell command

Action Sequencing: Actions execute in the order displayed. Capture actions (backups, detailed logging) should precede notifications to ensure data is recorded before alerting.

Action Configuration Example:

Filter: "Juniper Config Commit Notification"
Actions:
  1. Download Device Configuration
  2. Send Alert (email/Slack channels)
  3. Webhook (https://monitoring.company.com/api/events)

Filter Best Practices

Start with Common Traps: Configure filters for high-value traps first:

• Configuration change notifications
• Authentication failures
• Critical hardware alerts
• Link state changes on critical interfaces

Test Before Enabling: Create filters in disabled state, verify OID accuracy in logs, then enable after confirming matches.

Document Filter Logic: Use description field to explain:

• Why filter was created
• Expected trap frequency
• What actions accomplish
• Any special considerations

Monitor Match Rates: Review dashboard filter performance regularly. Filters with zero matches may have incorrect OIDs or be obsolete.

Use Appropriate Cooldowns: Balance responsiveness with action overload. Start conservative (5-10 minutes), adjust based on actual trap patterns.

---

Device Resolution: Mapping Trap Sources

Device Resolution maps trap source IP addresses to rConfig device records, enabling trap correlation with device configurations and automated workflows.

Why Device Resolution Matters

The Challenge: Network devices often send traps from management interfaces, loopback addresses, or secondary IPs that don’t match the IP address configured in rConfig for device management. Without resolution mapping, rConfig cannot associate traps with device records.

The Solution: Device IP mappings explicitly link trap source IPs to rConfig devices, enabling:

• Accurate trap-to-device correlation in logs and reports
• Device-specific filter actions (backup correct device when trap received)
• Historical analysis of trap patterns per device
• Integration with device-specific configuration workflows

Example Scenario:

• Device “core-router-01” in rConfig: 10.1.1.1 (management IP)
• Traps sent from: 192.168.100.1 (loopback interface)
• Without mapping: Traps show “No device” in logs
• With mapping: Traps correctly associated with core-router-01

How rConfig Finds the Device

For each trap, rConfig looks up the source IP in this order:

1. Enabled IP mapping in this table. Used as-is.
2. Device management IP. If a device’s IP address in rConfig equals the trap source IP, that device is used, and rConfig adds an auto-created mapping for it so later traps resolve from the mapping.
3. No match. The trap is stored with no device, and device actions such as backups are skipped.

Results are cached for 10 minutes, and the cache for an IP clears whenever its mapping is saved or deleted.

You only need to add mappings by hand when a device sends traps from an address that isn’t its management IP (loopbacks, secondary interfaces, NAT). Auto-created mappings appear faded with an Auto Created badge. They can be deleted but not edited. Delete one if a device has been readdressed, and it is recreated on the next trap if the address still matches.

Device Resolution Table

Displays all configured IP mappings:

Column	Description
Device	rConfig device name
IP Address	Trap source IP to map
Status	Enabled/Disabled
Auto Created	Created by rConfig from a device management IP match, not by a user
Notes	Mapping documentation
Actions	Edit or delete mapping

Creating Device Mappings

Click Add to create a new device IP mapping:

Device (Required):

• Select target device from rConfig device inventory
• Use search/filter to locate device by name or IP
• Device must exist in rConfig before creating mapping

IP Address (Required):

• Enter trap source IP address exactly as seen in trap logs
• Format: Standard IPv4 (e.g., 192.168.100.1) or IPv6
• This is the IP address from which the device sends traps

Status:

• Enabled: Mapping actively resolves trap sources
• Disabled: Mapping stored but not used (testing or temporary)

Notes:

• Document why mapping is needed
• Record interface or source information
• Example: “Loopback0 interface used for all SNMP operations”

Mapping Best Practices

Identify Unmapped Sources: Review trap logs for “No device” entries, note source IPs, create mappings for devices sending valuable traps.

Document Interface Context: Use Notes field to record which physical/logical interface sends traps. Aids troubleshooting when trap sources change.

Verify After Creation: After adding mapping, confirm next trap from that IP correctly associates with device in trap logs.

Handle Multi-Interface Devices: Devices with multiple management IPs sending traps may require multiple mappings (one per source IP).

Update During Network Changes: When devices are readdressed or management interfaces change, update or create new mappings to maintain correlation.

---

Logs: Trap History and Analysis

The Logs section provides searchable, filterable access to all received SNMP traps with detailed processing information.

Log Table Columns

Column	Description
ID	Unique trap record identifier
Source	IP address and port that sent the trap. From V8.4.0 also the SNMP version (SNMPv2c, SNMPv3) and, for v3, the user it was sent as
Trap OID	Object Identifier of received trap (N/A if not parsed)
Event Type	Trap classification from filter or parsed MIB. Refused traps show Trap Rejected
Device	Mapped device name or “No device” if unmapped
Filter Match	Name of matched filter or “No match”
Status	Processing status (received, processed, filtered_out, error, and rejected from V8.4.0)
Created	Timestamp when trap was received
Actions	View details, raw trap data, or delete

Understanding Log Entries

Example Log Entry:

ID: 1009
Source: 127.0.0.1
Trap OID: N/A
Event Type: Memory Usage Check
Device: No device
Filter Match: No match
Status: received
Created: 12/10/2025, 20:15:13

Analysis: This trap was received from localhost (likely test trap), did not match any filter, and has no device mapping. The event type suggests it’s a monitoring trap that may not require action.

Searching and Filtering Logs

Search Capabilities:

• Filter by source IP address
• Search by SNMPv3 user name (V8.4.0+)
• Search by device name
• Filter by event type or trap OID
• Date range selection
• Status filtering (received, processed, failed)

Common Search Scenarios:

Find all traps from specific device:

1. Enter device name in search
2. Review trap frequency and types
3. Identify candidates for filter creation

Identify failed processing:

1. Filter status: “failed”
2. Review error details in trap details
3. Troubleshoot filter actions or device mappings

Analyze trap patterns:

1. Select date range
2. Export filtered results
3. Analyze in spreadsheet for trends

Rejected Traps (V8.4.0+)

When the handler refuses a trap, it writes a log row with status rejected and a red reason under the badge. Nothing else happens: no filter runs and no backup is triggered. To stop a misconfigured device flooding the table, rConfig keeps one rejected row per source IP and reason each minute.

Reason shown	What it means	Fix
Wrong community string	A v1/v2c trap carried a different community while Require Community is on	Match the device’s snmp-server host community to the one stored in Settings
SNMP version not accepted	The trap’s version is switched off in Settings	Switch the version on, or move the device to the accepted version
Unknown or disabled v3 user	No enabled SNMPv3 user has that name	Add the user, or enable it, in Settings
Wrong auth password or protocol	The v3 signature check failed	Re-enter the auth password and check the protocol (for example SHA vs SHA-256) on both sides
Wrong privacy password or protocol	The v3 trap could not be decrypted	Re-enter the privacy password and check the protocol (for example AES-128 vs AES-256)
Encryption setting does not match the user	The device sent encrypted traps to an auth-only user, or the reverse	Make Encrypt traps on the user match the device’s priv / auth level
Engine ID does not match the user	The user is pinned to a different engine ID	Correct the engine ID, or clear it to accept any device
v3 without authentication	The device sent noAuthNoPriv	rConfig never accepts unauthenticated v3. Configure the device user with at least auth

The Source column shows which user name the device claimed, which is usually the fastest way to spot a typo.

Trap Detail View

Click the actions menu (⋯) and select “View Details” to see complete trap information:

Detail View Includes:

• Complete varbind list (all OID-value pairs in trap)
• Raw trap PDU data
• Processing timeline (received, matched, actions executed)
• Error messages if processing failed
• Associated device configuration snapshot (if backup action triggered)

Use Cases for Detail View:

• Troubleshooting filter matching issues
• Verifying trap content for filter creation
• Investigating processing failures
• Auditing automated actions executed

Log Retention and Management

Automatic Retention: Trap logs are retained according to system configuration (default: 90 days). Older logs are automatically purged to manage database size.

Manual Log Management:

• Export logs to CSV for external analysis
• Delete specific trap records manually
• Bulk delete using filters and date ranges

Tip

Performance Tip: For environments receiving high trap volumes (thousands per day), schedule regular log exports and purges of old data to maintain optimal database performance. Consider archiving exported logs for long-term compliance requirements.

---

Settings: Receiver and SNMPv3 Users (V8.4.0+)

Available in rConfig V8.4.0+

Before 8.4.0 the community string was a command-line flag on the trap handler, it was never checked against incoming traps, and SNMPv3 traps could not be received. Upgrading keeps that behaviour until you change these settings: v1/v2c stays on, Require Community stays off and SNMPv3 stays off.

The Settings tab controls which traps the handler accepts. Saved changes reach the running trap service within about 10 seconds. You don’t need to restart it or re-run the Supervisor install.

Trap Receiver

Setting	What it does
Accept SNMPv1/v2c	When off, every v1 and v2c trap is rejected
Community String	The community your devices send. Stored encrypted and never shown again, so the box is always blank after saving. Leave it blank to keep the stored value
Require Community	When on, v1/v2c traps with any other community are rejected. When off, any community is accepted
Accept SNMPv3	When on, v3 traps from the users below are accepted. When off, all v3 traps are rejected

Click Save to apply. rConfig won’t let you switch on Require Community without a community stored, or switch off both versions. To stop receiving traps altogether, stop the service from the Dashboard instead.

Caution

Switch on Require Community only after every device sends the stored community. Traps from devices that don’t will be rejected straight away and won’t trigger backups. Check the Logs tab for rejected rows after the change.

SNMPv3 Users

Devices sending v3 traps must use one of the users in this table. Each row shows the username and description, the security level (authPriv or authNoPriv), the authentication and privacy protocols, the engine ID (or Any device), and an on/off switch. Use the actions menu (⋯) to edit or delete a user.

Click Add User to create one:

Field	Notes
Username	Must match the user configured on the device. Up to 32 characters, no spaces
Engine ID	Leave empty to accept the user from any device. Enter a device’s engine ID (on Cisco IOS, show snmp engineID) to accept it from that device only. 10 to 64 hex characters; 0x and : separators are fine
Authentication	MD5, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512, plus the auth password (at least 8 characters)
Encrypt traps	On for authPriv (signed and encrypted), off for authNoPriv (signed only)
Privacy	DES, AES-128, AES-192 or AES-256, plus the privacy password (at least 8 characters). Shown only while Encrypt traps is on
Status	Disabled users are ignored, and their traps are rejected as an unknown user
Description	Optional, for example the device group using this user

Passwords are stored encrypted and never returned. When you edit a user the password boxes are blank; leave them blank to keep the current passwords.

For MD5 and SHA-1 users the dialog shows a Cisco IOS starting point you can copy, with placeholders where the passwords go:

snmp-server group RCONFIG-TRAPS v3 priv
snmp-server user rconfig-traps RCONFIG-TRAPS v3 auth sha <auth-password> priv aes 128 <priv-password>
snmp-server host <rconfig-ip> version 3 priv rconfig-traps
snmp-server enable traps config

SHA-2 command syntax differs across platforms, so no example is shown for those. Check your device documentation.

Tip

noAuthNoPriv traps are always rejected. They carry no proof of who sent them, which is weaker than a v2c community. Prefer authPriv with SHA-256 and AES-128 or stronger where your devices support it.

Test a new user from the rConfig server with snmptrap -v3; the setup guide has the full command.

---

Common Workflows

Workflow 1: Setting Up Trap-Driven Backups

Objective: Automatically backup device configuration when config change traps received.

Steps:

1. Identify Config Change Traps:

   • Review Logs for traps from target devices
   • Note trap OID for configuration change events
   • Example Cisco OID: 1.3.6.1.4.1.9.9.43.2.0.1

2. Create Device Mapping (if needed):

   • Navigate to Device Resolution
   • Add mapping for trap source IP to rConfig device
   • Verify mapping works by checking subsequent trap logs

3. Configure Trap Filter:

   • Navigate to Trap Filters
   • Click Add, name filter “Config Change - Auto Backup”
   • Enter trap OID from step 1
   • Select vendor (Cisco)
   • Add action: “Download Configuration”
   • Set cooldown: 300 seconds (5 minutes)
   • Enable filter

4. Test Configuration:

   • Make configuration change on test device
   • Verify trap appears in logs with filter match
   • Confirm backup job created in rConfig
   • Validate configuration captured correctly

5. Monitor and Adjust:

   • Review dashboard metrics daily
   • Adjust cooldown if too many/few backups triggered
   • Expand to additional devices as validated

Workflow 2: Resolving “Unknown Trap” Sources

Objective: Identify and map unmapped trap sources to rConfig devices.

Steps:

1. Identify Unknown Sources:

   • Navigate to Dashboard
   • Review Recent Trap Activity
   • Note source IPs showing “No device”

2. Cross-Reference with rConfig Inventory:

   • Open Devices section
   • Search for devices potentially sending traps
   • Check device management IP vs. trap source IP
   • Identify devices with secondary management interfaces

3. Create Device Mappings:

   • Navigate to Device Resolution
   • For each unmapped source IP:
     • Add mapping to corresponding device
     • Document interface in Notes
     • Enable mapping

4. Verify Resolution:

   • Return to Logs
   • Check if new traps from mapped IPs show device names
   • Confirm “No device” count decreasing in dashboard

Workflow 3: Troubleshooting Failed Trap Processing

Objective: Diagnose and resolve trap processing failures.

Steps:

1. Identify Failures:

   • Check Dashboard “Failed Processing” metric
   • Navigate to Logs, filter by status: “failed”
   • Review failed trap entries

2. Analyze Failure Details:

   • Click actions menu on failed trap
   • Select “View Details”
   • Review error message and processing timeline
   • Common issues:
     • Device mapping missing
     • Filter action failed (backup unreachable device)
     • Webhook endpoint unavailable
     • Email notification misconfigured

3. Resolve Root Cause:

   • For mapping issues: Create device resolution entry
   • For action failures: Verify action configuration (email, webhook URL)
   • For device issues: Verify device accessibility from rConfig
   • For filter problems: Review filter OID and action settings

4. Test Resolution:

   • Trigger test trap to verify fix
   • Monitor for recurring failures
   • Adjust filter or mapping configuration if needed

---

Performance and Optimization

Dashboard Performance

Refresh Behavior: Dashboard auto-refreshes every 30 seconds when viewing. Manual refresh available via browser refresh.

Large Dataset Handling: Dashboards with thousands of daily traps may show brief loading delays. This is normal for high-volume environments.

Log Query Optimization

For Large Log Tables (100,000+ entries):

• Use specific date ranges rather than “All time”
• Filter by device or source IP before exporting
• Schedule regular log purges for old data
• Consider archiving historical logs externally

Filter Efficiency

Optimize Filter Performance:

• Keep total filter count under 100 for optimal performance
• Disable unused or obsolete filters rather than deleting (preserves historical data)
• Use specific trap OIDs rather than wildcard matching
• Monitor processing time metrics in dashboard

---

Troubleshooting Common Issues

Dashboard Shows “Service Offline”

Symptom: Service status indicator shows red “Offline” state.

Resolution:

1. Verify Supervisor service status:

   supervisorctl status rconfig-snmp-trap

2. If stopped, start service:

   supervisorctl start rconfig-snmp-trap

3. If won’t start, review troubleshooting in Supervisor Management
4. Refresh dashboard after service startup

Traps Show as Rejected (V8.4.0+)

Symptom: Traps appear in the Logs tab with status rejected and nothing else happens.

Resolution: Read the reason under the badge and use the rejected traps table. The most common causes are a community mismatch after switching on Require Community, and a v3 protocol or password that differs between the device and the user in Settings.

Filters Not Matching Traps

Symptom: Traps appear in logs but show “No match” despite configured filters.

Resolution:

1. Verify filter is enabled (Status column in Trap Filters table)
2. Check trap OID in logs matches filter OID exactly
3. Review filter configuration for typos in OID
4. Verify vendor selection matches trap source device
5. Check filter cooldown hasn’t prevented matching (wait cooldown period, retry)

Device Resolution Not Working

Symptom: Traps still show “No device” after creating mapping.

Resolution:

1. Verify mapping is enabled (Status column)
2. Confirm IP address entered matches trap source exactly (check Logs)
3. Verify device exists in rConfig device inventory
4. Check for typos in IP address or device selection
5. Try deleting and recreating mapping

Actions Not Executing

Symptom: Filters match but actions don’t execute (no backup, no email).

Resolution:

1. Check trap detail view for action execution errors
2. Verify action configuration in filter settings:
   • Backup action: Device is reachable and in rConfig
   • Email action: SMTP configured correctly in rConfig
   • Webhook action: Endpoint URL is accessible
3. Review processing errors in storage/logs/snmp-YYYY-MM-DD.log. Backup and alert actions run as queued jobs, so also check failed jobs in Horizon
4. Test action manually outside trap handler to verify configuration

---

Security Considerations

Access Control

User Permissions: SNMP trap management requires administrative privileges. Ensure only authorized personnel have access to:

• Trap filter configuration (prevents unauthorized automation)
• Device resolution settings (maintains device association integrity)
• Log viewing (trap data may contain sensitive device information)

From V8.4.0 the Settings tab and its API need the settings view and update permissions. The community string and SNMPv3 passwords are never returned to the browser, shown on the dashboard, or stored in trap log rows.

Sensitive Data in Traps

Trap Content Awareness: SNMP traps may contain sensitive information:

• Configuration snippets
• Internal IP addresses and network topology
• User authentication failures with usernames
• System health metrics revealing vulnerabilities

Best Practices:

• Restrict log access to network operations staff only
• Implement log retention policies compliant with data protection requirements
• Sanitize trap data before external integrations (webhooks, tickets)
• Audit filter configurations regularly to prevent unauthorized data exfiltration

---

What’s next

• SNMP Trap Handler Setup and CLI - Service installation, Supervisor configuration, and CLI management commands
• SNMP Traps Concepts - How SNMP trap handling integrates with rConfig workflows
• Device Management - Managing device inventory and connectivity settings

---

Quick Reference

Accessing SNMP Trap Interface

Navigation: Network Services → SNMP Traps

Key Dashboard Metrics

• Traps Today: Total traps received since midnight
• Matched Filters: Traps matching configured rules
• Config Downloads: Backups triggered by traps
• Failed Processing: Traps with processing errors

Creating a Basic Filter

1. Navigate to Trap Filters tab
2. Click Add button
3. Enter Name (required), Description, Trap OID (required)
4. Select Vendor (required)
5. Configure Actions (Download Configuration, Send Email, etc.)
6. Set Status to Enabled
7. Click Save

Creating Device Mapping

1. Navigate to Device Resolution tab
2. Click Add button
3. Select Device from dropdown (required)
4. Enter trap source IP Address (required)
5. Add Notes documenting interface/purpose
6. Set Status to Enabled
7. Click Save

Adding an SNMPv3 User (V8.4.0+)

1. Navigate to Settings tab
2. Switch on Accept SNMPv3 and click Save
3. Click Add User
4. Enter Username, pick the Authentication protocol and enter its password
5. Leave Encrypt traps on, pick the Privacy protocol and enter its password
6. Leave Engine ID empty unless you want to pin the user to one device
7. Click Save, then configure the same user on the device

Viewing Trap Details

1. Navigate to Logs tab
2. Locate trap record in table
3. Click actions menu (⋯)
4. Select “View Details”
5. Review complete trap information and processing timeline