CloudLabBox
Try the free demo

Network automation lab 21 of 27

Capstone: deliver a network change through a pipeline from a source of truth

Deliver a real change the way an automation team does: lint and fix the source of truth, guard it with a Git hook, render the CLI with Jinja2, deploy IOS with Ansible and IOS XE with RESTCONF, configure telemetry and an EEM alert, validate in parallel with Netmiko and ntc-templates, run it all as one idempotent pipeline, prove the alerting with a drill, and release the change with a merge commit and a tag.

Run this lab

It needs Lite: its 4 nodes are set to 4 vCPU and 6,144 MB in total. That fits the free demo too.

In your workspace: Shared, then Network Automation - CCNA and CCNP Automation guided labs, then 21 - Capstone - deliver a network change through a pipeline from a source of truth

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
Advanced
Time
About 180 minutes
Nodes need
4 vCPU, 6,144 MB
Smallest plan
Lite

The scenario

Kestrel Freight's network team has stopped typing configuration into routers. Intent lives in a Git repository, kestrel-netops, and a pipeline makes the network match it. Your first change on the team is CHG-2041: bring the Manchester data centre router xe1 (IOS XE) into the northern OSPF triangle with the Leeds routers r1 and r2 (IOS), with the management baseline, CPU telemetry and an EEM alert for lost adjacencies. Priya Shah, the network lead, has written the change brief and the source of truth, and started three scripts. You'll build the rest of the pipeline, deliver the change with it, prove it works, and release it.

LinkA end (.1)B end (.2)Subnet
Leeds ringr1 Gi0/1r2 Gi0/110.1.12.0/30
Leeds to Manchester, path 1r1 Gi0/2xe1 Gi210.1.13.0/30
Leeds to Manchester, path 2r2 Gi0/2xe1 Gi310.1.23.0/30

Loopback0: r1 10.255.0.1, r2 10.255.0.2, xe1 10.255.0.3, all /32, all in OSPF process 1, area 0. NTP and syslog server: the workstation, 10.10.20.10. Telemetry collector: 10.10.20.10, TCP 57500.

The routers start with only their management address (Gi0/0 or Gi1, 10.10.20.11, .12 and .21) and the netops / NetOps-Lab1 login; xe1 has RESTCONF and NETCONF enabled. Everything is in ~/lab/capstone, a clone of the team repository whose origin is /srv/git/kestrel-netops.git: the brief (README.md), sot.yaml, sotlib.py (derives per-router data from it), rc.py (the RESTCONF client from lab 10), collectors.py (syslog and telemetry receivers), and skeletons of check_sot.py, deploy_xe.py and validate.py.

What you’ll practise

  • Validate a source of truth before use, and stop bad intent with a versioned Git pre-commit hook
  • Generate the CLI configuration and the Ansible inventory from the source of truth
  • Deploy IOS with Ansible and IOS XE with RESTCONF, idempotently, using IETF, native and telemetry YANG models
  • Write pre- and post-change validation that runs in parallel and records evidence
  • Chain the stages into a pipeline (lint, render, preflight, deploy, validate) and prove a second run changes nothing
  • Prove monitoring end to end (telemetry dial-out, syslog and an EEM alert), then merge, tag and push the change

The tasks

  1. Read the change and start a branch
  2. Lint the source of truth
  3. A pre-commit hook that guards the source of truth
  4. Render the intended configuration
  5. An inventory generated from the source of truth
  6. Write the validation before the change
  7. Deploy the CLI configuration with Ansible
  8. Deploy IOS XE through RESTCONF
  9. One command: the pipeline
  10. Prove the monitoring works
  11. Evidence, merge, tag and push

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 Capstone - deliver a network change through a pipeline from a source of truth4 nodes and 1 network, 7 links. Every link is listed as text below the diagram.devboxr1r2xe1Mgmteth0Gi0/1Gi0/1Gi0/2Gi3Gi0/0Gi1Gi0/2Gi2Gi0/0
4 nodes and 1 network, with the interface names each link uses. On a narrow screen, scroll the diagram sideways.
Every link, as text
  • devbox eth0 to Mgmt (network)
  • r1 Gi0/0 to Mgmt (network)
  • r2 Gi0/0 to Mgmt (network)
  • xe1 Gi1 to Mgmt (network)
  • r1 Gi0/1 to r2 Gi0/1
  • r1 Gi0/2 to xe1 Gi2
  • r2 Gi0/2 to xe1 Gi3
Nodes in Capstone: deliver a network change through a pipeline from a source of truth, 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
r1Cisco IOSvvios-adventerprisek9-m.spa.159-3.m91 vCPU, 512 MB
r2Cisco IOSvvios-adventerprisek9-m.spa.159-3.m91 vCPU, 512 MB
xe1Cisco CSR 1000vcsr1000vng-universalk9.17.03.08a-serial1 vCPU, 4,096 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 21 - Capstone - deliver a network change through a pipeline from a source of truth 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.