ServiceNow Discovery updates the IP address of the IP switch CIs multiple times during discovery, leading to inconsistent data of the CI. The management IP should be displayed in this field.
According to the documentation "Discovery IP address configuration" there is 'glide.discovery.enforce_ip_sync' property to prevent this behaviour, but it doesn't seem to work.
When discovering a CI with multiple IP addresses via probes the DiscoveryJSONIDSensor checks if we have already discovered this device via another IP address. It does this by checking if the device already exists via (DiscoveryJSONIDSensor.CMDBIdentify()), if so it updates the payload before it is passed to the IRE so that certain values do not get updated (see DiscoveryJSONIDSensor.preventCiDataFlipping()), one of which is IP address.
With patterns, this mechanism to prevent data flipping is not present. Thus when discovering a device with multiple IP addresses, such as a switch, the CI will have the values updated by each IP returned payload.
The system property 'glide.discovery.enforce_ip_sync' which was set to true by default. This picks the IP from the network adapter and updates the ip_address field of the switch.
When the property 'glide.discovery.enforce_ip_sync' set to false, this doesn't update the IP of the cmdb_ci_ip_switch. In this case, we get the IP Address from the schedule / Quick discovery and update the same in the ip_Address field of cmdb_ci_ip_switch.
This is the expected behaviour. The IP on which you run discovery will be updated as an ip_address field.
Steps to Reproduce
Using patterns for identification:
- Discover a Switch, via quick discovery, which has two IP addresses.
- Modify the IP address manually on the IP Switch CI
- Discover the same server using, via quick discovery, using the other IP address.
This problem has been fixed. If you are able to upgrade, review the Fixed In or Intended Fix Version fields to determine whether any versions have a planned or permanent fix.
The fix ensures that the original IP address is still in the CI after the pattern has finished updating the CI. However, the fix was done as a second non-IRE update to put the value back again after the original IRE update from the pattern payload changed it. That 2nd update still causes flapping and unnecessary audits, and another problem has been opened to address that:
PRB1380126 Discovery causing IP Address flapping: Existing value is still changed by the Pattern to the IP we are scanning, and then changed straight back in an unwanted second update
Related Problem: PRB1343838