NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will configure device management and programmatic read access so an AI agent can translate natural-language queries into network API calls. We will enable secure CLI access (SSH) and a read-only SNMP community, then demonstrate how natural-language questions map to CLI and SNMP queries. This matters in production because automating state queries reduces mean-time-to-detect and mean-time-to-repair — for example, a NOC engineer can ask “Which routes contain 10.30.0.0/24?” and an LLM-based agent will run the proper API call and return actionable output.

Quick Recap

We continue using the topology introduced in Lesson 1. No new physical devices are added in this lesson. The management host (mgmt) is the origin of the AI agent queries.

ASCII topology (exact IPs on every interface):

Router1 (Router1)

GigabitEthernet0/0: 10.10.10.1/24 (Mgmt)
GigabitEthernet0/1: 10.20.20.1/30 (Link to Router2)

Router2 (Router2)

GigabitEthernet0/1: 10.20.20.2/30 (Link to Router1)
GigabitEthernet0/0: 10.30.30.1/24 (LAN)

Management host (mgmt)

eth0: 10.10.10.10/24

Topology diagram:

[mgmt 10.10.10.10/24] --- Gi0/0 10.10.10.1/24 --- Router1 --- Gi0/1 10.20.20.1/30 === 10.20.20.2/30 --- Router2 --- Gi0/0 10.30.30.1/24 --- [LAN Host 10.30.30.10/24]

Device table:

Device	Role	Management IP
Router1	Edge/Core router	10.10.10.1 (Gi0/0)
Router2	Remote router	10.30.30.1 (Gi0/0)
mgmt	Management host	10.10.10.10

IP addressing table:

Interface	IP Address	Mask
Router1 Gi0/0	10.10.10.1	255.255.255.0
Router1 Gi0/1	10.20.20.1	255.255.255.252
Router2 Gi0/1	10.20.20.2	255.255.255.252
Router2 Gi0/0	10.30.30.1	255.255.255.0
mgmt eth0	10.10.10.10	255.255.255.0

Key Concepts

SSH for secure programmatic CLI access: When an AI agent needs authoritative real-time state, SSH is commonly used to run CLI commands. SSH traffic is encrypted; the router requires a local user and an RSA keypair to authenticate connections. In production, SSH protects credentials and command data in transit.
SNMP as a programmatic read API: SNMP (v2c or v3) exposes MIB objects that map to device state (sysName, interface counters, route information). An LLM can translate a natural-language question into an SNMP GET or GETNEXT sequence. SNMP is efficient for polling and monitoring at scale.
Mapping natural language to device queries: The LLM must decide whether to use CLI (via SSH) or SNMP based on the requested information. Example: “Show me interface errors” -> CLI show interfaces or SNMP if using IF-MIB counters.
Least privilege: Provide the AI agent only read-only access (SNMP RO community and SSH account with read-only privileges if possible). This avoids accidental changes from automated agents.
Deterministic responses for parsing: CLI outputs and SNMP OIDs are deterministic formats the parser consumes. Use consistent platform output to simplify the translation layer.

Real-world note: In production, you will usually expose monitoring APIs (SNMPv3 preferred) rather than broad write-capable SSH accounts. For learning, SNMPv2c demonstrates the translation pipeline without additional cryptography complexity.

Step-by-step configuration

Step 1: Configure management addressing, hostname, domain, and local admin account on Router1

What we are doing: Assign the management IP, set a hostname and domain name, and create a local administrative user. These are prerequisites for secure management and RSA key generation for SSH.

enable
configure terminal
hostname Router1
ip domain-name lab.nhprep.com
username admin privilege 15 secret Lab@123
interface GigabitEthernet0/0
 ip address 10.10.10.1 255.255.255.0
 no shutdown
interface GigabitEthernet0/1
 ip address 10.20.20.1 255.255.255.252
 no shutdown
end

What just happened:

hostname Router1 sets the device identity; useful in prompts and SNMP sysName.
ip domain-name lab.nhprep.com is required before generating RSA keys (SSH) and ensures complete FQDNs for certificates.
username admin ... secret Lab@123 creates a local account with full privileges; the password matches the lab policy.
Interface commands assign IPs and bring interfaces up so the management host and peer router can reach Router1.

Real-world note: Hostnames and domain names are used by logging and cryptographic functions. Always set them consistently across devices for easier automation and certificate validation.

Verify:

show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0        10.10.10.1      YES manual up                    up
GigabitEthernet0/1        10.20.20.1      YES manual up                    up
GigabitEthernet0/2        unassigned      YES unset  administratively down down
GigabitEthernet0/3        unassigned      YES unset  administratively down down

Step 2: Enable SSH v2 for secure CLI-based queries

What we are doing: Generate an RSA keypair and configure the VTY lines to accept SSH logins using the local user database. SSH allows the AI agent to run CLI commands securely.

enable
configure terminal
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0 4
 login local
 transport input ssh
 exec-timeout 10 0
end

What just happened:

crypto key generate rsa modulus 2048 creates the device RSA keypair used in SSH handshakes. Modulus 2048 is currently a good security minimum.
ip ssh version 2 forces SSHv2 which is more secure and robust than SSHv1.
line vty 0 4 with login local ties VTY authentication to the local username database. transport input ssh permits only SSH connections (not telnet).
exec-timeout 10 0 ensures idle sessions close after 10 minutes, reducing risk from forgotten sessions.

Real-world note: For automated agents, use key-based authentication (public key) on the management system where supported, and limit source IPs via ACLs. This lab uses password-based login for clarity.

