Back
Lesson 3 of 6

AI-Generated Configuration

Objective

In this lesson you will use an LLM-style workflow to take an intent description and produce safe, verifiable device configuration changes on IOS routers. You will learn how to (1) prepare devices for an automated configuration change, (2) apply the AI-generated configuration to two routers, (3) validate the changes at the protocol level (OSPF adjacency, routing, interfaces), and (4) implement a safe rollback option. This matters in production because automated configuration that is neither validated nor reversible can cause outages; in real networks, teams use verification and rollback steps to ensure changes are safe before they touch the network.

Quick Recap

This lesson continues from the topology used in Lesson 1 (no new devices are required). We will operate on the two routers R1 and R2 that form the core/edge pair. IP addressing used in this lesson is shown below and must be used exactly as given.

ASCII Topology (exact IPs on every interface)

   [LAN]                          [Internet]
   10.0.1.0/24                      192.168.0.0/24
     |                                |
     | G0/1 10.0.1.1                  | G0/1 192.168.0.1
    R1 ----------------- 10.0.12.0/30 ---------- R2
    G0/0 10.0.12.1          link        G0/0 10.0.12.2

Device table

DeviceRoleInterface (exact name)IP address
R1Core routerGigabitEthernet0/010.0.12.1/30
R1LAN gatewayGigabitEthernet0/110.0.1.1/24
R2Edge routerGigabitEthernet0/010.0.12.2/30
R2Edge/InternetGigabitEthernet0/1192.168.0.1/24

Use domain: lab.nhprep.com and passwords: Lab@123 when the lesson asks for credentials.

Key Concepts (theory before CLI)

  • Intent vs. Configuration: Intent is a human-readable description ("Connect LAN to Internet via OSPF and set default route"). The AI generates configuration text from that intent. In production you must validate the generated text before applying it; the device only understands configuration commands, not intent.
  • Atomic, Testable Changes: Make small, atomic changes and validate at the protocol level (interfaces up, OSPF adjacency, routes learned). This reduces blast radius. OSPF neighbors send Hello packets (every 10 seconds on broadcast networks by default) to form adjacencies; if the neighbor is missing, routing won't converge.
  • Backup and Rollback: Always capture a known-good config before automated changes so you can quickly revert. In IOS you can save running-config to startup-config or keep a copy of the running-config externally.
  • Least Privilege and Access Control: Create or use a dedicated administrative account for automated changes. This allows auditing and limits exposure if credentials are leaked.
  • Validation Commands: Use deterministic commands to validate behavior: show ip interface brief, show ip ospf neighbor, show ip route, and ping — these show interface state, protocol adjacency, route table, and basic IP reachability respectively.

Tip: Think of applying AI-generated config like shipping code — you run unit tests (validation commands) and have a rollback strategy.

Step-by-step configuration

Each step below follows the pattern: What we are doing, exact commands, what just happened, a real-world note, and verification with expected output.

Step 1: Record intent and back up current configuration

What we are doing: Before any automated change, capture the current running configuration to create a backup baseline. This preserves a known-good config you can restore if the AI-generated changes cause problems.

show running-config

What just happened: This displays the full current running configuration of the device to your terminal. Capturing this output (copy/paste to a text file) gives you a point-in-time backup of the running state.

Real-world note: In production you would also push this to a centralized config archive (TFTP/SCP/Git). For this lab we capture local output.

Verify:

show running-config
! Expected output (excerpt showing hostname and interface config)
hostname R1
!
interface GigabitEthernet0/0
 ip address 10.0.12.1 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/1
 ip address 10.0.1.1 255.255.255.0
 no shutdown
!

(For R2 run the same show running-config and expect the analogous interfaces and any pre-existing configuration.)

Step 2: Prepare device for automated changes (secure admin account and domain)

What we are doing: Create a dedicated local administrative user for the automation process, set the domain name (used by some automation tools), and ensure an enable secret exists. These are safety and auditing best practices.

configure terminal
hostname R1
ip domain-name lab.nhprep.com
enable secret Lab@123
username aiadmin privilege 15 secret Lab@123
end
write memory

