A device list is not a network diagram

The inventory knows four hundred devices. Model, serial number, location, owner, all maintained. It is still not a network diagram, and the difference becomes obvious exactly when you need it: at three in the morning, when a switch fails and somebody wants to know what hangs off it.

A list knows nodes. A diagram needs edges.

Where the edges come from

Connection information does not live in the inventory but in the devices themselves. Switches and routers regularly tell their direct neighbours who they are, which port they are sending from and what they can do. Each device builds a local neighbour table from this.

The vendor-neutral standard for it is LLDP, defined in IEEE 802.1AB. Cisco has its own proprietary counterpart in CDP, which does the same thing but only among Cisco devices. Both operate at layer 2, exchange their details as TLV fields and store the result locally, where it can be queried over SNMP.

That is exactly where most automated network-diagram attempts fail. A tool can diligently collect system names, uptimes and interface counters over SNMP and still know not a single edge, because the neighbour table is a different query from the rest.

The trap in our own house

Concretely for us: the topology SNMP import feeds on LLDP and CDP data, and that data is produced solely by agent tasks of type SNMP Scan. The similar-sounding type SNMP Discovery collects OID values but delivers no neighbour data. Choose the wrong one and you get an empty import and no error message, because technically everything worked.

The second precondition lies outside the tool: LLDP or CDP has to be enabled on the switches at all. In many networks it is deliberately switched off, because a protocol announcing device names and port labels into the network has no business in the access layer. That is a defensible decision. It only means the diagram is drawn by hand there.

What the import does not give you

Neighbour data describes what is actually cabled. It says nothing about what was intended. Segmentation, VLAN zones, the separation of production and management networks, all of that is intent and appears in no table. This is why the module separates physical, logical and hybrid topologies: the physical view can be imported, the logical one has to be thought through by someone.

A second starting point is the rack import, which takes all devices in a rack as elements. It too delivers nodes, not edges, but it saves the typing.

Why diagrams otherwise go stale

Everyone knows the network diagram that sits in a drawing file and has not been right since two rebuilds ago. The reason is always the same: the boxes are labels. They know nothing about the device they depict, and nobody notices when it gets replaced.

In the designer every element can therefore be linked to a real object, through a picker with tabs for DCIM devices, IT systems, networks and racks. A linked element is a reference, not a drawing. It keeps pointing at the same record when that record changes.

The practical advice from the documentation is correspondingly unspectacular: link elements consistently instead of merely labelling them, separate physical and logical views via the topology type instead of mixing them, set finished diagrams to published and archive outdated ones instead of deleting them. An archived diagram later answers the question of what it looked like before.

More on the network topology module page.