Skip to content
DX Infrastructure Manager Probes
Documentation powered by DocOps

snmpcollector Known Issues and Workarounds

Last update October 30, 2018

This article describes the known issues that are found in a particular release of snmpcollector.

Contents

Version 3.x Issues

Issue:

When I try to change device profile credentials for a SNMPv3 device from the AC profile, the device goes into failed state.

Workaround:

Delete the SNMPv3 device, and restart the probe and run device discovery, using the new profile credentials.

Issue:
        Rarely, the snmpcollector probe might lose communication with its database.

Workaround:
        Restart the snmpcollector probe.

Issue:

(3.3x) You see an error message stating that discovery_server 8.5 is required.

Workaround:

In v3.3, a Device Service Filter was added to the probe UI. You must have discovery_server 8.5 or later for the filter to work. If you do not want to upgrade to discovery_server 8.5 or later to use the Device Services Filter, clear any selections from the Selections field for the Device Services Filter. Clearing any selections prevent error messages. 

Issue:

(3.2x) If you have saved a CA UIM user name and password in the Chrome browser, the browser automatically fills in that CA UIM password in some fields in the snmpcollector v3.2x probe UI. The incorrect information in these fields causes an error in the snmpcollector UI that appears to result in the loss of profiles. If you have this issue, you might observe that, when you have more than 100 devices being polled by the snmpcollector probe running on CA UIM 8.47, the probe UI does not show the hostname or credentials for the devices. If you select Save, the probe saves either incorrect or no credentials.

Workaround:

Disable Chrome from automatically filling in credentials in the snmpcollector probe UI.

Issue:

(3.2x) If you use the probe update utility to enter more than one set of credentials for a device, the probe appears to save the credentials but does not use them correctly. This results in unpredictable monitoring.

Workaround:

Use only one set of credentials for each device with snmpcollector 3.2x.

Issue:

When you create a profile in the snmpcollector GUI with the non-default (161) port and then try to validate the credentials on that device, the validation fails. The validation fails because the dialog in which the user enters the credentials does not have a field to enter a port number and the probe uses the default port number to validate.


Workaround:

Validate the credentials manually by verifying that they enabled a profile connection and the collection of monitoring data for the device.

Issue:

The probe continues to poll and deliver metrics from deleted templates.

Workaround:

Restart the probe after deleting a template. Verify that the probe configuration is correct in the probe configuration GUI.

Issue:

The probe does not apply changes to preexisting templates.

Workaround:

Verify that the template is active and restart the snmpcollector probe. Verify that the probe configuration is correct in the probe configuration GUI.

Issue:

Some metrics that are related to RTTMON do not display in USM or in the PRD.

workaround:

None

Issue:

Interfaces or other device components on a Windows server are not sending QoS data to USM. This issue might be caused by issues that are related to SNMP GetBulk support on some Windows servers.

Workaround:

Change the SNMP configuration in the device profile to SNMPv1.

Issue :

Data might be lost in some instances where the password save feature that is included in most browsers automatically overwrites any passwords added to a device profile. The remaining profile information is deleted.  Profiles that have been impacted no longer display data when you select the first profile node.

Workaround:

Do not use the password save feature that is included in most browsers to save the admin console password.

Issue :

The probe does not start after install/upgrade.

Error in snmpcollector.log shows:

Feb 01 10:42:44:718 [SnmpCollectorMainExecution, snmpcollector] Exception thrown initializing database: Connections could not be acquired from the underlying database!
Feb 01 10:42:44:719 [SnmpCollectorMainExecution, snmpcollector] stderr: Exception in thread "SnmpCollectorMainExecution"
Feb 01 10:42:44:720 [SnmpCollectorMainExecution, snmpcollector] stderr: java.lang.NoClassDefFoundError: Could not initialize class com.nimsoft.probes.network.snmpcollector.database.PMF

Cause :

This issue appears due to:

  • internal database too busy to respond.
  • corruption of internal database (snmpcollector.mv.db) file.

