Prompt Engineering for Network Engineers
Automation & ToolsPrompt Engineering for Network Engineers<br>Tony Mattke<br>2026.07.30<br>11 min read<br>You finally caved and started using Claude. You opened a new chat and typed something like this.<br>prompt<br>My BGP session keeps dropping. How do I fix it?<br>What came back was a CCNA-level checklist. Verify ASN numbers. Check route filters. Confirm connectivity. The kind of answer you’d get from a sales bro who used the Yahoo search plugin on his browser.<br>So you closed the tab, told yourself the LLM hype was overblown, and went back to packet captures.<br>The model can absolutely diagnose a hold timer mismatch on a session that establishes and drops fifteen minutes later. It can walk you through MTU/MSS pathology on an eBGP peering. It knows IOS-XE has a quirky behavior where DSCP markings get stripped on VRF transits. Your first prompt didn’t give it any reason to reach for any of that… so it didn’t.<br>Same model, two prompts.<br>prompt<br>eBGP session on ASR 1002-X, IOS-XE 17.6, peering to Comcast PE.<br>Establishes, holds 10-15 min, drops to Idle. Hold timers default.<br>No interface flaps. Most likely causes?<br>And just like that, without changing models, just by adding enough relevant details, the AI agent feels more like a seasoned engineer. Now you get a ranked list. Hold timer mismatch, with the command to confirm. MTU/MSS on the path, with how to test. Route table churn, prefix limits, carrier-side errors, authentication.<br>This is most of what prompt engineering is. Claude is an expert reasoner with an unreliable memory. Hand it data and its analysis is legitimately senior-level. Ask it to recall exact syntax from thin air and you get a confident coin flip. Every pattern in this post is a way of feeding the reasoner and fencing in the memory.<br>Make it interview you<br>The biggest upgrade to my own prompting was ending prompts with one line…<br>prompt<br>Ask me anything you need to know before answering.<br>A BGP problem has a dozen variables you probably failed to mention. iBGP or eBGP? Route reflector or full mesh? What changed last week? Is the remote end yours or a carrier’s? Leave those out and the model guesses, and every guess dilutes the answer. Invite questions instead and it comes back with the three or four that actually matter, you answer each in a sentence, and the next response is built on your network instead of a hypothetical one.<br>The reason this works is that it flips who carries the burden of completeness. You no longer have to anticipate what’s relevant. The model turns out to be very good at knowing what it’s missing, and it almost never admits that unprompted.<br>Set up the context once, stop typing it forever<br>If you’re going to talk to Claude about your network more than twice, set up a Project. Claude Projects let you attach a block of context that’s invisibly prepended to every conversation in that workspace. Drop it in once, never type it again.<br>Something like this works as a starting file.
Platform mix:<br>Core: Nexus 9300-EX, NX-OS 10.3(2)<br>Access: Catalyst 9200, IOS-XE 17.9<br>WAN: ASR 1002-X, IOS-XE 17.6<br>Firewalls: Palo Alto PA-5220, PAN-OS 10.2
Topology:<br>Two DCs, hub-spoke WAN, 12 remote sites
Constraints:<br>Healthcare/HIPAA. 48hr CAB. Weekend maint.
Naming:<br>[site]-[role]-[number] (DC1-CORE-01)
Give exact CLI for the platform I specify.<br>If unsure about a command, say so.<br>Now when you open a new chat and ask about an issue on DC1-CORE-01, Claude already knows that’s a Nexus 9300 running NX-OS 10.3(2). You stop re-explaining the environment. Claude stops guessing.<br>Custom Instructions can do the same thing, just one layer up, they get applied to every conversation regardless of project. That’s where you tell Claude, “I’m a senior network engineer. Don’t explain basic protocol concepts unless I ask. Skip the safety speech about taking backups unless I’m doing something genuinely dangerous.” Once that’s saved, you stop getting the boilerplate “in production environments you should…” caveats that nobody’s life is short enough for.<br>Structure helps when prompts get long<br>For most messages, plain English is fine. When a single prompt has multiple distinct pieces of context, XML tags keep them separate. Claude was trained on a lot of XML-structured text and it parses the tags as boundaries.<br>xml
NX-OS 10.3(2) on Nexus 9300-EX
Two N9Ks in vPC, 48 downstream access switches
[paste relevant config]
TCNs every 30s on VLAN 200. Two switches flapping.
Hospital. No uplink bounces during business hours.
Without the tags, Claude can conflate your STP output with your VLAN config. With them, the model treats each block as a distinct kind of context and reasons about them separately. It’s the difference between handing someone a stack of papers and handing them a folder with labeled tabs.<br>For genuinely hard problems, turn on extended thinking in the Claude apps and...