ICTNWK431 Create network documentation

Network documentation is the map of a thing you cannot see. A network is cables in walls, configuration inside boxes, addresses in tables and rules in firewalls, none of it visible by looking at the room. The documentation is how anyone other than the person who built it, including the person who built it a year later, understands what is there and why.

Ask what the documentation is actually for, and the answers are the whole unit. Troubleshooting: when a service is down at 2am, the diagram that shows how traffic is meant to flow is the difference between a diagnosis and a guess. Upgrades and expansion: you cannot safely change what you cannot see, and a change made without knowing what depends on it is how a small job becomes an outage. Onboarding: a new technician who can read the documentation is productive in days rather than months. Incident response: when a network is under attack, the responders need to know the layout faster than the attacker is learning it. Continuity: documentation is what stops the whole network living in one person's head, so that the person leaving, or being unavailable, is an inconvenience rather than a crisis. And compliance: many standards and audits require that the network be documented, and an auditor's first request is almost always to see the diagrams.

The uncomfortable truth that runs under all of it, and that the rest of this page keeps returning to, is that documentation is only useful if it is current. A diagram that describes the network as it was two changes ago is worse than no diagram, because it is trusted and it is wrong. Producing network documentation is the easy half of this unit; keeping it true is the hard half, and it is where the modern tools earn their place.

"Network documentation" is not one document but a set, each answering a different question about the network. The core artefacts are worth naming, because the unit expects you to produce most of them.

The physical topology shows where things are: the devices, the racks and the cabling, drawn with standard icons, with port details, rack positions and device names, so a technician can walk to the right box. The logical topology shows how things communicate: subnets and IP addressing, VLANs, routing, and the flow of traffic through the core, distribution and access layers, without regard to where the boxes physically sit. The IP address plan, or IPAM record, is the authoritative list of which addresses and subnets are used where. The cable and patching schedule records what connects to what, which port on which patch panel reaches which outlet. The device inventory lists the hardware and software, with models, serial numbers, firmware versions and support dates. The naming and labelling standard defines how everything is named and tagged so the names are consistent and mean something. The configuration documentation captures the important settings of the devices. And the procedure and policy manuals, the runbooks, say how routine and emergency tasks are actually done on this network.

Not every network has all of these, and a small one may fold several into a page or two, but the discipline is the same: each answers a question someone will ask under pressure, and each is only worth keeping if it is kept current.

The two topology diagrams are the documents most people picture when they hear "network documentation", and the unit treats them as a pair because they answer different questions and you need both.

The physical topology answers "where is it". It shows each device as a labelled icon, a server, an end device, an intermediary device such as a router or switch, and the media between them, positioned to reflect the real world: which room, which rack, which rack unit, which port. Its value is partly locational and partly environmental; it lets you see not only where a device is but whether it sits somewhere fit for purpose, such as a switch in a ventilated comms room rather than a hot cupboard.

The logical topology answers "how does it work". It abstracts away the physical placement and shows the addressing, the subnets and VLANs, the routing and the paths traffic takes. It is the diagram you reason about the network with, and it is usually drawn against the classic three-tier hierarchy: an access layer where end devices connect, a distribution layer that aggregates and applies policy, and a core layer that moves traffic fast between the distribution blocks. Designing against those layers is part of what keeps a network free of bottlenecks, because it puts the right capacity at each level.

flowchart TD
  subgraph Core["Core layer (high-speed backbone)"]
    C1[Core switch]
  end
  subgraph Dist["Distribution layer (aggregation, routing, policy)"]
    D1[Distribution switch A]
    D2[Distribution switch B]
  end
  subgraph Access["Access layer (end-device connection)"]
    A1[Access switch: Level 1]
    A2[Access switch: Level 2]
    A3[Access switch: Level 3]
  end
  C1 --- D1
  C1 --- D2
  D1 --- A1
  D1 --- A2
  D2 --- A3
  A1 --- PCs1[Workstations, phones, APs]
  A2 --- PCs2[Workstations, phones, APs]
  A3 --- PCs3[Workstations, phones, APs]

