Foundations capstone: explain one request path clearly

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 443 from 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.

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 587 returns "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-server fails 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.

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.

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.

You have completed the Foundations stage. You now have the vocabulary (layers, PDUs, identifiers), the process (encapsulation, local vs remote delivery, the request path), and the practical skill (four-part diagnosis notes).

The Applied stage builds on this foundation. Module 9 covers how TCP provides reliability and flow control. Module 10 covers DNS resolution in practice. Modules 11 through 16 cover UDP, QUIC, routing, NAT, TLS, and a complete troubleshooting method. Each one assumes you can already name the layers, use the correct PDU terms, and trace a request 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 eight modules and will show you which areas need a second pass.