Claude Code Network Automation Lab - Deep Dive: Configure Complex Topologies with AI

Lab Overview & Topology

In this lab you'll build a realistic enterprise network topology and hand full control to Claude Code running on a management terminal. Claude Code will SSH into every device, configure the entire topology from scratch, troubleshoot intentional errors, and generate compliance reports - all from natural language prompts.

This is not theoretical. By the end of this lab, you'll have a fully configured, multi-vendor network that was built entirely through AI-driven automation.

The Topology

Here's what we're building:

                        ┌─────────────┐
                        │   INTERNET   │
                        │  (Simulated) │
                        └──────┬───────┘
                               │ BGP (eBGP AS 65000)
                        ┌──────┴───────┐
                        │   CORE-RTR   │
                        │  Cisco IOSv  │
                        │  10.0.0.1/32 │
                        └──┬───────┬───┘
               OSPF Area 0 │       │ OSPF Area 0
                    ┌───────┴──┐ ┌──┴───────┐
                    │ DIST-RTR1│ │ DIST-RTR2│
                    │ Cisco IOSv│ │ Cisco IOSv│
                    │ 10.0.0.2 │ │ 10.0.0.3 │
                    └───┬──────┘ └──────┬───┘
                        │               │
                   ┌────┴────┐    ┌─────┴────┐
                   │  FW-PA  │    │  SW-CORE │
                   │PaloAlto │    │ IOSv L3  │
                   │ VM-300  │    │ 10.0.0.5 │
                   │10.0.0.4 │    └──┬────┬──┘
                   └────┬────┘       │    │
                        │       ┌────┴┐ ┌─┴────┐
                   ┌────┴────┐  │SW-A1│ │SW-A2 │
                   │  DMZ-SRV│  │IOSvL2│ │IOSvL2│
                   │  Ubuntu │  │VLAN10│ │VLAN20│
                   │10.0.100.│  └──┬──┘ └──┬───┘
                   │   10    │     │       │
                   └─────────┘  ┌──┴──┐ ┌──┴──┐
                                │SRV-1│ │SRV-2│
                                │Ubunt│ │Ubunt│
                                │.1.10│ │.2.10│
                                └─────┘ └─────┘

             ┌──────────┐
             │ MGMT-PC  │ ← Claude Code runs here
             │  Ubuntu  │   SSH access to all devices
             │10.0.99.10│   via management network
             └──────────┘

Device Inventory

Platform Setup (GNS3 / EVE-NG / CML)

The lab works on any network simulation platform. Here's how to set up management connectivity on each one - this is the critical piece that lets Claude Code reach your devices.

GNS3 Setup

GNS3 uses a Cloud node or NAT node to bridge your lab devices to the host machine where Claude Code runs.

# 1. Add a Cloud node to your topology
#    - Right-click canvas > Add node > Cloud
#    - Configure it to use your host's network interface
#      (e.g., virbr0, eth0, or a dedicated management bridge)

# 2. Create a dedicated management switch in the topology
#    Connect all device management interfaces to this switch
#    Connect the Cloud node to the same switch

# 3. On each network device, configure a management interface:
!--- Cisco IOSv example ---
interface GigabitEthernet0/7
 description MGMT-NETWORK
 ip address 10.0.99.1 255.255.255.0
 no shutdown

# 4. On the GNS3 host (or VM), add a route to reach 10.0.99.0/24:
sudo ip route add 10.0.99.0/24 via <cloud-node-ip>

# 5. Verify connectivity from MGMT-PC:
ping 10.0.99.1    # Should reach CORE-RTR
ssh [email protected]   # Should get login prompt

EVE-NG Setup

EVE-NG has built-in management bridges that make this easier. Every node's first interface (e0 or Gi0/0) can be connected to a Management (Cloud0) network.

# 1. In EVE-NG web UI:
#    - Add a "Network" object > Type: Management (Cloud0)
#    - Connect each device's management interface to Cloud0

# 2. EVE-NG's pnet0 bridge is typically on 10.0.99.0/24
#    (configure in /etc/network/interfaces on the EVE-NG host)