Worth knowing, because it is where large networks have moved, is that the three-tier model is not the only shape any more. Data centres now commonly use a spine-leaf (Clos) design, where every leaf switch connects to every spine switch, giving predictable, equal-length paths for the east-west traffic between servers that modern applications generate; and campus networks increasingly collapse the core and distribution into a single layer, or run software-defined access where the policy lives in a controller rather than in each switch. The documenter's job is unchanged, to draw what is actually there, but what is actually there is more varied than the textbook diagram.

The unit asks you to be able to lay out the OSI model, and it belongs in a documentation unit for a practical reason: it is the shared vocabulary that lets a diagram, a fault report or a design note say precisely which part of the network it means. When a colleague says a problem is "layer 2", every networker knows they mean switching and MAC addresses, not cabling and not routing. The model is a reference, not a thing you build, but it structures how the whole field talks and writes.

In real work the four-layer TCP/IP model is what the internet actually runs on, and the two are mapped onto each other constantly; the OSI model's value is as the more detailed common reference. For documentation, the layers are also a natural way to organise what you record: physical cabling and media at layers 1 and 2, addressing and subnets at layer 3, and the services and applications the network exists to carry at the top.

An element of the unit in its own right, and one of the least glamorous and most valuable things a documenter does, is to decide how everything is named and labelled, and then to hold the line on it. A network where every device, port, cable, subnet and site follows a consistent, meaningful naming scheme is one you can reason about; a network of ad hoc names is one where every task starts with detective work.

A good scheme is consistent, meaningful and scalable: it encodes useful information such as site, building, floor, role and a number, in a fixed order, so that a name tells you what a thing is and where it is without looking it up. It avoids encoding things that change, such as an owner's name or a temporary function, because a name that has to be changed rarely is. The same discipline applies to physical labelling: every cable, patch panel port and outlet labelled at both ends so that tracing a connection is reading, not guessing.

This is one place the industry has a formal standard worth citing, because it is directly on point. ANSI/TIA-606-C, the administration standard for telecommunications infrastructure, sets out how to label and record cabling, pathways, spaces and grounding so that the labelling on the floor matches the records in the documentation. You do not have to adopt it wholesale, but it is the reference a professional labelling scheme is measured against, and naming a recognised standard in a documentation policy is stronger than inventing a scheme from nothing.

Developing, calculating and verifying the network addressing scheme is the numerate heart of the unit, and it is where the documentation has to be exactly right, because an address plan with an overlap or a gap is a fault waiting to happen. The task is to divide the available address space into subnets sized for each part of the network, with room to grow, and to record which subnet serves which area, so that the plan is both a design and a reference.

Current practice is dual-stack, running IPv4 and IPv6 together, which is what the unit's own scenario calls for. Each device and subnet gets both an IPv4 address, usually from a private range, and an IPv6 address from an allocated block, so the network can reach both the older IPv4 internet and the growing IPv6 internet. The reason this is no longer treated as future-proofing is that the future arrived: in April 2026 the share of Google's traffic arriving over IPv6 crossed half for the first time, so most traffic to one of the world's largest platforms now runs on IPv6, with different measurements putting the global figure somewhere between the low forties and just over half depending on method. The figure drifts, so it is worth checking live rather than fixing here; the Google IPv6 statistics page tracks it and the milestone was reported on the APNIC blog in April 2026. A network documented today without an IPv6 plan is documented incompletely.

The modern way to keep an address plan correct is not a spreadsheet but an IP address management (IPAM) system, and this is worth knowing because it is where address documentation has gone. A spreadsheet of subnets is the classic approach and it drifts out of date the moment two people edit it; an IPAM tool holds the addresses as live data that other systems can read and write, so the plan and the network stay in step. This connects directly to the source-of-truth idea in the next sections.

Identifying the right software mapping tools is an explicit performance criterion, and the honest current answer is broader than the single tool most older material names. It falls into four groups.

