Documentation, Fault Injection, and Troubleshooting

Why Documentation and Troubleshooting Go Together

A network that no one has documented is a network that no one can support reliably. When a fault occurs at 2 a.m., the technician on call depends on accurate records to understand what "normal" looks like before they can identify what went wrong. In this lesson you will finalize the complete documentation package for the environment you built, receive and resolve instructor-injected faults, and conduct a formal security review. Each step mirrors what employers expect in a real help-desk or NOC role.

Finalizing the Documentation Package

As-built network diagram. Export your diagram from draw.io or Visio after confirming that every device, link, IP address, VLAN, and port label matches the actual physical and logical configuration. An as-built diagram reflects what was actually installed, not what was originally planned. Any deviation from the original design must appear in the change-management log.

Asset inventory. Record each device's hostname, make, model, serial number, and MAC address (one entry per interface if a device has multiple). Use a spreadsheet with consistent column headers. Serial numbers come from the device label or from `show version` on Cisco devices; MAC addresses come from `show interfaces` or `ipconfig /all` on Windows hosts.

Configuration backups. Copy the running configuration from every managed switch and router to a plaintext file. Name each file clearly, for example `core-sw1_running-config_YYYY-MM-DD.txt`. Store backups in a labeled folder and note the backup date in the asset inventory.

Runbook. Write numbered, imperative steps for startup and shutdown. A good runbook entry reads: "1. Power on the UPS. 2. Power on core-sw1. 3. Verify all access-layer switch uplinks show green before powering on end devices." Anyone unfamiliar with the environment should be able to follow the runbook without asking questions.

Change-management log. List every deviation from the original design: date, description of the change, reason, and who approved it. Even small changes such as renaming a VLAN belong here.

Troubleshooting with a Systematic Methodology

CompTIA Network+ defines a structured troubleshooting process. The steps, simplified, are: (1) identify the problem, (2) establish a theory of probable cause, (3) test the theory, (4) establish a plan of action and implement a solution, (5) verify full system functionality, and (6) document findings, actions, and outcomes.

You may work through OSI layers from the bottom up (start at Layer 1 — Physical) or from the top down (start at Layer 7 — Application), depending on the symptoms. A bottom-up approach works well when the problem is broad and affects many users, suggesting a physical or data-link issue. A top-down approach works well when only one application or service fails.

For each injected fault, open a help-desk ticket and record:

• Symptoms — what the user or system reports
• Hypothesis — which layer and which component you suspect, and why
• Test — the specific command or action taken (e.g., `ping`, `show vlan brief`, `ipconfig /all`)
• Result — what the test revealed
• Resolution — the exact configuration change or physical fix applied
• Verification — confirmation that the fix restored normal operation

Use the ticket format from Course 6. A ticket is only acceptable when the root cause you state matches the fault the instructor actually injected and when the instructor independently verifies the resolution.

Common injected fault examples and starting points:

• Misconfigured VLAN — begin with `show vlan brief` and `show interfaces trunk` to confirm VLAN membership and trunk allowed lists.
• Duplicate IP address — ARP conflicts appear in `show ip arp` and in Windows Event Viewer; isolate the duplicate with `arp -a` on hosts.
• Failed NIC driver — Device Manager on Windows will show a yellow warning; reinstall or roll back the driver and retest with `ping`.

Security Review

Before any environment goes live, a security audit reduces the attack surface. Check the following and document every finding and remediation in a one-page security audit memo:

1. Default passwords — Log into every device and confirm the enable secret or privileged password has been changed from the factory default. Default credentials are the most commonly exploited entry point on internal networks.

2. Unused switch ports — Issue `shutdown` on every access port that has no connected device. An open, active port is a physical entry point for an unauthorized device.

3. Wireless authentication — Confirm the wireless network uses WPA2 or WPA3 with a strong passphrase, not WEP or open authentication.

4. Document findings and remediations — Write what you found, what risk it represented, and what you changed. Even a finding of "no issues" must be written down as evidence of the review.

Safety Points

When working inside equipment racks or handling powered devices, follow your lab's posted safety rules. If any device requires internal hardware work, power it off and use lockout/tagout (LOTO) procedures before opening the chassis to prevent unexpected re-energization. Use an antistatic wrist strap when handling any circuit board or NIC card to prevent electrostatic discharge (ESD) damage. Network cables left across walkways are a trip hazard; route and secure them before the final documentation photographs are taken.

Completing the Lesson

Your deliverables are: the full documentation package, three completed fault tickets with verified root causes, and the security audit memo. The instructor will score the documentation package against a 15-point rubric; you must score 12 or higher. Pay equal attention to accuracy and completeness — a diagram that is neat but missing one VLAN will lose points just as a diagram that is complete but unreadable will.