-->

Making Network Topology Readable (C4 + Graph Theory) - Scanopy

Making Network Topology Readable (C4 + Graph Theory)<br>July 10, 2026 · Maya

TL;DR: Network topology gets unreadable as it grows, because one diagram tries to answer four structural questions at once. The fix is to separate them: each view answers one question (physical wiring, L3 segmentation, workloads, or application dependencies) and hides the rest, with C4-style zoom that falls out of expand and collapse. Below: the graph-drawing research behind each choice, and the tradeoffs.

Every network mapping tool demos beautifully. A router, two switches, a dozen hosts, a tidy diagram. Then someone points it at a real network, and every host, subnet, and service dependency lands in the same view. The tidy diagram turns into a wall of boxes and links you have to hunt through.

We build Scanopy, a tool that discovers network topology over SNMP, LLDP, CDP, and ARP, and draws it. Our original view put everything it discovered in one diagram: physical links, subnet membership, service dependencies. It was fine on a small network. As networks grew it stopped being readable, and users told us the same thing in different words: I can't read this, and I want to see it a different way.

The original single view: every host, subnet, and service dependency in one diagram.

None of this was novel. The visualization field settled the underlying question decades ago, and the established network tools already separate these views. Scanopy shipped a single combined view for too long; the rewrite was catching up, plus a few decisions specific to our data.

Why one diagram can't answer four questions<br>Network topology is at least four different graphs over the same nodes:

Physical (L2): which port connects to which, from LLDP/CDP neighbor discovery.

Logical (L3): which hosts sit on which subnets, and how subnets reach each other.

Workloads: which host runs which services + whether those services are containerized or running in VMs

Applications: which service talks to which as part of different application stacks.

A single host appears in all four graphs, connected by relationships that mean completely different things. The switch uplink that dominates the physical view is irrelevant when you're asking "what breaks if I decommission this database." The subnet boundary that structures the logical view says nothing about cabling.

Draw all four at once and the layout algorithm has to satisfy four structural questions simultaneously. It satisfies none of them. This is not a rendering problem you can style your way out of. It is a data modeling problem.

What the graph readability research says<br>Two findings from the graph-drawing literature drove the redesign.

Edge crossings are what make a graph hard to read, so minimize them. Purchase (2002) found that minimizing edge crossings is the strongest single aesthetic factor in graph readability, ahead of angular resolution or edge-length uniformity; Huang, Hong, and Eades (2006) found crossings are the strongest predictor of reading errors. People don't just find cluttered graphs ugly; they read them wrong. What we did with it: give each view a single structural edge type to lay out, so there are fewer edges to cross, and run a crossing-reducing layout (the Sugiyama method, below).

A display has a limited budget of visual channels, so don't overload one view. Colin Ware's book Information Visualization: Perception for Design makes the point that line style, color, thickness, and direction can only carry so much before they interfere. What we did with it: rather than stack physical links, subnet membership, and service dependencies in one view at equal weight, we split them across views and made secondary edges opt-in overlays.

Industry practice agrees. NetBox models physical cabling (DCIM) separately from IP and VLAN structure (IPAM), and leaves topology rendering to plugins. SolarWinds ships separate L2 and L3 mapping modes from a single scan. LibreNMS builds its L2 map from CDP/LLDP and ARP. The tools built to render big networks separate these views.

So the direction was clear. The open questions were in the details: how many views, what defines each one, and what happens to all the edges that don't fit.

Borrowing the C4 model from software architecture<br>Simon Brown's C4 model solves a parallel problem for software diagrams: one architecture, different questions at different zoom levels. Context, Container, Component, Code. Each level is a complete diagram at one scale, and you move between levels instead of cramming scales together.

Networks map onto it cleanly:

C4 level<br>Software meaning<br>Zoom level in any view

Context<br>Systems and users<br>Every top-level container collapsed to a single node with a count badge. The whole network in one screen.

Container<br>Deployable units<br>Containers expanded, their members visible inside.

Component<br>Parts inside a container<br>Individual leaf entities: hosts with their ports,...