What just happened:

  • hostname R1 sets the device prompt and identity used in configs.
  • ip domain-name lab.nhprep.com configures the device domain name (some tools and logging use it).
  • enable secret Lab@123 secures privileged EXEC access.
  • username aiadmin ... creates a local admin user specifically for automated changes.
  • write memory persists the running-config to startup-config so the changes survive reloads.

Real-world note: Use a dedicated automation account with minimal necessary privileges; avoid sharing accounts between humans and automation.

Verify:

show running-config | section username
username aiadmin privilege 15 secret 5 $1$abcd$abcdefghijklmnopqrstuv

show running-config | include domain-name
ip domain-name lab.nhprep.com

(Expected output shows the username line and domain-name line. The exact enable secret is stored encrypted and will appear as enable secret 5 ....)

Step 3: Apply the AI-generated configuration (interfaces + OSPF + default route)

What we are doing: We will apply the configuration that an LLM produced for R1 and R2 to implement OSPF area 0 between them, configure the interfaces with exact IPs, and set a default route where appropriate. This is the core functional change that enables LAN-to-Internet routing.

R1 commands:

configure terminal
interface GigabitEthernet0/0
 ip address 10.0.12.1 255.255.255.252
 no shutdown
exit
interface GigabitEthernet0/1
 ip address 10.0.1.1 255.255.255.0
 no shutdown
exit
router ospf 1
 router-id 1.1.1.1
 network 10.0.12.0 0.0.0.3 area 0
 network 10.0.1.0 0.0.0.255 area 0
exit
ip route 0.0.0.0 0.0.0.0 10.0.12.2
end
write memory

R2 commands:

configure terminal
interface GigabitEthernet0/0
 ip address 10.0.12.2 255.255.255.252
 no shutdown
exit
interface GigabitEthernet0/1
 ip address 192.168.0.1 255.255.255.0
 no shutdown
exit
router ospf 1
 router-id 2.2.2.2
 network 10.0.12.0 0.0.0.3 area 0
 network 192.168.0.0 0.0.0.255 area 0
exit
ip route 10.0.1.0 255.255.255.0 10.0.12.1
end
write memory

What just happened:

  • Each interface block put the exact IP addresses on the router interfaces and brought interfaces up with no shutdown. Link-level OSPF Hellos will now be exchanged on the 10.0.12.0/30.
  • router ospf 1 enables OSPF process 1, sets a deterministic router-id for predictable neighbor output, and places LAN and inter-router links into area 0. OSPF will start sending Hello packets (every 10 seconds on broadcast by default) and attempt to form a FULL adjacency.
  • On R1 we added a default route pointing at R2 so R1 forwards unknown-destination traffic to R2. On R2 we added a static route for 10.0.1.0 via R1 — this is a conservative safety addition; OSPF should also learn this route but the static ensures reachability during convergence.

Real-world note: Production automation should avoid hard-coded static routes where dynamic routing is intended — we include a static on R2 here only as a protective fallback. In real networks you'd prefer OSPF-only and verify via graceful convergence testing.

Verify:

  • Interfaces up
show ip interface brief
! Expected output on R1
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0        10.0.12.1       YES manual up                    up
GigabitEthernet0/1        10.0.1.1        YES manual up                    up

! Expected output on R2
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0        10.0.12.2       YES manual up                    up
GigabitEthernet0/1        192.168.0.1     YES manual up                    up
  • OSPF neighbor adjacency
show ip ospf neighbor
! Expected output on R1
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2          1    FULL/ -         00:00:33    10.0.12.2       GigabitEthernet0/0

! Expected output on R2
Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1          1    FULL/ -         00:00:34    10.0.12.1       GigabitEthernet0/0
  • Routing table entries (OSPF learned routes)
show ip route
! Expected output on R1 (excerpt)
Codes: C - connected, O - OSPF, S - static, ...
O    192.168.0.0/24 [110/20] via 10.0.12.2, 00:00:12, GigabitEthernet0/0
S*   0.0.0.0/0 [1/0] via 10.0.12.2
C    10.0.1.0/24 is directly connected, GigabitEthernet0/1
C    10.0.12.0/30 is directly connected, GigabitEthernet0/0

