Prompt Engineering for Network Engineers

You finally caved and started using Claude. You opened a new chat and typed something like this.

My BGP session keeps dropping. How do I fix it?

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.

So you closed the tab, told yourself the LLM hype was overblown, and went back to packet captures.

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.

Same model, two prompts.

eBGP session on ASR 1002-X, IOS-XE 17.6, peering to Comcast PE.
Establishes, holds 10-15 min, drops to Idle. Hold timers default.
No interface flaps. Most likely causes?

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.

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.

Make it interview you

The biggest upgrade to my own prompting was ending prompts with one line…

Ask me anything you need to know before answering.

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.

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.

Set up the context once, stop typing it forever

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.

Something like this works as a starting file.

Platform mix:
Core: Nexus 9300-EX, NX-OS 10.3(2)
Access: Catalyst 9200, IOS-XE 17.9
WAN: ASR 1002-X, IOS-XE 17.6
Firewalls: Palo Alto PA-5220, PAN-OS 10.2

Topology:
Two DCs, hub-spoke WAN, 12 remote sites

Constraints:
Healthcare/HIPAA. 48hr CAB. Weekend maint.

Naming:
[site]-[role]-[number]  (DC1-CORE-01)

Give exact CLI for the platform I specify.
If unsure about a command, say so.

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.

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.

Structure helps when prompts get long

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.

<platform>
NX-OS 10.3(2) on Nexus 9300-EX
</platform>

<topology>
Two N9Ks in vPC, 48 downstream access switches
</topology>

<config>
[paste relevant config]
</config>

<symptoms>
TCNs every 30s on VLAN 200. Two switches flapping.
</symptoms>

<constraints>
Hospital. No uplink bounces during business hours.
</constraints>

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.

For genuinely hard problems, turn on extended thinking in the Claude apps and tell it to think the problem through before answering. The model does more internal work before it commits to a response. If you live in Claude Code, ultrathink is a literal keyword that buys a bigger reasoning budget. Either way, save it for the problems where the obvious answer is wrong. Asymmetric routing tangled up with vPC, HSRP, and PBR all interacting. STP misbehavior across a multi-vendor vPC domain. Any time you’ve already ruled out the first three things that come to mind.

How to make Claude dumber

Three habits will reliably make the model less useful, and yes, I’ve done all of them…

Leading the witness. “I think it’s an MTU problem, can you help me troubleshoot?” Claude will agree with you and build its whole investigation around MTU, even if the symptoms point somewhere else. Present the symptoms and the data, hold your theory back, and let the model reach its own conclusion. If it lands where you already were, fine, you were right. If it lands somewhere else, you’ve maybe just learned something.

Pasting the world. 500 lines of show tech-support with “what’s wrong here?” attached is a recipe for the model latching onto whatever looks most anomalous, which is often a cosmetic counter, not the actual problem. Be surgical. Paste the specific command output that’s relevant. Tell Claude what to look at. “Here’s show spanning-tree vlan 200 from two switches, look at port roles and uplink states.”

Asking for “best practices.” “What are the best practices for OSPF design?” returns the textbook answer that applies to no real network. Replace “best practices” with your actual scenario. “I have a 15-site WAN, NX-OS hub, IOS-XE spokes. Should I keep everything in area 0, or break out areas per region?” Now you’re asking a question that has a real answer.

One more failure mode. Claude states fabricated commands with the same confidence as established ones. I have absolutely typed show ip igmp snooping membership into a Nexus and watched it complain at me, only to realize I’d accepted that command from a chat session two weeks earlier without verifying. Add to your custom instructions. “If you’re unsure a command exists on this platform, say so.” Then verify with ? on the CLI anyway. Trust the reasoning, verify the syntax.

Trust this, verify that

Things Claude is genuinely good at. Parsing show output, generating config from a detailed spec, translating between vendor syntaxes (ASA to Palo, IOS to NX-OS), writing MOPs and rollback procedures, reasoning about failure scenarios, explaining protocol mechanics, and producing serviceable Python/Ansible/regex for network automation tasks. For all of that, the bottleneck is the quality of context you give it, not the model.

Things to verify before you paste into a terminal. Any command that involves a feature you haven’t personally used (these are where the fabricated commands live), anything that depends on IOS vs IOS-XE vs IOS-XR (the model conflates them sometimes), Arista/Palo/Fortinet specifics in older codebases, hardware-generation-dependent scaling numbers, and any time you’re asked to take an RFC behavior at face value over a specific vendor’s implementation of that RFC.

