{"slug": "using-ai-to-re-architect-the-cisco-devnet-sandbox-environment-part-1", "title": "Using AI to re-architect the Cisco DevNet sandbox environment – Part 1", "summary": "A network engineer building a Cisco DevNet sandbox with two Secure Firewall 3100 appliances, two C8475-G2 Secure Routers, Nexus 93600CD-GX spines and Nexus 93180YC-FX leaves reported that Anthropic's Claude flagged a topology error before any cabling was run: in a spine-leaf fabric, spines should connect only to leaves, with external connectivity on dedicated border leaves per Cisco's VXLAN BGP EVPN design guide. Claude also noted the C8475-G2 tops out at 25G per port (SFP28) while the 93600 spine ports are QSFP (40/100G, plus 400G), a mismatch that would require breakout cables or adapters. The correction eliminated two routers the engineer had budgeted for, turning them into spares.", "body_md": "*Part 1 of a five-part series on AI network design: building a production-grade sandbox network with Claude as a second architect in the room, not a tool I queried for facts. The rest of the series: Part 2 – The Fabric Claude Designed; Part 3 – Why I Let Claude Talk Me Out of Its Own Design; Part 4 – From Whiteboard to Rack; Part 5 – The Outage Claude Diagnosed in Minutes.*\n\nI’ll be upfront about where I started: skeptical. In one short AI network design review, Claude caught a cabling mistake I was about to make, and a few questions later, two routers I’d budgeted for had become spares.\n\nI was building a sandbox network with real Cisco firewalls, real edge routers, and a real Nexus switching fabric: the kind of gear that costs real money and doesn’t get re-cabled on a whim. I’d used AI chatbots plenty for drafting and summarizing, but I didn’t expect one to push back on an enterprise network topology. At best, I figured, it would politely agree and recite a spec sheet back at me.\n\nSo before I ran a single cable, I opened a chat with Claude, laid out my full topology, and asked the simplest possible question: *Is this a valid setup?*\n\n### The plan: Firewalls, routers, and a Nexus fabric\n\nMy plan was two Cisco Secure Firewall 3100 appliances running Secure Firewall Threat Defense (FTD) for the internet edge, two Cisco C8475-G2 Secure Routers (Cisco 8400 Series) behind them for edge connectivity, and a two-tier Nexus fabric underneath: Cisco Nexus 93600CD-GX switches as spines, Cisco Nexus 93180YC-FX switches as leaves. On paper it read cleanly: internet, firewalls, routers, fabric, done.\n\n### It checked the hardware before it answered\n\nClaude’s first move wasn’t an opinion on my design. It said it wanted to verify one of the hardware models first, then went and searched for it.\n\nThat small move told me more than I expected. It would have been trivial to nod along (“yes, that’s a reasonable topology”), and I probably wouldn’t have questioned it. Instead it treated “do I actually know this box” as a question worth answering first, the same instinct I’d want from a colleague reviewing my work rather than agreeing to be agreeable.\n\nThe hardware checked out: the C8475-G2 is a legitimate, fairly recent platform, part of Cisco’s 8400 Series Secure Routers. The problem was elsewhere.\n\n### The catch: Spines should connect only to leaves\n\nHere’s roughly how it went:\n\n**Me:** I have two FTDs for internet, two C8475 routers behind them, then 93600 spines and 93180 leaves.\n\n**Claude:** The gear all checks out, and the overall shape is sound, but there are two things I’d change. In a spine-leaf fabric, spines should connect *only* to leaves. Nothing else (no servers, no firewalls, no WAN routers) attaches to a spine. External connectivity comes in through dedicated border leaves instead. Connecting your routers to the spines breaks that.\n\nI sat with that for a second, because my diagram hadn’t felt wrong when I drew it. “Routers are the edge, spines are the top of the fabric, edge plugs into top” seemed like a reasonable mental shortcut.\n\nClaude was describing Cisco’s recommended practice: **spines connect only to leaves**, and the [Cisco VXLAN BGP EVPN design guide](https://www.cisco.com/c/en/us/td/docs/dcn/whitepapers/cisco-vxlan-bgp-evpn-design-and-implementation-guide.html) puts external connections on border leaves. Border spines are supported, but they complicate scaling.\n\nMy layout broke the one property that lets a Clos fabric scale cleanly. Spines stay pure transit, carrying zero external state, so adding fabric capacity later never means touching spine config. Hang a router on a spine and every future spine inherits that exception.\n\nClaude backed this up with something I could check in 30 seconds: the C8475-G2 tops out at 25G per port (SFP28), while the 93600 spine ports are QSFP (40/100G, plus 400G). Wiring them directly meant breakout cables or adapters just to bring up a link. In hindsight, that was a physical hint the two boxes were never meant to talk point to point.\n\nThe fix was simple once it was named: move the routers and firewalls onto a dedicated border-leaf pair, and let the spines go back to doing nothing but spine things. A five-minute conversation saved me from cabling a mistake that would have been annoying to unwind once racked.\n\n*The topology after the first fix: the firewalls connect through a border-leaf pair, and the spines connect only to leaves.*\n\n### The question that mattered more than the fix\n\nThis is what changed how I thought about the rest of the project. Claude didn’t stop at “fixed your diagram, you’re welcome.” It asked a question I hadn’t answered for myself:\n\n**Claude:** What are the routers actually *for*? “Network edge connectivity” could mean a WAN/SD-WAN headend for remote sites and multiple ISPs, which is what this hardware is built for, or it could just mean an extra hop behind firewalls that are already doing NAT and inspection. Those are different jobs, and they lead to different topologies.\n\nI didn’t have a crisp answer. I’d inherited “routers behind firewalls” as a shape without interrogating why. It’s a pattern I’d see again and again in this project: the most valuable thing Claude did wasn’t correcting my diagram; it was **refusing to let a vague requirement slide by unexamined**.\n\n### One yes/no question changed the architecture\n\nOver the next exchange, I clarified: the routers wouldn’t run BGP, the firewalls just needed a default route from the ISP, and the fabric would use classic VLANs rather than an overlay. That raised another question I hadn’t thought through: If the routers aren’t doing BGP, were they supposed to own inter-VLAN routing for the fabric?\n\nClaude’s answer was blunt and backed by real numbers: no. Both Nexus switches are full Layer 3 switches that route in hardware at line rate, while the routers top out at roughly 91 Gbps, the maximum forwarding rate in the [Cisco 8400 Series Secure Routers data sheet](https://www.cisco.com/site/us/en/products/collateral/networking/sdwan-routers/8000-secure-routers/8400-series-secure-routers-ds.html).\n\nPut the fabric’s gateways on the routers and every inter-VLAN packet (most of the traffic in a compute environment) leaves the fabric, hairpins through that bottleneck, and comes back. The switches should route; the routers, if they’re needed at all, hold a northbound default and nothing more.\n\nThen came the fork that decided everything downstream: **Did my VLANs need to live on more than one leaf?** Classic VLANs can’t stretch across a routed spine-leaf fabric without an overlay, so the answer would decide between a routed-access Clos design and a two-tier aggregation/access design.\n\nI confirmed: yes, they needed to span. Claude’s conclusion was plain: the fabric wasn’t really a spine-leaf design anymore. It was a two-tier vPC design.\n\nWithout the Layer 3 job I’d implicitly assigned them, the routers had nothing left in the data path. Keep them as spares, or for a future WAN need. Not thrown away. Just not doing anything today.\n\n### What this first exchange taught me about AI network design\n\nI went in expecting a quick check. What I got was something closer to a design review from someone who refused to let “it looks right” stand in for “I checked why it’s right.”\n\nTwo boxes I’d budgeted for as core infrastructure turned out to be spares before I’d spent a dollar on cabling. That’s the kind of catch that’s cheap in a chat window and expensive in a data center.\n\n**What this round made clear to me:**\n\n- **Ask for a review, not a fact.** Give the agent the whole design and an open question. A good review doesn’t just fix the diagram; it asks what you were actually trying to build.\n- **Make it verify, then verify it.** Claude checked the part number before opining, and I confirmed its port-speed argument in 30 seconds. That habit is worth having in a person or a tool.\n- **Answer its questions precisely.** The most consequential question in this project, do the VLANs need to span more than one leaf, was one sentence long, and I hadn’t thought to ask it of myself.\n\nBefore you rack anything, try the same AI network design review on your own topology.\n\nWe’d landed on a two-tier vPC design because it fit the requirements I’d actually stated. But I wanted to know what I’d give up by skipping an overlay on day one, so in the next conversation I asked Claude to design that version too. Part 2 is that fabric: the one we designed in full, and ultimately didn’t build.", "url": "https://wpnews.pro/news/using-ai-to-re-architect-the-cisco-devnet-sandbox-environment-part-1", "canonical_source": "https://blogs.cisco.com/cisco-devnet/ai-network-design-devnet-sandbox-part-1", "published_at": "2026-10-22 19:00:34+00:00", "updated_at": "2026-10-22 19:13:37.884452+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents"], "entities": ["Cisco", "Claude", "Anthropic", "Cisco DevNet", "Cisco Secure Firewall 3100", "Cisco C8475-G2 Secure Routers", "Cisco Nexus 93600CD-GX", "Cisco Nexus 93180YC-FX"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/using-ai-to-re-architect-the-cisco-devnet-sandbox-environment-part-1", "markdown": "https://wpnews.pro/news/using-ai-to-re-architect-the-cisco-devnet-sandbox-environment-part-1.md", "text": "https://wpnews.pro/news/using-ai-to-re-architect-the-cisco-devnet-sandbox-environment-part-1.txt", "jsonld": "https://wpnews.pro/news/using-ai-to-re-architect-the-cisco-devnet-sandbox-environment-part-1.jsonld"}}