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

Lab Objectives

Understand the basic principles of REST APIs (GET, POST, PUT, DELETE) and how they map to network configuration actions.
Learn how IOS XE can present configuration in JSON using the format restconf -json pipe and inspect interface configuration programmatically.
Practice making a simple configuration change on an interface and verifying the change in both CLI and JSON output.

Base Topology (exact IPs shown)

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
      Gi0/0: 10.10.10.1  Gi0/1: 10.10.20.1  Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 Gi0/0: 10.10.20.2 Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

IP SCHEME (reference)

10.10.10.0/24 — R1-R2 link
10.10.20.0/24 — R1-R3 link
10.10.30.0/24 — R1-R4 link
10.10.40.0/24 — R2-S1 link
192.168.1.0/24 — VLAN 10 (Sales)
192.168.2.0/24 — VLAN 20 (Engineering)
192.168.3.0/24 — VLAN 30 (Management)
203.0.113.0/24 — Public/Internet simulation

Tip: Think of a REST API like a waiter at a restaurant. You (the client) make a request (GET menu, POST an order, PUT change the order, DELETE cancel). The server (network device) responds with the requested information or performs the requested change. JSON is the menu format — structured and easy for machines to parse.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Retrieve R1 running-config in JSON

Use the device CLI to display the running configuration of R1 in RESTCONF-compatible JSON format and inspect the object for interface Gi0/0 (10.10.10.1). Do not change configuration.

Parameters: device = R1, command = show running-config piped to restconf JSON.

Task 2: Configure an interface description and view JSON

Configure a human-readable description on R1 Gi0/1 (10.10.20.1). Then retrieve the running-config for that interface only, in JSON, to confirm the description is represented.

Parameters: interface = GigabitEthernet0/1, description = "Link-to-R3"

Task 3: Map REST verbs to configuration actions (practical verification)

Understand mapping:

GET — retrieve config (verify with show commands).
POST/PUT — create or replace configuration (we will demonstrate by configuring and then verifying).
DELETE — remove configuration (demonstrate by removing the description and verifying it no longer appears in JSON).

Perform the PUT-like change (set description), then perform the DELETE-like change (remove description), verifying JSON after each action.

Think About It: Why does viewing configuration in JSON matter for automation? (Hint: consider idempotence and programmatic parsing.)

Lab Solution

Task 1 Solution: Retrieve R1 running-config in JSON

What we are doing: Use the IOS XE pipe format to render the running configuration as RESTCONF-style JSON so automation tools can parse the device configuration.

R1# show running-config | format restconf -json

What the command does and why it matters:

show running-config — reads the current active configuration (read-only).
| format restconf -json — pipes the CLI output into JSON formatted in a RESTCONF-friendly layout. This enables automation tools to use the CLI as a programmatic data source (read operation equivalent to an HTTP GET).

Verify:

R1# show running-config | format restconf -json
{
  "native": {
    "version": "16.12",
    "hostname": "R1",
    "interface": [
      {
        "name": "GigabitEthernet0/0",
        "description": "",
        "ip": {
          "address": {
            "primary": {
              "address": "10.10.10.1",
              "mask": "255.255.255.0"
            }
          }
        },
        "shutdown": false
      },
      {
        "name": "GigabitEthernet0/1",
        "description": "",
        "ip": {
          "address": {
            "primary": {
              "address": "10.10.20.1",
              "mask": "255.255.255.0"
            }
          }
        },
        "shutdown": false
      },
      {
        "name": "GigabitEthernet0/2",
        "description": "",
        "ip": {
          "address": {
            "primary": {
              "address": "10.10.30.1",
              "mask": "255.255.255.0"
            }
          }
        },
        "shutdown": false
      }
    ],
    "ip_route": [
      {
        "prefix": "0.0.0.0/0",
        "next_hop": "203.0.113.1"
      }
    ]
  }
}

The JSON object shows each interface as an element with keys for name, IP, and shutdown state. For automation, a script can parse "interface" array and locate "name":"GigabitEthernet0/0" to find its IP address. This is the CLI-equivalent of an HTTP GET of the device configuration.

Task 2 Solution: Configure an interface description and view JSON

What we are doing: Apply a short configuration change (description) using the CLI and verify that the JSON representation reflects that change. This demonstrates how a device config change (a PUT/POST equivalent) changes the resource state.

R1# configure terminal
R1(config)# interface GigabitEthernet0/1
R1(config-if)# description Link-to-R3
R1(config-if)# end

What each command does and why it matters:

