Myrmex
BlogProduct

Not every line on the map means the same thing

Not every line on the map means the same thing
PRODUCTTopology

Every tool that draws a network map draws lines. Few of them say how they know the line is there.

On screen, a link proven by a switch's MAC table and a link deduced from a tunnel route are the same line. Same weight, same color, same apparent confidence. Except one is an observation and the other is a hypothesis.

That is irrelevant while the map is a picture on a wall. It stops being irrelevant the moment someone acts on it.

A map is not for looking at, it is for acting on

Network maps do not exist to illustrate slide decks. They get consulted before segmenting a VLAN, isolating a compromised host, opening a firewall rule, deciding whether that server can be taken down in Saturday's window.

And the cost of being wrong is asymmetric.

Treating an inferred link as proven is the expensive mistake: you segment believing you separated two networks and you did not, or you tear down a path that was a device's only administrative access. Treating a proven link as doubtful costs time, and time is recoverable.

So the question that matters is not "is the map complete?". It is "does the map tell apart what it saw from what it deduced?".

What the map distinguishes

The MYRMEX topology map, in the demo environment. Each line names where the evidence came from: orange, a proven link between networks; blue, reach inferred from a tunnel route; purple, an inferred IP range; dashed, an expiring link.
The MYRMEX topology map, in the demo environment. Each line names where the evidence came from: orange, a proven link between networks; blue, reach inferred from a tunnel route; purple, an inferred IP range; dashed, an expiring link.

The link types on the MYRMEX map are not drawing styles. Each one names where the evidence came from:

Proven link between networks. The link exists because the equipment said so. It comes from the MAC table, which is the switch reporting on which port that physical address was seen. There is no deduction in between.

Reach inferred from a tunnel route. The link is plausible, not observed. Routing says you can get from here to there, and the map shows that for what it is: an inference, marked as one. And when not even the inference closes, the map says so too: it groups those assets under the label "no known egress" instead of wiring them to a plausible gateway.

Discovered via ARP, no agent. The asset exists, answers on the network and has no agent installed. The record keeps who saw it, not merely that it was seen: this node saw that physical address on its segment. The evidence has an owner, which is what makes it contestable.

Inferred IP range. In the cloud, a virtual machine sees its own interface as an isolated address. The subnet's real prefix is not in the operating system, it is in the provider's API. The map projects the range and says that it projected.

Link that expires. Every observation has a validity window. A map that never forgets what it saw once stops describing the present and starts describing an accumulation.

The map is not maintained by an anonymous module. Inside the platform, topology is answered for by a named agent, Apolo, and it does that by reading: the graph is what the collectors measured, not an active scan fired at the network and not a diagram someone declared. That is why every link can say where it came from.

Counting what you do not cover

There is a number on that same screen worth as much as the map itself: how many assets have no agent.

An inventory that only shows what has an agent installed is comfortable and misleading, because it is complete by definition: whatever was never instrumented does not appear, and whatever does not appear worries nobody. Showing the agentless count does the opposite. It turns the gap into a visible number, and visible numbers end up on meeting agendas.

In September 2026, in our own demo environment, the map header read 26 of 32 assets, 52 links and 14 without an agent. Turn on the "Discovered via ARP" switch, which brings in the neighbours that showed up in some device's ARP or MAC table, and the same environment read 87 of 154 assets, 132 links and 136 without an agent. The network did not grow between one click and the next. What grew was the part of it that was outside the count.

What to ask any vendor, including us

If you are evaluating a tool that draws inventory or topology, four questions separate a map from a drawing:

  1. Does it tell an observed link from a deduced one, in the interface, without my having to open the documentation?
  2. When it deduces, does it say what it deduced from?
  3. Does it show what falls outside its own coverage, with a number?
  4. Does what it saw yesterday and cannot see today still sit on the map as though it were current?

None of these is about how many integrations there are, and that is why they work. All of them are verifiable in a demo, by looking at the screen.

Why we built it this way

It is the same rule that holds across the platform: never present as certain what was not verified. In a report, that shows up as declaring what could not be evaluated. On a network map, it shows up as separating the line that came from the equipment from the line that came from a piece of reasoning.

The alternative is to draw everything the same and leave the distinction in the operator's head. That works until the day the person who held the distinction is on holiday.

See the features · Read the human approval post · See the plans

Classified in: Product
Author : Marcelo Benevides