A network that exists only in one engineer's head is a liability. Maintain both a physical and a logical diagram, kept current as the network changes — not recreated from memory during an outage.

• Physical topology diagram — actual cabling, physical device locations, rack positions, and interconnects between switches, routers, and firewalls.
• Logical topology diagram — Layer 3 view showing subnets, VLANs, routing paths, and how traffic actually flows between segments.
• WAN/circuit diagram — ISP circuits, redundant links, SD-WAN or MPLS paths, and failover relationships between sites.
• Store diagrams in a shared, version-controlled location and set a review cadence (e.g., quarterly, or on any material change).

• Document the overall IP addressing plan: subnet ranges by site, function, and VLAN, with room for growth.
• Record VLAN ID, name/purpose, subnet, and gateway for every VLAN in use (e.g., VLAN 10 — Corporate Data — 10.10.10.0/24).
• Note which VLANs are routed and which are isolated, and where inter-VLAN routing/firewall policy is enforced.
• Maintain a static/reserved IP list separate from DHCP scope, covering infrastructure devices, servers, and printers.

• For every switch, router, firewall, and access point: make, model, firmware/OS version, serial number, and physical/rack location.
• Record management IP address and management method (web UI, SSH, dedicated management VLAN) per device.
• Track warranty/support contract status and renewal date per device.
• Flag end-of-life or end-of-support hardware explicitly so it is planned for replacement rather than discovered during a failure.

• DNS — internal and external DNS server addresses, zones managed, and who has administrative access.
• DHCP — scope ranges, lease duration, reservations, and options (gateway, DNS, NTP) configured per scope.
• IPAM records — the authoritative source of truth for IP assignments; note where it lives and how it stays in sync with actual usage.
• Document the process for requesting a new subnet, VLAN, or DHCP scope so changes go through a controlled path.

• Record every material network change: date, change description, systems affected, and who made it.
• Reference the related change ticket or approval where a change management process exists.
• Version the documentation itself and note who last reviewed or updated it.
• Review the change log periodically to identify drift between documentation and actual running configuration.

• Network Architecture Fundamentals — /knowledge-center/infrastructure/infrastructure-networking/network-architecture-fundamentals
• DNS, DHCP, and IPAM — /knowledge-center/infrastructure/infrastructure-networking/dns-dhcp-and-ipam