Issue

We have seen occurrences of CIDR blocks being stored as "discovered" entities (aka External-IPs). This seems to occur when entities are discovered while a matching CIDR is concurrently being added/removed.

Root Cause

There is no certainty about the actual root cause, however, this could be due to a race condition where Sensor doesn't know (anymore) about the CIDR while Collector (still) knows about it and detects a matching IP. The CIDR would then be sent by Collector, which is interpreted as a "discovered" entity in Sensor.

Impact

• A CIDR block is not supposed to appear among the External-IPs ; this could be misleading for the user.
• The API to manipulate CIDRs prevents inserting a CIDR if it is already present in the database. If a CIDR is inserted as a result of External-IPs discovery, then it could collide with the CIDR a user wants to insert.

ProposedSolution/Status

• Proposed workaround: in Sensor, we propose to discard CIDR blocks received from Collector if we don't know them. This could result in a loss of a connection information shortly after a matching CIDR is removed.

• Better but more complex solution: keep using a set of CIDR block definition until Collector is updated with a new set.

More context

The ExternalNetworkSources groovy test (prior to using a distinct CIDR for each test) sometimes manages to get a CIDR to be stored in the DB as a "discovered" entity.