A switch-to-switch uplink screams at 90+ Mb/s in one direction and crawls at barely 2 Mb/s in the other — same cable, same ports, no QoS in sight. Everyone suspects a failing cable. The interface counters on the two ends disagree in a very specific way. Three hypotheses and the Claude prompt that names the culprit in one line.
You are using 10% of Claude. The other 90% is setup, not talent — six operator moves (context files, real-file grounding, plan-first, skeptic review, guardrails) that turn Claude from a chatbot into a teammate.
$ claude # most use 10% of it
[ ] context file ← stop starting cold
[ ] real files wired ← grounded > guessing
[ ] plan-first + skeptic review
✓ tutorial level → operator
We audit a representative AI-generated BGP config of the kind posted to r/networking every week. The session establishes, the output looks clean — and it advertises nothing, black-holes half your traffic, and risks a route leak. Here is the line-by-line teardown and the corrected config.
router bgp 65001
network 10.0.0.0 [!] no mask
neighbor … iBGP [!] no next-hop-self
neighbor … eBGP [!] no filters
verdict: comes up, black-holes traffic
A representative AI-generated pfSense NAT config of the kind pasted in for "quick help." The port forward works perfectly — and it also exposes RDP to the entire internet, because the autogenerated firewall rule did exactly what it was told. The line-by-line teardown and the config that should have shipped instead.
NAT ▸ Port Forward (from an AI)
Source: any [!] the internet
Dest WAN:3389 → 192.168.10.10
+assoc rule: WAN any → :3389 PASS
verdict: RDP on the internet
An app server lost its database the instant the DB was migrated to a new IP — and DNS pointed at the right place the entire time. A two-hour outage caused by one line in a hosts file, added as a "temporary" override in 2018. The post-mortem: the false lead, the tell, the fix, and the Claude prompt that would have ended it in five minutes.
14:02 db migrated → 10.0.6.40
14:03 app01: connection refused
nslookup db.corp → 10.0.6.40 (right!)
app still connects to 10.0.6.12
[!] hosts file pinned it since 2018
Logins failing building-wide, services throwing errors, the identity team in a war room — and the domain controllers were up, replication was healthy. The root cause was a 47-minute clock skew on the PDC emulator and Kerberos doing exactly what it is designed to do. The post-mortem: the false lead, the tell, the fix, and the prompt that names it.
08:31 auth failing: OWA/VPN/shares
DCs up · replication healthy
every error: KRB_AP_ERR_SKEW
w32tm offset +2847s on the PDC
[!] clock drifted 47m; Kerberos >5m = no
A field-tested playbook for moving from Cisco ASA to pfSense — the security-level trap that breaks one-to-one ACL translation, NAT and VPN mapping, the AnyConnect problem, gotchas, and a rollback plan. Plus the Claude prompt that does the line-by-line translation.
CISCO ASA → pfSense
security-level → (none)
access-list → Firewall ▸ Rules
nat (inside,out) → Firewall ▸ NAT
[!] ASA trusts by level; pfSense does not
Moving from FortiGate to OPNsense means unbundling one of FortiGate's all-in-one firewall policies into the separate rule, NAT, and inspection objects OPNsense uses — and rebuilding the SD-WAN and UTM behavior people forget they turned on. The conceptual map, the policy-unbundling trap, gotchas, a rollback plan, and the Claude prompts that do the translation.
A TCP session completes the handshake, pushes exactly one byte, gets the ACK — then the next segment vanishes and the connection hangs forever. The same two hosts work fine for everyone on the LAN. The capture, three hypotheses, and the Claude prompt that names it in one shot.
$ ssh app01 # hangs after connect
[ok] SYN / SYN-ACK / ACK
[ok] 1-byte push ACKed
[!!] 1460B [DF] retrans ×5, no ACK
tell: MTU black hole → clamp MSS
A server is reachable for thirty seconds, then gone for thirty, in a near-perfect cycle. Reboots and cable swaps do nothing. The ARP table holds the answer: two MAC addresses are fighting over one IP. The capture, three hypotheses, and the Claude prompt that ends the war.
$ ping 10.0.4.50 # up...down...up
arp -a → 10.0.4.50:
00-1a-2b-3c-4d-5e then…
00-50-56-9a-11-22 same IP!
tell: duplicate IP — last ARP wins
A new server answers ping perfectly in both directions, but every TCP connection dies right after the SYN. ICMP is happy; the handshake never finishes. The capture, three hypotheses, and the Claude prompt that finds the firewall you forgot was in the path.
$ ping 10.20.5.10 # 0% loss
$ curl :443 # hangs
SYN → out via fw-A
SYN-ACK ← via fw-B → no state → DROP
tell: asymmetric routing + stateful fw
Half the laptops on a floor pull a normal lease; the other half land on 169.254 with no internet. Everyone is hunting a rogue DHCP server. The switch counters say the real server is being silenced by the very feature meant to protect it. Three hypotheses and the Claude prompt that calls it.
ipconfig → 169.254.18.44 (APIPA)
next switch → 10.30.3.x fine
snooping drops (untrusted): 4012↑
uplink Gi1/0/48 Trusted: NO
tell: you blocked your own DHCP
We gave three AI models the same dual-homed eBGP task — advertise one /24, prefer one ISP, and do not become a transit AS. Here is the scoring rubric, Claude's full config, and the one line that turns a working config into a route leak.
$ ai "dual-homed eBGP · no transit"
[✓] neighbors AS64500 / AS64501
[✓] originate 192.0.2.0/24
[✗] outbound filter MISSING
[!] route leak in one missing line
We gave three AI models the same automation task — back up the running-configs of 50 switches with Netmiko — and scored the output against the failures that actually bite: hardcoded credentials, swallowed exceptions, and the devices a script silently skips. The rubric, Claude's real script, and how to grade your own run.
$ ai "netmiko: back up 50 switches"
[✓] connects & pulls config
[✗] password="Cisco123" hardcoded
[✗] except: pass → silent skips
[!] "works" on 50, backs up 47
A 28-minute network outage caused by a $19 unmanaged switch, a single line of "fix-it" config from 2019, and a backup job. The full post-mortem — symptoms, false leads, the tell that cracked it, the fix, and the Claude prompt that would have saved 15 minutes.
03:14 ALERT ping loss 47% · all VLANs
03:14 ALERT core cpu 98% · mac-flap 2400/s
03:31 "why is bpdufilter set on Gi1/0/14?"
03:33 RESOLVED port [BLK] · cpu 5%
[!] root cause: rogue switch + bpdufilter
Same DNS server, same subnet, same patches — one user's lookups fail and yours do not. The capture, three hypotheses, the reveal, and the Claude prompt that finds it in one shot.
Paid tools are great. Free tools solve 80% of real problems and run on every machine you already own. Here are five free network troubleshooting tools every admin should be able to drive cold — what each one does, when to reach for it, and the one limitation that bites you.
[1] Wireshark → every packet on the wire
[2] Nmap → who is on my network
[3] iperf3 → is this link actually fast?
[4] LibreNMS → what happened over time
[5] MTR → where exactly the path dies
When DNS breaks, everything looks broken — but the real cause is rarely obvious. This step-by-step guide takes you from "the internet is down" to root cause using nslookup, dig, and a handful of resolver checks.
$ dig @192.168.1.1 corp.local +stats
;; ANSWER SECTION:
corp.local. 60 IN A 10.0.4.20
;; Query time: 412 ms ← way too slow
↳ check resolver upstream chain
A saturated WAN feels like the entire network is broken — but the cause is usually one app, one host, or one runaway backup. This step-by-step guide takes you from "everything is slow" to the exact source using interface stats, NetFlow, DPI, and Wireshark.
Firewall rulebases grow until nobody remembers what half the entries do — and the audit nobody wants to run is the one that finds the holes. AI changes the math. Here are five prompts that turn Claude into a tireless firewall reviewer, plus the privacy guardrails to keep you safe.
$ claude --review fw.conf
[!] rule 14 shadowed by rule 9
[!] rule 22 permits any/any
[+] suggest: tighten src to 10.0.0.0/8
audit complete · 3 high · 5 med
Stop hand-writing configs. Learn how to use AI tools like ChatGPT and GitHub Copilot to generate accurate Cisco IOS, Junos, and MikroTik configurations in seconds.
$ claude "VLAN 10 guest, Gi0/1 access"
[+] vlan 10
[+] name GUEST_WIFI
[+] interface Gi0/1
[+] switchport mode access
Done. Config ready to paste. ✓
Packet loss kills voice calls, video, and file transfers — but the cause is rarely obvious. This step-by-step guide walks you from complaint to root cause using ping, traceroute, switch commands, and Wireshark.
A systematic methodology for diagnosing slow networks — from end-user complaint to root cause. Covers ping, traceroute, packet capture, interface stats, and common fixes.