- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2019 12:00 PM
Our network team tracks their switches and routers based on their internal loopback address. The issue I'm running into is when discovery runs against these CI's, by the time it hits the loopback address, it determines it's already discovered this CI and ignores that IP.
Is there any way to set up discovery so even if it discovers these multiple IP's it will at least log them against the CI?
Solved! Go to Solution.
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-03-2019 06:10 AM
HI Technical support was able to provide some insight for me on this issue.
As to not trigger unnecessary probes on the same device and on the same discovery, discovery checks if the CI has already been discovered on such discovery attempt. If the CI is found in the same discovery, discovery stops triggering "repeated" probes on the same device and sets the status to "extra IP". This saves both the MID server and instance from duplicating work. It is only needed to discover a device via one IP address to collect the necessary information.
Thus, it would not be necessary to discover the device via x.x.x.x. All you would need to do is manually set the IP address to x.x.x.x, if this were not a loopback address. The next discovery should keep it, when using probes (I checked and this discovery is using probes), so long this IP address is one of the ip addresses returned on the payload. However, because x.x.x.x is a loopback interface, discovery automatically removes this IP address from the payload. This is done on script include SnmpIdentityInfoParser.
You can see in SnmpIdentityInfoParser that interfaces of type 24 are removed, see line 296.
Therefore, to use a loopback address for network switches you would need to:
01) Customize the script include SnmpIdentityInfoParser to not remove interfaces of type 24.
02) Manually set the IP of the device to the desired ip.
03) Ensure "Enforce syncing of IP addresses" is false (it is currently set to true) under "Discovery Definition > Properties".
04) Next discoveries should not modify the ip address
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-03-2019 06:10 AM
HI Technical support was able to provide some insight for me on this issue.
As to not trigger unnecessary probes on the same device and on the same discovery, discovery checks if the CI has already been discovered on such discovery attempt. If the CI is found in the same discovery, discovery stops triggering "repeated" probes on the same device and sets the status to "extra IP". This saves both the MID server and instance from duplicating work. It is only needed to discover a device via one IP address to collect the necessary information.
Thus, it would not be necessary to discover the device via x.x.x.x. All you would need to do is manually set the IP address to x.x.x.x, if this were not a loopback address. The next discovery should keep it, when using probes (I checked and this discovery is using probes), so long this IP address is one of the ip addresses returned on the payload. However, because x.x.x.x is a loopback interface, discovery automatically removes this IP address from the payload. This is done on script include SnmpIdentityInfoParser.
You can see in SnmpIdentityInfoParser that interfaces of type 24 are removed, see line 296.
Therefore, to use a loopback address for network switches you would need to:
01) Customize the script include SnmpIdentityInfoParser to not remove interfaces of type 24.
02) Manually set the IP of the device to the desired ip.
03) Ensure "Enforce syncing of IP addresses" is false (it is currently set to true) under "Discovery Definition > Properties".
04) Next discoveries should not modify the ip address
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-19-2019 04:46 PM
This saved me what was likely a few hours of troubleshooting and digging around. Thank you very much!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-17-2019 12:31 AM
Hi David,
if we set IP address manually for that ci. and what if ci gor decommissioned and later we use same ip address for newly commissioned/build device.
how we can tackle this.
R's,
Bharath
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-20-2020 05:25 AM
Check out this video, it will clear all your doubts and help you to understand Discovery queries in details.
Link: https://www.youtube.com/watch?v=30JbWVsusyE&t=10s&ab_channel=ServiceNowHelpdesk
It help you to understand below points.
- Discovery Overview
- Discovery prerequisite
- Understanding Discovery Phases in details
- Discovery credentials and IP Affinity
- Mid Server Management with Cluster and Load Balancer
- Schedule jobs
- Set up discovery from scratch to end
- Live implementation with real world data.
- Troubleshooting on various aspects
- Many more other issue related to mid server, CIs
- Cloud discovery
- Service Mapping
Please mark reply as Helpful/Correct, if applicable. Thanks!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2025 05:06 AM
Hi can you share the help support topics on my smita.yogesh.jadhav@accenture.com. Help would be appreciated.
- Troubleshooting on various aspects
- Many more other issue related to mid server, CIs