The current device response processing depends heavily on container selection and subsequent parameter consolidation. This is the process of choosing a representative or “container” (also called reference) device that collects salient information from all the child devices. This container is then ready to present the accumulated information when queried. The container is also currently used in determining whether a device response is from a known device or a new one. Once a container has been chosen, the children are considered consolidated or stitched together to that container.
What is a container?
The container is essentially an interface consisting of an amalgamation of child data. The data promoted to the container comes from different children. Consequently, key query/search parameters like IP and MAC addresses are extracted from different children. The primary function of the container is a designated reporter. There is nothing intrinsically special about the container. If this is the case, there should be no need to recompute a container unless the interface that the container is based on is removed.
"Containering" Rules Established
These product enhancements revolve around device response handling and, at their root, how and when devices are consolidated and the accuracy of the consolidated data the container presents. To achieve these, we implemented several objectives:
- One function/query is used globally to choose a container
Whenever and wherever a container needs to be generated a single function/query is called. This leads to consistent/expected behavior. Further, one container choice algorithm and one place to improve/debug if there are issues/problems. - The container's query/search parameters are consistent with a specific child
A container’s fundamental query/search parameters are consistent with a specific child and not a mixture of addresses from various children. When a container is created it inherits all its query/search parameters from one child. - Avoid copying by querying the children of a designated container for relevant data
This prioritizes integrity over of real-time query performance, which is an acceptable trade-off because very few if any customers use real time queries over large data sets. - Containers play no role in deciding whether or not a response is a new device
Lumeta's device response process (initially for SNMP Details) has been updated to include a new Existing Device Detection (EDD) function that ignores paternity in its decision making. This updated process also assumes the consolidation of the choice-of-container into a single task. - Container is not recomputed unless there's a reason
Given there is nothing intrinsically special about the container, there is no need to recompute a container unless the interface that the container is based on is removed. Only in the case of the container interface being removed is the container recomputed. The new EDD function knows which interfaces have been removed/added, making it simple to determine whether or not a container needs to be recomputed.
Algorithm
In brief, the algorithm to pick an interface as container does the following:
Exclude private IPs
Exclude network or special (e.g loopback) address
Prefer Physical Address
Prefer IPV4
Prefer Trusted
Prefer Eligible types
Prefer Known types
Order by IP