Foundations capstone: explain one request path clearly
By the end of this module you will be able to:
- Write a short diagnosis note that names the symptom, the first failed function, one observable, and one safe next test
- Distinguish between a symptom report and a diagnosis
- Apply the layer model to turn vague problem descriptions into actionable investigation steps
- Narrate one whole request path, from the Wi-Fi association to the first byte, naming the evidence available at each checkpoint
A clear request-path diagnosis is an evidence chain
Symptom, hypothesis, evidence and next step are joined by connectors reading propose, prove and act, so a note that skips the evidence card is left offering a conclusion nobody else can check.
A clear diagnosis note carries a symptom, one named hypothesis, the evidence that supports or refutes it, and the next safe test.
10.1 The four-part diagnosis format
Every diagnosis note follows the same structure. Four parts, each one sentence:
1. Symptom.What the user reported or what you observed. Stick to facts, not interpretation. "Users report that login.company.com returns a connection timeout."
2. First failed function.Which communication function stopped working first? Name the layer. "TCP connections to port 443 on 10.2.1.50 are timing out. DNS resolves correctly. The failure is at Layer 4 (Transport)."
3. One observable.What specific evidence supports your conclusion? Give a command and its output. "Running telnet 10.2.1.50 443from the affected VLAN returns no response after 20 seconds. The same command from the server VLAN succeeds in under 1 second."
4. One safe next test.What should someone check next to confirm or narrow the diagnosis? "Check the firewall rules between VLAN 100 and VLAN 200 for port 443 traffic. A recent change may have blocked it."
That is the entire format. Four sentences. Symptom, failed function, evidence, next step. Anyone reading it knows what broke, where it broke, how you know, and what to do about it.
Written out cold, the four parts look obvious. They are much less obvious under pressure, so the rest of this module is practice: three incidents put through the format, a comparison with a note that skips it, and one full request path narrated checkpoint by checkpoint.
10.2 Worked examples
Here are three scenarios. Each one starts with a vague report and ends with a four-part diagnosis note.
Scenario A: "The website is down."
Symptom: Users in the London office cannot load app.company.com. Users in the New York office can load it fine.
First failed function:DNS resolution for app.company.com returns SERVFAIL from the London DNS resolver (10.1.1.5) but succeeds from Google's 8.8.8.8. The failure is at Layer 7 (Application, DNS).
Observable: nslookup app.company.com 10.1.1.5 returns SERVFAIL. nslookup app.company.com 8.8.8.8 returns 203.0.113.50.
Next test: Check the London DNS resolver (10.1.1.5) for service health and whether it can reach the authoritative nameserver for company.com.
Scenario B: "My email is not sending."
Symptom:A user's email client shows "connection failed" when trying to send via mail.company.com on port 587.
First failed function: TCP connection to mail.company.com:587 is refused. DNS resolves correctly. The failure is at Layer 4 (Transport).
Observable: telnet mail.company.com 587returns "Connection refused" immediately (TCP RST). Port 587 is not listening.
Next test: Check the mail server. Is the SMTP service running? Did it crash? Is it listening on a different port?
Scenario C: "The VPN is slow."
Symptom: Large file transfers over the VPN hang after a few seconds. Small web requests work fine.
First failed function:Packets exceeding the VPN tunnel's effective MTU are being dropped. The failure is at Layer 2/3 (Data Link/Network, MTU).
Observable: ping -s 1400 -M do vpn-server succeeds.ping -s 1500 -M do vpn-serverfails with "Message too long." The effective MTU is between 1400 and 1500 bytes.
Next test: Binary search the MTU (try 1450, then 1425 or 1475) to find the exact threshold. Then check whether the VPN tunnel configuration accounts for encapsulation overhead.
Each of those three notes names a layer and pins it to a command output, which is what makes them auditable by someone who was not there. The quickest way to see why that matters is to read a note about the same incident written without the format.
10.3 What bad diagnosis notes look like
Compare these two notes for the same incident:
Bad:"The website is down. We need to restart the web server."
Good:"Users in London cannot load app.company.com (timeout). DNS resolution fails from the local resolver (10.1.1.5) but succeeds from 8.8.8.8. nslookup confirms SERVFAIL from 10.1.1.5. Check the resolver service and its connectivity to the authoritative nameserver."
The bad note describes a symptom and jumps to a solution without evidence. It skips the diagnostic process entirely. Restarting the web server will not fix a DNS resolver problem. Someone following the bad note wastes time on the wrong system.
The good note follows the four-part format. Anyone reading it knows the symptom (London users, timeout), the failed function (DNS, Layer 7), the evidence (nslookup output), and the next step (check the resolver). No expertise is assumed. No time is wasted.
Writing skill is not what separates the two. The bad note skipped the evidence step and jumped to a fix, and notes fail in a small number of recognisable ways like that one. Four of them account for most of the damage.
Common misconception
“A diagnosis should include the fix.”
A diagnosis identifies the failure. A fix addresses it. These are separate steps. If you jump to a fix before confirming the diagnosis, you risk solving the wrong problem. The four-part format stops at 'next test' deliberately. Confirm first, then fix.
10.4 Pitfalls to avoid
Starting at the wrong layer.If a user says "the app is slow," it is tempting to start investigating the application server. But if the problem is a DNS resolver adding 2 seconds of latency, or a TLS certificate verification taking an extra round trip, the application server is fine. Always verify the lower layers before blaming the higher ones.
Using vague language."Something is wrong with the network" is not a diagnosis. Name the layer. Name the protocol. Give a specific command and its output. If you cannot be specific, you have not finished investigating.
Confusing symptoms with causes."DNS is returning SERVFAIL" is a symptom. "The DNS resolver cannot reach the authoritative nameserver because port 53 is blocked by a new firewall rule" is a cause. The four-part format separates these cleanly: the symptom goes in part 1, the likely cause goes in parts 2 and 3, and the confirmation goes in part 4.
Running too many tests at once.Change one variable at a time. If you switch DNS servers and change the VLAN simultaneously, you will not know which fix resolved the problem. The "one safe next test" in part 4 is singular for a reason.
The first and third of those, starting at the wrong layer and mistaking a symptom for a cause, are the same error: joining the request path halfway along and treating whatever you find there as the beginning. The cure is to be able to narrate the whole path first, so you know which checkpoints exist before you decide which one failed.
One request path, with the evidence checkpoint at every hop
Every checkpoint from the radio to the response carries the observable a learner could collect there, so a narration advances only as far as the evidence in hand and the first missing observable names the failed function.
A capstone narration walks six checkpoints from the radio to the response, and names at each one the observable you could collect there, which is what turns a story into the module's four part diagnosis note.
10.5 Narrating one path end to end
Here is the whole path for one ordinary request: a laptop on office Wi-Fi opening https://shop.example.com. Six checkpoints, each with an observable you can collect before you form an opinion.
Checkpoint 1, the radio. The laptop associates with an and shares that radio with every other device the access point serves. Evidence: signal strength and the negotiated data rate on the client, plus the association and retry counters on the access point. A weak signal or a high retry rate slows this request without touching anything above it, and a laptop that has just walked between access points may have re-associated mid-request.
Checkpoint 2, the addresses. The laptop needs a usable address on each family it will attempt. IPv4 comes from a DHCP lease; IPv6 usually comes from a router advertisement, with the host building its own address by SLAAC. Evidence: ip address show or ipconfig /all. A host holding a 169.254 address has no IPv4 lease; a host with only a link-local fe80:: address has no usable IPv6 prefix, and neither state is visible from the application.
Checkpoint 3, the name. The resolver is asked for shop.example.com and returns whatever it holds: an AAAA record, an A record, or both. Evidence: dig AAAA shop.example.com and dig A shop.example.com, run against the resolver the laptop is actually using rather than a public one.
Checkpoint 4, the race. On a network the client does not pick one family and hope. It runs : it starts the IPv6 connection first, and if no answer arrives within a short delay it starts the IPv4 attempt alongside it and uses whichever completes first. RFC 8305 puts the recommended delay at 250 milliseconds. Evidence: the remote address on the established socket, from ss -tnor the browser developer tools. This is the checkpoint people skip, and skipping it is how a broken IPv6 path gets recorded as "the site is a bit slow" for months.
Checkpoint 5, the transport. Whichever family won, a connection has to open: a TCP handshake, or a QUIC handshake over UDP 443 if the client and server both offer HTTP/3. Evidence: ss -tn state established for TCP, or the protocol column in developer tools. A connection that never leaves SYN-SENT is a different failure from one that opens and then stalls.
Checkpoint 6, the response. TLS completes, the request goes, and the first byte comes back. Evidence: the status code and the time to first byte. Only here can you honestly say the application answered.
Now write the note. "Users on the second-floor wireless report that shop.example.com is consistently slower to load than it is for wired users on the same site, on every request rather than occasionally. The name resolves to both an AAAA and an A record. Sockets to the AAAA address never reach established, and the browser reports the IPv4 address on every successful load. The first failed function is IPv6 reachability at Layer 3, not the application. Next test: ping the site's IPv6 address from the wireless VLAN and from the wired VLAN, and compare." That note names a checkpoint, not a feeling.
Common misconception
“IPv6 is experimental. We will deal with it when something forces us to.”
IPv6 is the present, not a pilot. Google measured 50.10 percent of its worldwide users reaching it over IPv6 on 28 March 2026, and APNIC Labs measures India and France above 70 percent IPv6 capability. Because clients try IPv6 first, a half-broken IPv6 path does not sit idle and unnoticed: it becomes a delay on every request that races it. A diagnosis note that never says which address family carried the connection has skipped a checkpoint.
Wireless users report that one site loads slowly. The name returns both an AAAA and an A record, and every successful connection ends up on the IPv4 address. What is the most likely first failed function?
Which observable belongs to the address checkpoint rather than the name checkpoint?
A laptop user on Wi-Fi reports that a download stalled for a few seconds in the middle. Wired users on the same site saw nothing. Which checkpoint should you collect evidence from first?
10.7 What comes next
You have completed the Foundations stage. You now have the vocabulary (layers, PDUs, identifiers), the process (encapsulation, local versus remote delivery, addressing on both families, the request path), and the practical skill (four-part diagnosis notes anchored to checkpoints).
The Applied stage opens each of those checkpoints in turn. TCP reliability and congestion control explain what the transport is doing between the handshake and the first byte. DNS, routing, NAT and the IPv6 transition explain how the name and the addresses were produced. TLS explains what the encrypted part protects. The stage ends with a repeatable troubleshooting method that assumes you can already name the layers, use the correct PDU terms, and narrate a path from URL to first byte.
If any of those feel shaky, revisit the specific module before moving on. The Foundations practice test (available from the course overview) covers all ten Foundations modules and will show you which areas need a second pass.
Core distinctions
- A diagnosis note has four parts: symptom, first failed function (with layer), one observable (command + output), and one safe next test.
- Symptoms are not causes. 'DNS returns SERVFAIL' is a symptom. 'The resolver cannot reach the authoritative nameserver' is a cause. The format separates them.
- Change one variable at a time. If you fix two things simultaneously, you cannot say which one resolved the problem.
- Start low, work up. Verify each layer before moving to the next. Most network problems live at Layers 1 through 3.
- Narrate the path before you diagnose it: radio, addresses, name, the IPv6 and IPv4 race, transport, response. Each checkpoint has its own observable, and a note that names none of them is a feeling.
Standards and sources cited in this module
RFC 1122, Requirements for Internet Hosts: Communication Layers
Section 3.3.1, Local/Remote Decision
The local vs remote delivery decision underpins the troubleshooting approach taught in this capstone. Referenced throughout the Foundations stage.
ISO/IEC 7498-1:1994, Open Systems Interconnection Basic Reference Model
Clause 5, Architecture principles
The layer model that provides the vocabulary for diagnosis notes. Referenced throughout the Foundations stage.
RFC 8305, Happy Eyeballs Version 2: Better Connectivity Using Concurrency
Section 5, Connection Attempt Delay
Defines the staggered IPv6-first connection race described at the fourth checkpoint in Section 10.5, including the recommended 250 millisecond connection attempt delay.
IPv6 adoption among Google users, measured 28 March 2026
Source for the 50.10 percent figure in the misconception card in Section 10.5. It measures the share of Google's own users who reach it over IPv6.
Per-economy IPv6 capability
Source for the statement that India and France exceed 70 percent IPv6 capability, used in the same misconception card.
CompTIA Network+ N10-009 Exam Objectives
Domain 5.0, Network Troubleshooting (24% of exam)
The troubleshooting domain expects systematic layer-by-layer diagnosis. The four-part format aligns directly with this objective.
You have completed the Foundations stage. The Applied stage begins inside the transport checkpoint you have just been narrating: how TCP tracks every byte with sequence numbers, why a new connection starts slowly, and what TCP actually guarantees as against what people assume it guarantees.
Module 10 of 45 · Foundations · Stage complete