SNMP Discovery explainedDescriptionLooking for more insight about how SNMP Discovery works? This article provides in-depth information about prerequisites, flow, and common troubleshooting steps. Contents PrerequisitesMID Server capabilities and requirementsSNMP Discovery Flow in a base systemCommon issues and how to investigate Prerequisites SNMP Version: This is one critical check that has to be verified for the target host. ServiceNow Discovery supports SNMP versions 1, 2c and 3.Discovery uses version 1 and 2c by default.The support for version 3 must be explicitly enabled.MID Servers support all SNMP protocol versions by default.You can also set a MID Server to only support specific versions of SNMP. Credentials - Credentials for SNMP do not include a user name, just a password, called the community string. The default read-only community string for many SNMP devices is public, and Discovery will try that automatically.Enter the appropriate SNMP credentials if they differ from the public community string. MID server capabilities and requirements No additional capability needs to be verified for running discovery on SNMP devices. The MID should just have the ability to perform DISCOVERY. SNMP Discovery Flow in a base system ServiceNow's discovery process has the capability to discover devices managed by SNMP. A few example devices- Switches (Stacked switches as well starting Kingston)RoutersPrintersControllers of Wireless Access PointsLoad Balancers The Discovery process uses MIBs and OIDs to Classify, Identify and Explore Network-enabled devices. MIB - Management Information Base is like a database that contains a set of Values, both statistical and control, that are defined by the network device. Device vendors also have a choice to choose the MIBs which are referred to as private MIBs.OID - Object Identifier is a representation followed by the SNMP implementation which is a combination of MIB + Object of Interest. The Object of interest can be defined as the parameter value which a polling device can look for, say for example the Devices' uptime.Say, for example, a Device has OID = 1.3.6.1.2.1.1.3.0. The image below shows an example of how it adds up. The first 7 digits represent the MIB while the last 2 digits represent the Object of Interest. Quick brief of discovery phases Shazzam or Scan phase - For the user-provided IP address, the Shazzam polls the device and checks the port(s) it's responding on. Say, in our scenario, the expected port to be responding for the device is 161. There are all chances that an organization might have customized the port on which SNMP runs and hence, it has to be duly checked.Classification phase - For any active port, the port probes module will have the set of probes or Patterns to be triggered and for SNMP devices it's usually SNMP - Classify. This probe mainly aims at extracting valid OID from the target device. The Input payload for SNMP - Classify looks like the example image below. The 'sysDescr' tags define the type of deviceThe 'sysObjectID' tag contains the OID. Device classification is handled by the SNMP discovery process in the below way There would be specific SNMP classifiers for that are defined for each device type. They can be found under the table discovery_classy_snmp.For each classifier, you would find the classification criteria. This section/tab contains the condition that a target host has to satisfy in order to trigger a relevant classifier. All the different classification criteria records can be looked under discovery_class_criteria. The fetched OID would also be taken into consideration (If the OID exists in SNMP OID table and if it doesn't, even then the classification proceeds but the conditions of all available classifiers would be checked) for choosing the right classifier and the list of OIDs that which are defined and mapped to a classifier, found under the tab SNMP OID Classifications. All the OID specific information can be found under discovery_snmp_oid.Once the right classifier is chosen, the probe that has to be triggered based on the condition match during classification would be defined under 'Trigger probes' section and they can also be viewed under discovery_classifier_probe.Below is an example SNMP classifier record for Standard Network router. Identification phase- Per the obtained MIB, the classification phase feeds the Identification phase with the type of device and the necessary probes/patterns which are needed to be triggered to identify the device. The MIB of the target host gets polled to extract the object(s) of interest which in turn would be the details that are expected to be populated for the CI. In general, the SNMP MIBs are present in ecc_agent_mib table on the instance and they are expected to be compiled and loaded on the MID server on which the discovery is running from. Please note that not all MIBs are present OOTB and have to be added as per the requirement. If there is no relevant MIB, the discovery doesn't go beyond classification phase.Exploration phase- In the exploration phase, the target host gets further explored for obtaining internal details by triggering the Layer-2 discovery. The detailed SNMP discovery flow is outlined in the image below. Following the steps in the flow image above, common issues and their possible solutions are listed in the following table. StepsInputExpected OutputCommon issue that can be encounteredPossible solution 1.1 1.2 1.2.1 IP of a N/W deviceAcknowledging the Device response on SNMP port and a go-ahead trigger SNMP - Classify Issue 1: Though the SNMP port is active, a connection can be refused. Issue 2: SSH taking priority over SNMP if the device responds on both the ports. This eventually results in SNMP being triggered. Issue 1: Have port access enabled. Issue 2: Create an SNMP behavior for the device and have that inherited to a discovery schedule. 2.1 2.2 2.3 SNMPTable and SNMPWalk targeting MIBs for extracting device detailsSystem OID and an extraction of condition that would let the discovery process choose the right classifierDevice listed as "Active, couldn't classify"A relevant OID may be missing from discovery_snmp_OID. There may be no criteria match for any of the SNMP classifiers. 3.1 3.1.1 3.1.2 3.2 SNMPTable targeting to extract details like NIC and Serial numbers or a relevant patternDevice-specific details extracted from the MIB Issue 1: "Classified, couldn't identify" errors Issue 2: Pattern failures Issue 1: Check to see if the SNMP - Identity probe succeeded. If it hasn't, investigate based on the error received. Issue 2: Perform a pattern debug to determine the error or look at the pattern execution logs for the error. 4.1 4.2 SNMPTable targeting to extract details like the neighboring devicesSeveral devices which are the neighbors for the N/W device and the relationship typesRelationship between Device Neighbors missingThe information about Device Neighbors [discovery_device_neighbors] is gathered by Layer 2 protocol cache probe during exploration. Check to see if it has been triggered or if it has errors. Note: There is a flexibility to add parameters to the SNMP probe. There would be scenarios where OID Children needs to be identified and explored or a time out to be set. To understand more about how to do this, please refer to ServiceNow's documentation for SNMP probe parameters and how to add them. SNMP Probe parameters There are additional probe parameters that can be used while discovering an SNMP device. These can be found in the table below and the SNMP probe parameters documentation. ParameterDescriptionDefault Valueoid_spec_listA list of OID specifications, one per line. Each specification must be in one of the following two forms: walk {OID}: Walks the OID and all its children table {OID} {OID Children}: Walks all entries in the table, returning only the given children (for example, "iso.org.dod.internet") {OID Children} refers to a comma-delimited list of child nodes within the entries for the given table. For example, "ifEntry.ifIndex,ifEntry.ifDescr,ifEntry.ifType" are OID children of the table "iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable". As a convenience, the table entry prefix may be left off. (The preceding children could be specified as "ifIndex,ifDescr,ifType".) Any child may include a filter qualifier in parentheses. For example, the child "entPhysicalContainedIn(=0)" specifies returning table entries only if the value of "entPhysicalContainedIn" equals 0. The operators supported in the expression are: =equals!=does not equal#contains If more than one child has a filter expression, a match on any one of the children causes that entry to be read. Any content including and after a "//" is ignored (comments). Any OID that does not start with "1.3.6.1" or "iso.org.dod.internet" automatically prefaces with "1.3.6.1." as a convenience. requiredsourceThe IP address or host name of the device to query SNMP on.requiredindexThe index to apply after the community string, for Cisco-style community string indexing (for VLAN interrogation).0credential_idThe sys_id of a specific credential that is preferred for use above the rest. This parameter is for internal use only and is not supported.nonecredential_tagThe credential tag that must be used. This parameter is for internal use only and is not supported.nonetimeout The timeout value (in milliseconds) to wait for a response, instead of the default. You can use this parameter to override themid.snmp.request.timeout SNMP MID Server configuration parameter. Note: When use_getbulk is set to true, the timeout value is for an individual GETBULK request. 1500established_session_timeoutThe interval (in milliseconds) to wait for a response after at least one response has been received. Longer values can be useful for collecting complete and accurate data. You can use this parameter to override the mid.snmp.session.timeout SNMP MID Server configuration parameter.500debugEnables debug logging. Set to true for debug mode.falserequest_intervalThe interval (in milliseconds) between successive requests for an OID when a response has not been received, until the timeout (or established_session_timeout) value is reached. If this value is set to at least as long as the timeout (or established_session_timeout) value, then only a single request is sent for any particular OID. If you change the timeout (or established_session_timeout) value, adjust the request_interval at the same time to avoid sending too many or too few requests for the same OID, as appropriate for a given environment.400request_delayThe interval (in milliseconds) between the receipt of a response and the transmission of the next request. The default is 0 (no delay). This value may be set to slow the overall rate of an SNMP query.0result_formatReturns JSON formatted payloads for these probes: SNMP - F5 BIG-IP - SystemSNMP - Netscaler - SystemSNMP - Routing This parameter returns data in a more compact format to prevent sensor failure or memory problems on a node when the payload becomes large. Do not change this value or delete this parameter. Caution: Use of this parameter with any other probes causes the sensor to fail. JSONuse_getbulk Enables the use of SNMP GETBULK requests to retrieve tabular data from SNMP devices instead of using multiple SNMP GETNEXT requests. For tabular data, GETBULK is more efficient. Regardless of the request type, certain devices may not return any results when they are busy with other tasks. This parameter is used to configure at the probe level. GETBULK can also be set for an individual MID Server or globally for all MID servers. Settings are listed in the order of precedence: SNMP probe parameterMID Server configuration parameterMID Server properties The established_session_timeout, request_interval, andrequest_delay parameters are ignored when use_getbulk is set to true. Instead, the retries parameter is available. The timeout configuration is the same one used by use_getscalar. By default, the following probes use GETBULK requests (the parameter value is true). SNMP - Switch - VlanSNMP - Switch - BridgePortTableSNMP - Switch - ForwardingTableSNMP - Switch - SpanningTreeTableSNMP - Network - ArpTableSNMP - Layer 2 Protocol CachesSNMP - F5 BIG IP - System (only for Service Mapping customers) Note: These probes have a timeout value of 5000. falseuse_getscalarEnables the use of simplified retrieval and handling of scalar values from SNMP devices. The established_session_timeout, request_interval, and request_delay parameters are ignored when use_getscalar is set to true. Instead, the retries and timeout parameters are available. The timeout configuration is the same one used byuse_getbulk. falseretriesThe number of additional attempts Discovery makes to complete an individual GETBULK request (see use_getbulk) or a GETNEXT request when the use_getscalar parameter is set totrue.2 SNMP sys_properties glide.discovery.L3_mapping - Should be enabled if the ask is to extract a logical mapping of the TCP/IP layer for network gears. This is beyond Layer 2 discovery. SNMP script includes Here are a few SNMP script includes that are useful to know SnmpSensor Retrieves the OID for the specified field name from the respective Probe for this Sensor.Automatically trims the last object name off of Table SNMP field OIDs, for ease of use with the SNMPResponse class. SNMPResponse Wraps an SNMP payload response instance with methods to safely and easily retrieve SNMP singleton fields or tables. SnmpIdentityInfoParser Parses the SNMP - Identity Info MultiProbe result, adding generic NICs and serial numbers to the passed CIData object. SNMPNetworkInterfaces Handles creating network interfaces for JavaScript SNMP sensors. Common issues and how to investigate For information about troubleshooting SNMP issues from a MID server and how to perform an SNMP walk, see KB0696727: MID Server SNMP troubleshooting.For information about the Discovery of Wireless Access Points (WAP), see KB1511615. SNMP FAQs Q: Does SNMP discovery support V3 credentials?A: Yes. A credential type SNMPv3 Credentials can be used to configure the V3 credentials. Q: Do we support Wireless access point discovery?A: Yes if the WAP is expected to respond on SNMP. No, if its doesn't and in this case, we may have to look at targeting the controller that would be parenting the WAPs. Q: Why do we see slowness while discovering SNMP devices?A: In some cases, there will be differences between debug and runtime execution because during runtime, the execution demands more OIDs. This may cause the device not to respond properly to SNMP queries because SNMP services on network devices are a low priority. In cases of inconsistency or any weird behaviour, Wireshark logs can be collected and reviewed.Additional InformationSNMP Discovery TroubleshootingMID Server and SNMP TroubleshootingWhy Did SNMP Put my SNMP Device in the Wrong Table or CI ClassDiscovery Deep Dive - SNMP Classification and Properties