Checking device access

Use reports and SQL queries to check that all devices responded to SNMP requests during the discovery.

About this task

If you want to check that the discovery was able to access all the devices in your configured scope zones, run the Devices with no SNMP Access report. This report lists the devices that were found but for which for some reason the discovery was unable to access the device using SNMP.

Once you have identified the devices that the discovery was unable to access using SNMP, you can begin to investigate why SNMP access failed. Reasons why SNMP access might fail include the following:
Device not reachable
A firewall configuration might be blocking SNMP access. Make sure that SNMP access to the device is possible across your network's firewalls.
Device not responding
When Network Manager issues a request to a device, if the device does not respond, the request times out after a configurable time-out period and number of retries. Reasons for the timeout might include any of the following:
  • If any of the devices in the configured scope zones is down at the time of discovery, then the device will not be found by the Ping finder and will not appear in the discovered network topology. You will also not be able to see these devices in the Devices with no SNMP Access report.
  • The SNMP agent on the device is not running. Check the device and make sure that the SNMP agent is running.
  • The SNMP agent is using a non-standard port. SNMP uses UDP protocol to communicate with the agents normally on port 161. You might need to reconfigure this on the device.
  • The SNMP agent on the device is configured with a different community string than the one that you specified in Network Manager.
  • If access control lists (ACLs) are being used for SNMP security, then check that the management device is on the SNMP agent ACL.
Note:

When a device fails to respond to SNMP polling a certain number of times, it is removed from the polling scope. The status of the device is then set to NoAccessConfigured (the value of m_haveAccess in the discovery returns database tables is set to false). The polling process cannot determine whether the device failed to respond because it is offline or because the credentials are incorrect. The next time that network discovery runs, the discovery determines whether the device has a new IP address, or the access credentials have changed.

In version 4.1 of Network Manager, the device was assumed to be offline.

To fix the case where the reason for SNMP access failure is that the SNMP agent on the device is configured with a different community string than the one that specified in Network Manager, complete the following steps:

Procedure

  1. Click the Reporting icon and select Common Reporting. Within the widget, select Network Manager. A list of folders display. These folders contain all Cognos reports for your access.
  2. Click Troubleshooting Reports.
  3. Select the Devices with no SNMP Access report.
    The report displays a list of devices (the entity name and the IP address for each device) that the discovery found but the discovery agents were unable to access using SNMP.
  4. To check which community string Network Manager used during discovery for a given IP address, run the following SQL query on the NCMONITOR database to retrieve the SNMP access attributes for that device.

    SQL Query for SNMPv1

    SELECT v1.community, sa.version, sa.timeout, sa.retries
FROM ncmonitor.snmpTarget st
INNER JOIN ncmonitor.snmpV1Sec v1 on v1.accessid = st.readaccessid
INNER JOIN ncmonitor.snmpAccess sa on sa.accessId = v1.accessid
WHERE st.netaddr = 'ip_address';

    SQL Query for SNMPv2

    SELECT v1.community, sa.version, sa.timeout, sa.retries
FROM ncmonitor.snmpTarget st
INNER JOIN ncmonitor.snmpV1Sec v1 on v1.accessid = st.targetid
INNER JOIN ncmonitor.snmpAccess sa on sa.accessid = v1.accessid
WHERE st.netaddr = 'ip_address';

    SQL Query for SNMPv3

    SELECT v1.userid, v1.securitylevel, sa.version, sa.timeout, sa.retries
FROM ncmonitor.snmpTarget st
INNER JOIN ncmonitor.snmpV3Sec v1 on v1.accessid = st.readaccessid
INNER JOIN ncmonitor.snmpAccess sa on sa.accessid = v1.accessid
WHERE st.netaddr = 'ip_address';
    Where ip_address is one of the IP addresses listed in the Devices with no SNMP Access report.
    This query retrieves the following information:
    community
    Community string to use.
    version
    SNMP version to be used. Possible value are:
    • 0: SNMPv1
    • 1: SNMPv2
    • 3: SNMPv3
    timeout
    Number of milliseconds before retrying the SNMP request .
    retries
    Number of retries before giving up.
  5. If the community string is encrypted, you can decrypt it using the ncp_crypt utility.
    For example, the following command-line decrypts an encrypted password.
    ncp_crypt -password @44:G5IhL1i2obPcXDu6uiMcse+U0qdRPojK0o6erxrfk/Y=@ -decrypt
ncp_crypt ( IBM Tivoli Network Manager Password Encryption/Decryption Tool )
Copyright (C) 1997 - 2008 By IBM Corporation. All Rights Reserved. See product license for details.

IBM Tivoli Network Manager Version 3.9 created by fblucher at 03:38:26 Wed Nov 19 GMT 2010

@44:G5IhL1i2obPcXDu6uiMcse+U0qdRPojK0o6erxrfk/Y=@ public
  6. Compare the SNMP community string stored in the NCMONITOR database for each device with the actual SNMP community for that device.
  7. Correct the SNMP community string information for each device in the Discovery Configuration GUI.

Results

You have now checked that discovery was able to access devices and have corrected the SNMP community strings for any devices which could not be accessed. The next step is to check for any unclassified devices, that is, devices that do not have a device type classification within Network Manager.