Verify:

show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3

show running-config | section line vty
line vty 0 4
 exec-timeout 10 0
 login local
 transport input ssh

Step 3: Configure SNMP read-only community and location/contact information

What we are doing: Enable SNMP read-only access using community string NHPREP. This gives programmatic read access that an AI agent can use for polling device state without interactive CLI.

enable
configure terminal
snmp-server community NHPREP RO
snmp-server contact "NHPREP NOC"
snmp-server location "DataCenter1"
end

What just happened:

snmp-server community NHPREP RO creates an SNMPv2c read-only community named NHPREP. Tools using this community can perform GET and GETNEXT operations but not SETs.
snmp-server contact and snmp-server location populate standard MIB objects (sysContact, sysLocation) which are helpful in monitoring dashboards and automated discovery.

Real-world note: In production, prefer SNMPv3 with authentication and encryption. SNMPv2c is included here because it’s simple and demonstrates the translation of natural language to SNMP GETs.

Verify:

show running-config | include snmp-server
snmp-server community NHPREP RO
snmp-server contact NHPREP NOC
snmp-server location DataCenter1

show snmp community
Community name: NHPREP         Access: read-only

Step 4: Execute representative queries (how an LLM maps a question to API/CLI)

What we are doing: Demonstrate the CLI and SNMP commands that an AI agent would run after translating a natural-language query. This shows the mapping from question to API call and gives the outputs that downstream parsers will consume.

Natural language example 1: "What interfaces are up and their IP addresses?"

CLI mapping: show ip interface brief
SNMP mapping: IF-MIB + IP-MIB queries (not shown here) but an LLM can choose CLI when exact textual output is required.

show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0        10.10.10.1      YES manual up                    up
GigabitEthernet0/1        10.20.20.1      YES manual up                    up
GigabitEthernet0/2        unassigned      YES unset  administratively down down
GigabitEthernet0/3        unassigned      YES unset  administratively down down
Vlan1                     10.255.255.254  YES manual administratively down down

Natural language example 2: "Show me the route(s) to 10.30.30.0/24"

CLI mapping: show ip route 10.30.30.0
SNMP mapping: IP-FORWARD-MIB route table lookups.

show ip route 10.30.30.0
Routing entry for 10.30.30.0/24
  Known via "connected", distance 0, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet0/1
      Route metric is 0, traffic share count is 1

Natural language example 3: "What is the device name and where is it located?"

CLI mapping: show running-config | include hostname and show running-config | include snmp-server location
SNMP mapping: sysName and sysLocation OIDs.

show running-config | include hostname
hostname Router1

show running-config | include snmp-server location
snmp-server location DataCenter1

What just happened:

These show outputs are deterministic and easier to parse than free-form natural language. The LLM translates user intent into specific commands (CLI or SNMP). For example, to answer interface status questions it will prefer show ip interface brief; to gather SNMP-identifiable metadata it will use SNMP sysName and sysLocation.

Real-world note: Platform CLI output can vary across IOS versions and models. Robust agents normalize output and prefer structured APIs (Netconf/RESTCONF/SNMPv3) where available.

Verify: (These are the same commands above; run them when building the agent to test the parsing pipeline)

show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0        10.10.10.1      YES manual up                    up
GigabitEthernet0/1        10.20.20.1      YES manual up                    up
GigabitEthernet0/2        unassigned      YES unset  administratively down down
GigabitEthernet0/3        unassigned      YES unset  administratively down down
Vlan1                     10.255.255.254  YES manual administratively down down

show ip route 10.30.30.0
Routing entry for 10.30.30.0/24
  Known via "connected", distance 0, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet0/1
      Route metric is 0, traffic share count is 1

Verification Checklist

Check 1: SSH is enabled and the router accepts SSH logins using the local user. Verify with:
- show ip ssh — expected: "SSH Enabled - version 2.0"
Check 2: SNMP read-only community exists. Verify with:
- show running-config | include snmp-server — expected lines for community, contact, location
Check 3: CLI queries return deterministic output for parsing. Verify with:
- show ip interface brief and show ip route 10.30.30.0 — outputs shown above

Common Mistakes

Symptom	Cause	Fix
SSH session refused	No RSA key generated or `ip domain-name` missing	Ensure `ip domain-name lab.nhprep.com` is configured, then run `crypto key generate rsa modulus 2048`
SNMP GETs fail from mgmt host	Wrong community string or SNMP blocked by access list	Verify community with `show running-config
Device name not returned in SNMP	sysName not set or not queried	`show running-config
Agent cannot parse CLI output	CLI differs across platform/IOS versions	Use structured APIs (NETCONF/RESTCONF) where available or normalize output with templates/regexes in the agent

Key Takeaways

Use SSH for secure interactive CLI queries and SNMP for efficient programmatic reads. Choose based on the information needed and scale.
Provide the AI/agent only the minimum privileges required (read-only SNMP; restrict SSH accounts and sources).
Natural language queries map to deterministic API calls: teach the LLM the correct mapping (examples above) and validate parsing with live CLI outputs.
In production prefer secure SNMPv3 or structured APIs (NETCONF/RESTCONF) — this lab demonstrates the principles using SNMPv2c and SSH for clarity.

Tip: When building an LLM query translator, create a small set of canonical mappings (e.g., “interfaces” → show ip interface brief) and test them against multiple devices to handle output variations.

This completes Lesson 2: Natural Language Network Queries. In the next lesson we will build a simple translator that converts sample natural-language prompts into these API calls and parses the results into human-readable answers.