Documentation, Baselines and Network Management

Documentation, Baselines and Network Management

What you'll learn

• Argue the business case for documentation with the book's cost arithmetic (fresh numbers included)
• Produce the three core documents: wiring schematic, physical topology, logical topology
• Use baselines to turn "it feels slow" into a budget line with a date — the capacity-planning method
• Sketch the policy and procedure library a professional network keeps
• Explain how networks are monitored: SNMP, logs, flow data — and why port scanners belong in your toolkit before an attacker's

This lesson builds on Chapter 13 of Dr. Tahseen Al-Doori's Network Essentials — the management-and-documentation chapter, including a persuasion case the book aims squarely at technicians who would rather do anything else than paperwork. Fair warning: that means you.

Why bother: the chart on the bridge

A classic analogy from Dr. Al-Doori's course puts you at the wheel of a huge ship approaching a harbor. The open sea is deep everywhere; the approach is not — most of the water ahead is too shallow for your hull, with safe passage threading a narrow channel. Guessing your way in is not bravery; it is a wreck on a schedule. Real ships enter harbors on charts — precise, continuously updated maps of depth and channel — kept by an officer whose entire job is knowing where the bottom is.

Now the network version, with the money attached. A key file server drops off the network. Order processing stalls at a cost of $3,000 a minute. The fix requires knowing which patch-panel port and switch port serve that server — and nobody wrote it down. Your options are the seafarer's nightmare in miniature: unplug things one at a time and see what breaks further. With documentation, the fix is a ten-minute walk to a labeled port: about $30,000 of downtime. Without, a three-hour guessing expedition: about $540,000. The documentation that made the difference — call it two technician-weeks to create, roughly $6,000, plus minutes a day to maintain — pays for itself about eighty-five times over on the first incident of the year — $510,000 of avoided downtime against $6,000 of documentation. No appliance on any price list buys uptime that cheaply. And the book's sharper point: solving the problem is not enough to keep the job; solving it fast is — slow fixes make owners wonder who else could hold the wheel.

What belongs in the library? The wiring layout, the topology maps, server configurations, key applications with versions and patch history, network services (DNS, DHCP and friends), procedures including security policy, and baselines. The next two sections take the heart of it: the three drawings and the numbers.

The three documents

