Description

The syslog messages, 'LIBJSNMP_NS_LOG_ERR' and 'LIBJSNMP_NS_LOG_WARNING' are SNMP related. They may be seen when the system generates a SNMP trap.

This article explains how to troubleshoot this problem.

Symptoms

These syslog messages keep prompting when the system generates a SNMP trap:

snmpd[7238]: LIBJSNMP_NS_LOG_WARNING: WARNING: _sess_async_send@5233: Encoding failure Result:4294967295 ReqID:0x3e45e1ed PDU-Type: 167
snmpd[7238]: LIBJSNMP_NS_LOG_ERR: ERR: snmpd: send_trap: USM unknown security name (no such user exists)

Solution

Perform these steps to determine the cause and resolve the problem (if any):

  • Check when these logs started prompting and if there were any changes made at that time.

  • If local engine-id was changed, then below log can also be found in log messages before LIBJSNMP_NS_LOG_WARNING and LIBJSNMP_NS_LOG_ERR log messages started prompting.

snmpd[7238]: SNMPD_ENGINE_ID_CHANGED: Warning: Local engine ID has changed. Passwords for all the users under [edit snmp v3 usm local-engine] need to be reconfigured.


As described in the documentation on  engine-id , SNMPv3 authentication and encryption keys are generated based on the associated passwords and the engine ID. If you configure or change the engine ID, you must commit the new engine ID before configuring SNMPv3 users. Otherwise, the keys generated from the configured passwords are based on the previous engine ID.

In order to recover, re-configure the SNMPv3 authentication passwords for all users so that a new set of keys based on the current engine ID and password is generated.

set snmp v3 usm local-engine user <UserName> authentication-sha authentication-password <Password>
set snmp v3 usm local-engine user <UserName> privacy-aes128 privacy-password <Password>
 

  • If no changes were made and no SNMPD_ENGINE_ID_CHANGED log can be found, then check the SNMP v3 configuration. Refer to the documentation on Configuring SNMPv3 . During lab testing, if SNMP v3 trap is configured without user defined under 'snmp v3 usm local-engine user'  hierarchy, it can also trigger these syslog messages.

  • While using QFX5130-32CD (running on EVO) you may observe similar error logs causing the authentication to fail. When explicitly configuring an engine-id in the SNMPv3 template of Apstra, observed similar error logs causing the authentication to fail. To resolve this, create a separate Apstra configuration template for the QFX5130-32CD with SNMPv3 configuration having no engine-id command, allowing the device to use its default engine ID. With this change, SNMPv3 authentication works fine as expected. 

Modification History

Added last point to Solution