Jan 31 2022 18:09:39+01:00 k17-optika %%01SNMP/4/SNMP_IPLOCK(s)[0]:The source IP was locked because of the failure of login through SNMP.(SourceIP=192.168.224.61, VPN= )
Jan 31 2022 18:09:39+01:00 k17-optika %%01SNMP/4/SNMP_FAIL(s)[1]:Failed to login through SNMP. (Ip=192.168.224.61, Times=1, Reason=the community was incorrect, VPN= )
we have the same problem with our Huawei devices. seems like the device is blocking the librenms IP for a while and during this time they appear as down in libre…
Feb 8 2022 08:04:53+02:00 BPoP-1 %%01SNMP/4/SNMP_IPUNLOCK(s)[9]:The source IP was unlocked.(SourceIP=x.x.x.x, VPN= )
Feb 8 2022 08:04:35+02:00 BPoP-1 %%01SNMP/4/SNMP_IPLOCK(s)[10]:The source IP was locked because of the failure of login through SNMP.(SourceIP=x.x.x.x, VPN= )
Feb 8 2022 08:04:35+02:00 BPoP-1 %%01SNMP/4/SNMP_FAIL(s)[11]:Failed to login through SNMP. (Ip=x.x.x.x, Times=4, Reason=the community was incorrect, VPN= )
This also causes problems with SNMPv3 AuthPriv and invalid context: it always sets the -n vlan-$vlanid option when calling snmpget, which causes login failures.
My workaround was to remove all lines where it sets the option.
First option is to ask huawei how to disable this behaviour. If the community is not available, fine, but blocking the monitoring system is probably not appropriate.
Second action: list the devices that are involved.
Third option is to suggest a fix:
– One fix could be to add a piece of detection code, and flag the device as “not supporting this feature”
– Other option, create a manual flag (or an OS specific flag) to define which device is supporting or not this feature.
For that part, opening a case at huawei TAC could help. The more people are asking, the more chances of getting a fix (like a setting to disable the behaviour) we have.