What is the main focus of blogg #3 in the CCIE Automation journey?

Blogg #3 focuses entirely on NETCONF and YANG, and how these technologies can be used in practice to orchestrate configuration changes and retrieve data from network devices.

What is NETCONF, and why is it important for network automation?

NETCONF is a protocol that enables structured communication with network devices using XML. Instead of sending unstructured CLI commands, NETCONF provides predictable, machine-readable, and automatable configuration management.

What role does YANG play in this solution?

YANG defines the data models that specify what data can be sent and retrieved via NETCONF. It acts as a contract between the client and the device, enabling precise interaction with configuration and operational state.

What is the Orchestration API built in blogg #3?

The Orchestration API is a dedicated microservice that allows users to create and execute NETCONF jobs. Jobs are stored in a database and immediately triggered to perform NETCONF operations across all devices in the inventory.

How do the Inventory service, Orchestration service, and CLI tool work together?

The CLI tool retrieves all devices from the Inventory API, creates jobs in the Orchestration API, and executes NETCONF operations across the entire infrastructure in a single, unified workflow.

Why is this architecture relevant for CCIE Automation?

The architecture covers multiple blueprint topics and demonstrates practical use of REST APIs, NETCONF, YANG, microservices, and automation workflows—closely mirroring the skills tested in the CCIE Automation lab exam.

What is planned next in the blog series?

Blogg #4 will focus on Ansible, including roles, variables, templating, loops, conditionals, and the use of connection plug-ins such as NETCONF and HTTPAPI.

Sicra supports organizations with modern network automation and architecture initiatives that combine networking expertise with software development and secure operations. Read more about "Network" here > Read more about "Secure software development" here > Read more about "Cloud (Azure, AWS, Google)" here > Read more about "Project management" here >

Blog

28.08.2025

min read

[My journey to CCIE Automation #3] Orchestration API and NETCONF

In blog #3 of the CCIE Automation journey, the focus is on NETCONF and YANG. An Orchestration API and a Python-based CLI tool are built to run NETCONF jobs across all devices in the inventory in a single flow.

<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >[My journey to CCIE Automation #3] Orchestration API and NETCONF</span>

(This article was originally published on Bluetree.no. Following the merger of Sicra and Bluetree, content from Bluetree has now been migrated to Sicra.)

[My journey to CCIE Automation #3] Orchestration API and NETCONF is part of an ongoing series about my CCIE Automation journey. In the previous post, I built an Inventory REST API as a foundation for further automation. This time, I move on to NETCONF and build an Orchestration API to execute jobs against devices in the inventory.

Blog #3

This time has been all about getting deeper into NETCONF and YANG – two cornerstones of modern network automation.

NETCONF and ncclient

NETCONF is a protocol that lets you communicate with network devices over XML. Instead of pushing raw CLI commands, you send structured data in XML.

To work with it in Python, I used the ncclient library:

It establishes a NETCONF session to the device
Lets you perform operations like get, get-config, edit-config
Uses XML payloads to push or retrieve configuration/state

YANG

YANG is the data modeling language that defines what kind of data you can send with NETCONF.

It describes device configuration and state in a structured way.
I familarized my self with Cisco Yang Suite, which is a tool that make it a bit easier to understand how Yang works.
To access specific parts of the model, you often use XPath queries. Think of it as a GPS coordinate inside the XML tree – so instead of digging through thousands of lines of config, you can just ask:
“Give me the interface description for GigabitEthernet0/0/0”

Orchestration Service + Automation script

Armed with this knowledge, I built a new Nautix service: Orchestration

Orchestration Service

A Flask app serving an Orchestration API.
API endpoints to create and list jobs
Jobs are stored in a database and immediately trigger a NETCONF operation with ncclient

This means I can now go from “devices in inventory” → to “execute NETCONF action” in one flow. Which brings me to a new automation script.

Run netconf job on all devices in inventory

A python Click tool that:

Takes XML path, NETCONF operation method, username, and password as parameters
Fetches all devices from the Inventory API
Creates jobs in the Orchestration API

Which pushes XML configs or retrieves data
Displays the results

Look into my GitLab repository for more details — I’ve tried to comment the code as best as I can.

Service Interactions update

Since a new service is added, the Nautix diagram has also been updated:

image-png-Aug-29-2025-12-11-03-6176-AM

Reflections #3

NETCONF and YANG were abstract at first, but working hands-on with ncclient and YANG Suite helped a lot.
There is for sure a lot of improvements to be made. But I have limited time, so it's best effort.

What’s next

In blog #4 I will focus on working with Ansible:

Blueprint item 2.7 Create and use a role by utilizing Ansible to manage infrastructure, given support documentation
2.7.a Loop control
2.7.b Conditionals
2.7.c Use of variables and templating
2.7.d Use of connection plug-ins such as network CLI, HTTPAPI, and NETCONF