Dark space scanning

This release makes some changes to the way that discovery is undertaken in BMC Atrium Discovery. This improves the efficiency of dark space scanning and removes the need for organizations with sparsely populated IP space to perform sweep scans to determine the IP addresses which should be scanned.

Scanning is now undertaken in two distinct parts:

  • Pre-scanning
  • Scanning

Pre-scanning is the initial stage of discovery. The list of endpoints to be scanned is segmented into blocks of 256, and each block is passed to discovery. The endpoints are then pre-scanned in parallel using the following techniques, if enabled in discovery configuration and the IP address is not part of an exclude range:

  • Ping
  • TCP ACK ping and/or TCP SYN ping

If pinging is not permitted:

  • The endpoints are port scanned, using the TCP/UDP ports configured for initial scans.
  • The valid port states setting is used to determine whether a port is open.

If a device is present and desktop discovery is disabled (the default), an SMB query using the guest account is used to determine whether the endpoint is a Windows desktop. If the device appears to be a Windows desktop, the WBEM ports are checked. If it responds on the WBEM ports, it continues the scan as the device is most likely an embedded OS on a storage device, otherwise it is classed as a desktop.

The following results are possible for each endpoint:

  • Response
  • Desktop (only if desktop discovery is disabled)
  • No response

Where there is a response, the endpoint is put into the discovery queue for full discovery.

Where the endpoint is determined to be a desktop, the DiscoveryAccess is created with the result Skipped (Desktop host discovery has been disabled).

For endpoints that have no response, the system searches for a DiscoveryAccess with that endpoint as the last IP address. The following outcomes are possible:

  • Not found.
  • A DiscoveryAccess is found and it has a dark_space flag set.
  • A DiscoveryAccess is found and it does not have a dark_space flag set.

For the first two outcomes, the endpoint is put into a DroppedEndpoints node and no further investigation of the endpoint is undertaken. For the third, the endpoint is put into the discovery queue. The DiscoveryAccess is then aged in a similar manner to DDD aging, though it uses no_response_count and last_response. If the DiscoveryAccess is successfully aged, then the dark_space flag is set.

Aging is also applied to DiscoveryAccess nodes with the dark_space flag set, so dark space endpoints will age out and be removed.

DroppedEndpoints nodes have the following attributes:


Why the endpoint was dropped. This is one of:

  • Excluded – the endpoint was part of an excluded range
  • Already processing – no longer created in the DiscoveryAccess chain
  • Dark space – this endpoint is dark space
Start timeWhen the first endpoint was added.
End timeWhen the last endpoint was added.
CountHow many endpoints are in the list.
List of IP addressesA list of all the dropped endpoints.

In previous releases the removed dark space endpoints caused a mismatch in the number of endpoints linked to discovery runs. As the DroppedEndpoints node records the dark space endpoints, this no longer occurs. A single DiscoveryRun can be linked to multiple DroppedEndpoints nodes.

Consolidation and dark space scanning

When a version 10.1 consolidator receives data from an earlier version scanner, the consolidator builds DroppedEndpoints nodes for already processing IP addresses on the consolidator and skipped optimized IP addresses.

A version 10.1 scanning appliance creates DroppedEndpoints nodes which are consolidated. If the consolidator does not have the endpoint marked as dark space, then an endpoint may be included in a DroppedEndpoints node and have a DiscoveyAccess. This permits a device previously found on an IP address to be aged out in the normal manner.

Was this page helpful? Yes No Submitting... Thank you