2 IPs on one Windows Server

[manddar]

Hi There,

I am working on project where discovery is used primarily to load new CIs into CMDB table.

Currently I am facing issue mentioned as below.

There are 2 IPs on windows server CI, One is created as Backup and other is created as Production IP as per network adapters table and relation. But primary IP of device do not match.

e.g.

Consider, There are 2 IPs for CI "ASDF" as 192.168.1.1 & 192.168.1.2 where 192.168.1.1 is tagged as Backup & 192.168.1.2 is tagged as Production IP, for testing purpose I scheduled discovery for 192.168.1.2 IP.

Once discovery completed, both of these IPs are placed in Network Adaptors table, however "IP field in win_server CI" is given backup IP and not production IP.

I think discovery should set production IP in place of IP Address field in win_server CI.

Now client is asking for for further analysis, when I tried to do quick discovery both IPs are returned as unresolved and no special attribute such as Back & Production IP.

Has anyone came across such issue?

[aleck_lin]

Mandar,

I'd like to take the opportunity to explore this topic. The concept of a "production" IP vs a "backup" IP is really a human contruct. The CI "ASDF" doesn't really know the difference between them because they're just IP addresses. Now, if you can tell me how Discovery can find the label for production and backup, we can then talk about how Discovery might be able to capture that piece of information.

I've talked to many people about this issue and what I decided was that the IP address field on a CI should be the one it was explored with first. And then we'll capture all the IP addresses through discovering the NIC cards since it's very common to have more than one IP address on a device.

Now, you can change the IP address field to be the production one if Discovery didn't pick the "right" one for you. And what happens in the subsequent Discovery is that it will look at the existing value on IP address field on the CI, and if that value matches any of the IP addresses that are discovered, then it leaves the existing IP address alone. In other words, the idea here is that Discovery will not pick one for you as long as a valid IP address was already on the CI.

Also, one of the things you said in your scenario doesn't sound right (unless there's a bug). If you discovered the device with 192.168.1.2, then the IP address field should be populated with 192.168.1.2. If you had tried to discover both 192.168.1.1 and 192.168.1.2 in the same schedule, then it's a matter of chance which one will be populated as the IP address, but again, you can just simply change the IP after the Discovery run is completed and it should not be overwritten in the subsequent runs.

Aleck

[manddar]

Thanks aleck.lin

That was very detailed answer and helped me to understand that flow.

I agree that possibly discovery can not understand label for 2 IPs and it will make Primary/Production IP which will be probed.

I can now revert back to user with analysis.

Thanks again

[Kuldeep Kumavat]

Hi Aleck Lin,

There is a windows Server having one IP address listed in the network adapters. Say: 168.189.1.1

However, the IP address for the CI has now been changed to 189.189.1.2

Discovery fetches the details correctly, however as the new IP is not associated with any of the NICs it reverts the update to reflect the old IP for the CI.

After disabling the "Enforce syncing of IP addresses" property, it updates the IP Address with the new IP 168.189.1.2

But the thing is; it does not insert a new entry for the new IP address in the network adapter table.

Is this the correct behavior, does discovery insert entries in the network adapter only at the time of CI creation

Should it not insert a new entry for the network adapter if there is a different IP for that CI which is not already listed

Regards,

Kuldeep

[aleck_lin]

When you click into a network adapter record, you should see a list of IP addresses associated with it. Is the new IP address 168.189.1.2 in the list of one of those network adapter records? The reason we do it like that was because it's possible to have multiple IP addresses per NIC.