The pattern is consistent. The model reasons well from the data you give it. It also confidently fills gaps it shouldn’t. Treat its analysis as expert. Treat its specific syntax claims as a draft that needs a ? confirmation.

One more guardrail that earns its keep. When Claude diagnoses something in a config you pasted, make it commit!

Point to the exact line that causes this.

A model that’s actually reasoning from your config will quote line and verse. A model that’s pattern-matching from its training data gets suddenly vague, and that vagueness is your tell to push back before you bounce an interface over a hunch.

Templates worth saving

A handful of prompt shapes I keep going back to. Steal whichever ones are useful, paste them into a Project, or just bookmark this section.

Troubleshooting from real output.

I'm seeing [symptom] on [platform/version]. Here's [show command]:
[paste]
Rank causes by likelihood, tell me what to check next.

Config generation.

Generate [feature] config for [platform/version].
Specifics: [details].
Just the config, no explanation.

Config review.

Review this [platform/version] config for errors and security gaps.
State the risk and the fix for each.

Cross-vendor translation.

Translate this [source platform] config to [target platform].
Preserve intent. Flag anything without a 1:1 equivalent.
Output as a comparison table.

Show command analysis.

Parse this [show command] from [platform/version].
Assume I can read it. Only flag anomalies.

Design decision (stop asking for the answer, ask for the tradeoffs).

I'm deciding how to [problem]. Give me three approaches.
For each: what it costs, where it bites at 2 AM,
and when you'd pick it anyway.

Design review (extended thinking earns its keep here).

Here's my design: [describe].
Your job is to break it.
What fails first? What's the blast radius? What did I miss?

MOP generator.

Write a MOP for [change] on [device].
Pre-checks with expected output, change steps, post-validation, rollback.

Automation script.

Python script using [Netmiko/NAPALM] that [task] for [platform].
Include error handling and a dry-run mode.

One-line directives that punch above their weight

Short phrases that change output quality more than they should. Sprinkle into any prompt where the default response isn’t getting you what you want.

• Think hard about this before answering. Slower, deeper reasoning on multi-variable problems. In Claude Code, ultrathink is a literal keyword that does the same thing.
• Skip the overview. I know how OSPF works. Jumps past textbook explanations.
• Rank these by probability. Forces prioritization instead of a flat list.
• What does this tell us? Forces the model to interpret data instead of jumping to a generic next step. Use this after pasting show output.
• Verify commands exist on [platform] before answering. Catches some hallucinations.
• What am I missing? Best four-word design review prompt ever written.
• What would you check next if that wasn't the cause? Keeps a troubleshooting session moving.
• This is NX-OS. Do not give me IOS syntax. Prevents platform drift mid-response.

It’s a conversation, not a vending machine

The pattern I keep seeing with engineers who bounce off these tools. One prompt, one answer, verdict rendered. That’s treating Claude like a vending machine, and it wastes the thing the model is actually best at.

The real workflow looks like a bridge call with a sharp engineer who’s never seen your network before. The first answer is a hypothesis, not a verdict. You come back with “checked that, the timers match” and the model re-reasons with that cause eliminated. You correct it, “no, that VRF only imports, it doesn’t export,” and it rebuilds the analysis around the new constraint instead of defending the old theory. Three or four turns in, you’re somewhere neither of you would’ve reached in one shot, because every turn narrowed the search space.

Two habits make the loop work. Feed results back in, including the boring ones, because “that debug came back clean” is information. And push back the moment something smells wrong. Claude treats a correction as new evidence instead of a personal attack, which puts it ahead of a few engineers I’ve shared bridge calls with.

So what

The hot take version is that Claude already knows networking. You just have to tell it which network. A Project file means you stop typing your environment into every chat. “Ask me what you need to know” means you stop guessing at what’s relevant. Custom instructions kill the safety speech, XML tags keep a complicated prompt readable, extended thinking helps when the obvious answer is wrong, and making the model point at the exact offending line keeps its confident memory honest.

Expert reasoner, unreliable memory. Feed the first, verify the second, and work it like a conversation instead of a search box. The first time it walks you to an answer you wouldn’t have reached on your own, you’ll stop wondering whether this is overhyped.

What’s in your prompting toolkit? Drop it in the comments… the guardrail you always include, the trick that finally made this stuff click, or the fabricated command that bit you the hardest. That last category is a support group, and I’ve already admitted to show ip igmp snooping membership.