Discovery of Loopback Network Adapters that are subsequently removed

[Bob Mullineaux]

Does anyone know what the purposes of the glide.discovery.allow_loopback_adapters property is (which once worked for Router Discovery) when step 47 in the SNMP - Identify Shared Library removes network adapters with empty MAC Addresses?   fyi...Loopback interfaces do not have MAC Addresses. 

[Anshu_Anand_]

Hi @Bob Mullineaux ,

A KB article already there for this. Hope its helpful.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0744533 

Another KB which can be helpful

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0994554 

As per the discovery docs , 

Loopback adapter filter: Allows network loopback adapters on SNMP devices to be discovered instead of being filtered out during Discovery. When this property is set to true, network loopback addresses are discovered and added to the CMDB.

• Type: true | false
• Default Value: false

Try making this property as true if above KB does not help but it will probably fill up your cmdb data with many CIs

Loopback adapters are fake type network interfaces, its useful for testing purposes but i am not sure if its crucial data for discovery. For us we never cared for this in our discovery operations.

There is another KB where its mentioned as a problem PRB1394394.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0821592 

If its helpful, please mark this solution as correct so that it can be helpful to others.

[Bob Mullineaux]

Hi Anshu, 

Thank you for the information.   However, I guess my question is related to why have a Discovery Loopback interface property (set to true) and indeed discover the loopback interfaces if only for the SNMP - Identity pattern to then later remove them?  So effectively, the loopbacks do get discovered only to get removed.  Also, loopback address may not be necessary for Discovery, but they are meaningful, sometimes critical, to the Network Support SME's who use them.  The loopback IP address is typically the IP that is used in DNS to identify the Hostname or FQDN of the Network device itself so they are indeed pertinent and they should be in the Network Adapter table or the Router Interface table (and in our case we have a custom field on the Router and Switch table to store the Loopback IP in addition to the IP Address field set by Discovery).   

fyi...discovering loopbacks should not fill up the CMDB as there is typically only one loopback interface on a device so e.g. 1,000 Routers would result in 1,000 loopback CIs. 

The other part of the issue is relating to the Identification rule on Network Adapters table which requires a  MAC Address and IP...since loopbacks have no MAC address, the IRE Rule will fail.   Same applies to Router Interface table.  

ServiceNow has apparently flipped flopped on this capability because several releases ago we seemed to have been discovering them.

[Anshu_Anand_]

Thanks for the information you shared .Really helpful

For Identification, you may write your own Identification rule if you want it since network adapter has a dependent IRE rule.

you can also try to write pre/post processing script which will allow you to modify your CMDB ci data before passing through the IRE.

example concat configuration item+name+netmask so to make it unique or whatever logic you want.

[Abhishek19857]

Hio @Bob Mullineaux : We have fixed the issue of OOB and shipping in the May 2024 Visibility Content Store app. Indeed, it was the defect.