15.4 Maintaining Network Documentation
Key Takeaways
Operational documentation includes physical and logical diagrams, device inventory with firmware and subscriptions, VLAN and IP tables, port maps, configuration backups, a change log, and runbooks.
Documentation is updated as part of closing every change; an out-of-date diagram is worse than none because people trust it.
AOS-CX and Central help keep documentation accurate:
show lldp neighbor-infoverifies cabling,copy running-config <url>exports configurations, and Central keeps inventory, topology, and an audit trail.As-built documentation records what was actually deployed, including deviations from the LLD and who approved them.
Credentials and shared secrets belong in an access-controlled password vault, never in diagrams, tickets, or plaintext configuration exports shared widely.
15.4 Maintaining Network Documentation
Quick Summary: Documentation is how a network stays understandable after the people who built it move on. HPE6-A85 lists maintain documentation as an Operate objective. In practice that means keeping a defined set of documents (diagrams, inventory, addressing, port maps, configurations, change log, and runbooks) accurate after every change, and using the network's own data (LLDP, Central inventory, configuration exports) to check them.
The Core Document Set
| Document | Contents | Why it matters |
|---|---|---|
| Physical diagram | Closets, racks, devices, and the cables between them, with port numbers | Fast fault isolation and safe maintenance |
| Logical diagram | VLANs, subnets, routing, VSX/VSF groupings, gateways, and tunnels | Explains how traffic flows |
| Inventory | Model, serial number, MAC address, location, firmware version, subscription, and support contract | Upgrades, renewals, RMA, and audits |
| VLAN and IP tables | VLAN IDs and names, subnets, gateways, DHCP scopes and helpers | Prevents overlaps and supports new requests |
| Port maps | Per-port device, VLAN mode, PoE priority, and access control | Moves, adds, and changes |
| Configuration backups | Current and historical configurations | Recovery, comparison, and audits |
| Change log | Date, change, reason, who, ticket, and result | Answers "what changed?" during incidents |
| Runbooks / MOPs | Step-by-step procedures for routine and emergency tasks | Consistent operations by any team member |
| As-built | What was actually deployed, including approved deviations | The real starting point for operations |
| Contacts and escalation | Vendors, support contract IDs, internal on-call | Faster escalation |
Keeping Documents Accurate
Use the network as the source of truth
- Cabling and neighbors:
show lldp neighbor-infoon each switch confirms the physical diagram; differences mean either the diagram or the cabling is wrong. - Interface state:
show interface briefandshow vlan port <port>confirm port maps. - Inventory and firmware:
show system,show version, andshow imagesper switch; Central's device inventory for the whole estate. - Configuration: export configurations regularly, for example
copy running-config sftp://backup@10.1.100.20/fl2-stack.cfg cli vrf mgmt, and keep them in version control so you can compare versions.
Use Central's records
- Inventory and subscriptions for every managed device.
- Topology views built from discovered neighbor data.
- Audit trail, which records administrative actions and configuration pushes, including automatic rollbacks.
- Reports for client, device, and usage history.
Make documentation part of change closure
A change is not closed until the documentation is updated. Add a "documentation updated" item to every MOP and change ticket, and record:
- what was changed and where,
- the before and after configuration (or checkpoint names),
- verification results, and
- who approved any deviation from the design.
As-Built Documentation
During implementation, reality often differs slightly from the LLD: a cable run turned out longer, so a different optic was used, or a closet had one free port fewer than expected. The as-built package records what was actually installed, with approved deviations, and replaces the LLD as the reference for operations.
Naming and Labeling Standards
Consistent names make documentation and CLI output readable:
- Hostnames that encode site, building, floor, and role (for example
HQ-B1-F2-ACC1). - Interface descriptions (
description) that name the connected device, which also appear in many show commands. - LAG descriptions that name both ends.
- Physical labels on both ends of every cable that match the port map.
Security of Documentation
- Store passwords, RADIUS shared secrets, and SNMPv3 keys in an access-controlled password vault, not in diagrams or tickets.
- Configuration exports can contain secrets; protect the backup repository with the same care as the devices.
- Limit who can edit master documents, and keep version history.
Diagram Layers
One diagram that tries to show everything becomes unreadable. Most campus teams keep a small set of layered views:
- Physical (Layer 1): devices, racks, and every cable with both port numbers. This is the view used during closet work and cabling repairs.
- Layer 2: VLANs per trunk, VSF stacks, VSX pairs and their VSX-LAGs, and the spanning tree root. This explains which VLANs reach which closet.
- Layer 3: subnets, gateways (including active-gateway virtual IPs), OSPF areas, VRFs, and the default route toward the WAN.
- Wireless: AP placement on floor plans, SSIDs with their security, forwarding mode, and VLAN or gateway cluster, and the RF settings that were agreed (for example channel widths per band).
- Management: the out-of-band network, the management VRF, Central connectivity, and where NTP, DNS, RADIUS, and syslog servers live.
Each view should show its date and the change that last updated it, so readers can judge how current it is.
Configuration Backup Practice
- Schedule: export every device's configuration on a schedule and after every change. On AOS-CX,
copy running-config <remote-url> {cli | json} vrf mgmtsends it to an SFTP or TFTP server; checkpoints (show checkpoint) provide on-box history. - Version control: store exports in a repository that keeps history, so you can compare any two versions and see who changed what.
- Test restores: a backup that has never been restored is unproven. Practice restoring to a lab switch, for example with
copy <remote-url> running-configorcheckpoint rollback. - Central history: for Central-managed devices, the configuration audit and audit trail record pushes, mismatches, and automatic rollbacks, which complements device-level backups.
Worked Example: Closing a Change
A technician moved six printers from VLAN 10 to the new IOT VLAN 30 on floor 2. Before closing the ticket, the documentation updates are:
- Port map: ports 1/1/31-1/1/36 now show VLAN 30 and MAC-Auth.
- VLAN table: VLAN 30 lists floor 2 as a location.
- Configuration backup: a new export of the floor 2 stack is stored, and the ticket references the checkpoint taken before the change.
- Change log: date, ticket number, reason, implementer, and verification results (printers authenticated with the IOT role and reachable from the print server).
- Diagrams: no physical change, so only the Layer 2 view's VLAN list for floor 2 is updated.
Common Exam Traps
- Treating documentation as a one-time task. It must be updated after every change.
- Trusting a diagram without verification. LLDP and Central data reveal undocumented changes.
- Storing secrets in documents. Credentials belong in a vault.
During an outage, a diagram shows access stack port 1/1/52 connected to core port 1/1/10, but the engineer suspects someone re-cabled the closet. Which command most quickly verifies the actual connection from the access stack?
show interface 1/1/52 brief
show lldp neighbor-info 1/1/52
show running-config interface 1/1/52
show vlan port 1/1/52
When should network documentation such as the VLAN table and port maps be updated?
Only when a new engineer joins the network team
As part of closing every change that affects them
Only after a major outage reveals errors in them
Only during the annual documentation audit
Where should RADIUS shared secrets and device administrator passwords be stored?
In an access-controlled password vault
In plaintext configuration exports emailed to the team
In the change ticket so the next engineer can find them
In the notes field of the network diagram
Sections you finish are checked off in the contents.
You've completed this section
Continue exploring other exams