- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2016 05:32 AM
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
Solved! Go to Solution.
- Labels:
-
Service Mapping

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-02-2016 08:40 AM
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 ::
Let me know if this helps or if you have any other questions.
Thanks,
-Ryan

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-15-2019 07:24 AM
I believe that the sysObjectID of the Discovered device must be defined in the 'SNMP OID Classifications' table (discovery_snmp_oid.list).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-20-2020 05:25 AM
Check out this video, it will clear all your doubts and help you to understand Discovery queries in details.
Link: https://www.youtube.com/watch?v=30JbWVsusyE&t=10s&ab_channel=ServiceNowHelpdesk
It help you to understand below points.
- Discovery Overview
- Discovery prerequisite
- Understanding Discovery Phases in details
- Discovery credentials and IP Affinity
- Mid Server Management with Cluster and Load Balancer
- Schedule jobs
- Set up discovery from scratch to end
- Live implementation with real world data.
- Troubleshooting on various aspects
- Many more other issue related to mid server, CIs
- Cloud discovery
- Service Mapping
Please mark reply as Helpful/Correct, if applicable. Thanks!!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-21-2022 06:14 PM
Can you switch the Classification Priority of Discovery Port Probes "SSH" and "SNMP"?
Out-Of-The-Box Classification Priority
Here is the order of Classification Priority out of the box.
- SSH - 2
- SNMP - 3
This Classification Priority causes Discovery to attempt SSH/UNIX Classification first, then SNMP Classification.
If a network device has TCP Port 22 open and SNMP enabled, the out-of-the-box Classification Priority attempts SSH/Unix Classification first. The SSH/Unix Classification fails and generates needless Discovery issues related to the failure of SSH/Unix Classification. Discovery then proceeds to SNMP Classification, which succeeds.
Modified Classification Priority
If all you want is SNMP Classification -- for most network devices this is the case -- then you can switch the order of the Classification Priority to attempt SNMP Classification first.
Here is the proposed reorder of Classification Priority.
- SNMP - 2
- SSH - 3
This Classification Priority causes Discovery to attempt SNMP Classification first. If SNMP Classification succeeds, Discovery never calls SSH/Unix Classification.
If a network device has TCP Port 22 open and SNMP enabled, the modified Classification Priority does not generate the needless Discovery issues related to SSH/Unix Classification.
Credits
I learned this from Doug Schulze