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!

[doug_schulze]

Id check the snmp classify return and in the sysdescr section, maybe you'll see something that you can filter the classifier on.   If say the word Linux is in the sysdescr, in the printer classifier you can add a criteria that states.. sysDescr does not contain linux ..

I believe that should stop the creation.. let us know what you have..

[andrewmccabe]

Newbie response ... I added a new Classification Criteria to the SNMP Classification "Standard Network Printer" ... it is still classifying as a printer

existing criteria: printing equals true

new criteria: sysdescr does not contain Linux (also spelled sysdescr as sysDescr)

I have added some debugging statements to the SNMP Classify Sensor and strangely, the existing criteria does not seem to be met

>>SNMP CLASSIFY capabilities[printing] = false (debugging statement)

The Linux Case should have caused the classifier not to be run (I think)

>>SNMP CLASSIFY props[sysdescr] = Linux phslxamd14 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64

There is an out-of-the-box SNMP OID Classification record that classifies 1.3.6.1.4.1.8072.3.2.10 as an Intermec Printer

Signed,

Confused

[robertgeen]

Hello Andrew,

This is a very interesting issue as OID are supposed to be unique. Are these linux servers some sort of appliance that are fulfilling a similar role? On top of what Doug mentioned I would also check the printing classifier attribute to see if it's set to true as I can't remember what cause that to get set (you can see it in the sensor code of the classifer). If it's set to true then that is also very strange as I would think that would of kept it from being classified. Either way what Doug said is most likely the best way around this issue.

[andrewmccabe]

I agree - I thought that OID were supposed to be unique ... If I manually do an SNMP walk on an IP Address I know to be an Intermec printer, it returns an OID of   .1.3.6.1.4.1.8072.3.2.10. When I manually do an snmpwalk of just many different Linux servers, I get the same OID (this includes many Linux flavors). I am guessing that this is the standard Linux OID AND that the printer is running Linux as an OS ... I do not have much info on the printer except that it is used to print Bar Code Labels in a hospital setting.

Look at the reply to Doug as the printing flag is not set, but the classifier runs anyway ... mysterious (because I have only been playing with discovery for about a month)