Capstone 3: Inspect, Diagnose and Document

Capstone 3: Inspect, Diagnose and Document

What you'll learn

• Capture at two points on a switched network and explain what each vantage point can and cannot see
• Turn packets into evidence: what a capture must record to survive being questioned
• Work real tickets by Module 8's method, producing a fault report per incident that a colleague could audit
• Run a defensive security review over your own build and rank the findings honestly
• Assemble a professional dossier: design, as-built, evidence, incidents, security, handover

This lesson synthesizes Chapters 10 through 15 of Dr. Tahseen Al-Doori's Network Essentials — the command-line tools, the performance and reliability chapter, the troubleshooting procedures, the management and documentation chapter, and the two security chapters. It is the fifth of the book's parts and, not coincidentally, the half of the profession that nobody sees until something breaks. Chapters 1 to 9 taught you to build a network. Chapters 10 to 15 taught you to be trusted with one.

Reading your own network: the two capture points

You have captured traffic since Module 2, and Module 8 turned scrolling into investigating. What is new here is position.

A switched network is not a shared wire. Module 3 explained the consequence: a capture on your own port sees your own conversations and the broadcasts that reach your VLAN — and almost nothing else. So a single capture point never tells you what happened to a packet; it tells you what happened at one place. The professional move is to capture on both sides of the boundary you are investigating. Then the difference between the two captures is itself the finding.

Capture point 1 — the client segment. Sit where a design workstation sits. Four things are worth watching here, in this order:

• The address handshake. The DHCP exchange is the single most informative thing a client segment ever shows you, because the final acknowledgement carries the client's whole configuration: address, mask, gateway, resolver, lease length. If a machine is misconfigured and nobody typed anything, this exchange is where the misconfiguration was delivered — and the packet naming the delivering server is right there.
• The gateway conversation. An ARP request for the gateway address, and whether anything answers. A client asking repeatedly with no reply is telling you it believes in a gateway that does not exist on its segment.
• Name lookups. Which resolver is being asked — the destination address on the query is the fact, not what the user believes — and whether a response comes back at all.
• The first connection attempt. The opening of a TCP conversation toward the NAS or the server. A connection that opens and completes is a working path; a connection that repeats its opening packet with no answer is a path that fails somewhere beyond your vantage point.

Capture point 2 — the server segment. Sit beside the server. The question here is almost always the same one, and it is the question that a client-side capture cannot answer: did the request arrive? If the client-side capture shows a query leaving and the server-side capture shows nothing arriving, you have located a boundary — the packet died between the two points, or it was never travelling toward this segment in the first place. That distinction is worth an hour of guessing. Also watch for the relayed DHCP traffic arriving as unicast from the router, the queries that do arrive and what the server answers, and repeated retransmissions, which say "something is being lost" long before a user notices.

In the simulator, Simulation mode is your capture. Packet Tracer will not export a capture file, so use what it does have: Edit Filters restricted to the protocols you care about (ARP, DHCP, DNS, ICMP, TCP), the event list as your packet list, and the Inbound/Outbound layer panel as your packet detail. Place your two vantage points by watching events at the client's own port and at the server's port. On your real machine, Module 8's Wireshark craft applies unchanged — and Download: Wireshark Essentials Guide has the display filters worth memorizing.

Evidence, not screenshots

A screenshot is a picture. Evidence is a picture that answers questions. Five fields turn one into the other, and any incident report missing them will be doubted by the next person who reads it:

1. What was captured — the protocol or conversation, in one line.
2. Where — device, interface or port, and which segment. "On the client" is not a location; "at PC-D07's switch port, VLAN as configured on Fa0/7" is.
3. When — a timestamp, and whether the network was in its normal state or already broken.
4. How — the exact filter applied. A filter changes what you can see, so an unstated filter makes an absence meaningless.
5. The finding — the specific packet or field that supports your conclusion, quoted, plus the sentence it proves.