Diagramming tools are for drawing topologies by hand. draw.io / diagrams.net is the free, widely used standard, with full network stencil sets; Microsoft Visio is the long-standing commercial option; Lucidchart is a common web-based one. These produce clear diagrams and are the right tool for a design you are proposing, but a hand-drawn diagram is a snapshot that starts ageing immediately.

Diagram-as-code tools describe a diagram in text that is then rendered, which means the diagram can be version-controlled, reviewed and regenerated like any other code. Mermaid (used for the diagram earlier on this page), Graphviz, PlantUML, the D2 language and the Python "diagrams" library all work this way. The advantage for documentation is that a text description sits in the same version control as everything else and cannot drift silently, because a change to it is a visible change to a file.

Source-of-truth and IPAM/DCIM systems hold the network as structured data rather than as a picture. NetBox, open source and now the de facto standard, models the devices, racks, cables, IP addresses and connections as a database that is designed to be the authoritative record, read and updated by automation. This is a different idea from drawing: instead of a diagram that represents the network, you keep data that is the documentation, and diagrams are generated from it.

Auto-discovery and mapping tools scan the live network and build the picture for you, tools such as Auvik, NetBrain, SolarWinds Network Topology Mapper and the open-source LibreNMS, with a plain nmap scan as the low-tech starting point. They matter because they attack the staleness problem directly: a diagram discovered from the running network is, by definition, current at the moment it was made.

Here is the single most useful thing to understand about network documentation, and the reason this page spends so long on tools: a network document is out of date the moment the network changes, and networks change constantly. A beautiful diagram drawn in Visio on Monday can be wrong by Friday, and nobody notices until they trust it during an incident and it sends them the wrong way. This is not a failure of effort; it is the nature of hand-maintained documentation, and it is why so many organisations' network diagrams are quietly fiction.

The modern answer has a name, the source of truth, and a discipline behind it. Instead of treating the documentation as pictures that describe the network, you keep one authoritative store of structured data, typically in a system such as NetBox, that is defined to be correct, and you drive everything else from it: the diagrams are generated from it, the automation configures devices from it, and the monitoring checks the real network against it and flags where they disagree. When the source of truth and the network drift apart, that gap is surfaced as an alert rather than discovered during an outage.

Around this sits a set of practices borrowed from software development, sometimes called NetDevOps. Network configuration and documentation are kept in version control, usually Git, so every change is recorded, attributed and reversible, and the history itself becomes documentation of how the network got to its current state. Changes are made through automation, using tools such as Ansible, Nornir and Netmiko, which both applies the change and updates the record in one step, so the documentation cannot lag the network because the same action does both. The goal, stated plainly, is documentation that maintains itself as a by-product of how changes are made, rather than documentation that depends on someone remembering to update a diagram after the fact.

None of this removes the skills in this unit; it raises their ceiling. You still have to decide what to document, design the naming and addressing, choose the standards and check the result with the people who depend on it. What changes is that the current tools let you keep the documentation true, which is the part that hand-drawing never solved.

Before any of the documentation can be produced, the requirements have to be understood, and the unit lists several strands of this. Knowing which applications the network carries matters because the applications determine the equipment, the protocols and the cost; a network carrying voice and video needs capabilities a file-sharing network does not, and buying to the wrong profile either wastes money or starves the service. Understanding the organisation's own requirements matters just as much, and above all whether it plans to grow: a network designed for a company about to double needs expansion built into the design and the addressing from the start, while one designed for a stable organisation can be sized to current need. The documentation records these requirements so the design can be judged against them later.

Networks also have a life cycle, and documentation is produced and revised at every stage of it, not once at the end. The plain version is design, implement and operate, sometimes written as plan, build and manage; Cisco's fuller version is remembered as PPDIOO, for prepare, plan, design, implement, operate and optimise. The point of naming a life cycle is that a network is never finished; it is operated and optimised continuously, and each change loops back through documentation. The modern extension of this is that change itself has become more disciplined and more automated, managed through formal change processes drawn from frameworks such as ITIL and, in automation-led teams, through the same review-and-deploy pipelines used for software, so that a network change is proposed, reviewed, applied and recorded rather than made live at the console and written up later, if at all.

