|
Sometimes, when trying to configure the SNMP agent and SNMP community on the FortiAnalyzer, the SNMPD process is not initialized and SNMP communication fails.
The SNMPD process ID is changing very quickly and it is not possible to kill or restart it.
The SNMPD process ID is visible with the following command:
diag system process list
PID USER VSZ STAT COMMAND
...
29937 root 0 Z snmpd]
On the SNMP debug the following messages appear:
FAZ # diagnose debug application snmpd -1
FAZ # diagnose debug enable
FAZ # snmpd: creating community=t3lmeXKom
snmpd: community: t3lmeXKom mask: 370900f
snmpd: creating community=public
snmpd: community: public mask: 370900f
snmpd: module_core.c:205: ERROR socket/bind 162: Address already in use
snmpd: snmp get->init() failed
snmpd: creating community=t3lmeXKom
snmpd: community: t3lmeXKom mask: 370900f
snmpd: creating community=public
snmpd: community: public mask: 370900f
snmpd: module_core.c:205: ERROR socket/bind 162: Address already in use
snmpd: snmp get->init() failed
snmpd: creating community=t3lmeXKom
snmpd: community: t3lmeXKom mask: 370900f
snmpd: creating community=public
snmpd: community: public mask: 370900f
snmpd: module_core.c:205: ERROR socket/bind 162: Address already in use
snmpd: snmp get->init() failed
snmpd: creating community=t3lmeXKom
snmpd: community: t3lmeXKom mask: 370900f
snmpd: creating community=public
snmpd: community: public mask: 370900f
snmpd: module_core.c:205: ERROR socket/bind 162: Address already in use
snmpd: snmp get->init() failed
The above error means that port162 is already used on the FortiAnalyzer configuration and that is why the SNMPD process could not be initialized Checking the SNMP configuration following settings:
config system snmp community
edit 2
(community)# edit 2
(2)# get
id : 2
events : disk_low intf_ip_chg sys_reboot cpu_high mem_low log-alert log-rate log-data-rate lic-gbday lic-dev-quota cpu-high-exclude-nice
hosts:
== [ 1 ]
id: 1
hosts6:
name : public
query_v1_port : 4560
query_v1_status : enable
query_v2c_port : 162
query_v2c_status : enable
status : enable
trap_v1_rport : 4560
trap_v1_status : enable
trap_v2c_rport : 162
trap_v2c_status : enable
In this example, the user wrongly configured the same UDP port 162 for SNMP traps and queries causing the reported behavior.
To fix the issue, we could use default values for SNMP services 161/162.
query_v2c_port : 161
query_v2c_status : enable
status : enable
trap_v1_rport : 4560
trap_v1_status : enable
trap_v2c_rport : 162
trap_v2c_status : enable
|
