Discovery SNMP Confusion: Linux Server Versus Intermec Printer

[andrewmccabe]

I am running discovery on Helsinki.

During discovery, I encounter numerous Linux Servers where the SSH Authentication fails because of invalid credentials (it is a large diverse somewhat decentralized environment with multiple IT Departments).

Classification Order

1. Try Windows
2. Try SSH (Open Systems)
3. Try SNMP
4. Try Others … there are a total of 14 (the order
   is only specified for 4 or 5 of them)

When a Linux server fails SSH authentication, it starts SNMP discovery.

1) SNMP asks the device for basic information to get started

2) an OID of .1.3.6.1.4.1.8072.3.2.10 is returned because it is the standard response for a Linux Server

ServiceNow has an SNMP OID Classification of .1.3.6.1.4.1.8072.3.2.10 defined as an Printer manufactured by Intermec. An SNMP Walk of an Intermec Printer does return this OID.

Here is the problem: I have over 1000 Intermec Printers in my environment as well as hundreds of Linux Servers that I currently cannot authenticate to ...

I am looking for advise on the best approach to identify Intermec Printers correctly AND identify Linux Servers that I cannot authenticate to ...

Can I force a change in the Identifier or Classifier to distinguish these two different kind of devices that return the same OID?

Any advise would be helpful

Thank You!

[robertgeen]

Hello Andrew,

Yeah that's most likely the case that it's running a verison of linux (although in my H instance I couldn't see the OID out of the box so maybe it was added). Another thing you can do to get more data is turn on classification debugging. This will allow you to see exactly which attributes are set to what at the classification stage which may help figure out further what is going on.

Debug classifications

Just a heads up it will also cause debug to run for process classification as well so if you are running a large load of discovery it could cause a lot of log noise. I would do this next to get more information and then give us a clipping of the debug information and maybe we find the AHA moment.

[andrewmccabe]

I turned on the debug flag and did not find any new entries in the Discovery Log or General Log ... I had tried this before ... and got no significant new entries, so I added my own statements into the sensor ... I will look some more into the OID Definition as Doug suggested and let you know what I find out ... Thanks for your responses

[robertgeen]

You won't see in the system log if I remember correctly you have to go to the node log file browser and at the time you ran discovery you will see it in there. Hope this helps. Honestly if you don't see anything that is causing it there then I would open a support case as Doug said they might of made the OID take precedence.

[doug_schulze]

I wonder if they are allowing the SNMP SYSOID to take precedence over the classifier.. so it measure the value over the criteria, thats they way it sounds.. interesting..

May have to goto the support route..

[Daniel Needles1]

Yes they should be unique.  I come from the monitoring space and this is a common problem.  Small shops cannot hire experienced workers and so they skip steps.  In this case they went and got NET-SNMP which is used industry wide for 30 years for SNMP.  But they missed the step of going to IANA.org and getting their own Enterprise SysOID.  (It doesn't cost anything, just a bit of hoop jumping.)  Instead, they took the most appropriate SysOID owned by NET-SNMP (in this case Linux) and used it.  ServiceNow being hammered with tons of these vendors have hardcoded not to allow you to add this SysOID as it will falsely scoop up all the vendors into whatever you set for the SysOID.  That said, you can work around it if the vendor (hopefully) populated the SysDesc.  So in the classifier you simply use SysDesc instead of the SysOID for Identification.