Underneath all of it are the manageable practices that keep a network documentable in the first place: monitor and document everything, build in redundancy, label everything, use proper management tools, automate what you can, and secure it throughout. Those are not separate from documentation; they are the habits that make good documentation possible.

The documentation records design decisions, so a documenter has to understand the concepts and the limits that shaped them. Finance is always one of them, because every component has a cost and a specification, and the two trade off. Cabling alone shows the range: the structured-cabling categories run Cat5e, Cat6, Cat6A and Cat8, each faster and dearer than the last, in shielded and unshielded variants, and a network typically mixes them, using the cheaper category where speed is not needed and the dearer where it is. The same trade runs through wireless, fibre, routers, switches, servers and access points. Documenting which choice was made, and being able to say why, is part of the record.

Constraints are the limits a design has to live inside, and the unit expects you to know the main ones: money, which sets the ceiling on quality, speed and redundancy; labour, meaning the skill available to design and maintain the network; time, both to build it and to run it, which automation can reduce; technology, meaning what is possible and what must interoperate with what already exists; and space, the physical room for equipment along with its power, cooling and uninterruptible supply. Good documentation makes these constraints explicit, because a design that looks wrong in the abstract is often the right answer to a constraint that is not written down.

Quality of service belongs here too, because it is a design concept the documentation has to capture. QoS is the set of techniques that prioritise some traffic over other traffic, so that time-sensitive services keep working when the network is busy. Voice over IP, video conferencing and streaming are the usual candidates; a dropped or delayed packet ruins a call but barely affects a file download, so the network is configured to move the call's packets first. The documentation records which traffic is prioritised and how, because QoS that nobody has written down is QoS that the next person will accidentally undo.

The assessment conditions name access to legislation, standards documentation and industry codes of practice, because network documentation is produced against external standards, not just organisational taste. The structured-cabling standards are the ANSI/TIA-568 series for the cabling itself and ANSI/TIA-606-C for administration and labelling, with ANSI/TIA-942 covering data-centre infrastructure and the international ISO/IEC 11801 sitting alongside them. The networking technologies themselves are defined by IEEE standards, the 802.3 family for wired Ethernet and 802.11 for Wi-Fi, so a documenter references them when recording what a link actually is. Citing the standard a document conforms to is what lets someone else trust and verify it.

Organisational policy sits on top of the external standards: an organisation's own documentation standards, its naming conventions, its templates, and the procedures for review, approval and storage. In Australia the broader legal context applies as it does to any ICT work, principally the Privacy Act 1988 where network documentation touches personal information or reveals where it is held, and the Work Health and Safety Act 2011 where the physical work of cabling and racking is involved. A network diagram is also, increasingly, a document an organisation may be required to produce for a security audit or after an incident, which raises the question the next section takes up: the documentation is valuable to the organisation and equally valuable to an attacker.

Security is one of the design concepts the unit names, and a documenter has to be able to list the threats and the protections. The threats the material sets out are the familiar ones: unauthorised access, where someone reaches the network who should not; malicious use of resources by someone who is trusted but should not be; tampering with files or configuration; destruction, whether of data or of physical equipment; disclosure, where the details of the network become known to people who should not have them; and faults, the failures that good design and monitoring head off before they happen. The protections run in parallel: strong authentication and least-privilege access control, monitoring so that misuse is seen, physical protection of equipment, and above all defence in depth, designing the network in layers so that no single failure exposes everything.

There is a sharper point that a documentation unit is exactly the place to make. The documentation is itself a security asset, and a dangerous one. A complete, current network diagram is precisely what an attacker wants; it hands them the layout, the addressing, the trust relationships and the weak points, so the very thing that makes documentation valuable to defenders, its completeness and accuracy, makes it valuable to an attacker who gets hold of it. This is the "disclosure" threat pointed straight back at the documents themselves. The response is not to keep the documentation vague, because vague documentation fails the people who need it; it is to treat it as sensitive: classify it, control who can read it, store it where it is protected rather than on an open share, and be deliberate about where the copies live. The tension is real and worth naming honestly, because documentation has to be current and available to the responders during an incident and, at the same time, must not be sitting somewhere an intruder can read it before they do.

