Verifying Individual Addresses


The main background task of the Autodiscovery module is to regularly verify the entries in its device list. The list is sorted by the timestamp of the last update for each entry which places the most recently update or verified entries at the end. To avoid overloading the network and the CPU, only one entry at a time is verified. The delay between the verification of consecutive entries is defined by the VerifyInterval parameter which is by default set to 30 seconds. To ensure that the addresses closest to the device are scanned and verified first, they are added to the list before entries coming through the Use Network Neighborhood parameter. The initial verification is executed according to the following rules, the schema at the end of the topic details this further:

  1. Select the oldest entry in the database to be verified. The age of an entry is based on the entry Update time which is the last time the entry was verified or merged with another.
  2. If the entry to be verified has its status value set to Learned and it is not a relay (RelayEnabled = 1), it is not verified. In this way, entries which are learned and already verified by other devices are not re-verified unless they are relays.
  3. The first part of the verification is to establish whether the IP address is valid by "ping"ing it. This is done by sending an ICMP echo request and waiting for a reply. The timeout period limiting the wait for a reply is set through the INI file Timeout parameter. As well as verifying the presence of a device at the given address, the ping is also used to establish the number of router hops to that device and its response time. This is done through the use of the IP standard TTL field in the request which cycles through these values in order:
    • TTL = 1. If the device is on the same network and present, a reply will be received and will verify the address. If no reply is received, go to next step.
    • TTL = 8. The request with TTL=1 did not respond which does not mean that the device does not exist but could be across many router hops. The maximum number of hops measured is 8 so send a new request with this value. If no reply comes back, then the address is considered invalid. If a reply is received, the address is valid so we need to try and get a more accurate hop count value.
    • TTL = 4. The request with TTL=8 had a response, so now try with 4. If no response is received, the hop count for the address is 8 and no more requests need to be sent. Otherwise try a new request with a lower TTL value.
    • TTL = 2. If a reply is received, a hop count of 2 is recorded for the address. A new request with TTL=1 is not sent as that is known to fail. If a reply is not received, the recorded hop count is 4.
  4. In some rare cases (such as the agent not running as root on UNIX) a raw socket needed for ICMP operations cannot be created. If so, the address is instead verified by attempting a TCP connection to a number of commonly used ports. The ports used are defined in the configuration file through the TcpPortRange parameter (the default values are 23, 25, 139). The module will step through the ports until one is connected or there are no more left in which case the address is considered invalid.
  5. If the ping or TCP connection attempt was successful, this indicates that the IP address is that of a real, online device. In this case the module tries to establish whether there is a CM agent running on that device by sending XML/RPC requests to the ports specified in the HttpPortRange parameter (the default values are 80, 1610, 8080). The calls executed are the following in the given order:
    • The AgentIdentity action is called first as all agents support this action regardless of which modules are loaded. If successful, all read information about the client is used to update the entry in the device list. If the call fails, the remote address is not a CM agent and no other actions need to be called.
    • The RelayInfo action is then executed to find if the agent has its relay function enabled or not. This is very important as the information is integrated into the device list and is later used by the local Relay module in selecting a parent device for communicating with the Master.
    • Finally, if the CanLearn parameter is enabled, the AutodiscoveryListDevices action is called to retrieve the list of verified devices from the contacted computer to be added to the current device's list. All read entries are marked as having been ‘Learned' which avoids the re-checking of the same computers.

After the list is scanned and verified, the Autodiscovery module can start a new cycle. It will then integrate possible new elements which are provided by NetBIOS (Use Network Neighbourhood parameter) and start a new verification at a rhythm of one element every 30 seconds.autodiscovery_verify.png

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*