Issue in CI discovery with Multiple IP address
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-23-2019 04:41 AM
Hi Folks,
Currently we are facing an issue with CI discovery where we have multiple IP address with single CI (Linux VM) .
The problem is , every time the discovery runs , IP is changing itself , do we have any option to have the primary IP of the CI to be static (management IP). Most of the Database VM's will have multiple Ethernet adapters with IP's assigned.
May be an option like Management IP which we have provided for discovery can be set as the primary IP of that CI in service now.
Thanks & Regards,
Jijo John
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-23-2019 11:28 PM
Hi Monali,
Thank you for looking in to this. In our case if we have the discovery setting the backup IP or a Heartbeat IP of the server as a primary IP of the CI in service now , it will be a problem for us. Could you please check if there any other options available to restrict this so that we only have primary IP assigned to the CI in service now.
Thanks,
Jijo John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-23-2019 11:58 PM
Hi jijo,
You can use system properties to control the selection of IP address for specified CI classes.
Use these properties to determine if the system should replace the IP address returned by Discovery in a device's CI record if the address does not match that of a network interface (NIC) on the device. This is important for the discovery of devices with management IP addresses that differ from IP addresses associated with one or more NICs on the device. Because a device's management IP is used in the Discovery schedule for that device, this is the address that Discovery returns.Property | Description |
---|---|
glide.discovery.enforce_ip_sync | Prevents the system from using a discovered IP address in the CI record if the address doesn't match that of a NIC on the device. If this property is true, Discovery checks the IP address returned to determine if it is associated with a NIC on the device. If the address is not associated with a NIC, Discovery uses the IP address from one of the NICs instead.
|
glide.discovery.exclude_ip_sync_classes | Defines CI classes whose IP addresses should not be substituted if the address returned by Discovery does not match one of the devices' NICs. Use a comma separated list to define multiple classes. By default, the system uses the management IP of a load balancer returned by Discovery in the CI record, rather than substituting it for the IP address of one of the load balancer's NICs.
|
If my answer is worthy please mark as correct/helpful.
Regards,
Monali Patil
Developer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-14-2020 08:34 AM
We are facing the same issue with IP Switches and Routers, they keep on flip flopping between different IPs.
We have changed the values for below two properties:
glide.discovery.enforce_ip_sync to 'true'
glide.discovery.exclude_ip_sync_classes to 'cmdb_ci_lb,cmdb_ci_ip_switch,cmdb_ci_ip_router'
Still on discovering IP Router & IP Switches via Discovery schedule, they flip flop between different IPs.
Please advise, what else we can check?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-14-2020 08:52 AM
If you are using Pattern-based discovery for switches and routers, the issue might be caused by duplicate switch discoveries in the same discovery schedule. The issue is documented in this community article:
Duplicate Discovery of Switch in One Discovery Schedule
One of the issues caused by duplicate switch discovery is the flip flop between different IP addresses per item #4. The duplicate discoveries cause multiple issues:
- The discovery schedule takes longer to complete.
- The Discovery Log and ECC Queue fills up with additional messages from the duplicate discoveries.
- Additional bandwidth is being used across the network.
- The CI Audit History fills up with additional IP Address changes for each duplicate duplicate discovery.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-15-2020 02:39 AM
Thank you Chuck for your response. However, excluding IPs from the schedule is not feasible/acceptable solution for over 1000 CIs with 8 to 10 different IP Addresses. It would be a cumbersome task to exclude these many IP addresses from the schedules.