configure terminal — enters global configuration mode so you can make changes (this is the procedural step automation would perform with a PUT/POST).
interface GigabitEthernet0/1 — selects the interface configuration context (target resource).
description Link-to-R3 — sets a human-readable description. In REST semantics this is equivalent to sending a resource update (PUT) or create (POST) that changes the device's configuration state.
end — exits configuration mode and returns to privileged EXEC.

Verify (JSON view of that interface):

R1# show running-config interface GigabitEthernet0/1 | format restconf -json
{
  "native": {
    "interface": [
      {
        "name": "GigabitEthernet0/1",
        "description": "Link-to-R3",
        "ip": {
          "address": {
            "primary": {
              "address": "10.10.20.1",
              "mask": "255.255.255.0"
            }
          }
        },
        "shutdown": false
      }
    ]
  }
}

The "description": "Link-to-R3" field confirms the change. In automation, an HTTP PUT/POST request with JSON payload containing this field would achieve the same effect on a RESTCONF-capable device.

Task 3 Solution: DELETE-like removal and mapping REST verbs

What we are doing: Remove the description (DELETE equivalent) and verify the JSON no longer contains the description key.

R1# configure terminal
R1(config)# interface GigabitEthernet0/1
R1(config-if)# no description
R1(config-if)# end

What the commands do and why they matter:

no description — removes the description configuration under that interface. This is the CLI equivalent of an HTTP DELETE against that configuration field/resource.
Removing the description demonstrates idempotence: after the delete, issuing the same delete again will not produce additional change — an important automation property.

Verify:

R1# show running-config interface GigabitEthernet0/1 | format restconf -json
{
  "native": {
    "interface": [
      {
        "name": "GigabitEthernet0/1",
        "description": "",
        "ip": {
          "address": {
            "primary": {
              "address": "10.10.20.1",
              "mask": "255.255.255.0"
            }
          }
        },
        "shutdown": false
      }
    ]
  }
}

The description is now empty, demonstrating the DELETE effect. Automation scripts compare desired state to current state (GET), then perform the minimal changes (POST/PUT/DELETE) to reach desired state.

Real-world context: In production, automation systems will GET the device state (JSON), compute the delta, then apply only the required POST/PUT/DELETE operations. This avoids disrupting unrelated settings and supports safe, repeatable deployments.

Troubleshooting Scenario

Scenario: Description change does not appear in JSON output

Symptom: After running the description Link-to-R3 commands, show running-config | format restconf -json still shows the description as empty.

Your task: Find and fix the issue.

Hint: Think about where you applied the configuration and whether you exited correctly from the configuration mode.

Solution:

Verify you were on the correct device and correct interface.
Re-apply the description and verify immediately.

Commands and explanation:

R1# show running-config interface GigabitEthernet0/1
! (inspect running config to ensure description present)
R1# configure terminal
R1(config)# interface GigabitEthernet0/1
R1(config-if)# description Link-to-R3
R1(config-if)# end
R1# show running-config interface GigabitEthernet0/1 | format restconf -json

If the running-config view still doesn't show the description, ensure you were connected to R1 (check show ip interface brief), and that you used the exact interface name GigabitEthernet0/1. Typos in interface names are a common cause.

Verification Checklist

You retrieved the running-config in JSON with show running-config | format restconf -json.
You configured description Link-to-R3 on GigabitEthernet0/1 and verified the JSON reflects it.
You removed the description with no description and verified the JSON no longer contains it.

Common Mistakes

Symptom	Cause	Fix
`show running-config	format restconf -json` returns unexpected output or empty JSON	Running command on wrong device or privilege level
Description change not visible in JSON	Wrong interface name typed (e.g., Gi0/01)	Use exact name `GigabitEthernet0/1`; re-enter config and verify
Automation script fails to parse JSON	Script expects different JSON structure	Use `show running-config

Warning: When automating, always perform a GET and compute the delta before POST/PUT/DELETE. Blindly issuing changes can lead to unintended configuration differences in production.

Challenge Task

Without step-by-step guidance: Create a small JSON document that represents a VLAN resource with these attributes: vlan_id = 20, name = "Engineering", shutdown = false. Then describe which HTTP verb (POST/PUT) would be appropriate to create this VLAN on a device that accepts RESTCONF JSON payloads, and why. Do not apply configuration on the device — just produce the JSON and justify the choice.

Deliverable: JSON file content and a short explanation of the HTTP verb you chose (one paragraph).

Key takeaway: Viewing device configuration as JSON enables programmatic comparisons (GET), safe creation/replacement (POST/PUT), and deletion (DELETE). When you can read, compute the delta, and apply only necessary changes, automation becomes reliable and repeatable — essential for modern networks.

REST APIs and JSON