Three habits go with those fields. Capture before you change anything — a capture taken after the fix documents the fixed network, not the fault, and cannot support any claim about the cause. Record absences deliberately — "no DHCP offer appeared at this point during a 60-second capture with the filter shown" is a strong finding, but only if the filter and duration are stated. And keep a positive control: alongside the thing that failed, capture something on the same segment that worked, so a reader can tell a policy from a broken cable.

Tickets arrive

Three tickets are waiting for you below. They are written the way real tickets are written: by the person suffering, in their own words, with the details they thought were relevant. Nobody has diagnosed anything. Nobody has told you which device is at fault, or whether these are one problem or three.

Work them with Module 8's nine steps — gather, isolate, what changed, probable cause, escalate if needed, plan with a rollback, one change, verify, document. Download: Troubleshooting Flowchart is the one-page form of that method, and its symptom table is fair game; keep it beside you. The bottom-up OSI ladder is your search order unless an early isolation move justifies jumping.

Two rules for this exercise, and they are the whole point:

Diagnose from evidence, not from memory. The faults were seeded into your build by someone other than you — your instructor's seeded file, a study partner working from the sealed seeding card in the instructor pack, or, if you are studying alone, by yourself from that card followed by a deliberate break of at least a few hours before you begin. If you find yourself writing "I knew it was X," delete it and go find the output that proves X. The deliverable is not the fix; the deliverable is a chain of evidence that would convince a colleague who was not there.

One change at a time, with a rollback. You have a stage-by-stage set of saved files from Lesson 2. Know which one you would reopen before you touch anything.

The fault report. For each ticket, produce one report with these fields. It extends the ticket template from Module 8 with the two fields that separate a repair from an improvement:

