SNMP Trap collector doesnt restart after midserver down

Les1
Tera Guru

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.

KB0782980 
 

SNMP trap listener fails to start

 245 Views  Last updated : Jul 7, 2021  Public  Copy Permalink
 
 

Description

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.
3 REPLIES 3

Rahul Priyadars
Giga Sage
Giga Sage

on Windows host u can try below command to see what ports processes are listening .

netstat -aon | findstr /i listening

Regards

RP

Thanks Rahul for your response.

we've since reconfigured for a different port per the recommendation of support kb article on this topic and that has us  working in PROD. 

 

i've still got an issue with our DEV instance when i reconfigured to a different port but suspect that something isnt right in the MIDserver or client sending traffic but dont have time to pursue at the moment. again thanks for giving me that direction for troubleshooting.

Thanks Les.

Regards

RP