An SNMP device is a device that is managed using the Simple Network Management Protocol (SNMP). This includes routers, switches, printers, PDUs, UPSs, Netware servers, load balancers and various other network-enabled devices. Discovery uses an SNMP scan to get device-specific MIBs and OIDs.
To ensure proper discovery of an SNMP device, there are three essential prerequisites:
Access | The platform also requires the ability to make port 161 SNMP requests from the MID Server to the target. If Access Control Lists (ACLs) are in place (on the target) to control the IP addresses that can make these queries, ensure that the IP address of the MID Server is in the ACL. ServiceNow Discovery supports SNMP versions 1 and 2c. |
SNMP Version | ServiceNow Discovery supports SNMP versions 1, 2c, and 3. Discovery uses version 1 and 2c by default. You must enable support for version 3. MID Servers support all SNMP protocol versions by default. You can set a MID Server to only support specific versions of SNMP. So, make sure you are using the correct SNMP version. |
Credentials (SNMP community credentials) | Many devices by default have a community string of "public" which Discovery uses when querying a target. Define additional community strings in the Credentials module which are tried in succession, along with public, until a successful query returns, in addition to the credentials. For how to define those strings see SNMP community credentials |
How an SNMP Device is discovered in the base system
- Shazzam runs and the SNMP port 161 is open
- The 'SNMP - Classify' probe is triggered as configured under Discovery Definition > Port Probes
- The 'SNMP - Classify' triggers the 'SNMP - Classify' sensor as configured in the 'SNMP - Classify' probe definition under Discovery Definition > Probes > SNMP - Classify.
- The 'SNMP - Classify' sensor will try to determine "classify" what type of SNMP device is this, using industry standards. For example, a device can be classified as printer if one of the SnmpObjectId of the hrDeviceEntry ends with .5 which is the ID value for printers , as seen at line 3 in the following input payload of the 'SNMP - Classify' probe:
<hrDevice oid="1.3.6.1.2.1.25.3">
<hrDeviceEntry instance=".1">
<hrDeviceType type="SnmpObjectId">.1.3.6.1.2.1.25.3.1.5</hrDeviceType>
<hrDeviceDescr type="SnmpOctetString">
FUJI XEROX ApeosPort-V C3374 v 40. 73. 0 Multifunction System
</hrDeviceDescr>
</hrDeviceEntry>
Or the prtGeneralEntry's prtGeneralSerialNumber has a value, as seen at line 4 in the following input payload of the 'SNMP - Classify' probe:
<printmib oid="1.3.6.1.2.1.43">
<prtGeneral oid="1.3.6.1.2.1.43.5">
<prtGeneralEntry instance=".1">
<prtGeneralSerialNumber type="SnmpOctetString">TC100985512273</prtGeneralSerialNumber>
</prtGeneralEntry>
</prtGeneral>
</printmib>
Note: you can review the code with the logic behind this in the 'SNMP - Classify' sensor's code in your instance.
- The 'SNMP - Classify' sensor will set the capabilities of the SNMP device accordingly and additional identification and exploration probes will be launched against the SNMP device as per the SNMP Classification of which the Classification Criteria is met. (Hint: sometimes you may need to change the order of the SNMP classifiers to ensure the correct SNMP classifier is launched first)
Common issues with SNMP devices discovery
Sometimes, it is inevitable to run into issues when discovering an SNMP device for a number of reasons, here are the most common ones along with some tips to fix them:
- Conflicting open ports
- Failing to classify a device
- Missing information
Conflicting open ports
There are ports other than the default SNMP port 161 open on a device, such as the default SSH port 22, are required to be open on an SNMP device for management, this can cause classification issues. You will need to create a new discovery schedule with SNMP only behavior. A Discovery Behavior determines what probes Shazzam launches and from which MID Servers these probes are launched. As an alternative to specifying a single MID server, a Behavior can assign different tasks to multiple MID Servers on the same IP address segment or on different network segments.
Failing to classify a device
The 'SNMP - Classify' sensor failed to classify the device, for various reasons the out of box 'SNMP - Classify' sensor might not be able to classify the SNMP device. In that case, you can manually add the sysObjectID's SnmpObjectId to the SNMP OID Classifications [discovery_snmp_oid] table by navigating to Discovery Definition > CI Classification > SNMP System OIDs.
Example from our network printer:
Note that the OID used is the sysObjectID's SnmpObjectId as seen at line 7 in the following input payload of the 'SNMP - Classify' probe:
<system oid="1.3.6.1.2.1.1">
<sysName oid="1.3.6.1.2.1.1.5" type="SnmpOctetString">Service Now Scanner</sysName>
<sysUpTime oid="1.3.6.1.2.1.1.3" type="SnmpTimeTicks">17469300</sysUpTime>
<sysDescr oid="1.3.6.1.2.1.1.1" type="SnmpOctetString">
FUJI XEROX ApeosPort-V C3374;ESS1.1.2,IOT 40.73.0,ADF 12.8.0,FAX 1.1.14,PANEL 10.16.4,IPS 13.10.0,BOOT 1.0.34,SJFI3.7.0,SSMI1.25.0,CNTS 2.0.3,Plugin 1.0.1
</sysDescr>
<sysObjectID oid="1.3.6.1.2.1.1.2" type="SnmpObjectId">.1.3.6.1.4.1.297.1.11.93.1.35.31.3.1</sysObjectID>
</system>
You can also use this method to:
- Manually set the Manufacturer and Model of the SNMP device.
- Select which CMDB table you want the SNMP device to be stored in.
- Select an existing classifier or a custom classifier to classify that device.
Missing information from the base system probes
If the information you are looking for isn't extracted using the base system probes you will probably need to Import the SNMP's device manufacturer's MIB module, (please see SNMP probe MIB modules for details). Don't forget to restart the MID Server agent as MIBs are only loaded during MID Server startup. It might be a good idea to also monitor the MID Server's agent log for MIB loading errors.
When you import manufacturer's MIB modules the extra information you are looking for won't be readily available, you will also need to create a custom classifiers, probes and sensors to extract that information and put it in the right place. SNMP probe uses the SNMP protocol to query a particular device for a list of OIDs, which are then traversed and the results passed back to the sensor for further processing. (Please see SNMP probe for details)
FAQ about discovering SNMP devicesDo we need to keep MIBs updated?There are two MIB modules that the MID Server loads when it starts up:
How we understand that there is requirement to install new MIBsWhen discovery of the SNMP devices that are described by those MIBs fails or is missing information that you are expecting about the SNMP device being discovered. How can we install latest MIBs? where we get latest MIB filesTo install the latest MIBs, kindly follow the steps outlined in the following wiki article: SNMP probe parameters Normally, you can get the latest MIBs from the manufacturer's website, for example visit Juniper. Additionally, if you believe that an existing MIB module needs to be updated, you can check the source field of the particular MIB module in ServiceNow by navigating to MID Server > SNMP MIBs. Where can i find information on the latest MIB downloads?You can refer to the following wiki article for more information about MIB Modules: SNMP probe MIB modules. There is no one link that provides information about the latest MIB downloads as MIBs belong to different manufacturers. |
SNMP discovery can seem overwhelming at first especially if you're not an SNMP expert, but once the logic behind it is demystified you will find it very useful. I hope this blog adds a little bit more information to this not-so-much documented subject.
Cheers,
Omar.
9 Comments
