Network automation lab 10 of 27

RESTCONF configuration management: desired state, native models and idempotency

Manage an IOS XE router's interfaces, OSPF and static routes as a list of RESTCONF resources in YAML: discover the JSON with the 'configure once, read back' technique, choose PUT or PATCH, and build an apply script that only changes what differs, then prove it by forming an OSPF adjacency with a neighbour.

Run this lab

It needs Lite: its 3 nodes are set to 3 vCPU and 5,632 MB in total. That fits the free demo too.

In your workspace: Shared, then Network Automation - CCNA and CCNP Automation guided labs, then 10 - RESTCONF configuration management - desired state native models and idempotency

Try it free for 30 minutesRun it on Lite from £3 a day

The free demo needs no card and no email. Every lab plan includes every guided lab.

Level
Intermediate
Time
About 80 minutes
Nodes need
3 vCPU, 5,632 MB
Smallest plan
Lite

The scenario

Kestrel Freight wants the Manchester router xe1 managed only through its API. Its desired state will live in Git as a YAML file of RESTCONF resources, and a script will make the router match it, as often as anyone likes, changing nothing when nothing needs changing. Today's state: the link to the branch router r1, a loopback, OSPF with r1, and a static route to a depot LAN behind r1. r1 is already configured and waiting for xe1 to join OSPF.

DeviceInterfaceAddress
xe1Gi1 (management)10.10.20.21/24
xe1Gi2to configure: 10.1.13.2/30, "Link to r1 Gi0/1"
xe1Loopback0to configure: 10.255.0.3/32, "Router ID"
r1Gi0/1 · Loopback010.1.13.1/30 · 10.255.0.1/32, OSPF area 0 ready

xe1 also needs OSPF process 1 (router ID 10.255.0.3, area 0 on 10.1.13.0/30 and its loopback) and a static route to 192.0.2.0/24 via r1 (10.1.13.1). Files in ~/lab: rc.py (a small RESTCONF client), show.py (prints any resource as JSON), desired.yaml (one entry so far) and apply.py (with one TODO). Login netops / NetOps-Lab1.

What you’ll practise

  • Discover the JSON shape of IETF and Cisco native YANG data by reading it back from the device
  • Configure interfaces, OSPF and static routes over RESTCONF with PUT and PATCH
  • Represent device configuration as YAML/JSON desired state derived from YANG models
  • Make a RESTCONF automation idempotent: read, compare, change only what differs
  • Verify the network effect (OSPF adjacency, routes) and save the configuration

The tasks

  1. Read the client and discover the data
  2. Apply the first desired-state entry
  3. Loopback0 with the native model
  4. OSPF with the native model
  5. A static route
  6. Make it idempotent
  7. Delete, check, save

The Lab Tasks pane has the scenario, these tasks, the checks to run, hints and the full solution.

Topology and devices

The network as it opens in EVE-NG, drawn from the lab’s own canvas, and the image each node runs.

Topology of RESTCONF configuration management - desired state native models and idempotency3 nodes and 1 network, 4 links. Every link is listed as text below the diagram.devboxxe1r1Mgmteth0Gi2Gi0/1Gi1Gi0/0
3 nodes and 1 network, with the interface names each link uses. On a narrow screen, scroll the diagram sideways.
Nodes in RESTCONF configuration management: desired state, native models and idempotency, with the image each runs and the vCPU and RAM it’s set to
NodeDeviceImage in Add NodeSet to
devboxEVE-NG GUI server (Docker)eve-gui-server:latest1 vCPU, 1,024 MB
xe1Cisco CSR 1000vcsr1000vng-universalk9.17.03.08a-serial1 vCPU, 4,096 MB
r1Cisco IOSvvios-adventerprisek9-m.spa.159-3.m91 vCPU, 512 MB

How to open this lab

  1. Sign in to your workspace at lab.cloudlabbox.com.

  2. In File Manager, open Shared, then the folder Network Automation - CCNA and CCNP Automation guided labs.

  3. Open 10 - RESTCONF configuration management - desired state native models and idempotency and start its nodes, then open Lab Tasks for the scenario and the steps.

The lab is read-only. You can start the nodes and configure the devices, but changes to the topology can’t be saved. To change it, rebuild it in your own folder.

More Network automation labs

All Network automation labs

Related labs in other courses

CloudLabBox is independent of Cisco. The lab follows exam topics and isn’t vendor training material; vendor names identify the exams and the images in the workspace.