The last element is the one that turns a draft into a controlled document, and it is easy to skip and examinable because it is easy to skip. Completed documentation is checked with the people who know the network, because the author is often the last to notice their own wrong assumption; it is published to where the people who need it can actually find it, which is a real decision rather than an afterthought; it is stored according to the organisation's policy, securely and where it will be found again; and its completion is notified to the right people and formally signed off, so there is a clear point at which this version is the current one.

Underneath that sits document control, the discipline that keeps a living document trustworthy over time. Each document carries a version number, a change log that says what changed and when and by whom, an owner responsible for it, and a review date by which it must be checked again whether or not anything obvious has changed. Version control systems such as Git do much of this automatically for documentation kept as text or as diagram-as-code, which is one more reason the current tools point that way. The habit to build is that a document is never simply finished; it is published as a version, and the next change starts the cycle again, which loops straight back to the life cycle and the staleness problem this page keeps circling, because keeping documentation true is not a step at the end but the whole job seen over time.

The unit says nothing about artificial intelligence, because when it was written there was nothing settled to say, and for a documentation unit the change is concrete and close to the work.

The most immediate use is generation. AI assistants can turn a device configuration into a plain-language description, draft a runbook from a rough set of steps, generate diagram-as-code from a description of a topology, and summarise a long configuration or a packet capture into something a person can read quickly. For a task whose least popular part is the writing up, this genuinely helps, and it lowers the barrier to documentation existing at all. Alongside it, the auto-discovery and monitoring tools mentioned earlier increasingly use machine learning to infer topology and flag anomalies, which is the same staleness fight fought with better tools.

The caution is the one that runs through every AI section on this site, and it is unusually sharp here because the whole value of documentation is that it is true. An AI can produce a confident, well-formatted network diagram or runbook that is subtly wrong, and a wrong document that looks authoritative is more dangerous than an obvious gap, because it will be trusted. So AI-generated documentation is checked against the actual network before it is published, exactly as a discovered diagram is verified against reality; the model drafts, the network is the authority. There is also a security edge worth carrying: feeding a live network's configuration into a public AI tool is disclosing the network's layout to a third party, which is the disclosure threat from the previous section in a new form, so it belongs in an assessed and approved tool rather than a consumer chatbot. The durable skill the unit teaches, knowing what good documentation contains and being able to tell whether a diagram is right, is exactly what lets a person use these tools well rather than be misled by them.

These notes were built from the delivered ICTNWK431 material in the unit folder, principally the assessor guide (2021) with its questioning benchmarks and documentation project, the two network-design-guidelines exemplars and the Cisco module materials, together with the training.gov.au unit descriptor generated by the Future Skills Organisation on 17 December 2024, which supplied the elements, performance criteria, foundation skills, performance and knowledge evidence and assessment conditions used in the scope block and to decide coverage.

The current-practice material was verified in September 2026. The IPv6 adoption milestone is from the Google IPv6 statistics page and the APNIC blog post "Google hits 50% IPv6" of 28 April 2026, which also gives a lower APNIC Labs figure measured by a different method; the two are presented as the grey area they are. The documentation tooling references are the projects' own sites: draw.io / diagrams.net, Mermaid and NetBox, the open-source network source of truth. The cabling and administration standards are cited by their designations, the ANSI/TIA-568 series for structured cabling, ANSI/TIA-606-C for administration and labelling, ANSI/TIA-942 for data centres and ISO/IEC 11801 internationally, published by the Telecommunications Industry Association and ISO/IEC; the IEEE 802.3 and 802.11 families are the networking technology standards. The source-of-truth, NetDevOps and diagram-as-code practices, the three-tier and spine-leaf topologies, the OSI model, the PPDIOO life cycle and the QoS and security material are established networking knowledge, current as at September 2026.