SNMP Active Discovery
Last updated on 20 January, 2020The SNMP Active Discovery method is used to detect and group SNMP objects. As with all other Active Discovery methods, it also supports filtering. SNMP Active Discovery will walk a given SNMP OID, and return all objects beneath that branch of the MIB tree as the wildcard value (without the common base OID). The Alias returned depends on the Discovery Type selected.
Please note that when SNMP active discovery is run, SNMPv3 is attempted first, followed by SNMPv2 and SNMPv1 then v2c, then v1. All SNMP versions will be attempted as a means of verifying any potential version change. When SNMPv3 is used, the default user will be “logicmonitor” if none has been configured.
Parameters
The parameters for SNMP Active Discovery are:
- Discovery Type: one of “value“, “wildcard” or “lookup”. For more detail, see the sections below.
- SNMP OID: The base SNMP object identifier that will be walked to discover all objects beneath it. All objects that are found by walking beneath this OID will be returned as instances – assuming they pass any filters.
- Description OID (optional): If not empty, the value returned by this OID is appended to the discovered instance, and returned as the instance description. This is useful for returning interface descriptions for switches, for example.
Value Discovery
Where Discovery Type =”value”, the name or alias for each discovered instance is the value reported by each leaf of the OID tree.
e.g. A walk of the interface OID, .1.3.6.1.2.1.31.1.1.1.1, on a given system returns:
Using the Active Discovery section from the snmp interface monitoring datasource:
this would return 3 instances, with the following instance names and wildcard values:
Wildcard Discovery
Where Discovery Type =”wildcard”, the name/alias for each discovered instance is the unique index of each leaf of the OID tree – i.e. the name is the same as the wildcard value. Using the same Active Discovery section as in the image above, except with the type set to wildcard:
this would return 3 instances, with the following instance names and wildcard values:
Lookup Discovery
Where Discovery Type is Lookup another parameter is required – the Lookup OID. The name returned for each instance is the result returned by querying the Lookup OID for the value returned by the primary OID for the instance. If the object does not exist in the second OID, the index of the first OID is returned.
For example, on a Cisco router, a walk of 1.3.6.1.4.1.9.9.109.1.1.1.1.2 returns the physical index of all CPUs:
You can then use the returned indices to query the entPhysicalName (.1.3.6.1.2.1.47.1.1.1.1.7) table to get the descriptive name of each CPU. So, an SNMP query of 1.3.6.1.2.1.47.1.1.1.1.7.3013 returns “CPU of Routing Processor 5”, while an SNMP query of 1.3.6.1.2.1.47.1.1.1.1.7.3001 returns “CPU of Switching Processor 5”. If the Active Discovery section is configured like this:
then the following 2 instances would be returned:
Filtering in SNMP ActiveDiscovery
SNMP Active Discovery supports flexible instance filtering. Multiple filters can be added, to include to exclude different objects.
Each Value object returned by the initial SNMP OID walk is appended to the OID in the filter section; the resulting SNMP object if retrieved, and tested against the applied tests.
For example, the below filters will walk all interfaces returned from the OID .1.3.6.1.2.1.2.2.1.2. (which returns the interface description.)
If the walk of the SNMP OID returns three interfaces, with Values of .1, .2 and .3 (i.e. their interface descriptions are available by doing an SNMP GET on .1.3.6.1.2.1.2.2.1.2.1, .1.3.6.1.2.1.2.2.1.2.2 and .1.3.6.1.2.1.2.2.1.2.3 respectively), then these interfaces will be tested against the filters.
Just taking the first interface as an example, the one with the .1 value, the interface will only be reported by ActiveDiscovery if:
- an SNMP GET on .1.3.6.1.2.1.2.2.1.8.1 (the filter plus the value) returns a value of 1 (meaning the interface is operationally up)
- an SNMP GET on .1.3.6.1.2.1.31.1.1.1.1.1 (the filter plus the value) returns a string that does not contain the string “Nu” (which usually indicates a Null interface, which does not need monitoring.)
Note that all filters must be passed in order for an object to be reported by ActiveDiscovery.
SNMP Instance Level Properties (ILP)
Instance Level Properties provide both rich instance-level information and more granular control of your monitoring.
Setting-up SNMP ILPs
Once Active Discovery is enabled on your SNMP datasource, the field “Extract Instance-Level Properties” will be displayed. Select this option.
You will be prompted to define the properties you wish to extract from your SNMP instances. To do this, you will need to provide the following information:
- SNMP OID: the OID of the instance from which you want to retrieve a property. You can append token ##WILDVALUE## to your OID. This will populate the key of the key-value pair that is walked.
- Property name: the name of the property you wish to retrieve. Note that instance level properties begin with prefix “auto.” which differs from LogicMonitor’s autoproperties, prefixed with “system.” This is meant to distinguish the fact that instance level properties, unlike autoproperties, are not inherent in LogicMonitor, so users can control how and if they are set.
- SNMP Method: The manner by which we will fetch the instance level property. There are four options available:
- GET: Uses snmpGET to fetch ILP. This is the default method for retrieving ILPs. This will perform an SNMP GET to retrieve a single value from the OID provided, after substituting any tokens, and assigning the returned value to the property.
- WALK: Uses snmpWALK to query all values under an OID, and sets the ILP to the returned key-value pairs, comma-delimited.
- WALK-KEY: Uses snmpWALK to retrieve all SNMP entries under the given OID, and set the ILP to a list composed of all keys returned, comma-separated.
- WALK-VALUE: Uses snmpWALK to retrieve all SNMP entries under the given OID, and set the ILP to a list composed of all values returned, comma-separated.
Add a filter
If any Active Discovery filters are specified, only discovered instances that meet the filter criteria will be returned.
If you choose to extract ILPs, you may add filters based on ILPs discovered. For example, with ILPs you can easily create an Active Discovery filter that display only enabled network interfaces.
