Share This:

KA 000349819 describes the process for running a device capture and requesting integration support for an unsupported SNMP-enabled device, such as a Network Device or Printer.

 

The device capture produces a zip that contains several files. The most important of these files are:

  • capture.log - Look here for the sysobjectid and sysdescr values, and check for any error messages
  • <ip_address>@public.MVC file - This is the actual formatted device dump.

 

However, problems occasionally occur when running a device capture. What are the most common problems, and how to troubleshoot them?

 

 

1. A device capture fails with "ERROR: SNMP++: SNMP request timeout" or "Device skipped - no SNMP access".

 

Here’s an example from a device capture log:

 

Note that there are two ways to get a device capture (see https://docs.bmc.com/docs/discovery/113/capturing-snmp-devices-788111406.html):

  • from the Discovery Access page
  • from the Device Info page (which is reached from the Discovery Access page)

 

In some cases, doing a capture from a Device Info node may result in a blank screen. When clicking the browser "back" button, it returns to the Device Info page and briefly shows a green banner that says "Device skipped (no SNMP access)", which then fades out after a few seconds:

 

There are many possible reasons for the "timeout / no access" result. Here are some possible causes and things to check:

  • Make sure a SNMP credential is present and that the IP range includes the address being discovered (a valid credential is needed for device capture)
  • Run a credential test. What is the result?
  • Increase the timeout in the SNMP credential to 100 seconds and retry.
  • What is the SNMP version (v1, v2c, v3) on the credential? Is the device configured to respond on that SNMP version?
  • If the device supports SNMP versions other than the one specified in the credential, change the version in the credential and retry.
  • For SNMP v1 and v2c, make sure the community string in the SNMP credential is correct. An invalid community string can cause a "Unable to get the deviceInfo: TRANSIENT" error.
  • Ask the device administrator:
    • if there might be an Access Control List (ACL) or some other configuration on the device that prevents responses to the Discovery appliance.
    • if the device is configured to use the default SNMP port (161). Run nmap to confirm the port is open (see below).
  • On the Discovery Access page, click on any links for "script failure" or "xx Session Results related" to look for clues.
  • In the case of a timeout during a device capture, check the log in /usr/tideway/var/captures for additional clues
  • In the case of a timeout during a scan, turn DEBUG logging on for Discovery, run the scan again, and check the tw_svc_discovery.log for clues. Remember to turn DEBUG logging off!
  • In one case, the customer made corrections to the IP range and mask on the device, then was able to discover the device.

 

  • From the Discovery command line, as user tideway, run the following commands and check the results:

    a) Check connectivity from the appliance to the endpoint:

                             ping [device_ip_address]

                             traceroute [device_ip_address]

 

     b) Check the port status of the device by running nmap. For example:

 

    /usr/bin/nmap --privileged -sT -sU -p T:22,U:161 [device_ip_address]

 

The expected result is that port 161 would have a state of "open" or "open|filtered" :

        

      c) Do a snmpwalk to the device. For example:

 

                         /usr/tideway/snmp++/bin/snmpWalk [device_ip_address] -v2c -cpublic > /usr/tideway/snmpwalk.out

 

Change the SNMP version and community string as needed. If using SNMP v3, other parameters need to be specified. To see the usage notes with a list of available options, run snmpwalk with the "--help" option.

 

If snmpwalk also fails, please consult the device administrator.

 

If the problem persists, please contact Customer Support and provide the results to all the questions / checks above.

 

 

2. A device capture fails with "ERROR: sysObjectID is not an enterprise MIB" :

 

sysDescr: Cisco Secure Access Control System 5.4

sysObjectID: 1.3.6.1.2.1.47.1.1.1.1.13.1

ERROR: sysObjectID is not an enterprise MIB: 1.3.6.1.2.1.47.1.1.1.1.13.1

 

Discovery expects every sysObjectId to begin with 1.3.6.1.4.1 as per the SNMP MIB standard. Each vendor is allocated a subtree under 1.3.6.1.4.1.

 

Because the sysObjectID does not comply with the SNMP MIB RFC published here:

 

https://www.rfc-editor.org/rfc/rfc3418.txt

 

it is currently not possible to discover this device.

 

3. A device capture fails with "ERROR: Loop detected" :

 

Dumping range: Start of MIB to End of MIB

ERROR: Loop detected: current OID is 1.3.6.1.2.1.17.4.3.1.1.0.0.170.199.13.135, WAS 1.3.6.1.2.1.17.4.3.1.1.44.65.56.156.227.187 previous OID, OID ILD is 1.3.6.1.2.1.17.4.3.1.1.44.65.56.156.227.187

 

An snmpwalk shows something like this:

 

SNMP++ snmpWalk to <ip address> SNMPV2 Retries=1 Timeout=1000ms Community=<community>

[...]

1.3.6.1.2.1.1.9.1.4.1 = 0:00:00.00

1.3.6.1.2.1.2.1.0 = 31

1.3.6.1.2.1.2.2.1.1.1 = 1

1.3.6.1.2.1.2.2.1.1.1 = 1

1.3.6.1.2.1.2.2.1.1.1 = 1

[...]

 

The "next oid" of 1.3.6.1.2.1.2.2.1.1.1 is itself (not normal, this indicates a loop).

 

In some cases, it is possible to work around this. Please contact Customer Support and provide the device capture file.

 

4. A device capture for a router device takes hours to complete.

 

If a router device has a huge routing table, device capture may take a long time to complete. In a case where the capture is not completed even after several hours, it can be cancelled and the partial capture can be shared with BMC Support for device integration.

 

In some cases, the partial device capture contains sufficient information for device integration.

 

5. A device capture fails with ERROR: SNMP: Variable does not exist

 

This typically indicates a problem with the device or the SNMP agent running on it. To confirm, run an snmpwalk on the device (see above). If the snmpwalk also fails (or does not produce usable output), please contact the device vendor.

 

6. A device capture fails with ERROR: SNMP: Cannot perform operation, General Error

 

This typically indicates a problem with the device or the SNMP agent running on it. To confirm, run an snmpwalk on the device (see above). If the snmpwalk also fails (or does not produce usable output), please contact the device vendor.

 

In some cases, the device capture in this case will produce a partial capture file that is sufficient to integrate this device. If so, please contact Customer Support and provide the device capture file and snmpwalk output.