{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Mode{{ resultsReady ? topologyModeLabel : '—' }} Zones{{ resultsReady ? computation.values.zone_count : '—' }} Links{{ resultsReady ? computation.values.link_count : '—' }}

Zone view unavailable.

Required; 1–80 characters.
The selected mode changes diagram language, review guidance, and exports.
The diagram, stage, and downloaded chart use this layout.
id | label | type | zone | address. Types include router, switch, firewall, server, access-point, endpoint, cloud, load-balancer, vpn-gateway, and other.
from-id | to-id | media | label. Media choices are ethernet, fiber, wireless, or vpn.
Neutral when blank. Included in the design review and ledger exports.

The diagram renderer is unavailable. The same topology remains available in the review and ledger.

Design review
{{ item.title }}
{{ item.status }}

{{ item.detail }}

Review note: {{ computation.normalizedInputs.review_note }}

KindIDLabelPlacement / endpointsDetailCopy
{{ row.kind }}{{ row.id }}{{ row.label }}{{ row.placement }}{{ row.detail }}
Network Change Plan Report Build a network change plan with readiness gates and ordered cutover steps, then review rollback evidence and residual-risk guidance.
Network Audit Findings Report Turn network audit findings into a ranked remediation register with escalation counts, due-state checks, owner gaps, and browser-local reporting.
Cloud-init Network Config Generator Build cloud-init version 2 YAML for a static VM interface, with CIDR and route validation plus warnings for risky boot assumptions.
Kubernetes NetworkPolicy Generator Build Kubernetes NetworkPolicy YAML from pod labels and allow rules with selector checks, rollout guidance, and security review warnings.

A network diagram turns an inventory into a map of relationships. Devices become nodes, connections become links, and zones group equipment by location, trust boundary, service role, or another useful organizing rule. The value of the map comes from the records behind it: a polished drawing cannot correct a missing device or an invented connection.

Logical and physical diagrams answer different questions. A logical view emphasizes intended relationships such as service paths, security boundaries, and dependencies. A physical view emphasizes installed equipment and media. Either view can be useful, but neither proves live reachability, routing behavior, port assignment, or current configuration.

ViewUseful forMust still be verified
LogicalTraffic intent, dependencies, zones, and security reviewRoutes, policy, addressing, and live state
PhysicalInstalled devices, media, racks, and field handoffPorts, cabling, labels, and inventory records

Stable device identifiers matter more than visual placement. Every connection should point to two known IDs, and each unordered endpoint pair should appear only once. Labels can change for readers; IDs should remain stable enough for links and handoff records to keep referring to the same equipment.

A topology also needs an explicit scope. A diagram of one branch office may intentionally omit upstream carrier systems or remote services. Isolated devices can be placeholders, but they should be reviewed rather than hidden because an accidental omission looks the same as a deliberate disconnected node.

How to Use This Tool:

Define the inventory first so every connection can be checked against a known device.

  1. Enter a Diagram title, choose Logical relationships or Physical connections, and set a reading direction that makes the topology easy to scan. Direction changes presentation, not the declared connections.
  2. Add one device per line to Device inventory in the order id | label | type | zone | address. Each row needs four or five columns; the address is optional, and a blank zone becomes Unassigned.
  3. Add one point-to-point link per line to Connection map in the order from-id | to-id | media | label. The label is optional, but both IDs must already exist.
  4. Review isolated devices and incomplete identifiers before using the diagram or topology ledger for implementation handoff.

Interpreting Results:

Endpoint integrity confirms that each accepted link refers to two known devices and is neither a self-link nor a duplicate endpoint pair. Connectivity coverage reports devices with no links. A result with no isolated devices does not prove that all devices belong to one connected graph; two separate groups can each have internal links.

Address coverage is descriptive, not a validity test. The optional value may be an IP address, hostname, rack reference, or inventory identifier, and it is not checked against live DNS, routing tables, or equipment. The largest zone is reported as the primary zone only by device count.

Treat the drawing as a reviewable design record. For a logical handoff, verify traffic paths and policy against the owning design. For a physical handoff, verify media, ports, and installed inventory against field records.

Technical Details:

The topology model is a bounded graph. Each accepted device row creates one node, each connection row creates one undirected endpoint pair for validation, and the zone field groups nodes for layout and review. The selected logical or physical mode labels the model but does not infer missing network facts.

Rule Core:

RecordRequired ruleFailure prevented
Device count2 to 24 rowsEmpty or unbounded inventories
Device IDStarts with a letter; up to 32 letters, numbers, dots, colons, underscores, or hyphens; uniqueAmbiguous link targets
Device typeRouter, switch, firewall, server, access point, endpoint, cloud, load balancer, VPN gateway, or otherUnrecognized diagram vocabulary
Connection count1 to 48 rowsEmpty or unbounded link maps
EndpointsTwo different known device IDs; one row per unordered pairMissing targets, loops, and duplicate links
MediaEthernet, fiber, wireless, or VPNUnsupported link classification

Mechanism Core:

After the rows pass validation, each link adds one to the degree of both endpoint nodes. A degree of zero marks an isolated device. Zone counts are sorted from largest to smallest, with the zone name breaking ties, and the largest group becomes the reported primary zone. Address coverage counts non-empty optional address fields.

The diagram stores the title, mode, reading direction, review note, nodes, and links as a deterministic topology record. This is a generic node-and-link representation rather than a complete implementation of a network management model. It does not discover termination points, layered networks, interface state, or protocol-specific properties.

For example, three devices joined by two links can report no isolated nodes. Four devices with the same two links report one isolated node when the fourth device appears in the inventory but in no connection row.

Privacy and Limitations:

The designer validates the records you supply; it does not scan a network, test reachability, model capacity, inspect configuration, or persist a cloud diagram. A passing review therefore means the declared rows are internally consistent, not that the deployed network matches them.

The title, device rows, connection rows, layout choices, and review note are shareable page inputs and can appear in the page URL. Avoid real credentials or sensitive infrastructure details, and inspect the URL before sharing or recording it.

References: