SNMP discovery is failing with UNIX classification

[Rakesh16i]

Hi Experts,

While I am trying to discover few SNMP devices, it is getting failed with following messages

"Active, couldn't classify: Can't connect SSH, now finished"

"SSHCommand: No valid credential found for types [SSH Password,SSH Private Key]"...

I can see source as "UNIX classify". I am wondering why UNIX classification is getting triggered while these are network devices.

Regards,

Rakesh Imandi

[Rakesh16i]

Reva....sorry I missed the thread....here are my observations.

When I discover one Network devices Ip ,which is failed to get created as CI, is showing error in the ecc payload like "active=0, alive=1". (UNix clasify)

Similarly when I discover same ip with SNMP behaviour as Anand suggested I see the error as "active=0, alive=0". Which makes me believe that it couldn't able to get any response from SNMP probes in the second   case. And in the first case it is getting some response from other probes like UNIX/SSH....

[Dave Mau]

You would want to next check if port 161 (snmp) is open on these devices.   Next take it outside of the instance and use a 3rd party tool on the mid server (Debug your SNMP configuration with SNMP Tester ) to see if you have connectivity to the SNMP device. Also make sure you have a valid community string in the credential table.

[Ryan Zulli · Accepted solution]

Hi Rakesh,

When discovering network gear using normal discovery (no behaviors) we will check of all of our classification ports (ie, 135/wmi, 22/ssh, 161/snmp..etc)

That said, most network gear will use port 22 as a management port - this means during shazzam it comes back in a state of open - if you look at our Port Probes (Discovery --> Discovery Definition --> Port Probes) and add the column Classification Priority to your view, you'll see we Classify in the following order ::

1 - WMI

2 - SSH

3 - SNMP

and so on....

This means that if we find port 22 open we WILL try to classify as UNIX first, then once credentials fails (since this is network gear) we will move on to SNMP.   This does create a false positive when running reports.   Its my recommendation that you switch SSH and SNMP classification priorities that way we'll check SNMP before SSH.   And since SNMP is stateless (UDP) we won't throw an error if snmp fails.

I believe in Geneva we implemented a new feature called IP Service Affinity, this just like Credential Affinity will remember which Classification was successful and try that one during all subsequent discoveries. More on this here ::

https://docs.servicenow.com/bundle/geneva-it-operations-management/page/product/discovery/concept/c_...

Let me know if this helps or if you have any other questions.

Thanks,

-Ryan

[Cedric Creton]

Hi Ryan,

Any idea/reason why it's not set in that order OOB? 🙂

I will probably change into our PRD to avoid 2 Jobs by remote office (one with a SNMP-only behavior on IP mgt range and one OOB in server ranges). 

Then I will probably merge Datacenter's Discovery Ranges less Discovery Schedules 

Best Regards

Cedric

[VaranAwesomenow]

Dear Ryan, Is this still valid in Madrid, I checked this ip_service_affinity table on my instance and not even a single record exists. We have been running discovery on various types of devices (windows, vcenter, storage, network, security) for more than a month.