Lab 04 · Guided Network Diagnosis

Farhan does field support for an MSP in Bengaluru. This morning a client's payroll officer, Rekha, reports: "Internet is down on my laptop. Google won't load. But email works and the intranet works. Everyone else is fine." Farhan has remote CLI access to the laptop but not to the network gear — so every conclusion has to come from evidence he can gather at the endpoint.

The discipline this lab drills: never let the AI (or yourself) jump from symptom to fix. At each fork, ask "what test distinguishes these two causes, and what would each outcome mean?" — then take the result to the next fork. The scenario contains one true cause, one genuinely broken-but-irrelevant component, and several dead ends that look like the answer.

Time & tier

~60 minutes hands-on · Core tier (maps to module M2). $0 — any free AI chat and a text editor. All command outputs are provided inline; you reveal them to yourself (and the AI) only when a step legitimately calls for that command.

Setup

Save the block below as outputs.txt. Rule of the game: you may only "run" a command by copying its output from this file after you (or the AI) have named it as the next diagnostic step and said why. No reading ahead — the point is the path, not the destination.

--- C:\> ipconfig /all  (LAPTOP-REKHA, excerpt) ---
   IPv4 Address. . . . . . . . . . . : 10.50.22.147
   Subnet Mask . . . . . . . . . . . : 255.255.254.0
   Default Gateway . . . . . . . . . : 10.50.22.1
   DHCP Server . . . . . . . . . . . : 10.50.1.5
   DNS Servers . . . . . . . . . . . : 10.50.1.10
                                       10.50.1.11
--- C:\> ping 10.50.22.1 ---
   Reply from 10.50.22.1: bytes=32 time=1ms TTL=255   (4/4 received)
--- C:\> ping 8.8.8.8 ---
   Reply from 8.8.8.8: bytes=32 time=28ms TTL=115     (4/4 received)
--- C:\> nslookup www.google.com ---
   Server:  dc01.client.local   Address:  10.50.1.10
   Non-authoritative answer:
   Name: www.google.com   Addresses: 142.250.183.68
--- C:\> nslookup www.google.com 10.50.1.11 ---
   DNS request timed out. timeout was 2 seconds. *** Request to 10.50.1.11 timed-out
--- C:\> tracert -d -h 6 8.8.8.8 ---
   1 1ms 10.50.22.1   2 2ms 10.50.0.1   3 9ms 100.72.16.1   4 24ms 72.14.204.62   5 27ms 8.8.8.8
--- C:\> curl -s -o NUL -w "%{http_code}\n" https://www.google.com ---
   200
--- C:\> curl -s -o NUL -w "%{http_code}\n" http://intranet.client.local ---
   200
--- Browser (Edge): https://www.google.com ---
   ERR_PROXY_CONNECTION_FAILED  "There is something wrong with the proxy server"
--- C:\> netsh winhttp show proxy ---
   Current WinHTTP proxy settings:  Direct access (no proxy server).
--- Edge -> Settings -> System -> Proxy (via GPO, greyed out) ---
   Use setup script: On
   Script address: http://config.client.local/proxy.pac
--- C:\> curl -s http://config.client.local/proxy.pac ---
   function FindProxyForURL(url, host) {
     if (dnsDomainIs(host, ".client.local")) return "DIRECT";
     return "PROXY 10.50.7.20:8080";
   }
--- C:\> curl -s -o NUL -w "%{http_code}\n" --connect-timeout 5 -x http://10.50.7.20:8080 https://www.google.com ---
   000   (curl: (7) Failed to connect to 10.50.7.20 port 8080: Connection refused)
--- C:\> curl -s -o NUL -w "%{http_code}\n" --connect-timeout 5 -x http://10.50.7.25:8080 https://www.google.com ---
   200
--- MSP change calendar (Saturday) ---
   CHG-4471: Decommission legacy proxy PRX-OLD (10.50.7.20). Replacement
   PRX-NEW (10.50.7.25) live since June. Task "update proxy.pac" - status: OPEN.
--- Helpdesk note ---
   "Everyone else is fine" - checked: other users in Rekha's office are on
   the wireless VLAN, which gets proxy settings from a different PAC URL.

Guided steps

1. 1Frame the differential before touching outputs. Give the AI only the symptom sentence ("Google won't load in the browser; email and intranet work; ping unknown; one user affected as far as we know") and ask: "List the 5–7 candidate causes for this symptom pattern, ordered by prior probability, and for the top two, name the single cheapest test that discriminates between them." Record its list in transcript.md.
2. 2Run the layered basics. Whatever the AI proposed, the defensible opening is L3 connectivity and name resolution: reveal ipconfig /all, ping gateway, ping 8.8.8.8, nslookup www.google.com. Log each as a transcript row: hypothesis under test · command · result · what is now eliminated. Expected elimination after this step: IP config, gateway, raw internet routing, and primary DNS are all not the cause.
3. 3Confront the tempting detour. The nslookup against 10.50.1.11 times out — a genuinely broken thing. Ask the AI: "Secondary DNS is dead. Does that explain the symptom? What would we see if it did?" Force the explicit reasoning: primary DNS answers, resolution works, so this is real-but-irrelevant to this ticket. Log it as a follow-up item, not a cause — and note whether the AI tried to close the case here.
4. 4Split browser from transport. The killer discriminating test in this scenario: curl to the same URL the browser fails on. Reveal both curl 200s and the browser's ERR_PROXY_CONNECTION_FAILED. Ask the AI what it means when curl (which ignores the system PAC by default) succeeds while the browser fails, and what the next discriminating test is. Expected answer family: the path difference is proxy configuration.
5. 5Follow the proxy chain. Reveal netsh winhttp show proxy, the GPO proxy-script setting, then fetch the PAC file. Transcript row: what the PAC says, and why intranet works (DIRECT for .client.local) while external sites die (all sent to 10.50.7.20:8080).
6. 6Prove the dead proxy, then prove the fix. Reveal the two -x curl tests: refused via 10.50.7.20, 200 via 10.50.7.25. Then reveal the change-calendar entry. You now have mechanism and provenance: PRX-OLD decommissioned Saturday, PAC update task still OPEN. Ask the AI to state the root cause in one sentence and check it names the PAC file, not the proxy hardware.
7. 7Explain the "everyone else is fine" anomaly. A root cause that cannot explain why only Rekha is hit is incomplete. Use the helpdesk note; log the explanation (wired VLAN PAC vs wireless PAC) as the final elimination.
8. 8Close the transcript. Finish transcript.md with: root cause (one sentence) · fix (immediate: point PAC at 10.50.7.25; systemic: close CHG-4471's open task, add PAC to decommission checklists) · blast radius (who else is on the wired-VLAN PAC and silently one reboot away from the same call) · the two dead ends you rejected and the test that killed each.

Verify

• •
  transcript.md has one row per step with all four fields: hypothesis · test · result · elimination.
• •
  No output was used before its command was justified in the transcript (self-policed, but the row order shows it).
• •
  The secondary-DNS failure appears as unrelated-but-actionable, with the reasoning, not as the cause.
• •
  The curl-vs-browser split is explicitly interpreted (what curl not reading the PAC proves).
• •
  The final root cause names the stale PAC entry and cites CHG-4471's open task; the fix has both an immediate and a systemic component.
• •
  The single-user anomaly is explained, and blast radius is stated.

Self-grading rubric (pass = 7/10): correct root cause with mechanism (0–2) · every step has a stated discriminating purpose (0–3) · secondary-DNS decoy handled correctly (0–2) · systemic fix + blast radius (0–2) · dead ends documented with their killing test (0–1).