Issue discovering a CI when scanning multiple IP's of same CI in single schedule where the first IP returns as being invalid IP (Network, Broadcast, HSRP VIP) - Known Error

Issue discovering a CI when scanning multiple IP's of same CI in single schedule where the first IP returns as being invalid IP (Network, Broadcast, HSRP VIP) Description When discovering multiple IP's of same device in same schedule, if the first IP after Classification is found to be a invalid IP (Broadcast, Network, HSRP VIP) but that IP is part of the CI, we will end up marking the record in the discovery_device_duplicate_ips table as being "completed". Then, when the following IP's come in and if one or more of these are valid IP's, we are not continuing to run Identification for these IP's because we think that these are duplicate (based on the first discovery_device_duplicate_ips record being marked as "completed".

Steps to Reproduce

Scenario 1 - Have a device that has multiple IP's and for one of the IP's, this is either a Broadcast, Network, or HSRP VIP.

1 - Run a Discovery scan against these IP's (this may take a few tries). 2 - Wait until you see the situation where the invalid IP gets processed first. You will then see that this IP will get processed and will not trigger Identification. 3 - When the 2nd IP gets processed, this IP will end up getting marked as duplicate and also will not trigger Identification.

Scenario 2 - This can also be reproduced with some CI manipulation on an instance that has already applied the fix from PRB1358510/KB0781931 .

1 - In SD Lab, run a Discovery against a Router in our lab that is not discovering on Network or Broadcast IP (ex. 10.11.130.221). 2 - After this has been discovered, you should see that you have 1 Network Adapter and 1 cmdb_ci_ip_address record for this 10.11.130.221 IP. 3 - For this CI, create a new Network Adapter and IP Address record with the value of the IP as "10.11.130.220". Other values like name and netmask should not matter, just make sure these records are linked to the same CI as the 10.11.130.221 records and make sure install_status = installed. 4 - Setup an SNMP Only Discovery Schedule that now will scan both the 10.11.130.220 and 10.11.130.221 IPs. 5 - This may take a few attempts, but you should see if/when we discover the 10.11.130.220 IP first that we get this same behavior to occur as mentioned above where both IP's will end up not running Identification.

NOTE: In some cases, if you end up with getting 10.11.130.221 discovered first, this may update the fake adapter and IP address records to mark them as "install_status = absent". Make sure before running scan again that the adapters and IP address records for both IP's linked to the CI are set as "install_status = installed".

Workaround This problem has been fixed. If you are able to upgrade, review the Fixed In section to determine the latest version with a permanent fix your instance can be upgraded to.