Turning Network Data Into Graphviz Diagrams

Writing a Python tool that generates Graphviz DOT files from network topology data turns a messy inventory into a map engineers can inspect. The program can read records for routers, switches, firewalls and links, then express their relationships in a language Graphviz understands. That small translation layer is valuable when a change affects several sites and the topology is otherwise buried in spreadsheets or configuration exports.

The goal is not to redraw an artist’s diagram, but to preserve the structure that operations teams need: device identity, interface, link capacity, site and dependency. A dependable generator should make those facts explicit, reject ambiguous records and produce the same DOT text whenever the same input is supplied.

For Australian teams, that reliability matters across widely separated environments. Workloads may sit in cloud regions around Sydney or Melbourne while regional branches operate over slower links, and .com.au or .au hostnames can make ownership boundaries less obvious than they appear in a flat list.

A command-line package fits this market well because it can run on a laptop, inside a CI job or on a modest Linux server. It also gives smaller Australian managed-service providers a reproducible way to publish topology diagrams without buying a heavyweight network-mapping licence.

Modelling Topology Before Graph Generation

Start with an intermediate model rather than emitting DOT while parsing each vendor format. A useful device record can contain a stable identifier, device type, site, management address and attributes; an edge can contain its source, destination, interfaces, bandwidth and state. JSON Lines is convenient for streaming, while YAML or JSON works well for a maintained inventory.

Normalise names during ingestion. Upper-case hostnames, trim whitespace and map aliases to canonical identifiers so router-01 and RTR-01 cannot become separate graphs. Keep vendor-specific fields in the source record if operators need them, but let the renderer use one controlled vocabulary for shape, colour and status.

Designing A Predictable DOT Renderer

The renderer should have one responsibility: convert validated model objects into DOT statements. Group each device into a subgraph by site, emit nodes with quoted identifiers, and connect them with labelled edges. Quoting every identifier is essential because Australian hostnames may include hyphens and interface descriptions may contain punctuation that DOT would otherwise interpret as syntax.

Keep visual decisions in a small mapping table: routers as boxes, switches as ellipses, firewalls as diamonds and disabled links as dashed lines. Do not let arbitrary input choose colours or inject graph attributes. A whitelist keeps labels readable and prevents malformed or hostile inventory data from changing the generated document.

Making Time And Identity Meaningful

Time fields deserve special care. Sydney, Melbourne and Adelaide observe daylight saving, while Brisbane does not, so timestamps recorded during a transition can appear inconsistent even when the underlying event is correct. Store timestamps in UTC, convert them only for display and label the diagram with a single stated timezone.

Ownership is equally important. The Australian Privacy Act 1988 and the Australian Privacy Principles can make some device or client metadata sensitive, even when a diagram serves as an internal operations aid. Avoid passwords, session data and unnecessary personal identifiers; if a topology includes a customer network, publish only the minimum required for the intended audience.

Supporting Australian Network Realities

Australian networks often combine major metropolitan sites with regional branches. Latency between a Sydney data centre and a remote office is not comparable with a short metropolitan path, so edge labels can show latency, utilisation or link class instead of implying that every line has equal importance. Keep the units visible and use Australian decimal and date conventions in summaries.

Cloud regions serving Sydney and Melbourne can sit alongside local appliances, creating links that cross providers and administrative domains. Mark those boundaries with clusters or styles rather than flattening everything into one lane. For teams comparing approaches, this network topology guide offers a useful starting point for deciding what belongs in the model and what should remain documentation.

Packaging The Generator For Real Use

Give the package a clear command-line interface: an input path, an output path and optional filters for site, device type or status. Standard output should remain valid DOT so it can pipe directly into Graphviz, while an ordinary file is easier to diff and review. Exit with a non-zero status when required fields are missing, and include a concise validation report.

Tests should cover unusual hostnames, duplicate device IDs, missing interfaces, self-links and records that arrive in different orders. A sample inventory makes the project approachable, and an MIT or BSD licence lets Australian consultancies and open-source contributors use it without friction. The Canyonero project provides another practical reference within Phil Schwartz’s collection of network and developer tooling.

Rendering And Sharing The Result

Graphviz can render DOT as SVG, PNG or PDF, but the generator should not stop at syntax that merely happens to parse. Inspect the rendered graph for overlapping labels, overly long edge names and clusters that obscure their contents. Automated tests can verify the DOT structure; visual review remains necessary for comprehension.

Version the topology input alongside the tool, and embed a generation date and schema version in graph metadata. That makes it clear whether a missing device reflects a network change or a failed collection run. The finished tool then fits naturally into an open-source portfolio: inspectable source, sample data, documented licensing and outputs that answer operational questions rather than merely looking polished.