FAULT REPORT — ticket reference · network m9-capstone · date
Reported symptom (user's words):
Scope (who and what is affected; who is not):
Evidence gathered (command or capture, where run, exact result):
Isolation boundary (what works / what does not):
What changed (or: no change identified, and how you established that):
Probable causes considered (and why each was ranked where it was):
Cause (the one supported by evidence, with the evidence reference):
Fix applied (exactly one change):
Rollback that was ready:
Verification (the original complaint retested, with the user's task, not just a ping):
Side effects checked:
Prevention (what would stop this recurring — a document, a check, a design change):

That last field is what makes a technician into an engineer. A fault fixed is worth an afternoon; a fault made impossible is worth a career.

TICKET MER-2041 · Priority: High · Reported by: Nadia S., Design team

TICKET MER-2042 · Priority: High · Reported by: Tomas R., Business/Admin · Affects: multiple users

TICKET MER-2043 · Priority: Medium · Reported by: Priya K., office manager · Stretch ticket

Tickets 2041 and 2042 are required. Ticket 2043 is offered as a stretch: if you finish the first two with time left, take it, and notice how much faster the second and third hunts go once the method is in your hands rather than on your page.

Reviewing your own security

Module 7 taught defence in depth; Module 6 gave you a router hardening scorecard and told you the capstone would reuse it. Here it is, widened from one router to a whole studio, and pointed at your own work — which is the hardest direction to point it. Reviewing your own build honestly is a skill, and the honest reviewer's trick is to write findings as facts with evidence rather than as judgements about yourself.

Grade each item pass, fail or not applicable, attach the evidence, and where it fails write a remediation and a residual risk.

1. Guest isolation is verified, not assumed. Evidence: the guest row of your ping matrix, every internal cell failing, with the positive control showing the same client reaching the Internet. A guest row of failures without a control proves nothing.
2. Camera egress is blocked. Evidence: the camera-to-Internet matrix cell failing; the access list's match counter incrementing on its deny line; the translation table containing no entry with a camera source address, plus a statement of the command you ran to look.
3. Administrative access is controlled. Every switch and the router have an encrypted privileged-mode secret rather than a plaintext password, unique per device; remote administration uses SSH rather than Telnet, or is disabled entirely; console and remote sessions time out; there is a login banner stating that access is restricted. Note plainly that service password-encryption is obfuscation, not encryption — it stops shoulder-surfing, not an attacker with the configuration file.
4. Unused ports are closed. Every switch port not in service is shut down, and ideally parked in an unused VLAN rather than left in VLAN 1. Evidence: the interface status list. This is the cheapest control in the building and the one most often skipped.
5. The native VLAN is not VLAN 1 and carries no data. VLAN 1 is where everything starts by default, which is exactly why it should carry nothing you care about.
6. Wireless meets the current standard. Your dossier states WPA3-Personal (or WPA2/WPA3 transition with the reason), separate passphrases for staff and guest, WPS disabled, client isolation on the guest SSID, an SSID that does not advertise the hardware model, and the access points' own admin credentials changed from default. Record explicitly that the simulator was configured to WPA2/AES and why that differs from the production requirement.
7. Servers and services run least privilege. Which services are enabled on the studio server, and does each one need to be? A file server also running services nobody uses is extra attack surface for free.
8. Firmware and patching have an owner and a rhythm. Not "we will keep things updated" — a named role, a stated interval, the current versions recorded as a baseline, and where release notes are checked. An unpatched device is a decision somebody made by not deciding.
9. Configurations are backed up off the device. copy running-config startup-config protects you from a reboot; it does not protect you from a dead switch. Exported configurations stored somewhere else, with a date, do. Module 8's backup discipline applies to configurations as much as to project files.
10. Logging and time are usable. Devices send logs somewhere they will still exist after the device dies, and every device agrees on the time. Unsynchronized clocks turn a five-minute incident reconstruction into an argument.
11. Physical security is stated. The closet locks; the rack is where you said it is; the server is not under a desk in the meeting room. If any of that is untrue, it is a finding, not an embarrassment.
12. The remote-access path is defensible. Remote staff arrive through the VPN, not through anything published to the Internet; the single public address exposes no internal file service; and the VPN client range appears in the reachability table as its own row with its own permissions.

Then rank your findings. A review that lists twelve items of equal weight is a list; a review that says "these two must be fixed this week, these four this quarter, these three are accepted risks and here is why" is advice a business owner can act on. Ranking is where the client discovers whether they hired a technician or a professional.

The dossier: what "documented" means

Module 8 made the case with the chart on the bridge: an undocumented network can only be operated by the head that holds it. The capstone dossier is the whole project in one place, written for three readers at once — the studio owner who wants to know what they bought, the technician who will operate it, and the engineer who will inherit it in three years without meeting you.

Its structure is not decoration. Each section answers a question somebody will ask, in the order they ask it:

Two sections deserve a note because beginners omit them and professionals never do.

Deviations from design. No build matches its design exactly. A port moved, a pool was widened, a name changed, an assumption turned out wrong. Recording the difference — and why — is not an admission of failure; it is the only thing that keeps the design document true. A design nobody corrected is a document that lies quietly for years.

Known risks. Your studio has a single inter-floor link, a single router, one Internet connection, and a bill of materials chosen against a small budget. Every one of those is a risk the client accepted, whether or not anyone said so out loud. Writing them down converts a future outage from "the network failed" into "the risk we documented on page 11 occurred, and here is the plan we wrote for it."

Download: Capstone Final Dossier Template contains this structure with every table pre-formatted, and Download: Network Documentation Templates has the Module 8 originals if you prefer to build it up yourself.

Project: inspect, diagnose and document

Objective. Produce capture evidence from two points, two completed fault reports (plus a third if you take the stretch), a ranked security review of your own build, and the final dossier that assembles the entire capstone into one professional document.

Setup. Your m9-capstone-build file, your Lesson 1 design document, your three verification artifacts from Lesson 2, Download: Capstone Final Dossier Template, Download: Troubleshooting Flowchart, and the seeded build (from your instructor, a study partner, or the sealed card as described above). Budget roughly: 25 minutes for Part 1, 50 for Part 2, 20 for Part 3, 25 for Part 4.

Part 1 — capture and interpret (two points).

1. Open the healthy build — the one that passed every gate — before any faults are seeded. You are establishing what normal looks like, and Module 8 was blunt about this: you cannot recognize broken without having seen working.
2. Capture point 1, client segment. In Simulation mode with filters set to ARP, DHCP, DNS and ICMP, force a design workstation to re-request its address (toggle its configuration to static and back to DHCP). Step through the event list and record, from the packets themselves: which server answered, and which gateway, mask, resolver and lease duration the acknowledgement carried. Then run a name lookup from that client and record the destination address of the query.
3. Capture point 2, server segment. Repeat with your attention on the server's own port. Record whether the relayed address request arrives, from which source address it arrives (it will not be the client's), and whether the name query from step 2 arrives here and is answered.
4. Write both captures into an evidence table with the five fields — what, where, when, how, finding. Two rows minimum per capture point.
5. Write one paragraph comparing the vantage points: name one thing point 1 could see that point 2 could not, and one thing point 2 could see that point 1 could not. This paragraph is the intellectual content of Part 1; the screenshots are just support.
6. (Optional, and worth it.) Repeat step 2 on your own real machine with Wireshark, using a dhcp or dns display filter, and compare a real exchange with the simulator's. The simulator is a good teacher and an incomplete one; knowing exactly where it simplifies is worth more than another lab.

Part 2 — the fault hunt.

7. Open the seeded build. Read all three tickets before touching anything: scope is often clearer across tickets than within one. Decide, and write down, whether you believe these are one fault or several, and on what basis. You may be wrong; the record of your reasoning is part of the exercise.
8. Work MER-2041 by the nine steps. Gather from the user's words and from the machine. Isolate — the ticket already contains one of the most valuable isolation facts a report can carry, and finding it is your first win. Establish what changed. Rank candidate causes by cost of testing, and test the cheapest first. Capture the evidence before you fix anything. Then one change, with a rollback ready, and verify against the user's actual task, not against a ping.
9. Write the fault report for MER-2041, complete, including the prevention field.
10. Work MER-2042 the same way. Note the difference in scope from the first ticket and let that shape your first move: a fault affecting several users on one side of the office lives somewhere different from a fault affecting one machine. Capture evidence at both points from Part 1 if the symptom suggests a boundary.
11. Write the fault report for MER-2042.
12. (Stretch.) Work MER-2043 and write its report. Take it if you have time; skip it without guilt if you do not — two complete, evidence-backed reports beat three rushed ones.
13. Re-run the full ping matrix after all repairs and compare against the copy you produced in Lesson 2. Any cell that changed and should not have is a side effect you introduced, and it belongs in the report that caused it.

Part 3 — the security review.

14. Walk the twelve-point checklist above against your own repaired build. For each item write: state (pass / fail / not applicable), evidence (the command, output or artifact that supports the state), and — where it fails — a remediation and the residual risk if it is not done.
15. Fix, now, everything you can fix inside the simulator: encrypted privileged-mode secrets on all three devices, unused ports shut down, the native VLAN moved off VLAN 1, wireless settings confirmed, configurations written to startup. Re-run the two required policy checks afterwards, because security changes have side effects like any other change.
16. Rank the remaining findings into must-fix, should-fix and accepted risk, each with a one-line justification aimed at a business owner rather than an engineer.

Part 4 — the dossier.

17. Assemble every section in the table above. Most of it already exists: the design document, the diagrams, the addressing tables, the verification artifacts, the capture evidence, the fault reports, the security review. Assembly is mostly editing, and editing is where a pile of files becomes a document.
18. Write the deviations from design section by comparing your build against your Lesson 1 tables line by line. Every difference gets a reason.
19. Write the executive summary last, in one page of plain language, with no command names and no acronym that is not expanded on first use. If the studio's owner cannot read it, rewrite it — this page is the one they will actually read.
20. Write the handover notes: who owns the network, who to call, where the configurations are backed up, and the first three documents a new administrator should read on day one.
21. Version and date the dossier, put your name on it, and read it once from the beginning as though you had never seen the project.

Deliverable. One dossier — 20 to 30 pages including tables and evidence — containing the design, the as-built record, the verification proof, the capture evidence, two (or three) fault reports, the ranked security review, and the handover notes. This is the capstone artifact. It is also, in almost exact form, the deliverable of a real small-network project, and it is the single best thing you can show somebody who is deciding whether to hire you.

Verify. The dossier is finished when all of these are true:

• Every requirement number from Lesson 1 appears somewhere in the verification section with a result beside it.
• Every claim of policy enforcement is backed by evidence that includes a positive control.
• Every fault report identifies its cause by pointing at a specific piece of captured or commanded evidence, not by assertion.
• Every fault report's prevention field proposes something concrete — a document, a check, a configuration standard.
• The security review's failures each carry a remediation and a residual risk, and the findings are ranked.
• The deviations section is non-empty, or you can state honestly why it is.
• A classmate can read the executive summary and describe what the network does.
• A classmate can read the configuration record and rebuild the network without asking you anything.

If it goes wrong.

• A ticket resists you for more than twenty minutes. Go back to isolation. Write the works/does-not-work boundary as two explicit lists. Most stuck hunts are stuck because the boundary was assumed rather than drawn.
• You fixed it but cannot explain why it broke. That is an incomplete ticket, not a completed one. Reopen the seeded file, reproduce the symptom, capture the evidence you skipped, then fix it again. Being able to make a fault come back on command is the strongest proof of cause there is.
• Two changes went in together and the fault vanished. Undo both, reapply one, and find out. Module 8 named the two things you otherwise never learn: which change fixed it, and what the other change is quietly doing.
• Your security review has no failures. Look harder. A review of a real build with twelve honest checks and zero findings usually means the checks were read rather than run.
• The dossier is enormous and unreadable. Cut evidence into an appendix and keep the body to conclusions with references. Length is not thoroughness; a reader who gives up has learned nothing from your best work.

Check yourself

1. You capture at a client and see its request leave; you capture at the server segment and the request is absent. Before naming any cause, state precisely what the pair of captures proves, what it does not prove, and what your next capture point would be.
2. A colleague submits an incident report whose evidence section reads: "Ran ping after the fix — works now." Explain why that is not evidence of anything about the fault, and name the one circumstance in which a post-fix capture is legitimate evidence.
3. Your matrix records a required FAIL for a guest client reaching an internal segment, but you did not run a positive control. What can you legitimately claim, what can you not, and what is the thirty-second test that closes the gap?
4. Rewrite these two fault-report lines to professional standard, and say what each addition buys: "Cause: the network was misconfigured. Fix: corrected the configuration."
5. A reviewer sees service password-encryption in a switch configuration and marks the "administrative access is controlled" item as a pass. Correct them in two sentences, and name two things that would actually justify the pass.
6. At handover, the studio's owner asks why your dossier contains a page listing everything that could go wrong with the network they just paid for. Give the answer you would actually give.
7. During an incident reconstruction, the router's logs, the switch's logs and the server's logs disagree about when the event occurred. Which security-review item failed, and why does this cost more than it first appears?

Answers

1. It proves that the packet was transmitted by the client onto its segment, and that no matching packet was observed at the server's vantage point under the stated filter and time window. It does not prove where the packet died, nor even that it died — it may have been forwarded somewhere other than the segment you watched, which is a completely different fault from being dropped. The next capture point is the boundary device between them: the router's own interface for that segment, or the trunk carrying it, which tells you whether the packet reached the routed edge at all.
2. The fault no longer exists, so any measurement taken afterwards describes the repaired network and can support no claim about what was wrong. The legitimate exception is a deliberate re-break: reintroduce the fault, capture it, then fix it again — a post-fix capture used as the "after" half of a before-and-after pair, where the "before" was also captured.
3. You may claim that this client could not reach that segment during the test. You may not claim that isolation is working, because a client with no address, a dead port or a wrong passphrase fails exactly the same way. The thirty-second test is to have the same client reach something it should reach — the public web server — from the same session; success there converts every accompanying failure from ambiguity into policy.
4. For example, from an unrelated incident: "Cause: the uplink port on the second-floor switch was running at 100 Mbps half duplex instead of the documented auto-negotiated setting; evidence E-4, the interface status output captured at 09
   , before any change was made." and "Fix: returned that single port to auto-negotiation at 09
   ; the rollback ready was the stage-3 saved file. Verified by having the user complete the file transfer from the original complaint at 09
   , and by re-running the ping matrix: no other cell changed." The additions buy three things: a cause someone else can confirm without trusting you, a change small enough to be undone, and a verification tied to the user's actual task rather than to a convenient network test.
5. service password-encryption applies a trivially reversible obfuscation to stored passwords; it defeats a shoulder-surfer reading the screen and nothing else, so it cannot by itself justify a pass. Two things that would: an encrypted privileged-mode secret (a properly hashed one) unique to that device, and remote administration over SSH rather than Telnet — or remote administration disabled altogether, with console access physically controlled.
6. Because every network has failure modes, and the only choice is whether they are discovered on the page or discovered on a Monday morning. The page tells you what we chose to accept in exchange for the budget — a single link between floors, a single router, one Internet connection — what the consequence of each would be, and roughly what it would cost to remove it later. It is the difference between an outage that is a surprise and an outage that is a decision you already made with your eyes open, and it also means the next person to work on this network inherits your reasoning instead of guessing at it.
7. Item 10 — logging and time — specifically the "every device agrees on the time" half; without synchronized clocks the devices cannot be placed on one timeline. The cost is larger than it sounds because ordering is the whole of causation in an incident: if you cannot say whether the interface went down before or after the configuration change, you cannot say which caused which, and every reconstruction becomes an argument between people reading different clocks. It also undermines evidence generally — timestamps are one of the five fields that make a capture credible.

Key terms

• Capture point (vantage point) — the place a capture is taken; on a switched network it bounds what can possibly be seen.
• Boundary evidence — the pair of captures either side of a suspected failure point; the difference between them is the finding.
• Positive control — a test that must succeed, run beside a test that must fail, so failure proves policy rather than breakage.
• Evidence fields — what, where, when, how (the filter), and the specific finding; a capture missing any of them is a picture rather than proof.
• Documented absence — the recorded fact that an expected packet did not appear, valid only with the filter and duration stated.
• Fault report — the incident record: symptom, scope, evidence, isolation, change, cause, fix, rollback, verification, side effects, prevention.
• Prevention field — the part of a fault report that proposes what would stop recurrence; the difference between repair and improvement.
• Residual risk — what remains after a remediation is applied, or what is accepted when it is not.
• Ranked findings — security review results ordered must-fix / should-fix / accepted, each justified in business terms.
• Deviations from design — the recorded differences between the built network and the designed one, with reasons; what keeps the design document true.
• Known risks — the accepted single points of failure and constraints, written down before they happen.
• Handover notes — ownership, contacts, backup locations, and the first documents a new administrator should read.
• Configuration backup (off-device) — exported configurations stored elsewhere and dated; protects against device death, which copy running-config startup-config does not.

Summary

• One capture point tells you what happened in one place; two capture points either side of a boundary tell you where something stopped — which is why the client segment and the server segment are both worth watching.
• Evidence is a capture with five fields attached: what, where, when, the filter used, and the specific finding it supports. Capture before you change anything, and record absences deliberately.
• A positive control turns an ambiguous failure into proof of policy; without one, a row of failed pings is indistinguishable from a broken client.
• Tickets arrive as symptoms in a user's words. The nine-step method converts them into causes, and the fault report is what makes the conversion auditable by somebody who was not there.
• A fault report without a prevention field records a repair; with one, it records an improvement — and prevention is where documentation, standards and design changes come from.
• The security review is the Module 6 scorecard widened to a whole site: isolation and egress proven with evidence, administrative access controlled, unused ports closed, wireless at the current standard, patching owned, configurations backed up off-device, clocks synchronized, findings ranked for a business reader.
• The dossier answers, in order, every question the owner, the operator and the inheritor will ask — including the two sections beginners skip: deviations from design, and known risks.
• Design, build, verify, inspect, diagnose, secure, document: that sequence is the capstone, and it is also the job.

Next lesson

There is no next lesson — and that is worth a paragraph rather than a full stop.

Look at what you did in this module. You read a client brief and found the questions it did not answer. You designed an addressing plan, chose a topology and defended a bill of materials against a budget. You built five segments across two switches and one router, delivered addresses from a central server across routed boundaries, put an entire studio behind one public address, and enforced two security rules that a business would genuinely depend on. You captured your own traffic, took tickets you had not written, found faults you had not planted, and wrote it all down well enough that a stranger could operate what you built. Nine modules ago you did not know what an IP address was.

Where to go next, in order of usefulness.

Keep the lab. The single strongest habit you can form is to keep building. Rebuild the Meridian network from a blank file next month, from your own dossier and nothing else — you will discover exactly which parts of your documentation are real. Then change one requirement (a sixth VLAN, a second Internet connection, a printer that must be reachable from the guest network under conditions you have to invent) and redesign for it. Cheap second-hand managed switches exist; one of them on a desk, with a laptop and a console cable, teaches things no simulator can. And run Wireshark on your own machine now and then with no goal at all, just to see what your laptop says when you are not looking.

Certify, if it helps you. CompTIA Network+ is the closest formal match to this course's scope — vendor-neutral, foundations-first, and it uses the same troubleshooting logic you learned in Module 8, folded into seven steps instead of nine. If you want configuration depth — routing protocols, switching at scale, the command line as a daily language — Cisco CCNA is the standard next step, and the Packet Tracer skills you have been building since Module 3 are its native environment. Neither certificate teaches you more than you learned here about why; both will push you much further into how, and both are read by employers.

Read the primary sources. You have been citing RFCs all course. Read one all the way through — RFC 1918 or RFC 2131 are approachable — and notice that the documents running the Internet are written in plain, argued prose by people making decisions. That realization changes how you read every technical document afterwards.

Continue in the collection. Two companion courses sit alongside this one in the Turning Point Academy collection; your dashboard lists them, and either is a reasonable next step now that this material is solid.

Finally, the habit that outlasts every technology in this course. When something breaks, resist the first guess. Gather, isolate, ask what changed, test the cheapest suspect, change one thing, verify against the complaint, and write it down. That method was true in Dr. Al-Doori's classroom, it is true in 2026, and it will still be true long after every protocol in these nine modules has been replaced. Everything else was detail. Go build something.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 10, 11, 12, 13, 14 and 15 — the command-line tools, performance and reliability, the troubleshooting procedures, documentation and management, and the two security chapters; the capstone's closing half is these six chapters applied at once.
• CompTIA Network+ certification overview — https://www.comptia.org/certifications/network — the vendor-neutral path closest to this course's scope.
• Cisco Networking Academy — https://www.netacad.com/ — home of Packet Tracer and the CCNA track, both free to start.
• Wireshark User's Guide — https://www.wireshark.org/docs/wsug_html_chunked/ — the capture and display-filter reference behind Part 1.
• RFC 2131, "Dynamic Host Configuration Protocol" — https://www.rfc-editor.org/rfc/rfc2131 — the exchange your client-segment capture reads packet by packet.
• Download: Capstone Final Dossier Template (every dossier section pre-formatted, with the fault-report and security-review forms).
• Download: Troubleshooting Flowchart (the nine-step method and the symptom tables, on one page, for the fault hunt).
• Download: Wireshark Essentials Guide (the display filters worth memorizing before you capture anything).
• Download: Network Documentation Templates (the Module 8 originals behind the dossier's diagram and table sections).