Interpret Network Output and Pick the Next Test

Tier: Core · Workflow area: Troubleshooting & diagnosis · ~30 minutes

The pattern is a tight loop: run a diagnostic, paste the complete output, get an interpretation plus exactly one next command with an explanation of what it tests. The explanation requirement is the safety mechanism — a next-step you cannot articulate the purpose of is a step you should not run.

When to use

• Connectivity triage"can't reach X" tickets where the fault could be adapter, DHCP, DNS, routing, firewall or the far end, and each layer has its own probe.
• Reading unfamiliar outputa traceroute with asymmetric latency, netsh stats, or a Wireshark expert-info summary you see twice a year.
• Teaching the ladderjuniors learn the OSI-ordered elimination sequence fastest when every command arrives with "here is what this tests and what each outcome means."

When NOT to use

• When monitoring already knowscheck the NOC dashboard and current incident list before troubleshooting one user's symptom of a known outage.
• Pasting raw packet capturesfull pcaps are both too large and too sensitive (payloads, cookies, credentials). Summaries and statistics only — never the raw capture.
• Change executionthis loop diagnoses. Config changes to switches, firewalls or DNS go through change management, whatever the chat window thinks of the urgency.

The recipe

1. 1.

   Start with the local baseline and paste it whole. Truncated output is the top cause of wrong interpretations — the model needs the boring lines to rule things out.

   Copy

   ipconfig /all
   Get-NetIPConfiguration -Detailed
   Get-DnsClientServerAddress
   

2. 2.

   Set the loop contract in the first prompt.

   Copy

   I am troubleshooting: user on an office desktop cannot reach
   https://portal.yourco.com (internal app). Browser shows a timeout.
   Other websites load fine. Started after lunch. I will paste diagnostic
   output; you interpret and propose the next test.
   
   Rules:
   - Interpret ONLY what the output shows. Say what is normal as well as
     what is abnormal — ruling out is progress.
   - Propose exactly ONE next command. Format:
     NEXT: <exact command>
     TESTS: <which layer/hypothesis this discriminates>
     IF <outcome A>: <meaning> / IF <outcome B>: <meaning>
   - Read-only diagnostics only. If a fix is implied, describe it but tell me
     to take it through change control.
   - If the output contradicts something we established earlier, flag it.
   
   First output — ipconfig /all from the affected machine:
   [paste]
   

3. 3.

   Follow the chain, one reading at a time. A healthy session walks the stack. Typical exchanges:

   Copy

   Interpretation: adapter has a valid lease (10.20.4.117/22, gateway
   10.20.4.1, lease renewed 13:02 — note: shortly before symptoms began).
   DNS servers are 10.20.0.10/11 — matches your site standard. Nothing
   abnormal at L2/L3 locally.
   NEXT: Resolve-DnsName portal.yourco.com -Server 10.20.0.10
   TESTS: whether internal DNS resolves the app's name from this site's resolver.
   IF it returns the expected internal IP: DNS is fine, move to path/port.
   IF it returns a public IP or NXDOMAIN: split-brain DNS or a stale record —
   that lease renewal timing becomes very interesting.
   

   Then, as the chain continues:

   Copy

   Resolve-DnsName portal.yourco.com -Server 10.20.0.10
   Test-NetConnection portal.yourco.com -Port 443
   tracert -d -w 800 10.20.8.45
   

   Paste each result in full, including successes. When output is long (a 30-hop tracert), paste all of it anyway — the pattern of where latency jumps or stars begin is the entire diagnostic content.

4. 4.

   Bring in capture data as summaries, not packets. If it escalates to Wireshark, export digests instead of the pcap: Statistics → Conversations (copy as CSV), Analyze → Expert Information, or a filtered text export of the relevant TCP stream's headers. Or from the command line:

   Copy

   tshark -r capture.pcap -q -z conv,tcp
   tshark -r capture.pcap -Y "tcp.analysis.retransmission" | head -40
   

   Prompt: "Here is the TCP conversation summary and retransmission lines for the failing connection. What does the handshake pattern indicate — SYN with no SYN-ACK, resets after handshake, or mid-stream stalls — and what does each implicate?"

5. 5.

   Verify the model's readings on the two load-bearing claims. Interpretations are usually right about the obvious and occasionally wrong about the pivotal: check the claimed subnet math with your own eyes, re-count claimed retransmissions with the tshark filter, and confirm any "this firewall behavior means…" claim against your firewall's actual documentation before it drives a change request. Microsoft AI Shell users get the same loop inline in the terminal (Start-AIShell) — convenient, but the verify-the-pivotal-claim habit is identical.

6. 6.

   Close with the chain as the artifact. Ask for the wrap-up: "Summarize the elimination chain: each test, its result, what it ruled out, and the surviving explanation." Paste that into the ticket — it is a ready-made escalation note for the network team, in exactly the evidence-per-claim format pb-04 demands.

Make it yours

• Linux toolkitsame loop with ip a, ip route, resolvectl status, dig +trace, mtr -rw -c 50 <host>, ss -tnp. mtr reports are the best paste-able artifact in networking: one block, whole-path story.
• Firewall-heavy environmentsadd a standing rule: "always consider an intermediate security device dropping or resetting; state the evidence pattern that would indicate it (SYN unanswered vs RST injected vs policy log hit)." Half of enterprise "network" mysteries end there.
• Wi-Fi ticketsstart with netsh wlan show interfaces (RSSI, channel, PHY rate) and add the environment fact the model can't guess: how many users, what building material, when it degrades.

Quality check

• You can state each command's purposebefore running any NEXT, say in one sentence which hypothesis it splits. If you cannot, ask the model to re-explain; if the explanation still doesn't land, do not run it.
• Full outputs, no summarizing on the way inresist "it basically timed out"; the model interprets evidence, not your interpretation of evidence.
• Read-only stays read-onlythe loop's rules ban config changes; enforce that on yourself too. Flush a DNS cache on the affected client, fine; touch a switch port, change request.
• Captures stay sanitizedcapture summaries can still leak internal hostnames and IPs; for hosted models, mask externally-meaningful identifiers, or run the loop on a local model when the topology itself is sensitive.