We have an SNMP trap collector setup for event mgt that feeds alerts and incident generation via ITOM.
when our MIDservers have a down condition (patching or whatever...not sure yet if 'why' matters)
the SNMP Trap collector fails to restart causing outage to ITOM for snmp based events. the error is: Could not start the trap listener on port 162: Address already in use: Cannot bind
and sometimes it gives this error when i try to restart: The extension with the sys_id 5dbdeefc1b1a64104f4dbfc61a4bcb7b is not currently active
Is there something else i need to configure to make this auto-restart or what would your advice be? thanks!
update: so apparently according to following article, the issue may be that the host machine for the midservers has a competing SNMP service on the same port that needs dealing with. I just dont know why it was working prior. I will contact our servers team to look into that.
SNMP trap listener fails to start
245 Views 
Last updated : Jul 7, 2021 
Public 
Copy PermalinkDescription
SNMP trap listener fails to start.
Error log : Could not start the trap listener on port 162: Address already in use: Cannot bind.
Release or Environment
All
Cause
The default SNMP trap service is configured for the port 162 on the mid server host machine, which was preventing the Servicenow’s trap being able to start on port 162.
Resolution
In order to fix this issue, below 2 approaches can be considered.
Approach 1
- You can define another port (1162) for the Servicenow trap listener and start the ServiceNow SNMP trap from the instance.
Approach 2
- Decouple the existing active exe that's running on port 162.
- Open services.msc on the MID server host, look for the SNMP trap service and then stop it.
- Once the default SNMP service gets stopped, please attempt to start the ServiceNow’s SNMP trap from the instance and it should start.
The recommended approach would be to define another port for Servicenow trap listener.
