Highlighted
Honored Contributor.
Honored Contributor.
135 views

IP's not in probe range but devices discovered anyway

Hi, we wanted to excluse certain devices, so we excluded their IP's from the ProbeRange. Later these IP's came into the uCMDB through an integration job and they are discovered now by Host Connection by Shell. This causes security alerts we don't want. I dont understand this. Is the exclusion of an IP from a probe range only vlaid for the ping job?

Can somebody explain this? Any help is appreciated

0 Likes
3 Replies
Highlighted
Absent Member.
Absent Member.

Re: IP's not in probe range but devices discovered anyway

Hi ,

 

I had a similar cases with support when customer was inserting data in UCMDB using integration by pushing Desktops and IpServiceEndPoin CI. After that client ran discovery jobs which discovered same IpServiceEndPoint and from that IpServiceEndPoint a link to the Desktop, marking that desktop CI for lincence.

 

By discovering a link it discovers also the ends of the link, since the link cannot exist whithout its ends, that is why it marks the Desktop CI as discovered, this is the default mechanism for marking CIs for licensing.

In your case I think that you have some links discovered into your system that tie the CIs inserted by integration with the CIs discovered by Host Connection by Shell job.

 

Hope this helps!

 

Best regards,

Cosmin

0 Likes
Highlighted
Honored Contributor.
Honored Contributor.

Re: IP's not in probe range but devices discovered anyway

Hi Cosmin, thanks a lot. This is more or less the same with us. These IP's came in when the customer imported Network Devices and links to their IP's from a 3rd party tool. What I still do not understand is, why the HostConnection by Shell Job takes this IP's as Input CI's even if they don't belog to a configured IP Range on any Probe. Do you have an idea?

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: IP's not in probe range but devices discovered anyway

Hi, 

 

HostConnection by Shell Job is a spiral discovery job which starts from a an IP from range and it discovers everything deep in the layout , and if one of the IP range is related somehow to one of the element from the integration it will also discover these. 

Another posibility would be that CIs from integration might be identified as the one discovered , as pbeing same CI due to reconciliation criteria.

 

In your flow I assume it starts from one IP from range and ties to other CIs discovered which eventually they tie to your third party CIs, so it does not take the third party IPs as an input but it discovers them as they relate to the IPs from the range, since this is a spiral discovery job they do not have to be tied directly they can be tied by using a common container node.

 

"If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”

 

Best regards,

Cosmin

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.