SNMP Configuration Guide
This document provides step-by-step instructions for enabling, configuring, and verifying SNMP (Simple Network Management Protocol) functionality between a Luna Network HSM (acting as the SNMP Agent — the device that sends SNMP traps or informs) and an SNMP Manager running on Linux (receiver of those traps). It covers configuration on the Luna Network HSM device via REST API and configuration on the SNMP manager (Linux host) for traps, MIBs, and notifications. It is broken down into the following sections:
>Basic Understanding of Traps and Informs
>Overview of SNMP Functionality
>Configuring SNMP on the SNMP Manager (Linux Host)
>Configuring SNMP on the Luna Network HSM Device
>Testing SNMP Query Operations
>Testing SNMP Trap Configuration
>Verifying Trap Reception on SNMP Manager
Basic Understanding of Traps and Informs
In SNMP, traps and informs are notifications sent from the Luna Network HSM (agent) to the SNMP Manager to report events or status changes. The key difference is that traps are one-way messages sent without acknowledgment — they are faster but less reliable since lost traps are not re-sent. Informs, however, require the SNMP Manager to acknowledge receipt; if no acknowledgment is received, the HSM resends the message. This makes informs more reliable but slightly slower due to the confirmation process. In general, traps are suitable for routine monitoring, while informs are preferred for critical alerts where confirmation of delivery is important.
Overview of SNMP Functionality
The Luna Network HSM supports SNMPv3, providing secure communication and monitoring capabilities for HSM status, operational metrics, and event traps.
Understanding the Three SNMP Endpoints:
The Luna Network HSM provides three distinct REST API endpoints for SNMP configuration, each serving a different purpose:
>POST /api/lunasa/snmp/users: Creates SNMPv3 users on the HSM to enable SNMP query operations (such as snmpwalk, snmpget) from an SNMP Manager. This allows monitoring of HSM status and metrics.
>POST /api/lunasa/snmp/traps: Configures trap/inform destinations that use the internal LSTA (Luna SNMP Trap Agent) service to send HSM-specific events. This operates independently of SNMP users and is used for runtime events like operational issues or internal state changes.
>POST /api/lunasa/snmp/users/{userId}/notifications: Configures SNMP service-level notifications (like cold start events). These notifications are sent by the SNMP service itself for service lifecycle events.
The configuration process includes:
>Creating SNMP users on the HSM for query operations.
>Defining trap destinations for HSM event notifications.
>Setting up user-specific notifications for SNMP service events.
>Configuring the SNMP Manager to receive and interpret these traps.
Prerequisites
On SNMP Manager (Linux):
>Root or sudo privileges.
>Network connectivity with the HSM (UDP ports 161 and 162 open).
>net-snmp version 5.8 or greater to support extended authentication and privacy protocols (SHA-256, AES-192, etc.).
Configuring SNMP on the SNMP Manager (Linux Host)
1.Install required packages,
yum install net-snmp-devel net-snmp net-snmp-utils -y
>net-snmp: Core SNMP daemon and libraries.
>net-snmp-devel: Provides net-snmp-config utility.
>net-snmp-utils: Provides SNMP testing tools like snmpwalk, snmptable, etc.
2.Locate and install MIB files.
net-snmp-config --default-mibdirs # Expected output (example): /usr/share/snmp/mibs cp <Luna MIB's path> /usr/share/snmp/mibs snmptranslate -Tp # Displays MIB hierarchy including CHRYSALIS-UTSP-MIB, SAFENET-HSM-MIB, and SAFENET-APPLIANCE-MIB
3.Configure the SNMP trap daemon.
The trap daemon (snmptrapd) listens for SNMP traps on UDP port 162.
Edit the configuration file /etc/snmp/snmptrapd.conf and add the following lines:
# SNMPv3 user configuration for receiving traps createUser restuser SHA <your_unique_password_for_authentication> AES <your_unique_password_for_privacy/encryption> # createUser <securityName> <authenticationProtocol> <your_unique_password_for_authentication> <privacyProtocol> <your_unique_password_for_privacy/encryption> authUser log,execute,net restuser # Allows this SNMPv3 user to log traps outputOption s # Logs will go into /var/log/messages
4.Start and enable snmptrapd service
sudo systemctl enable snmptrapd sudo systemctl start snmptrapd sudo systemctl status snmptrapd # Ensure it listens on UDP port 162 sudo netstat -anu | grep 162
Configuring SNMP on the Luna Network HSM Device
1.Start the SNMP service.
service start snmp
2.Create SNMP user.
Purpose: This endpoint creates an SNMPv3 user on the HSM to enable SNMP query operations (snmpwalk, snmpget, snmptable, etc.) from an SNMP Manager. The configured user credentials will be used to authenticate and encrypt SNMP requests when monitoring HSM status, metrics, and MIB objects.
POST /api/lunasa/snmp/users
{
"securityName": "restuser",
"authenticationPassword": "<your_unique_password_for_authentication>",
"authenticationProtocol": "SHA",
"privacyPassword": "<your_unique_password_for_privacy/encryption>",
"privacyProtocol": "AES"
}
This creates a secure SNMPv3 user with authPriv level (authentication and encryption) that can be used for SNMP walk and get operations on the HSM.
3.Configure SNMP trap destinations.
Purpose: This endpoint configures trap/inform destinations that use the internal LSTA (Luna SNMP Trap Agent) service to send HSM-specific events and runtime notifications. LSTA operates independently of SNMP users created via POST /api/lunasa/snmp/users and sends traps for operational issues, internal state changes, and HSM-specific events.
Important Notes:
•The securityName specified here does not need to exist as an SNMP user on the HSM — the credentials are embedded in the trap configuration itself.
•After creating trap destinations, you must enable trap sending on the HSM.
POST /api/lunasa/snmp/traps
{
"address": "<SNMP Manager IP>",
"securityName": "trapuser",
"authenticationPassword": "<your_unique_password_for_authentication>",
"authenticationProtocol": "SHA",
"privacyPassword": "<your_unique_password_for_privacy/encryption>",
"privacyProtocol": "AES",
"engineId": "<engineId from SNMP Manager>",
"trapType": "trap"
}
Note: For trap type, the engineId must be provided. For inform type, the engineId is optional (it will be discovered automatically).
Verify the created trap configuration:
GET /api/lunasa/snmp/traps
Enable Trap Sending: After configuring trap destinations, you must enable trap functionality on the HSM:
# Enable SNMP traps on the HSM using POST /api/lunasa/snmp/traps/actions/{actionId}
4.Configure user-specific SNMP notifications.
Purpose: This endpoint configures SNMP service-level notifications tied to specific SNMP users created via POST /api/lunasa/snmp/users. These notifications are sent by the SNMP service for standard SNMP-generated events related to the SNMP service lifecycle, such as cold start or shutdown events.
Important Notes:
•The SNMP service must be active for these notifications to work.
•These notifications are used for SNMP service lifecycle events, not HSM-specific runtime events.
Example for trap notification:
POST /api/lunasa/snmp/users/{userId}/notifications
{
"address": "<SNMP Manager IP>",
"port": 162,
"authenticationPassword": "<your_unique_password_for_authentication>",
"authenticationProtocol": "SHA",
"privacyPassword": "<your_unique_password_for_privacy/encryption>",
"privacyProtocol": "AES",
"type": "trap",
"engineId": "000FFFFFFFA9"
}
Example for inform notification:
{
"address": "<SNMP Manager IP>",
"port": 162,
"authenticationPassword": "<your_unique_password_for_authentication>",
"authenticationProtocol": "SHA",
"privacyPassword": "<your_unique_password_for_privacy/encryption>",
"privacyProtocol": "AES",
"type": "inform"
}
Note: The {userId} in the URL path refers to the SNMP user ID obtained when creating the user via POST /api/lunasa/snmp/users.
Testing SNMP Query Operations
Purpose: These tests verify that the SNMP user created via POST /api/lunasa/snmp/users is working correctly and can query HSM information.
Using MIB files with snmpwalk:
# CHRYSALIS-UTSP-MIB Examples
snmpwalk -v3 -l authPriv -u {USERNAME} -a SHA -A {AUTH_PASS} -x AES -X {PRIV_PASS} {HSM_IP} CHRYSALIS-UTSP-MIB::hsmOperationRequests
snmpwalk -v3 -l authPriv -u {USERNAME} -a SHA -A {AUTH_PASS} -x AES -X {PRIV_PASS} {HSM_IP} CHRYSALIS-UTSP-MIB::hsmCriticalEvents
# SAFENET-HSM-MIB Examples
snmpwalk -v3 -l authPriv -u {USERNAME} -a SHA -A {AUTH_PASS} -x AES -X {PRIV_PASS} {HSM_IP} SAFENET-HSM-MIB::hsmTable
snmpwalk -v3 -l authPriv -u {USERNAME} -a SHA -A {AUTH_PASS} -x AES -X {PRIV_PASS} {HSM_IP} SAFENET-HSM-MIB::hsmPartitionTable
# SAFENET-APPLIANCE-MIB Example
snmpwalk -v3 -l authPriv -u {USERNAME} -a SHA -A {AUTH_PASS} -x AES -X {PRIV_PASS} {HSM_IP} SAFENET-APPLIANCE-MIB::appSoftwareVersion
Note: Replace {USERNAME}, {AUTH_PASS}, {PRIV_PASS}, and {HSM_IP} with your actual SNMP user credentials and HSM IP address.
Testing SNMP Trap Configuration
Purpose: These tests verify that trap destinations configured via POST /api/lunasa/snmp/traps are working correctly.
Since generating actual HSM events for testing can be difficult, you can send a sample test trap using the REST API:
POST /api/lunasa/snmp/traps/test
{
"logFacility": "daemon",
"logLevel": "crit",
"process": "smartd",
"message": "Device: /dev/sda, Temperature is 45 C. Reached limit of 44 Celsius (Min/Max 31/49)",
"pid": false
}
This sends a sample SNMP trap to the configured destination, allowing you to verify:
>Network connectivity between HSM and SNMP Manager.
>SNMPv3 credentials are configured correctly.
>The SNMP Manager is receiving and logging traps.
Verifying Trap Reception on SNMP Manager
After configuring both the Luna Network HSM (SNMP Agent) and the SNMP Manager (trap receiver), perform the following steps to verify SNMP trap reception.
1.Enable debug logging on SNMP Manager.
To confirm that traps are being received, start snmptrapd in the foreground with verbose logging:
sudo systemctl stop snmptrapd sudo snmptrapd -f -Lo -d -n
2.Send a test trap.
Use the REST API to send a sample test trap (recommended for testing configuration):
POST /api/lunasa/snmp/traps/test
Alternative: Generate an actual HSM event trap by triggering the NTLS certificate monitor. First, regenerate the NTLS certificate with an expiry period of within 5 days, and then disable and then enable the NTLS certificate monitor using the following commands:
ntls certificate monitor disable ntls certificate monitor enable
3.Verify trap reception on SNMP Manager.
You should see output similar to the following in the snmptrapd debug logs:
sysUpTimeInstance = Timeticks: (44818015) 5 days, 4:29:40.15 snmpTrapOID.0 = OID: enterprises.12383.3.1.3.1 enterprises.12383.3.1.2.6 = STRING: "Nov 6 15:28:00 2025 GMT"
If you see this output, the trap configuration is working correctly.
See Also
SNMP Trap Configuration: POST /api/lunasa/snmp/traps
SNMP User Configuration: POST /api/lunasa/snmp/users
SNMP User Notification Creation: POST /api/lunasa/snmp/users/{userid}/notifications