A switch reboots after a power cut and comes back with last month’s VLANs, because the latest changes were never saved. A motherboard update fails halfway and nobody knows which BIOS version was running before. A drive on a production line is replaced, and the new one does nothing until someone finds the old parameter set. Three different devices with the same root cause: the record was missing.
Network and hardware documentation does not need to be elaborate. It needs to tell you exactly what a device is, how it was configured and how to get it back. Here is how to build that record for Cisco network equipment, ASUS motherboards and routers, and Lenze drives.
Start network and hardware documentation with an asset record
A model name alone does not identify a unit. For each device, capture:
| Record | What to capture | When to update it |
| Identity | Manufacturer, exact model, serial number, hardware revision | Installation or replacement |
| Role and connections | Network role, interfaces, addressing, connected equipment | Wiring or network changes |
| Configuration | Backup location, date, version, who can access it | Every configuration change |
| Firmware or software | Installed release and update notes | Every update or recovery |
| Documentation | Manual location and the model or revision it covers | When a manual is found or revised |
Restrict access to configuration backups. They can contain credentials and reveal the network’s layout.
Record Cisco configurations and baselines
On Cisco IOS devices, two configurations exist at once. The running configuration is what the device uses now; the startup configuration is what it loads after a reboot. Changes that are not saved with copy running-config startup-config disappear on reload, which is how the switch in the opening lost its VLANs.
Useful read-only commands for the record:
- show version: software release, uptime and the reason for the last reload;
- show inventory: product IDs and serial numbers of the chassis and modules;
- show running-config: the current configuration, for a dated backup.
The cisco manuals index can help you locate a manual by product. Confirm the model and software release against Cisco’s official documentation.
Compare against the baseline
When something breaks, compare live output with the last dated baseline before editing anything. show interfaces shows whether a port is administratively down or simply has no link, and its error counters. Rising CRC errors over a fixed interval point to cabling or the physical path. show ip interface brief gives addresses and status at a glance, and show ip route shows whether a route to the destination exists.
Record what you see first. Changing several settings at once can destroy the evidence you need.
Match ASUS firmware to the exact board or router
ASUS motherboards and routers update in completely different ways. Find your manual in the asus manuals index, then compare it with ASUS’s official support page.
Motherboards
On a motherboard, the BIOS (UEFI) version depends on the exact board model and revision. Many ASUS boards can update from the firmware setup itself with the EZ Flash utility, and many also support USB BIOS FlashBack, which can flash a BIOS from a USB drive even without a working CPU or memory installed. Find out if your board has it before you need it.
Before updating:
- Record the current BIOS version and photograph or note the settings you changed.
- If the system uses BitLocker or another form of device encryption, confirm the recovery key is available.
- Read the release notes for prerequisites, such as an intermediate version that must be installed first.
Routers
Router firmware is specific to the model and can reset or change settings. Save a configuration backup from the web interface first and store it off the device. If an update fails, ASUS provides a firmware restoration tool and a rescue mode for many models; the manual explains how to enter it.
Preserve Lenze drive parameters
Lenze is a German manufacturer of drives and automation equipment. Its inverters and servo drives are configured with parameter sets, and on a replacement unit those parameters are the difference between a running machine and a stopped one.
For each drive, record the model, firmware version, communication interface and the location of its parameter file. Many Lenze inverters store their parameters on a pluggable memory module, and Lenze’s engineering tools, such as EASY Starter, can read and save parameter sets. The lenze manuals directory can help you locate documentation, but fault numbers differ between product families, so use the manual for your exact model and revision.
Fault checks
- Write down the fault code, the operating state and what the machine was doing.
- Check the communication path and the controller’s status before resetting a communication fault.
- Follow the site’s lockout procedure before any physical inspection.
Drive capacitors can stay charged after the supply is switched off. The waiting time is printed on the device and in its manual. Electrical measurements are for qualified personnel only.
Isolate faults layer by layer
Start with the symptom and the last change. Then work upward:
| Layer | Check | Points to |
| Power | Status lights, supply path | Power supply or upstream feed |
| Physical | Cables, ports, link lights | Cable, port or remote end |
| Configuration | Interface state, addressing, VLANs | A changed or unsaved setting |
| Routing and services | Routes, next-hop reachability | Upstream path or service |
An unreachable device on its own does not tell you which layer has failed.
Update the record after every change
Close each job with a dated entry: what changed, who changed it, the resulting configuration or firmware version, test results and any open issues. Link it to the asset record.
Acceptance checks should match the device’s role. For a router, test the routes and next hops it serves. On a drive, confirm communication with the controller and correct operation under supervision.
Save and label the new backup, and keep the previous known-good version. Note if recovery was only reviewed on paper or actually tested, and run disruptive restore tests only on spare hardware or in an approved maintenance window. Audit the register on a fixed schedule, so stale entries are found before an outage, not during one.
