Issue in CI discovery with Multiple IP address

[Jijo John]

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

[arordeep]

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.

[chuckm]

I agree that excluding IPs from the Discovery schedule is not feasible or acceptable solution. I provided this information because you might have spent many hours troubleshooting something where there isn't currently a fix. I have already been down that path. The 2 Knowledge Articles mentioned in the community article are supposed to fix this issue and do not.

For my client’s current roll-out of discovery, I had to rollback to probe-based discovery for switches and routers because the duplicate discoveries were creating too many challenges. I look forward to a fix for this issue.

[arordeep]

Thank you Chuck for sharing your experience.  Probably we are also thinking to go the same route (reverting to Probe based discovery for Routers & switches).  From your experience, could you please advise, if there is any downside of reverting to Probe based discovery like risk of creating duplicate CIs, migration issues etc.

Regards,

Deepak

[chuckm]

One of the downsides was that we wouldn't be able to use some of the new capabilities of the switch and router patterns.  I suggest looking at the new capabilities of the switch/router patterns and make sure losing those new capabilities outweigh the duplicate discoveries.

One of the must have capabilities that switch patterns provide OOTB is the ability to discover stacked switches.  This is a requirement for my current discovery implementation.  Our team is implementing the Custom Probe/Sensor - Cisco Stacked Switches (member info) created by Ryan Zulli as a work around.  I implemented this solution 4 years ago and it worked great.

One other area to review is how Pattern-based and Probe-based discovery handles related items.  As per KB0694477 (Probe to Pattern Migration: Procedure for switching from probe-based Discovery to pattern-based Disc...😞

Probe-based discovery and pattern-based discovery use different mechanisms of saving data in the CMDB. Using both discovery methods together may result in duplicate data in the CMDB. In addition, pattern-based discovery relies on relationships, while the legacy probe-based discovery uses references.

I recommend opening a HI ticket and reviewing this with a HI engineer - as this may create duplicate data.  When our team reverted back to Probe-based discovery (only for switches and routers), we deleted all of the switch and router CIs, switched to Probe-based discovery (only for switches and routers), and then re-populated the switches and routers in the CMDB.