How to discover management IPs when "SNMP Identify" removes them?

[Greg Hubbard]

I have a problem with Discovery and Juniper routers.  These devices are configured with a "management IP" that is bound to a loopback address.  This is a common network management practice in large shops.

However, the management addresses are lost during discovery, and all CIs are posted to the CMDB with another (and incorrect!) IP address.  This causes a cascading set of problems -- for instance, the management IP is in DNS instead of other IPs on these devices.

I looked into this, and it appears that the "SNMP Identify" library pattern has a step that filters out all loopback addresses as it builds the IPv4 address table for the CI.  This happens at step 32.  This is a problem because the "SNMP Identify" pattern library is included in all of the "major" SNMP discovery patterns.

I would rather not write my own version of SNMP Identify...

Greg Hubbard

[adilrathore]

Would you be able to create an IP Address exclusion for all the IP addresses which are assigned thorugh DNS instead of on the device. I think that would solve 50% of the concern you are having.

Or if the pattern is fetching the IP from DNS that needs to be set as a secondary address or not taken into consideration as per your requirement.

[Greg Hubbard]

Thanks for your suggestions!

I am not sure how they help, though.  The problem is that the discovery pattern (SNMP Identify) reads a list of IP addresses configured within the device using SNMP queries.  It also obtains a list of interfaces from the device.  It then matches up the interface list with the IP address list to produce a merged table.  Then it filters the table by discarding entries that are loopback interfaces, among other things.  This means that any IP address linked to a loopback address will be lost, and will not be added to the CMDB!  I have looked at the code, and it performs this operation without any consideration of a flag or other control variable.

This pattern is included in all of the "out of the box" discovery patterns for network equipment, so it will be a big change if I edit it.  Doug will say "make a copy!" but that is a bit of work.  I was hoping for a "cheap fix."

I do not know who is the keeper of the patterns in ServiceNow, but my plea is to think this over and figure out how to discard useless loopback addresses while retaining the useful ones.

For those who might not understand this issue -- a common network management technique with large devices is to create a "management IP" and link it to a loopback address in the device.  Having ServiceNow discovery throw these addresses away is not a good thing.

Greg Hubbard

[adilrathore]

Yes I am able to understand this now from articles as below:

Understanding the Loopback Interface

I think this can be shared in the Idea Portal so that it has product management visibility and can be considered as a future enhancement.