Solution:

Follow these steps to resolve this issue:

  1. Navigate to the Raw Configure interface and add the MAX_BATCH key to the <setup> section and check if probe starts.
    MAX_BATCH = 3
  2. If the probe does not start, search for recent backups of snmpcollector.mv.db. If a backup is available, deactivate the probe, replace the backup, and then start the probe.
  3. If the probe does not start, deactivate the probe and move the following files out of the snmpcollector probe directory:

    Note: If you have modified the User-defined property 1 fields of ifSpeeds, the information is lost. Also, deleting the snmpcollector.mv.db file, deletes any manual additions. For example, profiles not pulled in through the discovery_server as well as any/all "User defined property 1" values that you added at the device and component level.

  4. Activate the snmpcollector probe.
  5. Query the discovery_server for the devices to monitor. You may need to delete and re-enter the discovery_server information in the Discovery Filter before you rediscover all your profiles. If profiles were manually added, you must add the profile again manually.
  6. The probe should start working as expected now and should respond properly to a restart or cold start. Check the logs after completing the above steps.

Version 2.2x Issues

Issue :

Data might be lost in some instances where the password save feature included in most browsers automatically overwrites any passwords added to a device profile. The remaining profile information is deleted.  Profiles that have been impacted no longer display data when you select the first profile node.

Workaround:

Do not use the password save feature included in most browsers to save the admin console password. 

Version 2.1x Issues

Issue :

In version 2.11, the probe configuration GUI and templates show some metrics as numbers. The metric types for the CacheHitRatio, SessionRate1Min, TotalLicenses, and UsedLicenses metrics as numbers.

Workaround:

  • 11.157:5 = DNS.CacheHitRatio
  • 11.55.27 = System Session Information.SessionRate1Min
  • 11.396:1 = License Management.TotalLicenses
  • 11.396:2 = License Management.UsedLicenses

Issue:

In version 2.1, the Availability metric value is either 100 or No Value (null).

Workaround:

Use the Reachability metric to provide an idea about whether a system is reachable or not. The Reachability metric always provides a value of 100 when the device is reachable and No Value otherwise.

Issue:

In version 2.1, the Run Vendor Certification Test does not work correctly for the Availability metric. The Availability metric is a calculated value for monitoring device up-time. The test returns "null" for v2.0 and "NA" for v2.1.

Workaround:

Use the Reachability metric instead of the Availability metric. The Reachability metric gives accurate information for monitoring connectivity to monitored devices. 

Issue:

In version 2.1, the speed for high speed interfaces (> 4 Gbits/sec) that appears on the interfaces tab in USM is incorrect.

Workaround:

Do not use the value for interface speed. This number is an approximate static maximum value.

Version 2.0x Issues

Issue:

The Run Vendor Certification Test does not work correctly for the Availability metric. The Availability metric is a calculated value for monitoring device up-time. The test returns "null" for v2.0 and "NA" for v2.1.

Workaround:

Use the Reachability metric instead of the Availability metric. The Reachability metric gives accurate information for monitoring connectivity to monitored devices. 

Issue:

The speed for high speed interfaces (> 4 Gbits/sec) that appears on the interfaces tab in USM is incorrect.

Workaround:

Do not use the value for interface speed. This number is an approximate static maximum value.

Issue:

The various threshold settings for a metric are used to generate baseline data in USM. The scale of the monitoring environment has a direct impact on the calculation of baseline data. In larger scale environments, it could take significantly longer for the data to appear in USM.

Workaround:

Only enable the threshold settings that are necessary. No workaround exists at this time.

Issue:

The discovery query can take a long time to complete if there is a discovery filter with a subnet mask.

Workaround:

It can take some time for the devices to load if the discovery scope is for a large number of devices. Entering range scopes larger than 65,536 addresses (subnets greater than /16) impacts discovery performance. Wait for the discovery process to complete. 

  • To verify the status of the device import, select the snmpcollector node, and view the Profile Import Status field.

  • To verify the status of subcomponent discovery, select snmpcollector > Profiles > profile name >device name, and view the Component Discovery field.

