SNMP probe timed out, target is either unreachable or there are no valid credentials for it

Mark Todorov
Tera Contributor

Hi All,

 

I have a case here. While discovering one SNMP device, should be CISCO switch, 161 is granted, credentials are successfully validated. No ACL are existing, confirmed. 

Discovery log says: SNMP Probe timed out. Target is either unreachable or there are no valid credentials. 

Privacy protocol is AES128

What I did: changed the MID server properties regarding SNMP session and request timeout to 6000 but nothing changes.  

MarkTodorov_0-1687339510731.png

Any troubleshooting direction or ideas would be highly appreciated. 

Thanks in advance!

 

1 ACCEPTED SOLUTION

Fabian Kunzke
Kilo Sage
Kilo Sage

Hello,

 

Check the most simple option first (i am sure you already did):
- Credential must be active
- Credential is usable by the Mid-Server (either it is assigned explicitly to the Mid-Server, or to all Mid-Servers)

 

Next, check if your discovery schedule is setup correctly:

In your discovery schedule you can select an option “SNMP”. Judging by your information, you are using SNMP v3. Make sure this is selected (either SNMPv1/v2 and SNMPv3 or just SNMPv3). If you want to have a quick way of checking, do a “quick discovery” for the IP address.

 

Next, check if the credential you’ve created is actually used. Go into the probe results from the SNMP classification probe. It should say, which credentials were attempted. If more than one was attempted, deactivate the other ones - for testing purposes.

 

Lastly, check with your network admin/device owner, if the SNMP request actually made it to the switch. If not, it could be that either a firewall is blocking it (unlikely) or the device itself is refusing a connection from the Mid Server host.

 

Hope this helps.

 

Regards

Fabian

View solution in original post

4 REPLIES 4

Fabian Kunzke
Kilo Sage
Kilo Sage

Hello,

 

Check the most simple option first (i am sure you already did):
- Credential must be active
- Credential is usable by the Mid-Server (either it is assigned explicitly to the Mid-Server, or to all Mid-Servers)

 

Next, check if your discovery schedule is setup correctly:

In your discovery schedule you can select an option “SNMP”. Judging by your information, you are using SNMP v3. Make sure this is selected (either SNMPv1/v2 and SNMPv3 or just SNMPv3). If you want to have a quick way of checking, do a “quick discovery” for the IP address.

 

Next, check if the credential you’ve created is actually used. Go into the probe results from the SNMP classification probe. It should say, which credentials were attempted. If more than one was attempted, deactivate the other ones - for testing purposes.

 

Lastly, check with your network admin/device owner, if the SNMP request actually made it to the switch. If not, it could be that either a firewall is blocking it (unlikely) or the device itself is refusing a connection from the Mid Server host.

 

Hope this helps.

 

Regards

Fabian

Hi Fabian, thank you for answering. 

 

This IP is not using any credentials, which I will follow up to the respective person. 

 

Thanks again! 

Have a great day! 

Mark

 

Jude S
Tera Contributor

Hi. I had this issue and please check the credential record to confirm that you have sent the 'applies to' field correctly. 

My firewall and crednetials were working fine. However, during the troubleshooting I must have set the SNMP credential to apply to a specific MID Server. It was giving this error when the Discovery was routing via  a different MID Server.


Error:
SNMP probe timed out. Target is either unreachable or there are no valid credentials for it.

 

Solution:
For my situation, I updated the specific credential record (SNMP V3 credential) so that it can be applied to "All MID servers". 

JudeSoosairaja_0-1722470827402.png

 

I hope this helps.

Regards,
Jude.

RiteshSwarnakar
Giga Guru

 

Below are some solution that worked for me: 

 

1) Check the credential affinity table (https://instance.service-now.com/dscy_credentials_affinity_list) . Check for the IP of that CI and look for Type column, it should be either snmp or snmpv3. If it is not any of these change the existing record type to snmp or snmpv3 manually (depending on what creds the CI is using).

 

2) Use different MID server to discover that CI. Sometimes it happens that MID server doesn't return SNMP port as open even though it is in CI.

 

3) Add probe parameter in SNMP Classify: request_interval with value:5000 (default is 400ms)

https://instance.service-now.com/discovery_probes_snmp.do?sys_id=930a60500a0a0b61006f83edd300f689