1. The wiring schematic answers "which copper is which?" It maps every wall jack to its patch-panel port and switch port, with each cable labeled physically at both ends and logged. A worked fragment (the lab's format):

Add a floor sketch marking jack locations, cable runs — and the things that hurt cables and signals: power panels, fluorescent fixtures, air-conditioning motors (the EMI sources from Module 3). The schematic is what turns "find the server's cable" from an expedition into a lookup.

2. The physical topology answers "where does equipment live?" — rooms, racks and boxes: server locations, the wiring closets (professionally: the MDF, the main distribution frame where the ISP hands over, and any IDF satellite closets), power and UPS positions, AC and duct runs, WAN handoff point, and which departments with how many users hang off each area. In text form:

[ISP fiber] → ONT → Router/Firewall → Switch SW1 (Closet C, rack U4-U8, on UPS-1)
Closet C: patch panel PP1 (24p), SW1, router, ONT, UPS-1
Front office (Room A): jacks A-01..A-04, AP-1 (ceiling)
Studio (Room B): jacks B-01..B-06, NAS (under desk 4 — flagged for relocation)

3. The logical topology answers "how does data flow?" — no walls, only structure: subnets and VLANs with their address ranges, routing between them, where DNS and DHCP live, data-flow direction for key services, and the high-priority users or applications. Text form:

VLAN 10 STAFF   192.168.10.0/24  gw .1  — DHCP .100-.199 from router
VLAN 20 GUEST   192.168.20.0/24  gw .1  — Wi-Fi guests only, no LAN access
NAS 192.168.10.10 (static)  ·  DNS/DHCP: router  ·  Internet: NAT at router

Three views, three failure hunts: a dead jack sends you to the schematic, a hot closet to the physical map, a "guest can see the NAS" complaint to the logical one. Keep all three current — an outdated chart that says the channel is where it is not steers you into the sandbank with confidence.

Baselines: the numbers that predict

A baseline is a recorded measurement of normal — link utilization through a day, storage consumed, response times — captured under stated conditions and repeated on a schedule so trends emerge. Baselines have two jobs. The diagnostic one: "is this slow?" has no answer without "compared to what?" The financial one is where careers are made, and Chapter 13 teaches it as a budget-meeting story. Here is the pattern with fresh numbers.

Your design studio's shared NAS runs RAID 5 with four 4 TB drives. A colleague eyeballs the purchase order — "16 terabytes, we're fine for a decade." Your baseline notebook disagrees twice. First, the parity correction from last lesson: four drives in RAID 5 yield 3 × 4 = 12 TB usable, not 16. Second, the growth line: project archives currently hold 7.5 TB and have grown 25% per year for three recorded years. Roll it forward: 7.5 → about 9.4 TB in twelve months → about 11.7 TB in twenty-four. Storage misbehaves well before it is full — past roughly 90% (here, about 10.8 TB) performance degrades and maintenance jobs crawl — and the projection crosses that line in under two years, with a fudge-free date attached. So the drives go into this budget cycle, get installed during quiet weeks, and the displaced drives retire into the spares shelf — versus the alternative timeline: an emergency purchase at panic prices, a weekend migration, and an owner asking why nobody saw a straight line coming. Baselines convert complaints into evidence and evidence into scheduled spending — and executives who rightly distrust "the IT crowd wants new toys" find a measured graph very hard to argue with.

Two vocabulary notes: system baselines measure the whole network's behavior; component baselines measure one device or link. And keep conditions comparable — a Tuesday-morning measurement compares with Tuesday mornings.

Policies and procedures: the paper firewall

Documentation also covers people rules. Policies state what is acceptable: network and Internet usage, email rules (quotas, personal use), whether staff may install their own software, account and password standards, and an ownership policy stating that the organization may inspect its own equipment — the clause that makes investigations lawful and expected. Procedures state how recurring work is done: the backup schedule (what, when, who — last lesson's rotation, written down), adding and removing users, security response, monitoring routines, software updates, remote access, and how violations get reported. Regulatory documentation reminds everyone which laws apply to the data you hold. The operational payoff is symmetry: procedures make good work repeatable when the person who always did it is on vacation, and policies make the rules enforceable because they were written and signed before the incident, not after.

Monitoring: the network reporting on itself

Documentation describes; monitoring keeps it true. The classic protocol is SNMP (Simple Network Management Protocol): agents in switches, routers, servers and printers expose counters and status, and a management station polls them into graphs and alerts — this is where baseline data comes from without anyone walking around with a clipboard. One security note that is not optional in 2026: use SNMPv3, the version with authentication and encryption; the older v1/v2c send their community strings — effectively passwords — in cleartext, an eavesdropper's gift you know exactly how to capture after last lesson.

Logs are the network's diary, in three classic books: security logs (logons, access attempts — where break-ins leave footprints), application logs (services starting, failing, complaining), and system logs (hardware, drivers, the operating system's own health). On Windows they live in Event Viewer; on Linux, in the journal (journalctl). The professional habit: read logs before an incident occasionally, so you know what normal chatter looks like — logs, too, have baselines.

Two measurement distinctions round out the kit. Bandwidth is potential bits per second; throughput is what actually gets through — baselines record the second. And testing has grades: performance testing measures normal, load testing measures behavior as demand grows, stress testing finds the breaking point on purpose — before your busiest day finds it for you.

The modern layer (current): polling counters tells you how much; flow data tells you who and what. NetFlow and its IETF standard IPFIX have routers summarize every conversation — endpoints, ports, bytes — into records a collector analyzes: the missing link between "the uplink is at 90%" and "because backups are running at noon." Newer gear pushes streaming telemetry — continuous state updates rather than polled snapshots. Awareness level is enough here: know that the questions "how much, who, and what" each have their instrument.

Finally, the port scanner — a tool that probes machines for open (listening) TCP/UDP ports. Attackers use scanners to inventory your doors; administrators therefore scan themselves first, on authorization, comparing what is actually listening against what is documented to be listening. Anything unexpected — a forgotten service, an unapproved application — is a finding. The well-known port numbers you memorized in Module 5 are exactly the reading vocabulary a scan report requires; keep that card at hand — Download: Ports and Protocols Reference (the Module 5 card) — and remember the two meanings of "port": the physical socket on a switch, and the numbered software door a scanner probes — context decides.

From the textbook to 2026

The discipline is unchanged; the stationery evolved. The diagramming freeware the book pointed students to has vanished from the web — a tiny irony for a chapter about keeping records current — and today's equivalents are free browser tools like diagrams.net for the drawings, with larger networks graduating to DCIM and IPAM systems (data-center infrastructure management, IP address management: databases where the wiring schematic, rack layout and address plan live as structured, queryable data instead of a drawing that drifts). SNMP endures — in v3 — now flanked by flow data and streaming telemetry. What has not changed by a millimeter: the three documents, the baseline method, the policy library, and the economics — the cheapest uptime money can buy is still a current chart of where the bottom is.

Activity: Document a Three-Room Office

Paper and text editor only — this is design-desk work, the same deliverables a consultant would leave behind after a site survey.

Objective. Produce the three core documents plus a baseline table for a small office, from a written site description.

The site: Fernway Architects. Three rooms. Room A — front office: reception desk with a PC, one shared color printer (network-attached), one staff PC, and a ceiling Wi-Fi access point serving staff laptops and guest phones. Four wall jacks installed (A-01 to A-04); reception PC uses A-01, printer A-02, staff PC A-03, the AP's cable drops from the ceiling to A-04. Room B — studio: four CAD workstations on jacks B-01 to B-04, and a NAS storing all project files (jack B-05); jack B-06 is spare. Room C — utility closet: a small rack holding the ISP's fiber terminal (ONT), the router/firewall, one 24-port switch, a 24-port patch panel, and a line-interactive UPS feeding the rack. All jacks are Cat6, home-run to the patch panel in Room C; panel ports mirror jack numbers (A-01 → PP-01 … B-06 → PP-10). The router provides DHCP and NAT; the business wants guest Wi-Fi kept away from the staff network (two VLANs, two subnets — your Module 3 and Module 4 skills decide the details); the NAS and printer should keep fixed addresses.

Steps.

1. Wiring schematic. Build the full jack table in this lesson's format — ten rows, A-01 through B-06 — assigning switch ports (a sensible scheme: panel port n → switch port n) and noting each jack's device. Add two hazard notes a surveyor would flag (the closet shares a wall with the building's electrical panel; Room B's ceiling has fluorescent fixtures near the B-run).
2. Physical topology. A text diagram (this lesson's compact style) showing the rack contents in Room C top to bottom, the uplink chain ONT → router → switch → patch panel, what is on UPS power, and per room: jacks, devices, the AP.
3. Logical topology. Choose and write: two VLANs with names and numbers, two /24 subnets with gateway addresses, the DHCP ranges, static assignments for NAS and printer, where DNS/DHCP/NAT live, and one line stating the guest-to-staff rule.
4. Baseline table. Five metrics worth trending for this office, each with: what, how measured (a tool from this module), how often, and why Fernway would care. Choose from anything you have learned — link throughput, NAS capacity, DHCP leases in use, AP client count, RTT to the ISP's first hop, log review — or better ideas of your own.
5. The drill. Test your own documents: the printer goes silent — write down, in order, which document you open and what you look up, before touching hardware.

Deliverable. Four artifacts plus the drill answer, in one text file or on paper.

Model solution sketch (compare after finishing). Wiring: ten rows; A-04 noted as "AP uplink — PoE if switch supports it"; hazards noted against the closet wall (EMI near patch panel) and the B-run ceiling path. Physical: ONT → Router/FW → SW1 (24p) → PP (24p), rack order listed, UPS feeding ONT + router + switch (the AP survives via PoE from the protected switch — a detail worth a bonus point). Logical: e.g. VLAN 10 STAFF 192.168.10.0/24 gw .1, DHCP .100–.199, NAS .10 static, printer .11 static; VLAN 20 GUEST 192.168.20.0/24 gw .1, DHCP .100–.199; router holds DHCP/DNS-forwarding/NAT; rule: "GUEST may reach the Internet only — no route to STAFF." Baselines (one good set): WAN throughput at busy hour, weekly (justifies ISP upgrades); NAS used TB, monthly (this lesson's capacity math); DHCP leases per VLAN, weekly (growth and rogue devices); AP client count, weekly (coverage planning); RTT from router to ISP first hop, daily (early warning on line quality). Drill answer: logical topology for the printer's static address → ping it (lesson 1's kit) → if dead, wiring schematic row A-02 → check jack, panel port PP-02, switch port 2 — a sixty-second path from symptom to socket, which is the entire point of this lesson.

Self-check. Every jack appears exactly once; the two subnets do not overlap and both gateways end in .1; every baseline row names a tool this module actually taught; the drill answer opens a document before touching a cable.

Check yourself

1. The $3,000-a-minute story assumed documentation existed. Compute the break-even: if creating the library costs $6,000 and it saves 170 minutes on one incident a year, how many years of incidents pay for it? What does your answer say about the "no time for paperwork" objection?
2. A technician reports: "Room B users can't reach the file server, Room A users can." Which of the three documents do you open first, and what specifically are you looking for?
3. Your baseline shows the office uplink at 92% utilization every weekday from 12
   to 13
   , and email complaints cluster in that hour. Management proposes doubling bandwidth. Using this lesson plus last lesson's QoS section, give a cheaper first response and the evidence you would cite.
4. Why is SNMPv1/v2c on a 2026 network a finding for your security log, and which lesson-2 skill would demonstrate the problem in sixty seconds?
5. A self-scan of the print server shows TCP ports 80, 443, 9100 — and 23 — listening. Using your Module 5 port knowledge, which one demands action, and what action?
6. Your NAS baseline: 4 × 6 TB in RAID 5, currently 9 TB used, growth 30%/yr, slowdown threshold 90% of usable. When must new capacity be in service? Show the two-step math.

Answers

1. It pays for itself about 85 times over in year one ($510,000 saved against $6,000): less than one incident recovers the cost many times — the objection prices twenty minutes a day against half a million dollars.
2. The wiring/physical view of the path shared by Room B — but the first open is the logical topology: if Room B is a different VLAN or subnet, the symptom pattern (one room out, one fine) points at inter-VLAN routing or a switch-port grouping before any cable.
3. Shape and prioritize before buying: mark VoIP and interactive traffic for priority (DSCP), shape the bulk lunchtime flows, and check flow data for what fills the hour (perhaps backups scheduled at noon — a calendar fix, not a purchase). Evidence: the baseline graph plus a flow summary of the peak hour.
4. Those versions transmit their community strings unencrypted; anyone capturing on the path reads the management password. A Wireshark capture filtered on the SNMP traffic would display the string in the packet details, in plaintext — demonstration complete.
5. Port 23, Telnet — a cleartext remote-login service on a printer is an unnecessary, insecure door. Action: disable the service on the device (and record the change); management should use the encrypted alternatives.
6. Usable = 3 × 6 = 18 TB; threshold = 16.2 TB. Growth: 9 → 11.7 (year 1) → 15.2 (year 2) → crosses 16.2 during year 3, a few months in. New capacity must be in service by roughly the end of year two — budgeted a cycle earlier.

Key terms

• Wiring schematic — jack → patch panel → switch port mapping with labeled cables; the "which copper is which" document.
• Physical topology — where equipment lives: rooms, racks, closets, power, WAN handoff.
• Logical topology — how data flows: VLANs, subnets, services, routing, priorities.
• MDF / IDF — main distribution frame (where the WAN hands over) and satellite wiring closets.
• Baseline — recorded normal, measured under stated conditions on a schedule; system-wide or per component.
• Capacity planning — projecting baseline growth to a dated budget decision — before the failure dates you.
• Policy / procedure / regulatory documentation — the acceptable-use rules, the how-to-do-recurring-work scripts, the applicable-law reminders.
• SNMP / SNMPv3 — the polling protocol behind monitoring; v3 is the only version that authenticates and encrypts.
• Security / application / system logs — the three diaries: break-in footprints, service health, hardware and OS events.
• Bandwidth vs throughput — potential versus actual bits per second; baselines record the actual.
• NetFlow / IPFIX / streaming telemetry — conversation summaries and continuous state push; the "who and what" behind utilization graphs.
• Port scanner — probes for listening ports; run on yourself, with authorization, before someone else does.
• DCIM / IPAM — documentation as structured data: infrastructure and address-plan databases (modern replacement for drift-prone drawings).

Summary

• Documentation is bought uptime: the chart that turns a three-hour guessing expedition into a ten-minute lookup — and the arithmetic pays for the whole library on the first incident.
• Three documents, three hunts: wiring schematic for the copper, physical topology for the rooms and racks, logical topology for the flows and VLANs — kept current, or the chart itself steers you onto the shallows.
• Baselines answer "compared to what?" and, projected forward, convert growth into scheduled budget lines — the RAID-parity correction and the 90% slowdown threshold included.
• Policies make rules enforceable and procedures make quality repeatable; both are written before the incident by definition.
• Monitoring feeds it all: SNMP (v3 only) for counters, logs for events, flow data and telemetry for who-and-what, port scans — authorized, of yourself — for doors nobody documented.
• The 2026 form of the discipline is documentation-as-data (DCIM/IPAM), but every principle in this lesson would be recognized by the book's original readers.

Next lesson

You have the tools, the microscope, the money argument and the charts. The module's finale assembles them into the skill that defines the profession: a systematic troubleshooting method — including the print-job case this course has owed you since Module 2, finally run to the end, and a simulator hunt with three seeded faults.

Sources and further study

• Al-Doori, T., Network Essentials, Chapter 13 — documentation management, baselines, policies, monitoring and network tools; the persuasion case this lesson retells with fresh numbers.
• RFC 3410, "Internet Standard Management Framework" — https://datatracker.ietf.org/doc/html/rfc3410 — the SNMP framework and its evolution toward v3.
• RFC 7011, "IPFIX Protocol Specification" — https://datatracker.ietf.org/doc/html/rfc7011 — the standards form of flow export.
• Nmap Network Scanning, "Port Scanning Basics" — https://nmap.org/book/man-port-scanning-basics.html — the canonical scanner's own primer; read alongside the authorization rule.
• Download: Ports and Protocols Reference (the Module 5 card — the reading vocabulary for every scan report and logical diagram).