Notifications

44 views

Description

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.

Actual behaviour

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:

  1. Discover a Switch, via quick discovery, which has two IP addresses.
  2. Modify the IP address manually on the IP Switch CI
  3. Discover the same server using, via quick discovery, using the other IP address.

Workaround

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

Seen In

New York Patch 1
SR - IntegrationHub - JIRA Service Desk Integration r2 - v2.0.7
SR - IntegrationHub - Microsoft Exchange Server Integration v1
SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - GRC Workbench - New York 2019 Q3
SR - IRM - PA Premium Integration - New York 2019 Q3
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Policy and Compliance PA Content - Madrid 2019 Q1
SR - IRM - Risk Management - New York 2019 Q3
SR - IRM - Risk Management PA Content - Madrid 2019 Q1
SR - IRM - Vendor Risk Management - Madrid 2019 Q1
SR - ITOM - CMDB CI Class Models - 201908
SR - ITOM - Discovery and Service Mapping - 201908
SR - ITOM - Discovery and Service Mapping - v1.0.35
SR - Security - Integration Framework - Madrid 2019 Q2
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Security Incident Response PA Content - New York 2019 Q3
SR - SIR - Store SecOps Setup Assistant - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3
SR - SIR - Tanium Integration - New York 2019 Q3
SR - SIR - Threat intelligence - New York 2019 Q3
SR - VR - Qualys - New York 2019 Q3
SR - VR - Vulnerability Response - New York 2019 Q3

Intended Fix Version

Orlando

Fixed In

Madrid Patch 9
New York Patch 3
New York Patch 4

Safe Harbor Statement

This "Intended Fix Version" information is meant to outline ServiceNow's general product direction and should not be relied upon in making a purchasing decision. The information provided here is for information purposes only and may not be incorporated into any contract. It is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at ServiceNow's sole discretion.

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-01-20 06:39:07
Published:2020-01-20