Alarm is generated due to packet rejection from the community group due to reject option instead of discard, the device drops the packet and sends a notification back to the source host and hence snmp server getting some logs.

We are observing the below log message from SNMP server-side indicating that there was a problem with a GET request for an alarm variable, from the SNMP walk output you provided the returned value is 2:

jnxRmonAlarmGetFailReason.32768 = 2

jnxRmonAlarmGetFailReason.32770 = 2

jnxRmonAlarmGetFailReason.32771 = 2

jnxRmonAlarmGetFailReason.32772 = 2

jnxRmonAlarmGetFailReason.32773 = 2

jnxRmonAlarmGetFailReason.32774 = 2

Get-Request from Source IP 10.71.100.124 to Destination 10.46.0.190:

Dec 4 22:57:33.051978 snmpd[4faf45f7] <<< Get-Response

Dec 4 22:57:33.052018 snmpd[4faf45f7] <<< Source:     10.46.0.190

Dec 4 22:57:33.052032 snmpd[4faf45f7] <<< Destination: 10.71.100.124

Dec 4 22:57:33.052043 snmpd[4faf45f7] <<< Version:    SNMPv2

The request includes several OIDs related to network interface (ifHCInOctets.1120, sysUpTime.0, ifDescr.1120).

The system logs SNMPD_AUTH_RESTRICTED_ADDRESS, indicating that the request from 10.71.100.124 is not allowed. This suggests that there is an access control restriction based on the source address. This log line shows that the SNMP request from the source IP address 10.71.100.124 was rejected due to an authentication or access control issue. The device is enforcing restrictions on allowed source IP addresses, and 10.71.100.124 is not permitted to make SNMP requests.

Dec 4 22:57:33.048348 snmpd[4faf45f7] >>> Get-Request

Dec 4 22:57:33.048362 snmpd[4faf45f7] >>> Source:     10.71.100.124

Dec 4 22:57:33.048374 snmpd[4faf45f7] >>> Destination: 10.46.0.190

Dec 4 22:57:33.048385 snmpd[4faf45f7] >>> Version:    SNMPv2

Dec 4 22:57:33.048396 snmpd[4faf45f7] >>> Request_id: 0x4faf45f7

Dec 4 22:57:33.048409 snmpd[4faf45f7] >>> Community:  @LIBERTYLAT2N2021

Dec 4 22:57:33.048421 snmpd[4faf45f7] >>> Error:      status=0 / vb_index=0

Dec 4 22:57:33.048445 snmpd[4faf45f7] >>>  OID : ifHCInOctets.1120

Dec 4 22:57:33.048463 snmpd[4faf45f7] >>>  OID : ifHCOutOctets.1120

Dec 4 22:57:33.048482 snmpd[4faf45f7] >>>  OID : ifDescr.1120

Dec 4 22:57:33.048498 snmpd[4faf45f7] >>>  OID : sysUpTime.0

Dec 4 22:57:33.048513 snmpd[4faf45f7] >>>  OID : ifName.1120

Dec 4 22:57:33.048529 snmpd[4faf45f7] >>>  OID : ifHighSpeed.1120

Dec 4 22:57:33.048540 snmpd[4faf45f7] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Dec 4 22:57:33.048568 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request from address 10.71.100.124 not allowed

Dec 4 22:57:33.048627 snmpd[4faf45f7] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

There are two workaround to resolve this issue:

1. you can add the following statement to the community `community_name` to explicitly allow the IP address 10.71.100.124/32 ensuring the packet is not rejected:

set snmp community "@community_name" clients 10.71.100.124/32

set snmp community "community_name" routing-instance "OM_CN" client 10.71.100.124/32

2. Alternatively, you can replace the `restrict` statement with a `discard` statement to the community `community_name'

set snmp community "@community_name" clients 0.0.0.0/0 discard

set snmp community "@community_name" routing-instance OM_CN client 0.0.0.0/0 discard