Version 1.6x Issues

Issue:

Starting with version 1.61, counts have significantly dropped for metrics that measured network packets (bits, frames, octets).

Workaround:

The drop in counts is expected after an upgrade to version 1.61 or later. Pollagent now calculates metrics with a RollupStrategy of sum as a rate over time in seconds since the last polling cycle.

Look in the appropriate metric family file in <install_path>\Nimsoft\probes\network\snmpcollector\MetricFamily to view the RollupStrategy for a particular metric.

Issue:

The SNMP Data Monitoring probe shows fewer metrics after an upgrade to v1.6.

Workaround:

This behavior is not an issue. The metrics for SNMP response time and availability previously existed within each metric family. With v1.6, these metrics were consolidated into their own metric families that are named Reachability and Availability.

Version 1.4x and Earlier Issues

Issue:

In versions earlier than1.2, all devices might not receive the updated thresholds when thresholds are changed in a monitoring template.

Workaround:

Avoid changing an existing monitoring template. Create a new template (uses the values in the default) and apply the new template to the devices.

Issue:

In version 1.0, discovery can take longer than expected. The snmpcollector version 1.1 probe greatly improves performance of discovery.

Workaround:

To verify discovery progress:

  • Version 1.0 
    In the probe GUI, click the SNMP Collector Probe node in the tree and view the Discovery Status field.
  • Version 1.1 and later
    In the probe GUI, click a device name in the tree and view the Component Discovery field.

General Probe Issues

Issue:

The probe does not collect or publish data for interface types 1 (other) and 24 (softwareLoopback).

Workaround:
None. The probe functions as designed. Because interface types 1 (other) and 24 (softwareLoopback) do not provide any network traffic information they are excluded from the vendor certifications for the probe.

Issue:

Changes to profile credentials are not saved if you add a profile and then edit an authentication credential.

Workaround:

Delete the profile and add it with the correct credentials.

Issue:

The configuration file can become corrupted if the probe is disconnected from the controller while executing a discovery or configuration operation.

Workaround:

The snmpcollector probe creates a configuration backup file every time the probe starts successfully. You can use the snmpcollector.cfg.BAK file that is located in Nimsoft/probes/networking/snmpcollector/ to assist with the recovery process. Make frequent backups while making configuration changes.

Issue:

The interface speed for some virtual interfaces is not reported correctly. The device is not able to detect the true speed of connection for the virtual interface. This issue is seen with WAN-related interfaces.

Workaround:

To calculate utilization on these interfaces, contact your system administrator to determine the maximum speed of the interface. Then set the interface speed in the probe.

The interface speed settings are available with probe v1.42 or later. Set an override value in the Speed out Override and Speed in Override fields in bits per second. 
For example, to set an interface to a speed of 100 GB you would enter 100000000000.

Issue:

Where are the probe log files?

Workaround:

For Admin Console users: Click the triangle next to the probe name in the Admin Console and click View Log in the drop-down list.

Issue:

Some polled metric values larger than 8 million might be rounded. This behavior limits the precision available in polled metrics.

Workaround:

No workaround exists at this time.

Issue:

I see an I/O communication error in the snmpcollector.log file with the following message:

Exception in ThreadClient: (2) communication error, I/O error on nim session (S) com.nimsoft.nimbus.NimServerSession(/123.45.678.191:54827-/123.45.6.7:59412): End of stream while trying to read header.

This message only appears when loglevel is 1 or greater when loading or reloading the configuration page.

Workaround:

No action is required. You can ignore this alarm.

Issue:

SNMP devices with nonstandard port numbers are not detected. The standard port number for an SNMP device is 161.

Workaround:

 View the device in NMS and verify that a nonstandard device port is in use. 

  • For v1.61 and earlier, reconfigure the device to use port 161.
  • For v2.0 and later, go to the probe configuration GUI and locate the device profile (snmpcollector > Profiles > profile name). Enter the correct SNMP port for the device.