! Expected output on R2 (excerpt)
O    10.0.1.0/24 [110/20] via 10.0.12.1, 00:00:12, GigabitEthernet0/0
C    192.168.0.0/24 is directly connected, GigabitEthernet0/1

Step 4: Validate connectivity and protocol-level behavior

What we are doing: Use active and passive tests to confirm the AI-generated configuration behaves as intended: pings to next-hop and remote networks, and verification of OSPF LSDB if needed.

ping 10.0.12.2

What just happened: This verifies basic IP reachability to the neighbor next-hop. A successful ping confirms the link is up and IP forwarding is functional.

Verify:

ping 10.0.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Additionally verify end-to-end route from LAN host (10.0.1.X) to Internet side (192.168.0.0) by testing from R1:

ping 192.168.0.1

Expected:

Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/5 ms

Real-world note: In production, follow-up tests include BGP/ACL behavior, application-level checks, and monitoring alerts to ensure no unintended impact.

Step 5: Rollback plan — restore pre-change configuration if needed

What we are doing: If tests fail or unexpected behavior occurs, restore the previously saved configuration snapshot. Here we demonstrate merging the startup-config backup into running-config to return to the baseline.

copy startup-config running-config
write memory

What just happened: copy startup-config running-config reads the saved startup-config (the known-good copy you created earlier) and merges it into the current running-config. write memory saves this restored state back to startup-config.

Warning: Some IOS versions merge configs rather than fully replace them. For full replacements use configure replace, but only do so when you are confident in the environment and downtime windows.

Verify:

show running-config
! Expected output should show the earlier pre-change config values restored (interfaces and OSPF entries removed or set back to baseline)

Verification Checklist

  • Check 1: Interfaces are up on both routers — verify with show ip interface brief and expect GigabitEthernet0/0 and GigabitEthernet0/1 UP/UP as shown above.
  • Check 2: OSPF adjacency is FULL between R1 and R2 — verify with show ip ospf neighbor and expect neighbor IDs 2.2.2.2 and 1.1.1.1 in FULL state.
  • Check 3: Routing table shows remote networks learned — verify with show ip route and expect OSPF routes for the remote LANs (O entries) and a default route on R1 pointing to 10.0.12.2.
  • Check 4: End-to-end ping works from R1 to 192.168.0.1 — verify with ping 192.168.0.1 and expect 100% success.

Common Mistakes

SymptomCauseFix
OSPF adjacency never achieves FULLInterface IPs mismatched, or network statements do not include the interface IP, or no shutdown missingCheck show ip interface brief for IP mismatch; ensure network statements include interface subnets or configure OSPF under the interface; bring interface up with no shutdown
Route for remote LAN not present on expected routerOSPF not running on that interface or wrong area configuredVerify router ospf section and network mask/wildcards; ensure same area (area 0) used for backbone networks
Pings time out to neighbor but interface shows up/upAccess-lists or firewall between routers, or IP misconfiguredCheck show access-lists, remove or adjust ACLs; verify IP/mask with show running-config
Unable to rollback to expected stateStartup-config was not saved before changeAlways write memory before applying major changes; if not saved, manual restore of saved file or reapply baseline config is required

Key Takeaways

  • Always treat AI-generated configuration as a draft — you must validate syntax and behavior before committing to production.
  • Prioritize small, atomic changes with clear verification steps (interfaces, adjacency, routing, ping). Protocol-level checks (OSPF Hellos/adjacency) are crucial to ensure dynamic routing functions.
  • Back up your configuration before changes and define a clear rollback plan; automation without rollback is high risk.
  • Use dedicated automation accounts and minimal privileges to aid auditing and reduce exposure.
  • In production, extend these steps with staged rollouts (lab → staging → prod), automated tests (unit and integration), and change windows for risky modifications.

Final real-world insight: Think of LLMs as assistants that produce configuration text from intent. Human operators must still run the equivalent of "unit tests" (validation commands) and ensure a rollback strategy exists before allowing that text to become network state.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security