# 3. Example /etc/network/interfaces snippet:
auto pnet0
iface pnet0 inet static
    address 10.0.99.254
    netmask 255.255.255.0
    bridge_ports eth1
    bridge_stp off

# 4. Each lab device gets a management IP in 10.0.99.0/24
#    (see device inventory table above)

# 5. From your workstation (or MGMT-PC VM):
ssh [email protected]   # CORE-RTR
ssh [email protected]   # FW-PA (Palo Alto)

Cisco CML Setup

# 1. In CML web UI:
#    - Add an "External Connector" node (bridge mode)
#    - Connect it to a management switch/hub in your topology
#    - Set bridge to: System Bridge (or your custom bridge)

# 2. Configure device management IPs as per the inventory table

# 3. From your host or MGMT-PC:
ssh [email protected]   # Verify SSH reachability

Connecting Claude Code to the Lab

This is where it gets interesting. Claude Code runs on your management terminal and uses SSH to reach every device in the topology. There are two approaches, and I'll walk you through both.

Approach 1: Direct SSH via Claude Code Terminal (Recommended)

Claude Code has full terminal access. It can run SSH commands, execute Python scripts, and interact with devices directly. This is the simplest and most powerful approach.

# Install Python dependencies for network automation
pip install netmiko napalm paramiko jinja2 rich

# Install Claude Code (requires Node.js 18+)
npm install -g @anthropic-ai/claude-code

# Set your Anthropic API key
export ANTHROPIC_API_KEY="sk-ant-your-key-here"

# Verify Claude Code is working
claude --version

# Generate SSH key pair (if you don't have one)
ssh-keygen -t ed25519 -f ~/.ssh/lab_key -N ""

# For Cisco devices, copy the public key:
# (You'll need to do this manually once, or via console)
!--- On each Cisco device ---
conf t
ip ssh version 2
crypto key generate rsa modulus 2048
username admin privilege 15 secret LabPass123
ip scp server enable
line vty 0 4
 login local
 transport input ssh
end

# For Palo Alto, enable SSH key auth via CLI:
# set deviceconfig system ssh-keys admin key <paste-public-key>

# For Ubuntu servers:
ssh-copy-id -i ~/.ssh/lab_key [email protected]
ssh-copy-id -i ~/.ssh/lab_key [email protected]
ssh-copy-id -i ~/.ssh/lab_key [email protected]

# Save as ~/lab/inventory.yaml
---
devices:
  - hostname: CORE-RTR
    host: 10.0.99.1
    platform: cisco_ios
    username: admin
    password: LabPass123
    role: core_router

  - hostname: DIST-RTR1
    host: 10.0.99.2
    platform: cisco_ios
    username: admin
    password: LabPass123
    role: distribution_router

  - hostname: DIST-RTR2
    host: 10.0.99.3
    platform: cisco_ios
    username: admin
    password: LabPass123
    role: distribution_router

  - hostname: FW-PA
    host: 10.0.99.4
    platform: paloalto_panos
    username: admin
    password: PaloLab123!
    role: firewall

  - hostname: SW-CORE
    host: 10.0.99.5
    platform: cisco_ios
    username: admin
    password: LabPass123
    role: core_switch

  - hostname: SW-A1
    host: 10.0.99.6
    platform: cisco_ios
    username: admin
    password: LabPass123
    role: access_switch

  - hostname: SW-A2
    host: 10.0.99.7
    platform: cisco_ios
    username: admin
    password: LabPass123
    role: access_switch

Approach 2: Claude Code with the Anthropic API + Python Scripts

If you prefer more control, you can write Python scripts that call the Anthropic API for decision-making and use Netmiko/NAPALM for device interaction. This gives you a programmatic loop where Claude analyzes output and decides the next command.

import anthropic
from netmiko import ConnectHandler

client = anthropic.Anthropic()

def ask_claude(prompt, context=""):
    """Send a prompt to Claude and get a response."""
    response = client.messages.create(
        model="claude-sonnet-4-6-20250416",
        max_tokens=4096,
        messages=[{
            "role": "user",
            "content": f"{context}\n\n{prompt}"
        }]
    )
    return response.content[0].text