Issue:

I see an alarm with the following message:

An attach queue for the subject probe_discovery on the hub /SNMPdom/SNMPhub/SNMProbot/hub has been successfully detected. Though not determined here, either a get or post queue may also be needed to forward discovery results if this is not the primary hub.

Workaround:

No action is required. You can ignore this alarm.

Issue:

Initial discovery of device subcomponents can take 30 minutes or more to complete the first time you query the discovery server. Screen (GUI) timeouts might occur during this period.

Workaround:

Upgrade to v3.3. Earlier versions of the probe have, by default, discovered over 400 metric families. In v3.3, we have reduced the number of metric families that are discovered by default. The configuration file for v3.3 includes only 35 metric families. When you upgrade to v3.30, only those metric families, and any other metric families that you have selected in the monitoring templates, are included in the configuration file. When you upgrade to v3.3, the metric families for any metrics that you have configured in monitoring templates are automatically added to the probe configuration file. Similarly, after you upgrade to v3.3, the metric family for any metric that you add to a monitoring template is automatically added to the configuration file for the probe.

For more information, see Upgrade snmpcollector.

Workaround:

Wait for subcomponent discovery to complete.

Issue:

Admin Console based Restart command does not work for snmpcollector or pollagent.

Workaround:

First Deactivate the probe and then Activate it.

Issue:

The SNMP Data Monitoring probe might be unresponsive under heavy load, during scheduled rediscovery, or immediately after applying a monitoring template to multiple large devices.

Workaround:

Upgrade to v3.3. Earlier versions of the probe have, by default, discovered over 400 metric families. In v3.3, we have reduced the number of metric families that are discovered by default. The configuration file for v3.3 includes only 35 metric families. When you upgrade to v3.30, only those metric families, and any other metric families that you have selected in the monitoring templates, are included in the configuration file. When you upgrade to v3.3, the metric families for any metrics that you have configured in monitoring templates are automatically added to the probe configuration file. Similarly, after you upgrade to v3.3, the metric family for any metric that you add to a monitoring template is automatically added to the configuration file for the probe.

For more information, see Upgrade snmpcollector.

Workaround:

If the probe is unresponsive, wait several minutes and try again.

Issue:

Your SNMP Data Monitoring probe does not start. If the process died or was killed while saving discovery or configuration changes, the configuration file might be corrupt.

Workaround:

Use the most recent snmpcollector.cfg.BAK file to recover the probe configuration. The SNMP Data Monitoring probe creates a configuration backup file every time the probe starts successfully.

  • Locate the snmpcollector.cfg and snmpcollector.cfg.BAK files in Nimsoft/probes/networking/snmpcollector/.
  • Copy and rename the current snmpcollector.cfg file. You can use this file for later analysis.
  • Copy and overwrite the snmpcollector.cfg file with the snmpcollector.cfg.BAK file.
  • Restart the probe. 
    The probe starts with the last successful configuration. Any configuration changes made since the last successful startup are lost.

Issue:

No QoS data is available.

Workaround:

  • Subcomponent discovery might not be completed. To verify  discovery progress:
    • Version 1.0
      In the probe GUI, click the snmpcollector node in the tree and view the Discovery Status field.
    • Versions 1.1 and later
      • In the probe GUI, click a device name in the tree and view the Component Discovery field. The device might not have a monitoring configuration.
      • If no subcomponents are listed for the device, try the following actions:
        • Validate that the MIB is returning valid data for the SNMP MIB table of interest using a tool such as the snmpget probe.
        • Verify that the subcomponents are administratively up.
        • Validate the SNMP credentials for the device. If the credentials are not valid, you cannot expand the nodes to see the components.
      • Subcomponents might be disabled on the device.
        If they are disabled, follow the manufacturer's instructions to enable the subcomponents.
Was this helpful?

Please log in to post comments.