The CreatorCon Call for Content is officially open! Get started here.

Issue in CI discovery with Multiple IP address

Jijo John
Kilo Explorer

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

  

13 REPLIES 13

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

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. 
PropertyDescription
glide.discovery.enforce_ip_syncPrevents 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.
  • Type: true | false
  • Default value: true
glide.discovery.exclude_ip_sync_classesDefines 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.
  • Type: string
  • Default value: cmdb_ci_lb

 

If my answer is worthy please mark as correct/helpful.

 

Regards,

Monali Patil

Developer

arordeep
Tera Expert

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?

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:

  1. The discovery schedule takes longer to complete.
  2. The Discovery Log and ECC Queue fills up with additional messages from the duplicate discoveries.
  3. Additional bandwidth is being used across the network.
  4. The CI Audit History fills up with additional IP Address changes for each duplicate duplicate discovery.

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.