Network automation lab 18 of 27
Troubleshooting lab: NETCONF, RESTCONF and YANG automation
Four model-driven scripts and an IOS XE router hide seven faults between them: RESTCONF authentication, an ACL that silently drops NETCONF, a mistyped module name, a reply parsed in the wrong format, a string where YANG wants a boolean, a filter namespace that returns nothing, and an augmented node without its namespace. Diagnose each from the evidence and fix it.
Run this lab
It needs Lite: its 2 nodes are set to 2 vCPU and 5,120 MB in total. That fits the free demo too.
In your workspace: Shared, then Network Automation - CCNA and CCNP Automation guided labs, then 18 - Troubleshooting lab - NETCONF RESTCONF and YANG automation
- Level
- Advanced
- Time
- About 75 minutes
- Nodes need
- 2 vCPU, 5,120 MB
- Smallest plan
- Lite
The scenario
Kestrel Freight's NOC runs four small scripts against the Manchester router xe1: two RESTCONF ones (rc_report.py lists the hostname and interfaces, rc_change.py prepares GigabitEthernet2 as the spare WAN link) and two NETCONF ones (nc_report.py lists interfaces, nc_change.py creates Loopback0). Since a security hardening change last night and a "small tidy-up" of the scripts, every one of them fails, and one of them fails without saying so. Find each fault, fix it in the right place, and prove all four scripts work.
| Item | Intended state |
|---|---|
| xe1 management | 10.10.20.21: SSH 22, RESTCONF on HTTPS 443, NETCONF 830, all authenticated against local users |
| Security policy | only SSH, HTTPS, NETCONF and ping may reach Gi1 (the hardening ACL MGMT-IN stays) |
| GigabitEthernet2 | description WAN to r1 (spare), enabled |
| Loopback0 | 10.255.0.3/32, description Router ID |
What you’ll practise
- Separate transport, authentication and data-model problems in NETCONF and RESTCONF
- Read RESTCONF status codes and error bodies, and NETCONF rpc-errors, to locate a fault
- Recognise silent failures such as an empty NETCONF reply from a wrong namespace
- Fix payloads against the YANG model: module names, types and namespaces of augmented nodes
- Fix device-side access (HTTP authentication, management ACLs) without weakening security
The tasks
- Gather the evidence
- RESTCONF says 401: who decides?
- Fix rc_report.py (two faults)
- Fix rc_change.py
- NETCONF times out: find what's in the way
- Fix nc_report.py: the silent failure
- Fix nc_change.py
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.
Every link, as text
- devbox
eth0to Mgmt (network) - xe1
Gi1to Mgmt (network)
| Node | Device | Image in Add Node | Set to |
|---|---|---|---|
| devbox | EVE-NG GUI server (Docker) | eve-gui-server:latest | 1 vCPU, 1,024 MB |
| xe1 | Cisco CSR 1000v | csr1000vng-universalk9.17.03.08a-serial | 1 vCPU, 4,096 MB |
How to open this lab
Sign in to your workspace at
lab.cloudlabbox.com.In File Manager, open Shared, then the folder
Network Automation - CCNA and CCNP Automation guided labs.Open
18 - Troubleshooting lab - NETCONF RESTCONF and YANG automationand 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
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.