This client's network contains many duplicate IPv4 addresses in the RFC1918 ranges, most of which cannot be eliminated because they are in use by customers. Unsurprisingly, Capsd has a hard time with some of their nodes. One IP address in particular, 192.168.254.54, is present but not reachable on many managed customer-premise nodes. The client also has a core switch with this address and wants to manage that switch with OpenNMS. Discovery, of course, ignores the address since it's already in the DB. Sending a manual newSuspect event does trigger Capsd to do a suspect scan, which completes; once the SNMP interface scan phase finishes, though, Capsd decides that it should not create a new node because (you guessed it) that address is already in the DB.

To get out of this quagmire, we created a requisition yesterday and imported it. The client was happy with the result and wants to use this approach to deal with all problem addresses that fit the same pattern (there's at least a /24 of them, maybe more). When we arrived this morning, though, the node we created still existed but its one IP interface (192.168.254.54) had disappeared overnight. Forcing a rescan on the requisitioned node brought back the IP interface, so I went digging in the DB to work out when and how it had disappeared. I found a duplicateNodeDeleted event from about four hours after we first imported the new requisition, with an event-source indicating it came from Capsd.

I've tracked down the few code paths that generate this type of event and I think it must be happening in org.opennms.netmgt.capsd.RescanProcessor.updateInterface(...). Since the node from which the interface is being reparented has a foreign-source name, Capsd should not be doing this. Right?

The client will be moving to an entirely requisition-driven way of provisioning, but the data in their provisioning DB is not yet of sufficient quality to support it, so for now they're using mostly Capsd with a few requisitions.