def execute_on_device(device_info, commands):
    """Execute commands on a network device via SSH."""
    conn = ConnectHandler(**device_info)
    output = ""
    for cmd in commands:
        output += conn.send_command(cmd) + "\n"
    conn.disconnect()
    return output

# Example: Claude analyzes a device and decides what to configure
device = {
    'device_type': 'cisco_ios',
    'host': '10.0.99.1',
    'username': 'admin',
    'password': 'LabPass123'
}

# Step 1: Gather current state
current_config = execute_on_device(device, ['show running-config'])

# Step 2: Ask Claude what needs to be configured
instructions = ask_claude(
    f"Here is the running config of CORE-RTR:\n{current_config}\n\n"
    "This router needs OSPF area 0 on all internal interfaces and "
    "eBGP peering with AS 65000 on Gi0/0. Generate the exact IOS "
    "commands I need to paste. Return only the commands, no explanation."
)

print("Claude's recommended commands:")
print(instructions)

Verify Connectivity

Before starting any lab exercises, verify that Claude Code can reach every device. Start Claude Code and give it this prompt:

# Launch Claude Code in your lab directory
cd ~/lab && claude

# Then give Claude Code this prompt:
"Read the inventory.yaml file in this directory. For each device,
 SSH into it (using ssh admin@<host>) and run 'show version'
 (for Cisco devices) or 'show system info' (for Palo Alto).
 Report back which devices are reachable and which are not.
 For each reachable device, tell me the hostname, platform,
 and software version."

Claude Code will iterate through each device, SSH in, run the appropriate show command, parse the output, and give you a clean summary. If any device is unreachable, it will tell you which one and suggest troubleshooting steps.

Lab 1: Base Configuration from Prompts

Let's start with the basics. We'll have Claude Code configure hostnames, management IPs, SSH access, banners, and NTP on every device - all from a single prompt.

The Prompt

"Read inventory.yaml for device details. SSH into each Cisco device
and apply the following base configuration:

1. Set the hostname according to inventory.yaml
2. Configure a MOTD banner: 'Authorized access only. All activity
   is monitored and logged.'
3. Set the domain name to lab.figigexams.local
4. Enable SSH v2, generate 2048-bit RSA keys if not already present
5. Configure NTP server 10.0.99.100 (the MGMT-PC)
6. Set logging to buffer 16384 and enable timestamps on log messages
7. Disable CDP on all interfaces except uplinks
8. Configure enable secret 'LabEnable123' with Type 9 (scrypt) if
   supported, otherwise Type 5
9. Save the running config to startup config on each device

For the Palo Alto firewall (FW-PA at 10.0.99.4):
1. Set the hostname to FW-PA
2. Set the DNS server to 10.0.99.100
3. Set the NTP server to 10.0.99.100
4. Configure a login banner with the same text as above
5. Commit the configuration

After configuring each device, verify by running 'show run | include
hostname' (Cisco) or 'show system info' (Palo Alto) and report the
results in a summary table."

What Claude Code Does

Claude Code will:

1. Read the inventory file to get device IPs, platforms, and credentials
2. SSH into each device sequentially (or write a Netmiko script for parallel execution)
3. Send the appropriate configuration commands for each platform
4. Handle platform differences automatically (IOS vs PAN-OS syntax)
5. Verify the configuration by running show commands
6. Present a summary table showing success/failure for each device

Expected Output

Claude Code should produce output similar to this:

Base Configuration Summary
==========================
| Device    | Hostname | SSH  | NTP      | Banner | Config Saved |
|-----------|----------|------|----------|--------|--------------|
| CORE-RTR  | OK       | v2   | 10.0.99.100 | OK  | OK           |
| DIST-RTR1 | OK       | v2   | 10.0.99.100 | OK  | OK           |
| DIST-RTR2 | OK       | v2   | 10.0.99.100 | OK  | OK           |
| FW-PA     | OK       | v2   | 10.0.99.100 | OK  | Committed    |
| SW-CORE   | OK       | v2   | 10.0.99.100 | OK  | OK           |
| SW-A1     | OK       | v2   | 10.0.99.100 | OK  | OK           |
| SW-A2     | OK       | v2   | 10.0.99.100 | OK  | OK           |

