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 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:
- 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 discoveryis disabled (the default), an SMB query is used to determine whether the endpoint is a Windows desktop. On FIPS enabled appliances, the SMB query is not used and detection of Windows desktops is done later. 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:
- 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
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:
|Start time||When the first endpoint was added.|
|End time||When the last endpoint was added.|
|Count||How many endpoints are in the list.|
|List of IP addresses||A 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.