Discovery Device IP Address


Description

As part of discovery, a configuration item (CI) may have its IP address updated. This KB focuses on explaining the steps followed by the discovery logic in order to update such IP address.

Note: The focus of this article is the field ip_address of a discovered CI, such as cmdb_ci_computer.ip_address. When a CI is discovered, the table cmdb_ci_ip_address is also populated with the IP addresses discovered for the CI.

Discovered CI IP Address

The IP Address for a CI is set during the identification phase of discovery.

PROBES/SENSORS:

At the identification phase, a payload called cidata is passed to the identification and reconciliation engine (IRE). The IRE uses such cidata to Create/Update the CI. The CI's IP address will be updated if the ip_address in the cidata is not the same as the currently set IP address for the CI.

The IP address in the cidata is the same IP address being used to discover the CI.

In most cases, it is not desirable to have the IP address changing with each discovery. Therefore, before passing the payload to the IRE, discovery attempts to determine whether to remove the ip_address from the payload. Removing the ip_address from the payload would ensure that the IP address for the CI is not updated.

The script include DiscoveryJSONIDSensor uses the function processIPAddressField(ciRecord) to performs the following steps:

  1. Did the identification engine find a matching CI?
    • No: This is the first time the device is discovered. Use the IP address from cidata
    • Yes: Continue
  2. Does the existing CI have an IP address?
    • No: Use IP address from cidata to update CI
    • Yes: Continue
  3. Does the CI current IP address match the cidata IP address?
    • No: Continue
    • Yes: No need to remove the ip from the cidata. The CI will maintain the IP address
  4. At this point we have an IP address in the cidata which does not match the CI current IP address. Leaving this IP address in the cidata would cause the CI IP address to be updated/flipped. The identification phase also collects the network adapters. Therefore, is the CI current IP address is one of the IP addresses discovered with the network cards?
    • Yes: Then this is still a valid IP address and we may keep it. Therefore, clear the cidata IP address so that the CI current IP address is not updated unnecessarily.
    • No: Then the CI record has an IP address which is no longer valid. Keep the ip address in the cidata so that the CI record will be updated

PATTERNS:

Patterns do not use DiscoveryJSONIDSensor. The ip_address for a CI will be set according to the logic in the pattern. Each pattern will have a step where $<class_name>[].ip_address is set. Steps can be added to the pattern or removed to control what IP address should be used and update field ip_address.

Pre Orlando Patch 5

CIs discovered via patterns will have their ip_address updated according to what is returned for field ip_address. The ip_address field will be updated each time a CI is discovered via different ip addresses. Extra logic was added to the Horizontal Discovery Sensor to prevent this flipping in PRB1343838.

Orlando Patch 5 and newer

Function preventFlappingAttributeOnParentClassReturnIreTime() was added to the discovery sensor (PRB1343838). This function checks if ip_address field is already populated on the CI and will not updated it if so. However, this keeps the IP address field from changing at all if already populated. The IP address field needs to be updated manually and the CI will keep the updated value (discovery will no longer updated it). PRB1443223 fixes this in Rome.

Rome

PRB1443223 added logic to check if the current ip address for the CI is still being discovered. If not, then replace it with the new IP address discovered for the CI. Similar to what was done with probes.

POST DISCOVERY:

Once discovery completes for a CI, a discovery.device.complete event is created. The script action which responds to this event calls script include IPAddressFixup. IPAddressFixup is controlled by the following properties:

  1. glide.discovery.enforce_ip_sync
  2. glide.discovery.exclude_ip_sync_classes
  3. glide.discovery.enforce_unique_ips

Note: Post discovery can update the ip_address field for both probes and pattern based discovery.

Discovery Properties

glide.discovery.enforce_ip_sync:

glide.discovery.exclude_ip_sync_classes:

glide.discovery.enforce_unique_ips:

ISSUES

CI ip address field updated after discovery completion by "System" account

This is usually due to system property glide.discovery.enforce_ip_sync set to true. This triggers code in script include IPAddressFixup that updates the ip address. Setting glide.discovery.enforce_ip_sync to false should stop this behavior. Alternatively could add the CI class to system property glide.discovery.exclude_ip_sync_classes.

IP Address field is updated each time discovery runs after migrating from probes to patterns

Previous to Orlando Patch 5 this is expected behavior. A custom script action triggered by event discovery.device.complete could be put in place to add custom logic on how to update the IP address, or a sa_pattern_prepost_script could perform such action.

IP Address field is no longer updated by discovery after migrating from probes to patterns

Starting in Orlando Patch 5 the ip_address field is no longer updated if it is not empty. One can empty out the ip_address field in a CI and rediscover it so that discovery will populate it. Alternatively, a custom script action or sa_pattern_prepost_script could perform such action. System property glide.discovery.enforce_ip_sync would also ensure that the ip address is updated to a "valid/current" value. This property is explained in a previous part of this document. This issue is fixed in Rome via PRB1443223.