All 7 devices configured successfully.

Lab 2: Routing Protocols (OSPF + BGP)

Now for the core of any enterprise network - routing. We'll configure OSPF for internal routing and BGP for external connectivity, all through Claude Code.

The Prompt

"Configure routing protocols on the lab topology. Here are the
requirements:

OSPF Configuration (all routers):
- Process ID: 1
- Router IDs: use loopback0 addresses (10.0.0.X/32 where X matches
  the last octet of each device's management IP)
- Area 0: all inter-router links
- Reference bandwidth: 10000 (to differentiate Gig vs 10G)
- Passive interfaces: all interfaces that don't face another OSPF
  router (loopbacks, server-facing, management)
- Authentication: MD5, key 1, string 'OSPFLab2026'
- Redistribute connected subnets on CORE-RTR

BGP Configuration (CORE-RTR only):
- Local AS: 65001
- Neighbor 10.0.0.254 (simulated ISP) in AS 65000
- Advertise the aggregate 10.0.0.0/8 via a summary route
- Set next-hop-self for iBGP peers (if any)

Verification:
After configuration, run these commands on each router and show me
the output:
1. show ip ospf neighbor
2. show ip route ospf
3. show ip bgp summary (CORE-RTR only)

Present a final summary: which adjacencies formed, which routes
are in the table, and flag any issues."

What to Watch For

Claude Code will generate the configs, push them, and verify. Pay attention to how it handles:

• Interface identification - Claude Code needs to figure out which interfaces connect to which routers. It'll likely run show cdp neighbors or show lldp neighbors first to map the topology.
• Wildcard masks - OSPF network statements use wildcard masks, not subnet masks. Claude Code should get this right.
• Authentication - MD5 auth must match on both ends of every link. Claude Code needs to configure it consistently.
• Passive interfaces - Claude Code needs to identify which interfaces face end devices vs routers.

Lab 3: Palo Alto Firewall Configuration

This is where the lab gets serious. Configuring a Palo Alto firewall requires a completely different syntax and workflow compared to Cisco IOS. Claude Code handles the transition seamlessly.

The Prompt

"SSH into the Palo Alto firewall at 10.0.99.4 (admin/PaloLab123!)
and configure the following:

Zones:
- TRUST (internal network, 10.0.1.0/24 and 10.0.2.0/24)
- UNTRUST (facing DIST-RTR1, uplink to internet)
- DMZ (facing DMZ-SRV, 10.0.100.0/24)
- MGMT (management interface, 10.0.99.0/24)

Interfaces:
- ethernet1/1: UNTRUST zone, IP 172.16.1.2/30 (link to DIST-RTR1)
- ethernet1/2: TRUST zone, IP 10.0.1.1/24 (internal gateway)
- ethernet1/3: DMZ zone, IP 10.0.100.1/24 (DMZ gateway)
- ethernet1/4: MGMT zone (already configured)

Virtual Router:
- Name: VR-LAB
- Static default route: 0.0.0.0/0 via 172.16.1.1 (DIST-RTR1)
- Connected routes for all interface subnets

Security Policies (in order):
1. TRUST-to-UNTRUST: Allow all outbound (for lab purposes)
2. TRUST-to-DMZ: Allow HTTP (80), HTTPS (443), SSH (22)
3. UNTRUST-to-DMZ: Allow HTTP (80), HTTPS (443) to DMZ-SRV
4. DMZ-to-TRUST: Deny all (with logging)
5. Any-to-any: Deny all (default, with logging)

NAT Rules:
- Source NAT: TRUST to UNTRUST, translate to ethernet1/1 IP
- Destination NAT: UNTRUST to DMZ-SRV on port 80/443,
  translate to 10.0.100.10

Security Profiles:
- Attach 'default' antivirus profile to rules 1, 2, 3
- Attach 'strict' URL filtering to rule 1 (outbound)
- Enable WildFire on all allow rules

After configuration, commit and verify:
1. show interface all - confirm IPs and zones
2. show routing route - confirm routing table
3. show running security-policy - confirm policy order
4. test security-policy-match from 10.0.1.10 to 8.8.8.8
   application dns - confirm rule 1 matches

Report results in a summary."

Lab 4: Switching - VLANs, Trunks & STP

The Prompt

"Configure the switching infrastructure across SW-CORE, SW-A1, and
SW-A2. Requirements:

VLANs (create on all switches):
- VLAN 10: ENG_DATA (Engineering data) - 10.0.1.0/24
- VLAN 20: OPS_DATA (Operations data) - 10.0.2.0/24
- VLAN 30: VOICE (IP telephony) - 10.0.3.0/24
- VLAN 99: MGMT (management) - 10.0.99.0/24
- VLAN 100: DMZ (DMZ network) - 10.0.100.0/24

Trunk Links:
- SW-CORE to SW-A1: trunk, allowed VLANs 10, 30, 99
- SW-CORE to SW-A2: trunk, allowed VLANs 20, 30, 99
- SW-CORE to DIST-RTR2: trunk, all VLANs
- Native VLAN: 999 (unused VLAN for security) on all trunks

Access Ports:
- SW-A1 Gi0/1: access VLAN 10 (connects to SRV-1)
- SW-A1 Gi0/2: access VLAN 10, voice VLAN 30
- SW-A2 Gi0/1: access VLAN 20 (connects to SRV-2)
- SW-A2 Gi0/2: access VLAN 20, voice VLAN 30

Port Security (on all access ports):
- Maximum 2 MAC addresses
- Violation mode: restrict
- Sticky MAC learning enabled

Inter-VLAN Routing (SW-CORE):
- SVI for VLAN 10: 10.0.1.1/24
- SVI for VLAN 20: 10.0.2.1/24
- SVI for VLAN 30: 10.0.3.1/24
- SVI for VLAN 99: 10.0.99.5/24
- Enable ip routing

Spanning Tree:
- Mode: rapid-pvst on all switches
- SW-CORE: root bridge for all VLANs (priority 4096)
- SW-A1: secondary root for VLAN 10 (priority 8192)
- SW-A2: secondary root for VLAN 20 (priority 8192)

Verification after config:
1. show vlan brief (all switches)
2. show interfaces trunk (all switches)
3. show spanning-tree root (all switches)
4. show port-security interface (access ports)
5. Ping from SRV-1 (10.0.1.10) to SRV-2 (10.0.2.10) to verify
   inter-VLAN routing

Present results in a formatted summary."

Lab 5: Injecting & Resolving Config Errors

This is the most valuable lab exercise. In the real world, you don't just configure networks - you troubleshoot them. Here we'll deliberately introduce configuration errors and let Claude Code find and fix them.

Error Injection Scenarios

Manually introduce these errors into the topology (or have a colleague do it for a blind test). Then ask Claude Code to find and fix them.

Scenario 1: OSPF Adjacency Failure

! Change the OSPF hello timer on one side only
interface GigabitEthernet0/1
 ip ospf hello-interval 20
! (default is 10, this causes a timer mismatch with CORE-RTR)

"OSPF adjacency between CORE-RTR and DIST-RTR1 has gone down.
SSH into both devices and diagnose the issue. Check:
1. Interface status (show ip interface brief)
2. OSPF neighbor table (show ip ospf neighbor)
3. OSPF interface details (show ip ospf interface Gi0/1)
4. Compare hello/dead timers on both sides

Identify the root cause, fix it, and verify the adjacency
comes back to FULL state. Show me exactly what was wrong
and what you changed."

Scenario 2: VLAN Mismatch on Trunk

! Remove VLAN 10 from the trunk to SW-A1
interface GigabitEthernet0/1
 switchport trunk allowed vlan remove 10
! (SRV-1 in VLAN 10 will lose connectivity)

"SRV-1 (10.0.1.10) in VLAN 10 behind SW-A1 has lost connectivity
to the rest of the network. SRV-2 (10.0.2.10) in VLAN 20 is
working fine. Diagnose the issue by checking:
1. VLAN assignment on SW-A1 access port
2. Trunk allowed VLANs on both sides (SW-CORE and SW-A1)
3. SVI status on SW-CORE for VLAN 10
4. MAC address table on SW-A1

Find the root cause, fix it, and verify by pinging from SRV-1
to SRV-2."

Scenario 3: Firewall Policy Blocking Legitimate Traffic

# Move the deny-all rule above the TRUST-to-UNTRUST allow rule
# (In Palo Alto, rules are evaluated top-down)
set rulebase security rules DENY-ALL top

"Users in the TRUST zone (10.0.1.0/24) can no longer reach the
internet. They could before. The firewall is the suspected cause.
SSH into FW-PA and:
1. Show the security policy (show running security-policy)
2. Check the traffic log (show log traffic last 20)
3. Run a policy test: test security-policy-match from 10.0.1.10
   to 8.8.8.8 application web-browsing
4. Identify which rule is matching and why

Find the misconfiguration, fix it, verify the policy order is
correct, and commit. Show the before and after policy order."

Scenario 4: Duplicate IP Address

! Assign the same IP as CORE-RTR's loopback
interface Loopback0
 ip address 10.0.0.1 255.255.255.255
! (duplicate of CORE-RTR's loopback, breaks OSPF router-id)

"OSPF routing has become unstable. Routes are flapping and some
destinations are unreachable intermittently. This started after
a recent change on DIST-RTR2. Investigate:
1. Check OSPF router IDs on all routers (show ip ospf)
2. Check for duplicate IPs (show ip ospf database router)
3. Check routing table for any oscillating routes
4. Check logs for duplicate router-id warnings

Identify the duplicate, fix it on the correct device, clear
OSPF process, and verify stability. Show the before and after
OSPF database."

Scenario 5: STP Loop

! Override STP priority to make SW-A1 root for all VLANs
spanning-tree vlan 1-4094 priority 0
! (conflicts with SW-CORE which should be root)

"The network is experiencing intermittent connectivity issues and
high CPU on the switches. Investigate spanning tree:
1. Check STP root bridge on all switches (show spanning-tree root)
2. Check for topology changes (show spanning-tree detail)
3. Identify if the root bridge is correct (SW-CORE should be root)
4. Check for any unexpected root bridge elections

Fix the issue, restore SW-CORE as root for all VLANs, and verify
STP is stable. Show the before and after STP topology."

Lab 6: Automated Reporting & Compliance

A configured and working network is only half the job. You also need documentation, compliance reports, and ongoing auditing. Claude Code excels at this - it can gather data from every device and produce professional reports in seconds.

Report 1: Full Network Documentation

"Generate complete network documentation for the lab topology.
SSH into every device and collect:

1. DEVICE INVENTORY:
   - Hostname, model, software version, uptime, serial number
   - All interface IPs, statuses, and descriptions
   - Routing table summary

2. TOPOLOGY MAP:
   - L2 topology: VLAN assignments, trunk links, STP root bridges
   - L3 topology: IP subnets, routing adjacencies, next-hops
   - Firewall zones and policy summary

3. PROTOCOL STATUS:
   - OSPF: neighbor table, area assignments, router IDs
   - BGP: peer status, advertised/received routes
   - STP: root bridges per VLAN, port states

4. SECURITY SUMMARY:
   - Firewall rules (source, dest, action, hit count)
   - ACLs on routers
   - Port security status on switches
   - SSH/authentication configuration

Format the output as a structured Markdown document with tables.
Include a timestamp and a summary section at the top.
Save it to ~/lab/reports/network-documentation.md"

Report 2: Security Compliance Audit

"Perform a security compliance audit on all devices in the topology.
Check each device against these baseline requirements:

AUTHENTICATION:
[ ] SSH v2 enabled (not v1 or telnet)
[ ] Local user with privilege 15 configured
[ ] Enable secret configured (not enable password)
[ ] Password encryption enabled (service password-encryption)
[ ] Login banner configured

ACCESS CONTROL:
[ ] VTY lines restricted to SSH only (transport input ssh)
[ ] Console timeout configured (exec-timeout, max 10 min)
[ ] VTY timeout configured (exec-timeout, max 5 min)
[ ] Unused interfaces are shutdown

LOGGING & MONITORING:
[ ] Logging buffer configured (min 8192)
[ ] Log timestamps enabled
[ ] NTP configured and synchronized
[ ] SNMP v3 (if SNMP is enabled, v2c is a finding)

ROUTING PROTOCOL SECURITY:
[ ] OSPF authentication enabled on all adjacencies
[ ] Passive interfaces on non-routing ports
[ ] No default routes pointing to null0 (unless intentional)

SWITCHING SECURITY (switches only):
[ ] Native VLAN is not VLAN 1
[ ] Trunk ports explicitly configured (no DTP auto)
[ ] Port security on access ports
[ ] BPDU guard on access ports
[ ] Unused VLANs pruned from trunks

FIREWALL (Palo Alto only):
[ ] Default deny rule at the bottom
[ ] All allow rules have security profiles attached
[ ] Zone protection profiles configured
[ ] Log forwarding enabled on all rules

For each check, report PASS, FAIL, or N/A with the specific
finding. Generate a compliance score (percentage) for each device
and an overall score. Save to ~/lab/reports/compliance-audit.md"

Report 3: Network Health Check

"Run a comprehensive health check across all devices. Check:

PERFORMANCE:
- CPU utilization on all devices (flag if > 70%)
- Memory utilization (flag if > 80%)
- Interface utilization and error counters
  (flag any CRC errors, input errors, collisions)
- Uptime (flag if rebooted recently)

REACHABILITY:
- Ping test from CORE-RTR to every loopback (10.0.0.X)
- Ping test from SRV-1 to SRV-2 (inter-VLAN routing)
- Ping test from SRV-1 to DMZ-SRV (through firewall)
- Traceroute from SRV-1 to simulated internet (8.8.8.8)

PROTOCOL HEALTH:
- OSPF: all expected neighbors in FULL state?
  Any stuck in 2WAY, INIT, or EXSTART?
- BGP: peer established? Prefix count as expected?
- STP: correct root bridge? Any topology changes in last hour?
- ARP table size (flag if unusually large)

FIREWALL:
- Session count (flag if near limit)
- Threat log entries in last hour
- Policy hit counts (flag rules with zero hits)
- System resource utilization

Generate a health score (green/yellow/red) for each device and
an overall network health score. Include recommendations for any
yellow or red items. Save to ~/lab/reports/health-check.md"

Prompt Best Practices for Complex Topologies

After running through all six labs, you've seen dozens of prompts. Here's a distilled set of best practices specifically for using Claude Code with network devices.

The Five Rules of Network Prompts

Prompt Templates You Can Reuse

"Read inventory.yaml for device details. On [DEVICE_LIST]:

Configuration requirements:
[LIST EVERY REQUIREMENT WITH EXACT VALUES]

Constraints:
- [PLATFORM VERSIONS OR LIMITATIONS]
- [SECURITY REQUIREMENTS]
- [NAMING CONVENTIONS]

Verification:
After configuration, run these commands on each device:
[LIST SHOW COMMANDS]

Output format:
Present results in a table with columns:
[COLUMN_1] | [COLUMN_2] | [COLUMN_3] | [STATUS]

Flag any issues and suggest fixes."

"[DESCRIBE THE SYMPTOM - what's broken and when it started]

Affected devices: [LIST]
Working before: [YES/NO, and what changed]

Investigate:
1. [FIRST DIAGNOSTIC CHECK]
2. [SECOND DIAGNOSTIC CHECK]
3. [THIRD DIAGNOSTIC CHECK]

For each check, show me the command output.
Identify the root cause.
Fix it.
Verify the fix by [VERIFICATION METHOD].
Show me the before and after state."

"Generate a [REPORT_TYPE] report for [SCOPE].

Data to collect from each device:
[LIST SHOW COMMANDS AND WHAT TO EXTRACT]

Compliance checks (if applicable):
[LIST BASELINE REQUIREMENTS AS CHECKBOXES]

Output:
- Format: Markdown with tables
- Include: timestamp, summary section, per-device details
- Score: [SCORING CRITERIA]
- Save to: [FILE_PATH]"