Discovery Access - Result and End State

Version 10
    Share:|

    Link to Chapter Contents:    ADDM Support Guide - Chapter 4 - Understanding the Discovery Process

     

    DA: Result and End State

     

    There are two key fields that show the result of the DA.  These are:

     

    1. End State
    2. Result


    End State and Result are attributes within the DA Nodes.



    Sample Query for Recent DAs

     

    Question:  How well are we doing in overcoming access issues?


    Answer: Run the following report as a Generic Query. You can cut and paste the column called Command into the Generic Search Query field.


    addm-chapter-4-generic-search.jpg

     



    Run the report when there are no discovery jobs running – otherwise some endpoints will be missing..Explanation of the lines:

     

     

    CommandExplanation
    SEARCH DiscoveryAccessSearch the DA nodes
    WHERE _last_markerOnly include rows where _last_marker is set.  This field is set if the DA is the last DA for the Host or Device – otherwise we will get multiple DAs for each endpoint.
    AND state = 'Finished'Exclude DAs that are currently running.
    AND end_state <> 'NoResponse'Exclude endpoints that don't respond.  Nothing there?
    AND end_state <> OptNotBestIPExclude secondary IP-Addresses
    AND end_state <> 'Excluded'Exclude excluded IP-Addresses
    ORDER BY discovery_starttime DESCSort the output by this column.  DESC = Sort Descending.
    SHOWShow the following columns in the report.
    #DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:DeviceInfo.os_class AS 'Discovered OS Class',Discovery OS Class:None, Windows, Embedded, Unknown, UNIX, Other
    whenWasThat(discovery_starttime) AS 'When',whenWasThat returns the time relative to now e.g. “25 minutes ago”
    endpoint as 'End Point',The target IP-Address
    #DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:DeviceInfo.hostname AS 'Hostname',The target hostname
    #DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:DeviceInfo.os AS 'Discovered OS',Discovered OS – such as:"Cisco 870 router or 2960 switch (IOS 12.2 - 12.4)"
    #DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:DeviceInfo.os_type AS 'OS Type',OS Type – a little more detailed that OS Class such as:
    "IOS"
    #DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:DeviceInfo.os_version AS 'OS Version',OS Version such as "12.2"
    end_state AS 'End State',UnsupportedDevice, GoodAccess, NoResponse, NoAccess, OptNotBestIP,Opt1stScan, Error, Excluded
    result AS 'Result'Skipped, Success, NoResponse, NoAccess, Error

     



    Breakdown of DA Results by end_state and result

     

     

    Query1 – All Latest DA nodes

     

    Queries can be run using the Generic Search Query menu (see picture).  To see all the DA result, run this query on the Consolidation server:


    SEARCH DiscoveryAccess WHERE _last_marker AND state = 'Finished'



    Query2 – End State by Result

     

    The table below can be obtained by running this query on the consolidation server:


    SEARCH DiscoveryAccess

    WHERE _last_marker

    AND state = 'Finished'

    SHOW end_state AS 'End State',

    result AS 'Result'

    PROCESS WITH countUnique(0)



    Results of Query – End State by Result

     

    The Table below shows end_state by result



    End StateResultTotal Count
    NoResponseNoResponse36474Unable to get the deviceInfo: NoSuchDevice.  The IP-Address was alive in a previous scan but is not responding now (maybe Laptop Offline).  This figure may look artificially high because all previous DAs may contribute to the figure – because _last_marker is still set for previous DAs. Endpoints with NoResponse should be excluded from reporting– since there is nothing that you can do about them.
    UnsupportedDeviceSkipped16380

    UnsupportedDevice.  Probably an IP-Phone, IOS Switch, HP or SPARC ILO Console, or Printer perhaps with no SNMP access due to ACL on Switch not configured.

    GoodAccessSuccess11747
    ErrorError4324Errors:  Unable to get the deviceInfo: User cancelled request.  A lot of these errors appear to be cancelled requests from several years ago.  Need to check Model Maintenance settings on the consolidation server and potentially ask BMC why these are not being purged.  There are more Errors on the consolidation Appliance than on the Discovery appliances.  Why?  Need to exclude Errors from any management reporting.
    OptRemoteSkipped2730The documentation says: IP Consolidated when originally optimized on Discovery Appliance.
    NoAccessNoAccess2322Devices with no Access – UNIX, Windows, VMWare ESXi servers with Credential problems.  Many are GNU/LINUX end-points which are the management consoles for hardware that use LINUX based firmware – such as Wirelsss Routers, ILM Consoles etc.
    OptNotBestIPSkipped102

    ADDM does not scan secondary IP-Addresses. OptNotBestIP DA nodes don't appear to get pushed to the consolidation server.  I believe they get renamed to OptRemote.

    Opt1stScanSkipped93When a host or device first appears on the Network, ADM will scan just for the IP-Addresses and then select the primary IP-Address for scanning.  Opt1stScan DA nodes don't appear to get pushed to the consolidation server.  I believe they get renamed to OptRemote.
    ExcludedSkipped84Unable to get the deviceInfo: Endpoint has no available scan window or is in an excluded range. IP-Addresses can be explicitly excluded.
    GoodAccessError13
    DeviceIdentifiedSuccess11



    Unused IP-Addresses will not have an associated DA
    if Darkspace suppression is configured
    (which it should be)
    .


    End State Values

     

    addm-chapter-4-chart-end-state.jpg

     

     

    The Bar Chart above shows the possible values for End-State.



    Skipped

     

    DAs that end with a Result of Skipped have an End State of: UnsupportedDevice, OptNotBestIP, Opt1stScan, Excluded.



    UnsupportedDevice

     

    UnsupportedDevice is the default end_state for any device that BMC Atrium Discovery can detect, but do not have any knowledge of in Reasoning to build an inferred node. We might still be able to identify what the device is and some key properties, or we might know nothing more than the fact it returned a ping.Example: Discovery has received a response from an endpoint but has not been able to identify the device further. This might mean that the OS is unrecognized, garbage has been returned or there is a shell error. This can be caused by a firewall.



    OptNotBestIP

     

    Second Scan Optimization (Best IP) Example: The user has requested a scan of an IP that is on a host that has already been scanned using another IP address that is considered to be the best IP to use to scan that host.



    Opt1stScan


    When a device first appears on an IP-Address, ADDM performed a light scan initially to get all the IP-Addresses on that host.  It then chooses one primary IP-Address to use for the next scan.  The other IP Addresses are then marked as OptNotBestIP for subsequent scans and are skipped.

     

     

    No Access

     

    Within each Discovery Run (DR), many DAs will finish with an End State of No Access.


    1. The target is responding on certain ports but ADDM has failed to establish a connection to the server in order to login.
    2. ADDM has cycled through all the credentials but all of them failed to logon to the server
    3. The Credentials were successful, but ADDM was unable to interrogate the device and runGetHostInfo due to other permission issues.

     

     

    Total Number of No Access Errors

     

    The following table shows the total number of No Access errors across all discovery jobs.  As you can see, the number of No Access errors is much too high.  There is a lot of work to do.



    ApplianceDiscovery NameSuccessfulNo Access
    #1Data Centres1850835
    #1

    Desktops & Servers #1

    1421279
    #1

    Desktops & abc.com

    28541258
    #1

    Desktops & Servers #2

    21663145
    #1

    Desktops & Servers #3

    574

    88

    #2

    Extranet - Public, Private DMZs #1

    48

    22

    #3

    Extranet - Public, Private, DMZs #2

    49

    17

    #4

    Extranet - Public, Private, DMZs #3

    42

    58

    Total

    9004

    5702

     

     

     

    No Access Errors – Example

     

    addm-chapter-4-noaccess-errors.jpg

     

     

    No Response

     

    The NoResponse result is returned for the following reason:  Port scanning indicated that something exists on the IP-Address, but getDeviceInfo failed.  getDeviceInfo may have been an SNMP get.  ADDM was therefore not able to identify the device and did not know if it should connect via WMI, SSH or SNMP.  The result of NoResponse does NOT mean that there is nothing detected on the IP-Address.



    No Response – Example


    If you scan a single subnet consisting of 256 IP-Addresses, you may get a DR result like this:

     

     

    DA: Result

    Number

    Success

    118

    Skipped

    14

    No Access

    13

    No Response

    12

    Error

    0

    Total Endpoints

    157

     

     

     

    Please note that in this example, the total number of end-points detected is not equal to 256 – because some of the IP-Addresses are not being used.

     

     

    Link to Chapter Contents:    ADDM Support Guide - Chapter 4 - Understanding the Discovery Process

     

    end