Event Handling System

The Event Handling System (EHS) is a framework that allows user-defined behavior to be configured on the router. EHS allows you to automate the router response to specific events. When a matching log event (trigger) occurs, EHS can run either a CLI script or a Python 3 application. You can use regular expressions to define flexible trigger conditions.

Basic EHS Object Handling (MD-CLI)

EHS configuration

You can configure complex rules to match log events as the trigger for EHS. When a log event is generated in SR OS, it is subject to being discarded if suppression and throttling are configured, before it is evaluated as a trigger for EHS, according to the following

• EHS does not trigger on log events that are suppressed through the configuration.

• EHS does not trigger on log events throttled by the logger

When using model-driven configuration mode and the MD-CLI, EHS can trigger a Python application that is executed inside a Python interpreter running on SR OS.

Python applications are not supported in classic configuration mode or mixed configuration mode.

When developing an EHS Python application, the event attributes are passed to the application using the get_event function in the pysros.ehs module

EHS debounce

EHS debounce (also called dampening) is the ability to trigger an action (for example, an EHS script) if an event happens (N) times within a specific time window (S)

For example, when linkDown occurs N times in S seconds, an EHS script is triggered to shut down the port.

Executing EHS

The execution of EHS scripts depends on the CLI engine associated with the configuration mode. The EHS script execution engine is based on the configured primary CLI engine.

Use the following command to configure the primary CLI engine.

/configure system management-interface cli cli-engine [md-cli]

Why Is EHS Required?

Traditional monitoring relies on polling. A system checks the router at regular intervals and responds only when it detects a problem.

This delay can cause important diagnostic information to be missed. For example, a flapping card, temporary hardware fault, or brief control-plane issue may recover before the next poll, leaving little or no evidence of what happened.

EHS closes this gap by reacting directly to the router’s internal events and logs as soon as a problem occurs.

Instead of checking the router every few minutes and hoping the evidence is still available, EHS responds immediately when the event happens.

For example, if a line card fails, EHS can automatically generate a tech-support dump at that exact moment. This captures the system state during the failure, including process information, memory, and hardware details.

The key benefit of EHS is immediate, event-driven diagnostics.

The Core Advantages

• Zero detection latency - the action fires as part of the same event pipeline that logs the failure, not on a follow-up poll.

• No external dependency for the trigger - the router doesn't need a collector or NMS in the loop to notice something's wrong; the event system is native to SR OS

• Consistent diagnostic capture - every occurrence of a defined event gets the same automated response, removing "did anyone remember to grab the tech-support before it got busy" from the equation.

• Extensible beyond diagnostics - EHS isn't limited to capturing dumps; it can drive remediation actions, notifications, or config changes tied to specific log events

What Is MD-CLI?

MD-CLI (Model-Driven CLI) is SR OS's YANG-based command-line interface, introduced alongside the model-driven management stack that also powers NETCONF and gNMI on the platform. Unlike the legacy "classic" CLI, every command in MD-CLI maps to a structured YANG data node; configuration, state, and actions are all defined against the same schema the router exposes over its programmatic interfaces.

Practically, this means:

1. Structured, predictable command trees - command hierarchy mirrors the YANG model, so tab-completion and pwc json-instance-path reveal exactly how a command maps to the underlying data model.

2. Consistency across interfaces - a config change made via MD-CLI, NETCONF, or gNMI converges on the same model, so there's no drift between "what the CLI shows" and "what an automation tool sees."

Why MD-CLI for EHS, Specifically?

This last point turned out to matter more than expected. While building an EHS workflow to auto-capture a tech-support dump on a cardFailure event, the initial approach used a pySROS python-script triggered on-box by EHS, calling admin tech-support via a pySROS management session.

That call failed outright:

SrosMgmtError: MINOR: MGMT_AGENT #2007: Operation failed - tech-support not supported from pySROS

This wasn't a syntax issue. The SR OS version I was testing on explicitly blocks tech-support generation from being invoked through the pySROS management agent, on-box, regardless of whether it's called via a structured action or the CLI passthrough. The same call worked without issue when run from an external pySROS session connecting into the router, which confirmed the restriction is specific to the on-box Python execution context, not the tech-support action itself.

The practical takeaway: for on-box, in-the-moment EHS actions, MD-CLI script execution is currently the more reliable path on this platform/release. Python-based EHS remains valuable for logic that needs conditionals, state, or external calls, but for firing built-in admin operations like tech-support, MD-CLI's direct execution model avoids a restriction that isn't obvious until you hit it in testing.

How do we configure it?

In this use case, we are demonstrating how a tech-support file can be collected if there is a cardFailure event

1. Create and store the CLI script file (CF/FTP/TFTP)

file 
edit techdump.txt 
/admin tech-support cf3:/test.txt 

2. Create script: "configure system script-control script"

/configure system script-control script "techdump" owner "TiMOS CLI" description " Automatic techdumps "
/configure system script-control script "techdump" owner "TiMOS CLI" location "cf3:\techdump.txt"
/configure system script-control script "techdump" owner "TiMOS CLI" admin-state enable

3. Configure script-policy : “configure system script-control script-policy”

/configure system script-control script-policy "autodump" owner "TiMOS CLI" admin-state enable
/configure system script-control script-policy "autodump" owner "TiMOS CLI" results "cf3:\"
/configure system script-control script-policy "autodump" owner "TiMOS CLI" script name "techdump"

4. Configure log filter: “configure log filter"

/configure log filter "100" named-entry "1" action forward
/configure log filter "100" named-entry "1" match application eq logger
/configure log filter "100" named-entry "1" match event eq 2011
/configure log filter "100" named-entry "1" match subject eq "CardFailure"

5. Configure event-handler: “configure log event-handling handler”

/configure log event-handling handler "handler-1" admin-state enable
/configure log event-handling handler "handler-1" entry 1 admin-state enable
/configure log event-handling handler "handler-1" entry 1 script-policy name "autodump"

6. Configure event-trigger: “configure log event-trigger event”

/configure log event-trigger logger event tmnxTestEvent admin-state enable
/configure log event-trigger logger event tmnxTestEvent entry 10 filter "100"
/configure log event-trigger logger event tmnxTestEvent entry 10 handler "handler-1"

How it works

In this scenario, I'm going to simulate a Card Failure using a Test Log Event.

Test log event

The SR OS provides the tmnxTestEvent event with optional custom text. The test event can be generated with the perform log test-event command. The custom-text command in this context replaces the default message of the event.

Step 1 - Trigger the event

perform log test-event custom-text "CardFailure"

Step 2 - Check logs

This will indicate if the execution of the script is successful

Log 99 log-name 99
==================================================================
Description: Default System Log
Memory Log contents  [size=500   next event=216  (not wrapped)]

215 2026/08/11 03:31:49.231 UTC MAJOR: SYSTEM #2053 Base CLI 'exec'
"The CLI user initiated 'exec' operation to process the commands in the SROS CLI file cf3:\techdump.txt has completed with the result of success"

214 2026/08/11 03:31:37.373 UTC MAJOR: SYSTEM #2052 Base CLI 'exec'
"A CLI user has initiated an 'exec' operation to process the commands in the SROS CLI file cf3:\techdump.txt"

213 2026/08/11 03:31:37.372 UTC MINOR: SYSTEM #2069 Base EHS script
"Ehs handler:"handler-1" with the description: "" was invoked by the cli-user account "admin"."

212 2026/08/11 03:31:37.372 UTC INDETERMINATE: LOGGER #2011 Base Event Test
"CardFailure"

Step 3 - Check the run history

/show system script-control script-policy "autodump" 

==================================================================
Script Run History Status Information
------------------------------------------------------------------
Script Run #4
------------------------------------------------------------------
Start time    : 2026/08/11 03:31:37  UTC
End time      : 2026/08/11 03:31:49  UTC
Elapsed time  : 0d 00:00:12             Lifetime      : 0d 00:00:00
State         : terminated              Run exit code : noError
Result time   : 2026/08/11 03:31:49  UTC
Keep history  : 0d 00:55:03
Error time    : never
Source file   : cf3:\techdump.txt
Results file  : cf3:\_20260811-033137-UTC.372706.out
Run exit      : Success
Error         : N/A
Application   : event-script            Auth. user ac*: admin
* indicates that the corresponding row element may have been truncated.
==================================================================

Step 4 - Output File

8/11/2026  03:31a              555368 test.txt
05/11/2026  02:36a             6203920 yang.tim
      72 File(s)               16235322 bytes.
      1 Dir(s)            249645916160 bytes free.
[/file "cf3:\"]

Conclusion

The Event Handling System gives Nokia SR OS the ability to react to log events on-box, in real time, closing the gap between a failure occurring and diagnostics being captured. MD-CLI is what makes those reactions dependable, as a native model-driven interface, CLI scripts under script-control execute built-in operations like admin tech-support directly and predictably, tied to the same event pipeline that logs the failure itself.

Together, EHS and MD-CLI turn reactive diagnostic capture from a manual, easily-missed step into something that happens automatically, consistently, every time the trigger condition occurs.

Most network automation projects focus on configuration deployment. Engineers use tools such as Python, Ansible, and NetBox to push changes across hundreds of devices.

However, one critical question remains:

How do you verify that the network is operating correctly after a change?

This is where Cisco pyATS and Genie become valuable.

pyATS (Python Automated Test Systems) is Cisco's open-source network testing and automation framework. At its core, it gives you a structured, programmatic way to connect to network devices, run commands, and validate results instead of manually SSH'ing in and reading the output.

Genie sits on top of pyATS and adds the parts that make it genuinely useful day-to-day :

• Parsers — convert raw CLI text into structured Python dictionaries

• Models/Ops — vendor-agnostic representations of network features (BGP, OSPF, interfaces, etc.), built by running several show commands and assembling them into one object

• Diff utilities — compare two snapshots of state and show exactly what changed

• A test framework (aetest) — for writing pass/fail validation scripts

Why Traditional Validation Is Difficult ?

After a maintenance window, engineers typically perform manual checks such as:

• Verify interfaces are up

• Check routing adjacencies

• Confirm BGP sessions

• Verify MPLS LSPs

• Check CPU and memory utilization

This approach has several challenges:

• Time-consuming

• Error-prone

• Difficult to scale

• No historical comparison

• Inconsistent validation procedures

As networks grow, manual validation becomes increasingly unreliable.

What Problem Does pyATS Solve?

If you've ever SSH'd into a router, run a show command, looked at the output, copy-pasted it into a spreadsheet and then repeated that for 20 routers .pyATS and Genie automate exactly that. The result comes back as structured Python data (dictionaries and lists) instead of plain text .

Topology

Step 1 - Install pyATS

Use a virtual environment so this doesn't interfere with other Python projects.

python3 -m venv pyats-env
source pyats-env/bin/activate
pip install pyats[full]

Check if it worked:

pyats version check

You should see version numbers for pyATS and pyATS Library (Genie).

Step 2 — Create a Testbed File

A testbed is a YAML file describing your device basically an inventory file. This is the only "config" pyATS needs.

Create testbed.yaml:

testbed:
  name: my_first_lab

devices:
  cisco_xrv9000:
    os: iosxr
    type: router
    connections:
      defaults:
        class: unicon.Unicon
      cli:
        protocol: ssh
        ip: 172.20.20.15
        port: 22
    credentials:
      default:
        username: <username>
        password: <password>

Step 3 — Connect to a Device

Your first script just connect and run a command, the "old fashioned" way:

# 01_connect.py

from genie.testbed import load

tb = load("testbed.yaml")

router1 = tb.devices["cisco_xrv9000"]
router1.connect()

output = router1.execute("show version")
print(output)

router1.disconnect()

Execute it :

python 01_connect.py

At this point, output is just a big string same as what you'd see in a terminal. Nothing magic yet. That changes in the next step.

Step 4 — Your First Parse (The Magic Step)

This is the single most useful thing Genie does. Instead of execute(), use parse():

# 02_parse.py
from genie.testbed import load

tb = load("testbed.yaml")
router1 = tb.devices["cisco_xrv9000"]
router1.connect()

# The key difference: parse() instead of execute()
parsed = router1.parse("show ip interface brief")

print(parsed)

router1.disconnect()

Expected Output:

2026-06-19 13:23:34,058: %UNICON-INFO: +++ cisco_xrv9000 with via 'cli': executing command 'show ip interface brief' +++
show ip interface brief
Fri Jun 19 01:24:13.557 UTC

Interface                      IP-Address      Status          Protocol Vrf-Name
Loopback0                      10.10.10.3      Up              Up       default
Loopback100                    172.165.11.1    Up              Up       multi-vendor
MgmtEth0/RP0/CPU0/0            10.0.0.15       Up              Up       clab-mgmt
GigabitEthernet0/0/0/0         192.168.1.3     Up              Up       default
GigabitEthernet0/0/0/1         unassigned      Shutdown        Down     default
GigabitEthernet0/0/0/2         10.57.254.3     Up              Up       multi-vendor

# Magic of parsing is instead of receiving a text you get structured data - python dictionary 

RP/0/RP0/CPU0:cisco_xrv9000#
{'interface': {'Loopback0': {'ip_address': '10.10.10.3', 'interface_status': 'Up', 'protocol_status': 'Up', 'vrf_name': 'default'}, 'Loopback100': {'ip_address': '172.165.11.1', 'interface_status': 'Up', 'protocol_status': 'Up', 'vrf_name': 'multi-vendor'}, 'MgmtEth0/RP0/CPU0/0': {'ip_address': '10.0.0.15', 'interface_status': 'Up', 'protocol_status': 'Up', 'vrf_name': 'clab-mgmt'}, 'GigabitEthernet0/0/0/0': {'ip_address': '192.168.1.3', 'interface_status': 'Up', 'protocol_status': 'Up', 'vrf_name': 'default'}, 'GigabitEthernet0/0/0/1': {'ip_address': 'unassigned', 'interface_status': 'Shutdown', 'protocol_status': 'Down', 'vrf_name': 'default'}, 'GigabitEthernet0/0/0/2': {'ip_address': '10.57.254.3', 'interface_status': 'Up', 'protocol_status': 'Up', 'vrf_name':

Now you can use it like any Python dict:

for intf, details in parsed['interface'].items():
    if details['interface_status'] != 'Up':
        print(f"⚠️  {intf} is DOWN")
    else:
        print(f"✅ {intf} is UP — {details['ip_address']}")

Expected Output:

2026-06-19 13:59:52,422: %UNICON-INFO: +++ cisco_xrv9000 with via 'cli': executing command 'show ip interface brief' +++
show ip interface brief
Fri Jun 19 02:00:31.950 UTC

Interface                      IP-Address      Status          Protocol Vrf-Name
Loopback0                      10.10.10.3      Up              Up       default
Loopback100                    172.165.11.1    Up              Up       multi-vendor
MgmtEth0/RP0/CPU0/0            10.0.0.15       Up              Up       clab-mgmt
GigabitEthernet0/0/0/0         192.168.1.3     Up              Up       default
GigabitEthernet0/0/0/1         unassigned      Shutdown        Down     default
GigabitEthernet0/0/0/2         10.57.254.3     Up              Up       multi-vendor

RP/0/RP0/CPU0:cisco_xrv9000#
✅ Loopback0 is UP — 10.10.10.3
✅ Loopback100 is UP — 172.165.11.1
✅ MgmtEth0/RP0/CPU0/0 is UP — 10.0.0.15
✅ GigabitEthernet0/0/0/0 is UP — 192.168.1.3
⚠️  GigabitEthernet0/0/0/1 is DOWN
✅ GigabitEthernet0/0/0/2 is UP — 10.57.254.3

That's it. You just turned CLI output into something you can filter, alert on, or feed into another system with no regex.

Step 5 — Don't Know If a Parser Exists? Check First

Not every show command has a parser . Two ways to check before you write code:

Option A — From the command line:

genie parse "show ip interface brief" \
    --testbed-file testbed.yaml \
    --devices cisco_xrv9000

Expected Output:

0%|                                                                                 | 0/1 [00:00<?, ?it/s]{
  "interface": {
    "GigabitEthernet0/0/0/0": {
      "interface_status": "Up",
      "ip_address": "192.168.1.3",
      "protocol_status": "Up",
      "vrf_name": "default"
    },
    "GigabitEthernet0/0/0/1": {
      "interface_status": "Shutdown",
      "ip_address": "unassigned",
      "protocol_status": "Down",
      "vrf_name": "default"
    },
    "GigabitEthernet0/0/0/2": {
      "interface_status": "Up",
      "ip_address": "10.57.254.3",
      "protocol_status": "Up",
      "vrf_name": "multi-vendor"
    },
    "Loopback0": {
      "interface_status": "Up",
      "ip_address": "10.10.10.3",
      "protocol_status": "Up",
      "vrf_name": "default"
    },
    "Loopback100": {
      "interface_status": "Up",
      "ip_address": "172.165.11.1",
      "protocol_status": "Up",
      "vrf_name": "multi-vendor"
    },
    "MgmtEth0/RP0/CPU0/0": {
      "interface_status": "Up",
      "ip_address": "10.0.0.15",
      "protocol_status": "Up",
      "vrf_name": "clab-mgmt"
    }
  }
}
100%|██████████████████████████████████████████████████████████████████████████| 1/1 [00:00<00:00,  1.25it/s]

Option B — Browse online :

Visit the Genie Feature Browser (pubhub.devnetcloud.com) and search for your platform + command.

Step 6 — learn(): Snapshot an Entire Feature

parse() handles one command. learn() runs several commands and builds a complete model of a feature like OSPF, BGP, or interfaces all in one line.

from genie.testbed import load

tb = load("testbed.yaml")
router1 = tb.devices["cisco_xrv9000"]
router1.connect()

# One line — runs multiple show commands behind the scenes
interfaces = router1.learn("interface")

for name, data in interfaces.info.items():
    print(name, "->", data.get("oper_status"))

router1.disconnect()

Expected output :

2026-06-19 14:09:33,278: %UNICON-INFO: +++ cisco_xrv9000 with via 'cli': executing command 'show vrf all detail' +++
show vrf all detail
Fri Jun 19 02:10:12.809 UTC

VRF clab-mgmt; RD not set; VPN ID not set
VRF mode: Regular
Description Containerlab management VRF (DO NOT DELETE)
Interfaces:
  MgmtEth0/RP0/CPU0/0
Address family IPV4 Unicast
  No import VPN route-target communities
  No export VPN route-target communities
  No import route policy
  No export route policy
Address family IPV6 Unicast
  No import VPN route-target communities
  No export VPN route-target communities
  No import route policy
  No export route policy

2026-06-19 14:09:33,656: %UNICON-INFO: +++ cisco_xrv9000 with via 'cli': executing command 'show interface detail' +++
show interface detail
Fri Jun 19 02:10:13.162 UTC
Loopback0 is up, line protocol is up
  Interface state transitions: 1
  Hardware is Loopback interface(s)
  Internet address is 10.10.10.3/32
  MTU 1500 bytes, BW 0 Kbit
     reliability Unknown, txload Unknown, rxload Unknown
  Encapsulation Loopback,  loopback not set,
  Last link flapped 9w4d
  Last input Unknown, output Unknown
  Last clearing of "show interface" counters Unknown
  Input/output data rate is disabled.

Loopback100 is up, line protocol is up
  Interface state transitions: 1
  Hardware is Loopback interface(s)
  Description: VRF-TEST-LOOPBACK
  Internet address is 172.165.11.1/24
  MTU 1500 bytes, BW 0 Kbit
     reliability Unknown, txload Unknown, rxload Unknown
  Encapsulation Loopback,  loopback not set,
  Last link flapped 9w4d
  Last input Unknown, output Unknown
  Last clearing of "show interface" counters Unknown
  Input/output data rate is disabled.

2026-06-19 14:09:34,238: %UNICON-INFO: +++ cisco_xrv9000 with via 'cli': executing command 'show ethernet tags' +++
show ethernet tags
Fri Jun 19 02:10:13.743 UTC
St:    AD - Administratively Down, Dn - Down, Up - Up
Ly:    L2 - Switched layer 2 service, L3 = Terminated layer 3 service,
Xtra   C - Match on Cos, E  - Match on Ethertype, M - Match on source MAC
-,+:   Ingress rewrite operation; number of tags to pop and push respectively

2026-06-19 14:09:34,607: %UNICON-INFO: +++ cisco_xrv9000 with via 'cli': executing command 'show interfaces accounting' +++
show interfaces accounting
Fri Jun 19 02:10:14.110 UTC
No accounting statistics available for Loopback100

No accounting statistics available for Null0

GigabitEthernet0/0/0/0
  Protocol              Pkts In         Chars In     Pkts Out        Chars Out
  IPV4_UNICAST          3517881        270803858           27             2220
  IPV4_MULTICAST              0                0      1264246         88497220
  MPLS                    51762          3974532      3032839       1444721933
  ARP                       407            24420          407            17094

Step 7 — Before/After Diffs (Change Window Pattern)

This is the pattern that makes pyATS genuinely useful day-to-day: snapshot, change, snapshot again, diff.

There are two ways to do this a no-code CLI option (great for quick checks and change windows), and a Python option (better when this logic needs to live inside a larger script).

Option A — No code: genie learn + genie diff

Collect a baseline before your change:

 genie learn bgp \
    --testbed-file testbed.yaml \
    --output baseline

Expected Output:

Learning '['bgp']' on devices '['cisco_xrv9000']'
100%|████████████████████████████████████| 1/1 [00:10<00:00, 10.03s/it]
+=============================================================+
| Genie Learn Summary for device cisco_xrv9000                                 |
+=============================================================+
|  Connected to cisco_xrv9000                                                  |
|  -   Log: baseline/connection_cisco_xrv9000.txt                              |
|-------------------------------------------------------------|
|  Learnt feature 'bgp'                                                        |
|  -  Ops structure:  baseline/bgp_iosxr_cisco_xrv9000_ops.txt                 |
|  -  Device Console: baseline/bgp_iosxr_cisco_xrv9000_console.txt                  |
|=============================================================|

Collect the current state:

 genie learn bgp \
    --testbed-file testbed.yaml \
    --output output

Expected Output:

Learning '['bgp']' on devices '['cisco_xrv9000']'
100%|███████████████████████████████████████| 1/1 [00:10<00:00, 10.53s/it]
+=============================================================+
| Genie Learn Summary for device cisco_xrv9000                                 |
+=============================================================+
|  Connected to cisco_xrv9000                                                  |
|  -   Log: current/connection_cisco_xrv9000.txt                               |
|-------------------------------------------------------------|
|  Learnt feature 'bgp'                                                        |
|  -  Ops structure:  current/bgp_iosxr_cisco_xrv9000_ops.txt                  |
|  -  Device Console:   current/bgp_iosxr_cisco_xrv9000_console.txt                   |
|=============================================================|

Now diff the two snapshot folders:

genie diff baseline current

1it [00:00, 441.13it/s]
+=============================================================+
| Genie Diff Summary between directories baseline/ and current/                |
+=============================================================+
|  File: bgp_iosxr_cisco_xrv9000_ops.txt                                       |
|   - Diff can be found at ./diff_bgp_iosxr_cisco_xrv9000_ops.txt              |
|-------------------------------------------------------------|

Expected Output:

cat ./diff_bgp_iosxr_cisco_xrv9000_ops.txt

--- baseline/bgp_iosxr_cisco_xrv9000_ops.txt
+++ current/bgp_iosxr_cisco_xrv9000_ops.txt
 info:
  instance:
   default:
    vrf:
     default:
      neighbor:
       10.10.10.1:
-       session_state: established
+       session_state: idle
-       bgp_negotiated_capabilities:
-        four_octets_asn: advertised received
-        route_refresh: advertised received
-        vpnv4_unicast: advertised received
 routes_per_peer:
  instance:
   default:
    vrf:
     default:
      neighbor:
       10.10.10.1:
        address_family:
-        vpnv4 unicast RD 65000:10:
-         routes:
-          10.57.255.0/24:
-           index:
-            1:
-             next_hop: 10.10.10.1
-             origin_codes: i
-             status_codes: *>i
-          172.165.10.0/24:
-           index:
-            1:
-             next_hop: 10.10.10.1
-             origin_codes: i
-             status_codes: *>i
-        vpnv4 unicast RD 65000:30:
-         advertised:
-          10.57.254.0/24:
-           index:
-            1:
-             froms: Local
-             next_hop: 10.10.10.3
-             origin_code: ?
-          172.165.11.0/24:
-           index:
-            1:
-             froms: Local
-             next_hop: 10.10.10.3
-             origin_code: ?
 table:
  instance:
   default:
    vrf:
     default:
      address_family:
-      vpnv4 unicast RD 65000:10:
-       prefixes:
-        10.57.255.0/24:
-         index:
-          1:
-           locprf: 100
-           next_hop: 10.10.10.1
-           origin_codes: i
-           status_codes: *>i
-           weight: 0
-        172.165.10.0/24:
-         index:
-          1:
-           locprf: 100
-           next_hop: 10.10.10.1
-           origin_codes: i
-           status_codes: *>i
-           weight: 0
-       route_distinguisher: 65000:10

Step 8 — A Simple Pass/Fail Test

pyATS has a built-in test framework called aetest. Here's the minimum useful structure: connect, check something, report pass/fail.

from pyats import aetest
from genie.testbed import load


class CommonSetup(aetest.CommonSetup):
    @aetest.subsection
    def connect(self, testbed):
        for device in testbed.devices.values():
            device.connect()


class CheckBGP(aetest.Testcase):
    @aetest.test
    def all_neighbors_established(self, testbed):
        router1 = testbed.devices["cisco_xrv9000"]
        bgp = router1.parse("show bgp summary")

        for instance_name, instance_data in bgp["instance"].items():
            for vrf_name, vrf_data in instance_data.get("vrf", {}).items():
                for ip, neighbor_data in vrf_data.get("neighbor", {}).items():

                    # state_pfxrcd is nested under address_family on XR
                    af_data = neighbor_data.get("address_family", {})
                    established = False

                    for af_name, af_details in af_data.items():
                        pfxrcd = af_details.get("state_pfxrcd")
                        up_down = af_details.get("up_down")

                        # A numeric state_pfxrcd means session is Established
                        if pfxrcd is not None and str(pfxrcd).isdigit():
                            established = True
                            self.passed(
                                f"[{instance_name}/{vrf_name}] {ip} ({af_name}) "
                                f"is Established — up {up_down}, pfx received: {pfxrcd}"
                            )

                    if not established:
                        self.failed(
                            f"[{instance_name}/{vrf_name}] {ip} is DOWN"
                        )


class CommonCleanup(aetest.CommonCleanup):
    @aetest.subsection
    def disconnect(self, testbed):
        for device in testbed.devices.values():
            device.disconnect()


def main():
    tb = load("testbed.yaml")
    aetest.main(testbed=tb)


main()

Expected Output:

RP/0/RP0/CPU0:cisco_xrv9000#
2026-06-22T14:10:47: %AETEST-INFO: Passed reason: [all/default] 10.10.10.1 (ipv4 unicast) is Established — up 2d22h, pfx received: 0
2026-06-22T14:10:47: %AETEST-INFO: The result of section all_neighbors_established is => PASSED
2026-06-22T14:10:47: %AETEST-INFO: The result of testcase CheckBGP is => PASSED
2026-06-22T14:10:47: %AETEST-INFO: +--------------------------+
2026-06-22T14:10:47: %AETEST-INFO: |                          Starting common cleanup            |
2026-06-22T14:10:47: %AETEST-INFO: +--------------------------+
2026-06-22T14:10:47: %AETEST-INFO: +--------------------------+
2026-06-22T14:10:47: %AETEST-INFO: |                        Starting subsection disconnect     |
2026-06-22T14:10:47: %AETEST-INFO: +--------------------------+
2026-06-22T14:10:58: %AETEST-INFO: The result of subsection disconnect is => PASSED
2026-06-22T14:10:58: %AETEST-INFO: The result of common cleanup is => PASSED
2026-06-22T14:10:58: %AETEST-INFO: +--------------------------+
2026-06-22T14:10:58: %AETEST-INFO: |                               Detailed Results                               |
2026-06-22T14:10:58: %AETEST-INFO: +--------------------------+
2026-06-22T14:10:58: %AETEST-INFO:  SECTIONS/TESTCASES                                                      RESULT
2026-06-22T14:10:58: %AETEST-INFO: ----------------------------
2026-06-22T14:10:58: %AETEST-INFO: .
2026-06-22T14:10:58: %AETEST-INFO: |--common_setup                                                        PASSED
2026-06-22T14:10:58: %AETEST-INFO: |-- connect                                                           PASSED
2026-06-22T14:10:58: %AETEST-INFO: |-- CheckBGP                                                              PASSED
2026-06-22T14:10:58: %AETEST-INFO: |-- all_neighbors_established                                       PASSED
2026-06-22T14:10:58: %AETEST-INFO: -- common_cleanup                                                        PASSED
2026-06-22T14:10:58: %AETEST-INFO -- disconnect                                                        PASSED
2026-06-22T14:10:58: %AETEST-INFO: +--------------------------+
2026-06-22T14:10:58: %AETEST-INFO: |                                   Summary                            |
2026-06-22T14:10:58: %AETEST-INFO: +--------------------------+
2026-06-22T14:10:58: %AETEST-INFO:  Number of ABORTED                                                            0
2026-06-22T14:10:58: %AETEST-INFO:  Number of BLOCKED                                                            0
2026-06-22T14:10:58: %AETEST-INFO:  Number of ERRORED                                                            0
2026-06-22T14:10:58: %AETEST-INFO:  Number of FAILED                                                             0
2026-06-22T14:10:58: %AETEST-INFO:  Number of PASSED                                                             3
2026-06-22T14:10:58: %AETEST-INFO:  Number of PASSX                                                              0
2026-06-22T14:10:58: %AETEST-INFO:  Number of SKIPPED                                                            0
2026-06-22T14:10:58: %AETEST-INFO:  Total Number                                                                 3
2026-06-22T14:10:58: %AETEST-INFO:  Success Rate                                                            100.0%
2026-06-22T14:10:58: %AETEST-INFO: ----------------------------

Quick Reference Cheat Sheet

Further Reading

• pyATS Documentation — developer.cisco.com/docs/pyats

• Genie Feature Browser — pubhub.devnetcloud.com/media/genie-feature-browser

• pyATS GitHub — github.com/CiscoTestAutomation/pyats

• Cisco DevNet pyATS Learning Labs — developer.cisco.com/learning

If you followed my last post, you now know how to confidently navigate NetBox's GUI. Creating sites, racks, devices, prefixes, and IP addresses through the web interface. For a small lab or a new deployment, that's perfectly fine.

But here's the reality of production network environments: you might have hundreds of devices to onboard, thousands of IP addresses to track, and a team of people who all need NetBox to reflect the truth of what's actually running in your infrastructure right now. Navigating a web form for each record quickly becomes impractical. Even worse, manual data entry can lead to human error such as a typo in an IP address, an incorrect VLAN assignment, or a device that was never added because someone forgot.

This is where automation changes everything. When NetBox is automated, it stops being a wiki that you have to remember to update and starts becoming a living, accurate source of truth that updates itself as part of your normal workflows. Devices get added when they're provisioned. IPs get allocated when servers are built. Status fields change as part of your change management process and not three days later when someone remembers.

In this article we look at automation approaches you can use with your running NetBox instance. Each one solves a different problem, and by the end you'll know exactly which tool to reach for in any situation.

The Big Picture - What is available

The REST API — Your Universal Entry Point

What it is

Every piece of functionality in NetBox is exposed through a RESTful HTTP API. When you click 'Add Device' in the GUI, the web interface is ultimately making the same API calls that you can make directly from a terminal, a script, or any tool that can send HTTP requests. The REST API is the common denominator that everything else in this article builds on.

NetBox's REST API is exceptionally well-designed. Every object type such as devices, interfaces, IP addresses, prefixes, VLANs and cables has its own endpoint following a consistent URL pattern. It supports filtering, pagination, sorting, and partial updates out of the box. There's even an interactive browser at /api/ where you can explore and test endpoints live in your browser.

Why You'd Use It

The REST API is the right choice when you need something quick and language-agnostic. If you want to verify a device exists before running a script, pull a list of IPs for a specific prefix, or test a filter's return before integrating it into your code. Curl and the REST API get you there in seconds. It's also the integration point for tools and platforms that don't have a dedicated NetBox library: monitoring systems, ticketing tools, CMDBs, and custom internal applications all speak HTTP.

Authentication

NetBox uses token-based authentication. Generate a token in the GUI under Admin → API Tokens, then pass it in an Authorization header on every request.

Verify your token works

curl -s \
  -H "Authorization: Token <API-token>" \
  http://<your-netbox>:8080/api/ | python3 -m json.tool

Expected Output

{
    "circuits": "http://<your-netbox>:8080/api/circuits/",
    "core": "http://<your-netbox>:8080/api/core/",
    "dcim": "http://<your-netbox>:8080/api/dcim/",
    "extras": "http://<your-netbox>:8080/api/extras/",
    "ipam": "http://<your-netbox>:8080/api/ipam/",
    "plugins": "http://<your-netbox>:8080/api/plugins/",
    "status": "http://<your-netbox>:8080/api/status/",
    "tenancy": "http://<your-netbox>:8080/api/tenancy/",
    "users": "http://<your-netbox>:8080/api/users/",
    "virtualization": "<your-netbox>:8080/api/virtualization/",
    "vpn": "http://<your-netbox>:8080/api/vpn/",
    "wireless": "http://<your-netbox>:8080/api/wireless/"
}

Use Case 1 — Query All Active Devices in a Site

curl -s \
  -H "Authorization: Token <API-token>" \
  http://<your-netbox>:8080/api/dcim/sites/ | python3 -m json.tool

Expected Output

{
    "count": 3,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 1,
            "url": "http://<netbox>:8080/api/dcim/sites/1/",
            "display_url":"http://"<netbox>:8080/dcim/sites/1/",
            "display": "DC-Auckland",
            "name": "DC-Auckland",
            "slug": "dc-auckland",
            "status": {
                "value": "active",
                "label": "Active"
            },
            "region": null,
            "group": null,
            "tenant": null,
            "facility": "",
            "time_zone": "Pacific/Auckland",
            "description": "Primary data centre Auckland",
            "physical_address": "Auckland, New Zealand",
            "shipping_address": "",
            "latitude": null,
            "longitude": null,
            "owner": null,
            "comments": "",
            "asns": [
                {
                    "id": 1,
                    "url": "http://<netbox>:8080/api/ipam/asns/1/",
                    "display": "AS65000",
                    "asn": 65000,
                    "description": "DC-Auckland ASN"
                }
            ],
            "tags": [],
            "custom_fields": {},
            "created": "2026-05-24T23:14:48.341970Z",
            "last_updated": "2026-05-24T23:14:48.341987Z",
            "circuit_count": 0,
            "device_count": 1,
            "prefix_count": 0,
            "rack_count": 1,
            "virtualmachine_count": 0,
            "vlan_count": 3
        },

Use Case 2 — Create an IP Address Record

curl -s -X POST \
  -H "Authorization: Token <API-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "192.168.10.50/24",
    "status": "active",
    "description": "Web server uplink - Rack A3"
  }' \
  http://<your-netbox>:8080/api/ipam/ip-addresses/
  

Expected Output

{"id":9,"url":"http://<netbox>:8080/api/ipam/ip-addresses/9/","display_url":"http://<netbox>                              :8080/ipam/ip-addresses/9/","display":"192.168.10.50/24","family":{"value":4,"label":"IPv4"},"                                       address":"192.168.10.50/24","vrf":null,"tenant":null,"status":{"value":"active","label":"Active"},"                                       role":null,"assigned_object_type":null,"assigned_object_id":null,"assigned_object":null,"nat_inside":null,"nat_outside":[],"dns_name":"","description":"Web server uplink - Rack A3","owner":null,"comments":"","tags":[],"custom_fields":{},"created":"2026-06-07T22:43:47.758249Z","last_updated":"2026   

GUI Verification

Use Case 3 — Partial Update with PATCH

I'm using the IP address above to update its status from Active to Reserved.

export NB="http://<your-netbox>:8080"
export TOKEN="<API-token>"

curl -s -X PATCH \
  -H "Authorization: Token $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status": "reserved"}' \
  $NB/api/ipam/ip-addresses/9/ | python3 -m json.tool

Expected Output

{
    "id": 9,
    "url": "http://<netbox>:8080/api/ipam/ip-addresses/9/",
    "display_url": "http://<netbox>:8080/ipam/ip-addresses/9/",
    "display": "192.168.10.50/24",
    "family": {
        "value": 4,
        "label": "IPv4"
    },
    "address": "192.168.10.50/24",
    "vrf": null,
    "tenant": null,
    "status": {
        "value": "reserved",
        "label": "Reserved"
    },
    "role": null,
    "assigned_object_type": null,
    "assigned_object_id": null,
    "assigned_object": null,
    "nat_inside": null,
    "nat_outside": [],
    "dns_name": "",
    "description": "Web server uplink - Rack A3",
    "owner": null,
    "comments": "",
    "tags": [],
    "custom_fields": {},
    "created": "2026-06-07T22:43:47.758249Z",
    "last_updated": "2026-06-07T23:00:09.572431Z"
}

Key Concepts

• Pagination: Results come back in pages. Use ?limit=100&offset;=100 to walk through large sets. The count field tells you the total.

• Filtering: Append ?field=value to almost any endpoint. Filterable fields are documented in the API browser.

• Depth: Add ?depth=1 to expand related objects from IDs into full nested objects.

• API Browser: Visit https://your-netbox/api/ — it's fully interactive and documents every endpoint with live try-it-out functionality.

pynetbox — The Python SDK

What It Is

pynetbox is the official Python client library for NetBox. Rather than constructing raw HTTP requests and parsing JSON by hand, pynetbox gives you Python objects that feel natural to work with. nb.dcim.devices.filter(site="sydney-dc1") is far more readable than a curl command and it handles pagination, authentication headers, and error responses automatically.

Why You'd Use It

The true strength of pynetbox shines in bulk operations and scripting. Need to import 500 IP addresses from a spreadsheet? A 25-line Python script can manage that. Looking for a nightly inventory report? Pynetbox seamlessly integrates with csv, pandas, and other Python tools. It also effectively manages idempotency, allowing you to verify if a record exists before creating it, update records in place, and develop scripts that can be safely executed multiple times without causing duplicates. This is crucial in real-world environments where scripts are rerun and initial attempts may not always succeed.

Install

pip install pynetbox

Connect to Netbox

import pynetbox
import requests

# Setup
nb = pynetbox.api(
    "http://<your-netbox>:8080",
    token="<API-token>"
)

# Disable SSL verification (not needed for HTTP but good habit for lab)
session = requests.Session()
session.verify = False
nb.http_session = session

# Now make a call to verify the connection works
status = nb.status()
print(status)

Expected Output

{'django-version': '6.0.5', 'hostname': '4ba0dd1e9137', 'installed_apps': {'django_filters': '25.2', 'django_prometheus': '2.4.0', 'django_rq': '4.1.0', 'django_tables2': '2.8.0', 'drf_spectacular': '0.29.0', 'drf_spectacular_sidecar': '2026.5.1', 'mptt': '0.18.0', 'rest_framework': '3.17.1', 'social_django': '5.9.0', 'taggit': '6.1.0', 'timezone_field': '7.2.1'}, 'netbox-version': '4.6.1', 'netbox-full-version': '4.6.1-Docker-5.0.1', 'plugins': {}, 'python-version': '3.14.4', 'rq-workers-running': 1}

Use Case 1 — Generate a Full Device Inventory Report

One of the most common tasks in any network team: pulling a current device list into a spreadsheet for audits, compliance reports, or sharing with stakeholders who don't have NetBox access. pynetbox handles pagination automatically and simply y iterate through the data.

#Export all active devices to a dated CSV
import pynetbox
import csv
from datetime import datetime

nb = pynetbox.api("http://<netbox>:8080", token="<API-token>")

# Pull all active devices — pynetbox handles pagination automatically
devices = nb.dcim.devices.filter(status="active")

filename = f"netbox_inventory_{datetime.today().strftime('%Y-%m-%d')}.csv"

with open(filename, "w", newline="") as f:
    writer = csv.writer(f)
    writer.writerow(["Name", "Site", "Rack", "Role", "Model", "Platform", "Primary IP", "Status"])

    for device in devices:
        writer.writerow([
            device.name,
            str(device.site) if device.site else "",
            str(device.rack) if device.rack else "",
            str(device.device_role),
            str(device.device_type),
            str(device.platform) if device.platform else "",
            str(device.primary_ip) if device.primary_ip else "No IP",
            device.status.value,
        ])

print(f"Inventory exported to {filename}")

Expected Output

# The output after successful execution 
Inventory exported to netbox_inventory_2026-06-08.csv

# The information in the csv 
cat netbox_inventory_2026-06-08.csv
Name,Site,Rack,Role,Model,Platform,Primary IP,Status
core-rtr-01,DC-Auckland,AKL-RACK-01,Core Router,cisco_xrv9000,Cisco IOS-XR,10.10.10.3/24,active
core-rtr-02,DC-Sydney,SYD-RACK-01,Core Router,vMX,Juniper Junos,10.10.10.4/24,active
pe-rtr-01,DC-Queenstown,Queen-RACK-01,PE Router,7750 SR-1,Nokia SROS,10.10.10.1/24,active
pe-rtr-02,DC-Queenstown,Queen-RACK-01,PE Router,7750 SR-1,Nokia SROS,10.10.10.2/32,active

Use Case 2 — Auto-Assign the Next Available IP from a Prefix

This is where pynetbox really shines for IPAM automation. Instead of looking up the next free IP manually, your provisioning script calls NetBox directly and gets one allocated : no spreadsheet, no guesswork, no collisions.

import pynetbox

nb = pynetbox.api("http://<netbox>:8080", token="<API-token>")

def allocate_next_ip(prefix_cidr, description, dns_name=None):
    """Find and allocate the next available IP in a given prefix."""
    prefix = nb.ipam.prefixes.get(prefix=prefix_cidr)
    if not prefix:
        raise ValueError(f"Prefix {prefix_cidr} not found in NetBox")

    available = prefix.available_ips.list()
    if not available:
        raise RuntimeError(f"No available IPs remaining in {prefix_cidr}")

    new_ip = nb.ipam.ip_addresses.create(
        address=available[0]["address"],
        status="active",
        description=description,
        dns_name=dns_name or "",
    )
    print(f"[+] Allocated {new_ip.address} — {description}")
    return new_ip

# Example usage
ip = allocate_next_ip(
    prefix_cidr="10.10.10.0/24",
    description="New app server - provisioned by automation",
    dns_name="app-server-04.internal"
)

Expected Output

[+] Allocated 10.10.10.5/24 — New app server - provisioned by automation

Ansible — Playbook-Driven Network Automation

What It Is

Ansible is the industry-standard open-source automation framework for configuration management, application deployment, and task orchestration. It uses human-readable YAML 'playbooks' to specify desired actions and communicates with devices and APIs over SSH or HTTP, eliminating the need for an agent on managed hosts. The netbox.netbox Ansible collection offers specialized modules for managing NetBox objects and includes a dynamic inventory plugin that converts your live NetBox data into an Ansible inventory.

Why You'd Use It

Ansible and NetBox complement each other by addressing different aspects of infrastructure management. NetBox maintains the intended state of your infrastructure, while Ansible ensures that the actual devices align with this state. The dynamic inventory plugin is especially effective, as it allows Ansible to query NetBox in real-time, creating a host list from live data instead of relying on a static list. This ensures your inventory is always up-to-date, automatically organized by site, device role, platform, and other attributes. When you add a device to NetBox, Ansible automatically recognizes it the next time a playbook is executed, eliminating the need for manual inventory updates.

Install Ansible and the NetBox collection

pip install ansible pynetbox
ansible-galaxy collection install netbox.netbox

Use Case 1 — Dynamic Inventory Setup

plugin: netbox.netbox.nb_inventory
api_endpoint: http://<netbox>:8080
token: nbt_vgoJvumHKFno.StatmKZYfkeHm6lQqmUWmAR88vEQMNE4urjTA7a4
validate_certs: false

# Group devices by these attributes
group_by:
  - device_roles
  - sites
  - platforms
  - tags

# Only pull active devices
query_filters:
  - status: "active"

# Map NetBox primary IP to Ansible's connection address
compose:
  ansible_host: primary_ip.address | ansible.netcommon.ipaddr('address')

Expected Output

ansible-inventory -i netbox_inventory.yml --graph

@all:
  |--@ungrouped:
  |--@sites_dc-auckland:
  |  |--core-rtr-01
  |--@sites_dc-queenstown:
  |  |--pe-rtr-01
  |  |--pe-rtr-02
  |--@sites_dc-sydney:
  |  |--core-rtr-02
  |--@device_roles_core-router:
  |  |--core-rtr-01
  |  |--core-rtr-02
  |--@platforms_cisco-ios-xr:
  |  |--core-rtr-01
  |--@tags_bgp-peer:
  |  |--core-rtr-01
  |  |--core-rtr-02
  |  |--pe-rtr-01
  |  |--pe-rtr-02
  |--@tags_lab:
  |  |--core-rtr-01
  |  |--core-rtr-02
  |  |--pe-rtr-01
  |  |--pe-rtr-02
  |--@tags_mpls-enabled:
  |  |--core-rtr-01
  |  |--core-rtr-02
  |  |--pe-rtr-01
  |  |--pe-rtr-02
  |--@platforms_juniper-junos:
  |  |--core-rtr-02
  |--@device_roles_pe-router:
  |  |--pe-rtr-01
  |  |--pe-rtr-02
  |--@platforms_nokia-sros:
  |  |--pe-rtr-01
  |  |--pe-rtr-02

ansible-inventory -i netbox_inventory.yml --list

{
    "_meta": {
        "hostvars": {
            "core-rtr-01": {
                "ansible_host": "10.10.10.3",
                "custom_fields": {
                    "automation_enabled": true,
                    "bgp_asn": 65000,
                    "config_backup_path": "/backups/auckland/core-rtr-01/",
                    "mgmt_vrf": "VRF-MGMT",
                    "ntp_last_deployed": null,
                    "support_contract": "PLATINUM",
                    "warranty_expiry": "2028-06-30"
                },
                "device_roles": [
                    "core-router"
                ],
                "device_types": [
                    "cisco_xrv9000"
                ],
                "is_virtual": false,
                "local_context_data": [
                    null
                ],
                "locations": [],
                "manufacturers": [
                    "cisco"
                ],
                "platforms": [
                    "cisco-ios-xr"
                ],
                "primary_ip4": "10.10.10.3",
                "racks": [
                    "AKL-RACK-01"
                ],
                "regions": [],
                "serial": "",
                "services": [],
                "site_groups": [],
                "sites": [
                    "dc-auckland"
                ],
                "status": {
                    "label": "Active",
                    "value": "active"
                },
                "tags": [
                    "bgp-peer",
                    "lab",
                    "mpls-enabled"
                ]
            },
            "core-rtr-02": {
                "ansible_host": "10.10.10.4",
                "custom_fields": {
                    "automation_enabled": true,
                    "bgp_asn": 65001,
                    "config_backup_path": "/backups/auckland/core-rtr-02/",
                    "mgmt_vrf": "VRF-MGMT",
                    "ntp_last_deployed": null,
                    "support_contract": null,
                    "warranty_expiry": null
                },
                "device_roles": [
                    "core-router"
                ],
                "device_types": [
                    "vmx"
                ],
                "is_virtual": false,
                "local_context_data": [
                    null
                ],
                "locations": [],
                "manufacturers": [
                    "juniper"
                ],
                "platforms": [
                    "juniper-junos"
                ],
                "primary_ip4": "10.10.10.4",
                "racks": [
                    "SYD-RACK-01"
                ],
                "regions": [],
                "serial": "",
                "services": [],
                "site_groups": [],
                "sites": [
                    "dc-sydney"
                ],
                "status": {
                    "label": "Active",
                    "value": "active"
                },
                "tags": [
                    "bgp-peer",
                    "lab",
                    "mpls-enabled"
                ]
            },

................... Truncated 

GraphQL — Ask for Exactly What You Need

What It Is

In addition to the REST API, NetBox offers a GraphQL endpoint at /graphql/. GraphQL is a query language for APIs that allows you to specify the exact data structure you need in a single request. Instead of accessing multiple REST endpoints and combining results in code, you can write a single query that navigates related objects and retrieves only the fields you require

Why You'd Use It

The core benefit of GraphQL over REST is efficiency in complex queries. Consider a common task: you need a list of all active devices with each device's interfaces and the IPs assigned to those interfaces.Using REST, you would need at least three separate requests: one for devices, followed by individual requests for each device's interfaces, and then additional requests for the IPs assigned to those interfaces.With GraphQL, it's a single query. This matters most when building dashboards, audit reports, or integration pipelines that need rich nested data.

GraphQL minimizes the need for transformation code since the response matches the requested structure. The interactive playground at /graphql/ provides live schema documentation, allowing you to explore and test queries effortlessly without coding.

Use Case 1 — Device with Interfaces and IPs in One Request

This single query would require at least three separate REST API calls to replicate. The equivalent in REST would require:

• GET /api/dcim/devices/ — get devices

• GET /api/dcim/interfaces/?device=x — per device, get interfaces

• GET /api/ipam/ip-addresses/?interface=x — per interface, get IPs

import requests
import json

NETBOX_URL = "http://<netbox>:8080/graphql/"
TOKEN = "nbt_vgoJvumHKFno.StatmKZYfkeHm6lQqmUWmAR88vEQMNE4urjTA7a4"

HEADERS = {
    "Authorization": f"Token {TOKEN}",
    "Content-Type": "application/json",
}

# GraphQL query to filter for dc-sydney only 

query = """
{
  device_list(filters: {site: {slug: {i_exact: "dc-sydney"}}}) {
    name
    status
    device_type {
      model
    }
    role {
      name
    }
    rack {
      name
    }
    primary_ip4 {
      address
      dns_name
    }
    interfaces {
      name
      enabled
      ip_addresses {
        address
        status
      }
    }
  }
}
"""

response = requests.post(
    NETBOX_URL,
    headers=HEADERS,
    json={"query": query},
    verify=False
)

data = response.json()

# Check for GraphQL errors
# GraphQL always returns HTTP 200 even when something goes wrong and errors come back inside the JSON body itself, not as HTTP status codes.

if "errors" in data:
    print("[!] GraphQL errors:")
    for error in data["errors"]:
        print(f"    {error['message']}")
    exit(1)

devices = data["data"]["device_list"]

if not devices:
    print("[!] No devices found")
    exit(0)

print(f"Found {len(devices)} device(s)\n")
print("=" * 65)

for device in devices:
    print(f"Device    : {device['name']}")
    print(f"Status    : {device['status']}")
    print(f"Model     : {device['device_type']['model']}")
    print(f"Role      : {device['role']['name']}")
    print(f"Rack      : {device['rack']['name'] if device['rack'] else 'N/A'}")

    if device["primary_ip4"]:
        print(f"Primary IP: {device['primary_ip4']['address']}")
        dns = device["primary_ip4"].get("dns_name", "")
        if dns:
            print(f"DNS Name  : {dns}")
    else:
        print(f"Primary IP: None")

    interfaces = device.get("interfaces", [])
    if interfaces:
        print(f"Interfaces: {len(interfaces)} found")
        for intf in interfaces:
            enabled = "up" if intf["enabled"] else "down"
            ips = intf.get("ip_addresses", [])
            if ips:
                for ip in ips:
                    print(f"  └─ {intf['name']:<20} [{enabled}]  {ip['address']}                                                            ({ip['status']})")
            else:
                print(f"  └─ {intf['name']:<20} [{enabled}]  no IP")
    else:
        print(f"Interfaces: None")

    print("=" * 65)

Expected Output

Found 1 device(s)

===============================================================
Device    : core-rtr-02
Status    : active
Model     : vMX
Role      : Core Router
Rack      : SYD-RACK-01
Primary IP: 10.10.10.4/24
Interfaces: 4 found
  └─ ge-0/0/0             [up]  no IP
  └─ ge-0/0/1             [up]  no IP
  └─ fxp0                 [up]  192.168.20.1/24  (active)
  └─ lo0                  [up]  10.10.10.4/24  (active)
===============================================================

Choosing the Right Tool

Here's a practical decision guide. In real environments, these tools often complement each other and the key is determining which one takes the lead for a specific task.

What are you trying to do ?

• REST API (curl) - One-off query, quick test, or debugging?

• pynetbox - Python scripting, bulk import, or scheduled reporting?

• Ansible - Managing device configs alongside NetBox records?

• GraphQL API - Complex queries joining devices, IPs, interfaces in one call

Conclusion

NetBox's value depends on the accuracy of its data. Achieving data accuracy on a large scale requires automation.

This article highlights an important point: NetBox is not merely a GUI with an API attached. It is an API that includes a GUI. Every click you made in my previous post has a programmatic equivalent. When your tools talk directly to NetBox , reading from it, writing to it, and reacting to changes in it. The data stays current without depending on human intervention to keep it updated.

Traditional documentation methods, like spreadsheets and static diagrams, are no longer effective at scaling.

This is why modern network automation depends heavily on a Source of Truth.

What is source of truth ?

A Source of Truth is a centralized platform that stores authoritative infrastructure information.

Instead of using:

• spreadsheets

• text files

• Visio diagrams

• disconnected databases

All infrastructure data is stored centrally. This includes:

• Devices

• IP addresses

• VLANs

• Interfaces

• Sites

• Racks

• VRFs

The Source of Truth serves as the reliable inventory for monitoring systems, automation tools, CI/CD pipelines, and validation frameworks.

Why is a Source of Truth Required?

1. Manual Documentation Fails - Spreadsheets and manually maintained inventories quickly become outdated.

2. Automation Requires Reliable Data - Automation frameworks such as Ansible, Nornir , pyATS and Terraform depend on accurate infrastructure information.

3. Multivendor Environments Increase Complexity - A Source of Truth normalizes infrastructure information across vendors.

4. Better Operational Visibility - Network teams can quickly identify Device Locations , Interface usage , IP allocations and VLAN assignments to name a few

What is Netbox ?

NetBox is a purpose-built "source of truth" (SoT) for network and infrastructure inventory, intended to be the definitive system for DCIM (data center infrastructure management) and IPAM (IP address management). It provides a structured data model, a REST + GraphQL API, change logging, webhooks, and a rich UI — all of which make it ideal as the authoritative dataset driving automation and operational workflows.

What Makes NetBox Unique?

1. API-First Design - NetBox was designed for automation from the beginning. Everything in NetBox can be accessed using APIs.

2. Excellent IPAM Capabilities - NetBox provides IPv4 management , IPv6 management, VRFs , VLAN tracking and Prefix management. This reduces IP conflicts , Duplicate allocations and poor subnet tracking.

3. Powerful Infrastructure Modeling - NetBox models real infrastructure relationships.

4. Dynamic Inventory Generation - NetBox allows dynamic inventory generation automatically. New devices become available immediately to automation frameworks.

Why Should Network Teams Use NetBox?

1. Better Documentation - NetBox replaces spreadsheets, disconnected inventories and static diagrams with centralized live documentation.

2. Improved Automation - NetBox enables Dynamic inventories , Configuration generation , Compliance validation and Automated provisioning

3. Faster Troubleshooting - Engineers can quickly identify Device ownership , Interface mappings , VLAN relationships and Rack locations

4. Scalable Operations - As networks grow, manual tracking becomes impossible. NetBox enables scalable operational workflows.

Populating Data in NetBox

Rather than jumping straight into code, we start where every network team should — with the NetBox GUI. Getting your data model right in the UI first means your automation scripts will query clean, consistent, well-structured data.

The principle of "garbage in, garbage out" is especially relevant to network automation.

Lab Topology

Install NetBox and Access the GUI

NetBox operates as a web application supported by PostgreSQL and Redis. The quickest method to obtain a fully functional instance is by using netbox-docker, an officially maintained Docker Compose stack that automatically manages all dependencies.

Installation

Clone netbox-docker and Configure Environment

# Clone the official netbox-docker repo — always use the release branch
git clone -b release https://github.com/netbox-community/netbox-docker.git
cd netbox-docker

Create docker-compose.override.yml to set port and credentials:

cat > docker-compose.override.yml << 'EOF'
services:
  netbox:
    ports:
      - "8080:8080"
    environment:
      - SUPERUSER_NAME=admin
      - SUPERUSER_EMAIL=devplayground.gmail.com
      - SUPERUSER_PASSWORD=CodedNetbox2026!
      - ALLOWED_HOSTS=*
EOF

Pull Images and Start NetBox

# Pull all required images (netbox, postgres, redis, nginx)
docker compose pull

# Start all services in detached mode
docker compose up -d

# Watch startup logs — wait for 'Listening at: http://0.0.0.0:8080'
docker compose logs -f netbox

# Check all containers are healthy
docker compose ps

Expected output of docker compose ps :

NAME                          STATUS          PORTS
netbox-docker-netbox-1        Up (healthy)    0.0.0.0:8080->8080/tcp
netbox-docker-postgres-1      Up (healthy)    5432/tcp
netbox-docker-redis-1         Up (healthy)    6379/tcp
netbox-docker-worker-1        Up (healthy)
netbox-docker-housekeeping-1  Up (healthy)

Access the NetBox GUI

Open your browser and navigate to:

http://localhost:8080

# If running on a remote server, replace localhost with the server IP:
http://<host-ip>:8080

You will see the NetBox login page

What You See After Logging In

The NetBox dashboard displays a summary of all object counts, including devices, IPs, prefixes, and VLANs. Upon first login, all values will be zero, which is normal. The top navigation bar features six main menus:

Generate an API Token (Required for Later Automation)

GUI : Admin → API Tokens → + Add

Although this post emphasizes the GUI, creating a token now will set you up for future automation

Click Save. The token will be displayed only once, so make sure to copy and store it securely.

# Quick API test

curl -X GET \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-H "Accept: application/json; indent=4" \
http://<local-host>:8080/api/status/

# Successful response 

{
    "django-version": "6.0.5",
    "hostname": "4ba0dd1e9137",
    "installed_apps": {
        "django_filters": "25.2",
        "django_prometheus": "2.4.0",
        "django_rq": "4.1.0",
        "django_tables2": "2.8.0",
        "drf_spectacular": "0.29.0",
        "drf_spectacular_sidecar": "2026.5.1",
        "mptt": "0.18.0",
        "rest_framework": "3.17.1",
        "social_django": "5.9.0",
        "taggit": "6.1.0",
        "timezone_field": "7.2.1"
    },
    "netbox-version": "4.6.1",
    "netbox-full-version": "4.6.1-Docker-5.0.1",
    "plugins": {},
    "python-version": "3.14.4",
    "rq-workers-running": 1

Useful Docker Management Commands

Organization - Sites , Racks and Location

Create Sites

GUI : Organization → Sites → + Add

Fill in the form for DC-Auckland :

Click Save . Repeat the same process for other sites

Create Rack Groups and Racks

GUI : Organization → Racks → Rack Groups → + Add

GUI : Organization → Racks → + Add

Device Types & Manufacturers - Hardware Models, Roles, and Platforms

Add Manufacturers

GUI : Device → Device Types → Manufacturers → + Add

Add Device Types — Cisco xrv9k (IOS-XR)

GUI : Device → Device Types → + Add

After saving, click the Interfaces tab → Add Interface Template:

Add Device Roles

GUI : Device → Device Roles → + Add

Add Platforms

GUI : Device → Platforms → + Add

Devices

Add core-rtr-01 — Cisco IOS-XR (DC-Auckland)

GUI : Device → Devices → + Add

Click Save to navigate to the device detail page. Leave the Primary IP blank for now; it will be assigned after creating the IP address record.

IPAM - RIRs, Prefixes, IP Addresses, and Primary IPs

Create RIRs

GUI : IPAM → Aggregates → RIR → + Add

Create Prefix Roles and Prefixes

GUI : IPAM → Prefixes → Prefix & VLAN Roles → + Add

GUI : IPAM → Prefixes → + Add

Add IP Addresses and Assign to Interfaces

GUI : IPAM → IP Addresses → + Add

Set Primary IP on Each Device

GUI : Devices → Devices → Edit

Custom Fields - Extending Netbox for Automation

Create Custom Fields

GUI : Customization → Custom Fields → + Add

Populate Custom Fields on Each Device

GUI : Devices → Devices → Edit → (scroll to Custom Fields)

Tags - Flexible Multi-Dimensional Grouping

Create Tags

GUI : Customization → Tags → + Add

Apply Tags to Devices

GUI : Devices → Devices → Edit → Tags Field

Cables - Documenting Physical Connectivity

Add a Cable Between core-rtr-01 and pe-rtr-01

GUI : Devices → Devices (choose site) → Interfaces Tab → Connect (cable-icon)

Webhooks & Event Rules - GUI Configured Event-Driven Automation

Create a Webhook

GUI : Integrations → Webhook → + Add

Create Event Rules

GUI : Integrations → Event Rules → + Add

Rule 2 — Device Status Changed to Active (with Condition):

In the Conditions field, the below JSON is used to filter on status change:

{
  "and": [
    {
      "attr": "status.value",
      "value": "active"
    }
  ]
}

Test the Webhook with a Quick Listener

In a terminal, start a one-liner HTTP listener:

python3 -c "
from http.server import HTTPServer, BaseHTTPRequestHandler
import json

class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        length = int(self.headers.get('Content-Length', 0))
        raw = self.rfile.read(length)
        data = json.loads(raw)
        print(json.dumps(data, indent=2))
        self.send_response(200)
        self.end_headers()
    def log_message(self, *args):
        pass

print('Listening on port 9000...')
HTTPServer(('', 9000), Handler).serve_forever()
"

In the NetBox GUI, edit pe-rtr-02, change Status from Active → Planned → Active. Expected output:

Listening on port 9000...
{
  "event": "updated",
  "timestamp": "2026-05-27T01:53:21.485685+00:00",
  "object_type": "dcim.device",
  "username": "admin",
  "request_id": "21724c08-cb44-4961-bde1-f76fd4d9fd89",
  "data": {
    "id": 4,
    "url": "/api/dcim/devices/4/",
    "display_url": "/dcim/devices/4/",
    "display": "pe-rtr-02",
    "name": "pe-rtr-02",
    "device_type": {
      "id": 3,
      "url": "/api/dcim/device-types/3/",
      "display": "7750 SR-1",
      "manufacturer": {
        "id": 2,
        "url": "/api/dcim/manufacturers/2/",
        "display": "nokia",
        "name": "nokia",
        "slug": "nokia",
        "description": ""
      },
      "model": "7750 SR-1",
      "slug": "7750-sr-1",
      "description": "",
      "device_count": 2
    },

My personal opinion about NetBox

For a long time, I assumed NetBox was exclusively for production use, primarily employed by enterprise teams to document campus networks and validate their IPAM budgets. I considered it unnecessary for my lab, thinking it was "just a lab."

Then I began using containerlab in a more serious manner.

The Problem Nobody Talks About

Containerlab is truly impressive. You create a YAML topology file, execute containerlab deploy, and in less than a minute, you have a fully connected network of Cisco XRv9000s, Juniper vMX routers, and Nokia SR OS nodes communicating seamlessly. The first experience feels magical.

But here's what happens after the first time.

You create a topology for BGP testing, then another for MPLS, followed by one for SR-MPLS, and a data center fabric. When someone requests you to replicate a production issue, you quickly set up a topology that somewhat resembles it. Soon, you find yourself with six topology files in different stages of completion, a folder full of configurations with names like final_v2_actually_final.cfg, and no clear idea of which IP addresses were used where.

You SSH into something and get a different device than you expected. You run an Ansible playbook and it hits the wrong node. You try to reproduce a test from two weeks ago and spend an hour figuring out what the management IPs were.

This is the source-of-truth problem. And it doesn't only affect production networks.

Why Netbox matters ?

A Source of Truth is now essential in modern networking. NetBox offers the centralized, automation-ready infrastructure platform needed for multi-vendor environments in my case. Modern automation starts with reliable infrastructure data, and NetBox provides that foundation.

Every network operations team is familiar with the scenario: a ticket arrives at 3 a.m. indicating a BGP session has been down for 45 minutes. The monitoring system, checking every five minutes, detected the issue on the third attempt and took an additional 10 minutes to alert someone. By the time it was addressed, the network had been compromised for nearly an hour.

This is the core issue with scheduled, polling-based automation. Problems are checked at fixed intervals, so if something fails between checks, the network remains compromised until the next cycle detects it.

Event-driven automation completely transforms this approach. Rather than periodically asking the infrastructure "are you OK?", the infrastructure immediately notifies you of any changes, triggering an instant response.

"Instead of asking the network if it's OK every five minutes, the network tells you the moment something changes — and a response fires in under a second."

Ansible Event-Driven Automation (EDA) is Red Hat's answer to this challenge built directly on top of the Ansible ecosystem most network teams already know. But it is not the first tool in this space. StackStorm has been doing event-driven automation since 2014.

Ansible EDA Explained

Ansible EDA was launched in 2022 and became generally available with Ansible Automation Platform 2.4 in 2023. It introduces a dedicated event-processing layer to the existing Ansible ecosystem, capable of simultaneously listening to numerous event sources and responding to them in real time.

The three core concepts are simple:

• Sources — where events come from: webhooks, Kafka topics, syslog streams, cloud alerts, Git commits, SNMP traps, monitoring system callbacks.

• Rules — conditions you define in YAML. If the event payload matches, an action fires. Rules can include throttling, grouping, and logical operators.

• Actions — what happens: run a playbook, post to Slack, open a ticket, set a variable, or simply log the event.

These are tied together in a Rulebook — a YAML file that looks like this:

---
- name: React to BGP session down
  hosts: network_devices
  sources:
    - ansible.eda.syslog:
        host: 0.0.0.0
        port: 5514

  rules:
    - name: BGP neighbor down
      condition: >
        event.message is search("bgpSessionDown", ignorecase=true)
      throttle:
        once_within: 60 seconds
        group_by_attributes:
          - event.host
      actions:
        - run_playbook:
            name: playbooks/bgp_remediate.yml
            extra_vars:
              source_host: "{{ event.host }}"

This forms the complete loop: source — condition — action. If you're familiar with Ansible, you already grasp 80% of EDA. The rulebook is the only new concept, and it reads like plain English.

What EDA is not

EDA is not a monitoring system; it doesn't generate events but responds to them. You still require a source, such as a syslog stream, a gNMI telemetry collector feeding Kafka, a Prometheus Alertmanager webhook, or a custom script. EDA serves as the reaction layer, not the observability layer. It is also not (yet) a fully stateful workflow engine. For long-running, multi-step orchestration with complex branching logic, Ansible Automation Platform's Workflows feature or a dedicated orchestrator is more suitable. EDA is optimized for quick, reactive, event-triggered automation.

Why EDA matters now ?

1. Networks Are Too Dynamic for Polling - Modern network environments—such as SD-WAN fabrics, containerized services, and cloud-native workloads—change states much faster than traditional infrastructure. A BGP session can fluctuate and recover in less than 30 seconds. An interface might experience a temporary optical issue and resolve itself. Polling-based tools capture the aftermath, not the event itself. EDA captures both.

2. Operator time is the bottleneck - The network operations talent gap is real and growing. Every alert that requires a human to log in, assess, and manually run a CLI command is wasted capacity. Closed-loop automation — where EDA detects an event, fires a playbook, and resolves the issue without paging anyone — frees operators to work on architecture, capacity, and projects instead of reactive fire-fighting

3. The Ansible Ecosystem Is Already There - This is EDA's single biggest advantage over purpose-built event-driven tools. If your team already has Ansible playbooks for network configuration, NETCONF-based remediation, or cloud provisioning, those playbooks work unchanged in EDA. There is no rewrite, no new DSL to learn, no separate execution engine to operate. The activation cost is dramatically lower than adopting an entirely new platform.

4. Kafka and gNMI Are Now Mainstream - Event-driven automation requires event streams. Coupler years ago, getting gNMI telemetry out of a network device and into an automation system was a niche skill. Today, gNMIc, Telegraf, and vendor-native streaming telemetry are standard practice. Kafka is ubiquitous. The infrastructure for event-driven automation is mature — EDA's role is to act on those streams, and it does so natively.

5. The Throttle and Group Model Solves the Alert Storm Problem - Anyone who has tried to build event-driven network automation before has hit the alert storm problem: one event generates hundreds of syslog messages, triggers hundreds of playbook runs simultaneously, and overwhelms both the automation system and the network device it is trying to fix. EDA's built-in throttle block — once_within: 60 seconds, group_by_attributes: [event.host] — handles this correctly at the rulebook level, without requiring custom deduplication code.

EDA vs Alternatives

Ansible EDA is not the only event-driven automation tool available. StackStorm, Rundeck (now Process Automation) have all been in production environments for years. Each solves a slightly different problem. Here is an honest look at where each one excels and where it falls short.

Head-to-Head Comparison

Choose Ansible EDA

• If your team already uses Ansible playbooks for any automation tasks

• If you need event-driven reactions to network syslog, gNMI, or webhooks

• Time-to-value matters — you want something running in hours, not weeks

• If your events come from Kafka, webhooks, or syslog streams

• If you are working with Nokia SR OS, Cisco, Arista, or Juniper via NETCONF

Ansible EDA meets Nokia SR OS

Overview

This guide provides a step-by-step guide for setting up Ansible Event-Driven Automation (EDA) with Nokia SR OS nodes running in Containerlab . By the end, you will have:

• A Python virtual environment with Ansible EDA and the nokia.sros collection

• SR OS nodes configured to stream syslog to EDA

• EDA rulebook reacting to BGP session changes

• NETCONF-based playbooks that automatically remediate those events on the SR OS nodes

Directory Structure

Create the working directory and subdirectories first:

mkdir -p sros-eda/{rulebooks,playbooks,inventory,logs}
cd sros-eda

Step 1 — Python Virtual Environment

Create an isolated environment so EDA dependencies do not conflict with system packages:

python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip

Install Ansible EDA and its dependencies:

pip install ansible ansible-rulebook ansible-runner aiohttp ncclient

Install the required Ansible collections:

ansible-galaxy collection install ansible.eda
ansible-galaxy collection install nokia.sros
ansible-galaxy collection install ansible.netcommon

Verify everything installed correctly:

ansible-rulebook --version
ansible-galaxy collection list | grep -E "eda|sros|netcommon"

Step 2 — SR OS Node Configuration

Find your host IP first:

ip route get 8.8.8.8 | awk '{print $7; exit}'

Apply on SR OS nodes (replace <HOST_IP>):

/configure log syslog "eda" address <HOST_IP>
/configure log syslog "eda" severity warning
/configure log syslog "eda" port 5514
/configure log log-id "20" admin-state enable
/configure log log-id "20" description "EDA event stream"
/configure log log-id "20" source main true
/configure log log-id "20" destination syslog "eda"
 

Verify syslog is functioning

Start a listener on your host:

python3 -c "
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(('0.0.0.0', 5514))
print('Listening on UDP 5514...')
while True:
    data, addr = s.recvfrom(1024)
    print(f'{addr[0]}: {data.decode()}')
"

Events from the SR OS node are being received:

Listening on UDP 5514...
172.20.20.13: <186>May 12 23:07:05 172.31.255.30 TMNX: 766 Base LOGGER-MAJOR-tmnxLogFileRollover-2008 [acct-log-id 9 file-id 19]:  Log file cf3:\act\act0919-20260512-223705.xml.gz on compact flash cf3 has been rolled over

172.20.20.13: <187>May 12 23:08:08 172.31.255.30 TMNX: 767 Base LOGGER-MINOR-tmnxLogFileDeleted-2009 [acct-log-id 9 file-id 19]:  Log file cf3:\act\act0919-20260512-200705.xml.gz on compact flash cf3 has been deleted

172.20.20.13: <187>May 12 23:08:08 172.31.255.30 TMNX: 768 Base LOGGER-MINOR-tmnxLogFileDeleted-2009 [acct-log-id 9 file-id 19]:  Log file cf3:\act\act0919-20260512-203705.xml.gz on compact flash cf3 has been deleted

Step 3 — Ansible Inventory

Create inventory/hosts.yml . This connects to SR OS via NETCONF using the nokia.sros.md network OS:

---
all:
  vars:
    ansible_user: <user-name>
    ansible_password: <password>
    ansible_connection: ansible.netcommon.netconf
    ansible_network_os: nokia.sros.md
    ansible_netconf_port: 830
    ansible_netconf_username: <user-name>
    ansible_netconf_password: <password>

  children:
    sros_nodes:
      hosts:

        sros1:
          ansible_host: 172.20.20.13
          ansible_netconf_host: 172.20.20.13
          bgp_neighbor: "10.10.10.2"
          bgp_peer_as: 65000

        sros2:
          ansible_host: 172.20.20.14
          ansible_netconf_host: 172.20.20.14
          bgp_neighbor: "10.10.10.1"
          bgp_peer_as: 65000

Step 4 — EDA Rulebooks

Rulebook 1 — BGP Events

---
- name: "SR OS EDA: BGP and Interface Event Handler"
  hosts: sros_nodes
  sources:
    - ansible.eda.syslog:
        host: 0.0.0.0
        port: 5514

  rules:

    - name: BGP session down
      condition: >
        event.message is search(
          "bgpBackwardTransNotification|bgpSessionDown|bgpPeerNotFound|ADMIN_SHUT|BGP-WARNING",
          ignorecase=true)
      throttle:
        once_within: 60 seconds
        group_by_attributes:
          - event.host
      actions:
        - run_playbook:
            name: playbooks/bgp_session_down.yml
            extra_vars:
              source_host: "{{ event.host }}"
              syslog_message: "{{ event.message }}"

    - name: BGP session up
      condition: >
        event.message is search(
          "bgpEstablishedNotification|ESTABLISHED",
          ignorecase=true)
      actions:
        - debug:
            msg: "BGP UP on {{ event.host }} — no action required"

    - name: Catch all — print every event received
      condition: event.message is defined
      actions:
        - debug:
            msg: "EVENT from {{ event.host }} | MSG: {{ event.message }}"

Step 5 — Playbooks

BGP Session down

---
- name: BGP Session Down — Remediate via NETCONF
  hosts: "{{ source_host | default('sros_nodes') }}"
  gather_facts: false

  tasks:

    - name: Collect BGP neighbor state via NETCONF
      netconf_get:
        filter: |
          <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
            <router>
              <bgp>
                <neighbor>
                  <ip-address/>
                  <admin-state/>
                </neighbor>
              </bgp>
            </router>
          </configure>
      register: bgp_state

    - name: Get current timestamp
      delegate_to: localhost
      command: date '+%Y-%m-%dT%H:%M:%S'
      register: timestamp

    - name: Log BGP down event
      delegate_to: localhost
      lineinfile:
        path: logs/bgp_events.log
        line: "[{{ timestamp.stdout }}] BGP DOWN on {{ inventory_hostname }} | {{ syslog_message | default('no message') }}"
        create: yes

    - name: Disable BGP neighbor
      ansible.netcommon.netconf_config:
        lock: never
        content: |
          <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
           <configure   xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
             <router>
             <router-name>Base</router-name>
              <bgp>
                <neighbor>
                  <ip-address>{{ bgp_neighbor }}</ip-address>
                  <admin-state>disable</admin-state>
                </neighbor>
              </bgp>
             </router>
           </configure>
          </config>
      when: bgp_neighbor is defined
      ignore_errors: yes
      register: clear_result

    - name: Wait 3 seconds
      pause:
        seconds: 3

    - name: Enable BGP neighbor
      ansible.netcommon.netconf_config:
        lock: never
        content: |
          <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
           <configure   xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
             <router>
             <router-name>Base</router-name>
              <bgp>
                <neighbor>
                  <ip-address>{{ bgp_neighbor }}</ip-address>
                  <admin-state>enable</admin-state>
                </neighbor>
              </bgp>
             </router>
           </configure>
          </config>
      when: bgp_neighbor is defined
      ignore_errors: yes
      register: clear_result

    - name: Wait for BGP to re-establish
      pause:
        seconds: 15

    - name: Log remediation result
      delegate_to: localhost
      lineinfile:
        path: logs/bgp_events.log
        line: "[{{ timestamp.stdout }}] BGP REMEDIATION COMPLETE on {{ inventory_hostname }} | neighbor {{ bgp_neighbor | default('unknown') }}"
        create: yes

Step 6 — Running EDA

Terminal 1 — Start EDA

cd sros-eda
source venv/bin/activate

ansible-rulebook \
--rulebook rulebooks/01_bgp_and_interface.yml \
--inventory inventory/hosts.yml \
--verbose 

EDA starts and listens on 0.0.0.0:5514. It is now waiting for syslog events from your SR OS nodes.

Output :

(venv) [kleburu@devplayground]$ ansible-rulebook   --rulebook rulebooks/01_bgp_and_interface.yml   --inventory inventory/hosts.yml --verbose
2026-05-13 12:05:43,531 - ansible_rulebook.app - INFO - Starting sources
2026-05-13 12:05:43,531 - ansible_rulebook.app - INFO - Starting rules
2026-05-13 12:05:43,532 - drools.ruleset - INFO - Using jar: /labs/kleburu/python-projects/Ansible_Automation/sros-eda/venv/lib/python3.9/site-packages/drools/jars/drools-ansible-rulebook-integration-runtime-1.0.11-SNAPSHOT.jar
2026-05-13 12:05:44 171 [main] INFO org.drools.ansible.rulebook.integration.api.rulesengine.MemoryMonitorUtil - Memory occupation threshold set to 90%
2026-05-13 12:05:44 172 [main] INFO org.drools.ansible.rulebook.integration.api.rulesengine.MemoryMonitorUtil - Memory check event count threshold set to 64
2026-05-13 12:05:44 172 [main] INFO org.drools.ansible.rulebook.integration.api.rulesengine.MemoryMonitorUtil - Exit above memory occupation threshold set to false
2026-05-13 12:05:44 177 [main] INFO org.drools.ansible.rulebook.integration.api.rulesengine.AbstractRulesEvaluator - Start automatic pseudo clock with a tick every 100 milliseconds
2026-05-13 12:05:44,199 - ansible_rulebook.engine - INFO - load source ansible.eda.syslog
2026-05-13 12:05:44,201 - ansible_rulebook.engine - INFO - loading source filter eda.builtin.insert_meta_info
Syslog listener started on 0.0.0.0:5514
2026-05-13 12:05:44,519 - ansible_rulebook.engine - INFO - Waiting for all ruleset tasks to end
2026-05-13 12:05:44,520 - ansible_rulebook.rule_set_runner - INFO - Waiting for actions on events from SR OS EDA: BGP and Interface Event Handler
2026-05-13 12:05:44,520 - ansible_rulebook.rule_set_runner - INFO - Waiting for events, ruleset: SR OS EDA: BGP and Interface Event Handler
2026-05-13 12:05:44 520 [drools-async-evaluator-thread] INFO org.drools.ansible.rulebook.integration.api.io.RuleExecutorChannel - Async channel connected

Terminal 2 — Test BGP event

On the SR OS node:

/configure router bgp neighbor 10.10.10.2 admin-state disable
commit

EDA catches the syslog within 1-2 seconds and fires bgp_session_down.yml. Re-enable after the test:

Output:

PLAY [BGP Session Down — Remediate via NETCONF] ********************************

TASK [Collect BGP neighbor state via NETCONF] **********************************
ok: [sros1]

TASK [Get current timestamp] ***************************************************
changed: [sros1 -> localhost]

TASK [Log BGP down event] ******************************************************
changed: [sros1 -> localhost]

TASK [Disable BGP neighbor] ****************************************************
ok: [sros1]

TASK [Wait 3 seconds] **********************************************************
Pausing for 3 seconds
(ctrl+C then 'C' = continue early, ctrl+C then 'A' = abort)
ok: [sros1]

TASK [Enable BGP neighbor] *****************************************************
changed: [sros1]

TASK [Wait for BGP to re-establish] ********************************************
Pausing for 15 seconds
(ctrl+C then 'C' = continue early, ctrl+C then 'A' = abort)
ok: [sros1]

TASK [Log remediation result] **************************************************
changed: [sros1 -> localhost]

PLAY RECAP *********************************************************************
sros1                      : ok=8    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Quick Reference

The Bottom Line

Event-driven automation is not optional anymore. Networks are highly dynamic, operators are limited, and the delay between events and responses is too expensive to rely on reactive, manual processes.

Ansible EDA secures its position in this landscape not due to its power, but because of its accessibility. For the vast majority of network automation teams that already have Ansible in their environment, EDA is the shortest path from a polling-based world to a truly event-driven one.

Start with syslog. React to BGP events and interface flaps. Watch a playbook fire in under two seconds after a real network event. Then ask yourself what else you want to connect to it. The answer is usually: everything.

Further readings

• Ansible EDA Documentation: ansible.readthedocs.io/projects/rulebook

• ansible-rulebook on GitHub: github.com/ansible/ansible-rulebook

• nokia.sros Ansible Collection: galaxy.ansible.com/nokia/sros

Network configurations change constantly — interfaces go up and down, routes shift, software gets upgraded. Without version control, there's no record of what changed, when, or by whom. Git addresses this for code. Here's how to extend that approach to your entire network.

Why version control for networks?

Software developers have relied on version control for decades, tracking every line of code, attributing every change, and allowing mistakes to be undone with a single command. Network engineers, however, have traditionally lacked this convenience—configurations reside on devices, changes are made manually, and the audit trail depends on what you remember to document.

Applying Git to network configuration management changes this completely. When every config change is committed to a repository you get a full history of your network state, the ability to diff any two points in time, and the foundation for automation via CI/CD pipelines.

Git fundamentals for network engineers

Git is a distributed version control system where each repository copy holds the complete history. You work locally, commit changes, and then push to a shared server, such as GitLab.

Git Terminology

Before moving forward, let's ensure we have a clear understanding of some key terminology.

Repository : In Git, a repository refers to the database that holds all of a project's information, including files, metadata, and history. Here, "project" is used to denote any arbitrary collection of work

Working directory : This is the directory where you, as a Git user, modify the files within the repository.

Index : The index represents the repository’s directory structure and contents at a specific moment. It is a dynamic binary file managed by Git, which updates as you stage changes and commit them to the repository.

Commit : A commit is an entry in the Git repository that records metadata for each change made. This metadata includes the author, the date of the commit, and a commit message, which describes the change introduced to the repository.

Essential Git Commands

Here's the core workflow for managing network configuration files:

# Make a change to your router list
vim inventory.yml

# Stage the change
git add inventory.yml

# Save a named snapshot
git commit -m "Add router3 to lab inventory"

# Upload to GitLab — triggers pipeline automatically
git push origin main

Automating Nokia SROS Backups with GitLab CI/CD and Python

What if your router configurations backed themselves up every night and flagged exactly what changed? Here is how I built a fully automated backup and inventory pipeline for Nokia SROS routers using GitLab CI/CD and Netmiko.

The problem

Manual router backups are tasks everyone knows they should perform but often neglect. You might make a change late on a Friday, forget to save a copy, and weeks later find yourself looking at a configuration that seems unfamiliar, with no clue when or how it was altered.

Managing a lab environment running Nokia SR OS routers brought this problem into sharp focus. The goal was simple: automate both the backup and change detection so that nothing slips through the cracks, and store everything in version control so you always have a full audit trail.

The solution

GitLab CI/CD pipelines

GitLab is a web-based platform that hosts Git repositories and adds powerful automation on top. The .gitlab-ci.yml file in your repository defines a pipeline — a sequence of automated jobs that run whenever specific events occur.

#.gitlab-ci.yml snapshot 

backup-job: # job name
  stage: backup # which stage it belongs to
  variables:
    GIT_STRATEGY: fetch # how to get the repo code
  script:
    - python backup.py # your automation script
    - git add clab-backups/
    - git commit -m "router backup [ci skip]"   
    - git push origin HEAD:$CI_COMMIT_BRANCH -o ci.skip
  tags:
    - nokia-runner # which machine runs this

Repository Structure

What this pipeline does ?

This is a two-job GitLab CI/CD pipeline that runs on a schedule. One job gathers router inventory and identifies changes, while the other captures the complete configuration. All results are committed back to the same GitLab repository, providing a version-controlled history of your entire network state.

inventory-job — smart change detection

Connects to each router via SSH using Netmiko, executes show commands, and compares the output with the last saved report. A new file is created and committed to the repository only if changes are detected.

Smart saving: if nothing changed between runs the job exits cleanly with no commit and no push. Your git history only grows when something actually happened on the network.

backup-job — full config capture

Always runs on every pipeline. Captures the complete running configuration via admin display-config. Saves a timestamped file per router. Verifies completeness by checking for exit all at the end. Keeps the last three backups per router.

The complete pipeline file

image: python:3.9.21

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
  GIT_STRATEGY: fetch

cache:
  paths:
    - .cache/pip
    - venv/

stages:
  - inventory
  - backup

before_script:
  - python -V
  - python -m pip install --upgrade pip
  - python -m pip install virtualenv
  - python -m virtualenv venv
  - source venv/bin/activate
  - pip install -r requirements.txt
  - rm -fr .git/rebase-merge .git/rebase-apply
  - git config --global user.email "$GITLAB_USER_EMAIL"
  - git config --global user.name "$GITLAB_USER_ID"
  - git config --global pull.rebase false
  - git fetch origin
  - git reset --hard origin/$CI_COMMIT_BRANCH

inventory-job:
  stage: inventory
  variables:
    GIT_STRATEGY: fetch
  script:
    - python inventory.py
    - git add clab-inventory/
    - >
      if ! git diff-index --quiet HEAD; then
        git commit -m "inventory update [ci skip]"
        git remote set-url --push origin "https://\(TOKEN_NAME:\)ACCESS_TOKEN@\(CI_SERVER_HOST/\)CI_PROJECT_PATH.git"
        git push origin HEAD:$CI_COMMIT_BRANCH -o ci.skip
      else
        echo "No inventory changes to commit"
      fi
  rules:
    - if: '$CI_PIPELINE_SOURCE == "push"'
      changes:
        - inventory.yml
    - if: '$CI_PIPELINE_SOURCE == "web"'
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  tags:
    - nokia-runner

backup-job:
  stage: backup
  variables:
    GIT_STRATEGY: fetch
  script:
    - python backup.py
    - git add clab-backups/
    - >
      if ! git diff-index --quiet HEAD; then
        git commit -m "router backup [ci skip]"
        git remote set-url --push origin "https://\(TOKEN_NAME:\)ACCESS_TOKEN@\(CI_SERVER_HOST/\)CI_PROJECT_PATH.git"
        git push origin HEAD:$CI_COMMIT_BRANCH -o ci.skip
      else
        echo "No backup changes to commit"
      fi
  tags:
    - nokia-runner

Expected Output

inventory-job log output

Created output files

Set it up from scratch

1. Create Gitlab Project - Log into gitlab.com, click New Project, create a blank private project named router-backups.

2. Add your files - Create .gitlab-ci.yml, backup.py, inventory.py, inventory.yml, and requirements.txt in the repository root.

3. Set CI/CD variables - Go to Settings > CI/CD > Variables. Add ACCESS_TOKEN (Maintainer role), TOKEN_NAME, and ROUTER_PASSWORD (masked).

4. Register a GitLab Runner - Install gitlab-runner on the Linux machine that can reach your routers. Register with shell executor and tag nokia-runner.

5. Set up a schedule - Go to Build > Schedules, create a schedule with cron 0 2 * * * to run daily at 2 AM.

6. Run the first pipeline - Go to Build > Pipelines, click Run pipeline. Both jobs execute and first backup files appear in clab-backups/.

Once the runner is registered and variables are set, the system is self-maintaining. It backs up your routers and records changes automatically — no manual steps needed.

Key lessons learned

• Use shell executor, not docker : Docker networking prevents the runner from reaching internal lab routers. Shell executor runs directly on the machine and has full network access to your SROS devices.

• environment no more is not optional : Nokia SR OS paging will silently truncate your backups. This must be the first command you send after connecting — before any show commands or admin display-config.

• Hard reset beats rebase in CI/CD : git reset --hard origin/main at the start of every job is more reliable than trying to rebase or merge diverged branches mid-pipeline.

• Project Access Token needs Maintainer role : A token with Guest role cannot push to the repo. Create a Project Access Token and explicitly set the role to Maintainer during creation.

• Filenames matter — check for hidden spaces : A leading space in inventory.yml caused hours of confusion. Always run ls -la on the runner to verify filenames have no invisible characters.

• send_command_timing for large output : For admin display-config, timing-based reading is more reliable than pattern matching on large outputs that take unpredictable time to stream from the router.

Modern networks generate enormous volumes of operational data every second — interface counters, CPU utilization, BGP session states, MPLS label information, and more. For years, network teams relied on SNMP polling to collect this data, but polling has fundamental limitations: it is slow, CPU-intensive at scale, and blind to events happening between poll cycles.

Streaming telemetry addresses this by reversing the model. Rather than a manager requesting data on a schedule, devices continuously push data whenever values change or at a set interval. This allows for sub-second observability, quicker fault detection, and scalable monitoring architectures.

In this post, we guide you through a comprehensive end-to-end setup using Prometheus as the metrics engine. We'll configure streaming telemetry on Nokia SR OS routers, expose it via GNMIC as a Prometheus exporter, scrape and store metrics in Prometheus, and visualize everything using Grafana.

Traditional SNMP vs Streaming Telemetry

Comparison Matrix

gRPC Protocol

gRPC (general-purpose Remote Procedure Call) is a modern, open-source, high-performance framework for Remote Procedure Calls (RPC).

gRPC was originally developed by Google, which had been using a general-purpose RPC infrastructure called Stubby to connect its numerous microservices across data centers for over a decade. In March 2015, Google decided to create the next iteration of Stubby and release it as open source. This led to the development of gRPC, now widely adopted by various organizations to support applications ranging from microservices to the "last mile" of computing, including mobile, web, and Internet of Things.

In Nokia SR OS, this framework is used to implement the gRPC server, which can then be used for configuration management or telemetry. The gRPC transport service uses HTTP/2 bidirectional streaming between the gRPC client (the data collector) and the gRPC server (the SR OS device). A gRPC session is a single connection from the gRPC client to the gRPC server over a TCP or TLS port. The gRPC service runs on port 57400 by default.

Protocol Stack

Transport Layer Security (TLS)

The gRPC server on the SR OS can operate in the following modes:

• without TLS encryption

• with TLS encryption

Enabling TLS encryption enhances security. Without it, gRPC messages are transmitted unencrypted, making usernames and passwords visible if packets are intercepted. In general, only server-side authentication is used, however, TLS does allow this to be extended to two-way authentication where the client certificate is also authenticated.

gNMI Service

gNMI (gRPC Network Management Interface) is a unified management protocol for streaming telemetry and configuration management, utilizing the open-source gRPC framework. It is an initiative of the OpenConfig consortium, a group of network operators led by Google. Nokia SR OS supports both OpenConfig and Nokia-native YANG models.

gNMI Operations

gRPC Telemetry Sessions

gRPC telemetry sessions can be initiated using Dial-in and Dial-out modes

Dial-in Telemetry

When the data collector starts the gRPC connection, the Nokia SR OS node acts as the gRPC server, and the collector becomes the client. This is known as dial-in telemetry, where the Nokia SR OS node pushes data to the collector.

Telemetry Dial-in : Dynamic Subscriptions

Dial-Out Telemetry

When the Nokia SR OS node initiates the gRPC connection, the Nokia SR OS node assumes the role of the gRPC client. This is referred to as dial-out telemetry.

Telemetry Dial-out: Persistent Subscriptions

Using gNMIc with Nokia SR OS

gNMIc : is a gNMI CLI client that provides full support for Capabilities, Get, Set and Subscribe RPCs with collector capabilities. Developed and maintained by Nokia.

gRPC Nokia SR OS server

# enable model-driven mode 

configure system management-interface configuration-mode model-driven

# select user and permissions 

[gl:/configure system security user-params local-user user "admin"]
access {
        grpc true
    }
    console {
        member ["administrative"]
    }

# Enable unsecured gRPC 

[gl:/configure system grpc]
    admin-state enable
    allow-unsecure-connection
    rib-api {
        admin-state enable
    }

gNMIc Install

# To download & install the latest release the following automated installation script can be used

bash -c "$(curl -sL https://get-gnmic.openconfig.net)"

# Check the version 

gnmic version
version : 0.45.0
 commit : d461eac0
   date : 2026-03-03T23:37:56Z
 gitURL : https://github.com/openconfig/gnmic
   docs : https://gnmic.openconfig.net

Using gNMI services

The following section offers practical examples of using gNMIc for gNMI operations. User documentation is available at gnmic.openconfig.net . It is well-structured and maintained, as well as easy to use.

Capabilities RPC

The simplest gNMI operation is the Capabilities RPC, which involves a Capability Request initiated by the client, followed by a Capability Response from the gRPC server detailing the supported gNMI version, YANG models, and gRPC encodings

gnmic -a 172.20.20.13:57400 -u admin -p codeNetwk@123! --insecure capabilities

gNMI version: 0.8.0
supported models:
  - nokia-conf, Nokia, 24.10.R5
  - nokia-state, Nokia, 24.10.R5
  - nokia-li-state, Nokia, 24.10.R5
  - nokia-sr-openconfig-aaa-augments, Nokia, 24.10.R5
  - nokia-sr-openconfig-dev-examples-augments, Nokia, 24.10.R5
  - nokia-sr-openconfig-if-ethernet-augments, Nokia, 24.10.R5
  - nokia-sr-openconfig-if-ip-augments, Nokia, 24.10.R5
  - nokia-sr-openconfig-mpls-augments, Nokia, 24.10.R5
  - nokia-sr-openconfig-system-terminal-deviations, Nokia, 24.10.R5
  - nokia-sr-openconfig-telemetry-deviations, Nokia, 24.10.R5
  - nokia-sr-openconfig-terminal-device-deviations, Nokia, 24.10.R5
  - nokia-sr-openconfig-vlan-deviations, Nokia, 24.10.R5
supported encodings:
  - JSON
  - BYTES
  - PROTO
  - JSON_IETF

................... [ Truncated Output ]

Get RPC

The Get RPC provides a mechanism for a client to request config or state data for a path or set of paths and for it to be returned by the target node

gnmic -a 172.20.20.13:57400 -u admin -p codeNetwk@123! --insecure \
      get --path /state/system/platform

[
  {
    "source": "172.20.20.13:57400",
    "timestamp": 1777325450020727215,
    "time": "2026-04-28T09:30:50.020727215+12:00",
    "updates": [
      {
        "Path": "state/system/platform",
        "values": {
          "state/system/platform": "7750 SR-1"
        }
      }
    ]
  }
]

Set RPC

The Set RPC is intended to allow for modifications to the configuration state of the target node .

gNMIc allows the user to execute Set RPCs for the update operation using in-line updates where the path and intended modifications are entered on the command line --update-value

gnmic --config configs/config.yml set --update-path /configure/port[port-id=1/1/c1/1]/description --update-value gnmictest

2026/04/28 09:38:31.296832 [gnmic] version=0.45.0, commit=d461eac0, date=2026-03-03T23:37:56Z, gitURL=https://github.com/openconfig/gnmic, docs=https://gnmic.openconfig.net
2026/04/28 09:38:31.296873 [gnmic] using config file "configs/config.yml"
2026/04/28 09:38:31.297023 [gnmic] adding target {"name":"172.20.20.13:57400","address":"172.20.20.13:57400","username":"admin","password":"****","timeout":10000000000,"insecure":true,"skip-verify":false,"buffer-size":100,"retry-timer":10000000000,"log-tls-secret":false,"gzip":false,"token":""}
2026/04/28 09:38:31.297280 [gnmic] sending gNMI SetRequest: prefix='<nil>', delete='[]', replace='[]', update='[path:{elem:{name:"configure"}  elem:{name:"port"  key:{key:"port-id"  value:"1/1/c1/1"}}  elem:{name:"description"}}  val:{json_ietf_val:"\"gnmictest\""}]', extension='[]' to 172.20.20.13:57400
2026/04/28 09:38:31.297683 [gnmic] creating gRPC client for target "172.20.20.13:57400"
{
  "source": "172.20.20.13:57400",
  "timestamp": 1777325911161749222,
  "time": "2026-04-28T09:38:31.161749222+12:00",
  "results": [
    {
      "operation": "UPDATE",
      "path": "configure/port[port-id=1/1/c1/1]/description"
    }
  ]
}

# check the configured port in Nokia SROS 
[gl:/configure port 1/1/c1/1]
 admin-state enable
    description "gnmictest"
    ethernet {
        lldp {
            dest-mac nearest-bridge {
                notification true
                receive true
                transmit true
                tx-tlvs {
                    port-desc true
                    sys-name true
                    sys-desc true
                }
            }
        }
    }

Subscribe RPC

When a client wants to receive specific state data, it initiates a subscription using the Subscribe RPC. This subscription includes one or more paths outlining the desired data, along with a chosen subscription mode. There are three modes that determine the duration of the subscription:

• ONCE: specifies a subscription that provides data as a one-time response

• POLL: is a subscription that uses a stream to periodically request data

• STREAM: is a continuous subscription that streams data based on triggers defined by the subscription mode. This mode can be ON_CHANGE, SAMPLE, or TARGET_DEFINED

ONCE

A subscription operating in the ONCE mode dictates a single request/response exchange

gnmic -a 172.20.20.13:57400 -u admin -p codeNetwk@123! --insecure \
      sub --path "/state/system/memory-pools/summary" -- mode once

{
  "source": "172.20.20.13:57400",
  "subscription-name": "default-1777327406",
  "timestamp": 1777327406422019039,
  "time": "2026-04-28T10:03:26.422019039+12:00",
  "prefix": "state/system/memory-pools/summary",
  "updates": [
    {
      "Path": "current-total-size",
      "values": {
        "current-total-size": "2095054848"
      }
    },
    {
      "Path": "total-in-use",
      "values": {
        "total-in-use": "1898836352"
      }
    },
    {
      "Path": "available-memory",
      "values": {
        "available-memory": "1720713216"
      }
    }
  ]
}
{
  "sync-response": true
}

STREAM

Stream subscriptions are long-lived subscriptions which continue to transmit updates at the requested sample interval for the set of paths within the Subscribe Request indefinitely

gnmic -a 172.20.20.13:57400 -u admin -p codeNetwk@123! --insecure \
      sub --path "/state/port[port-id=1/1/c1/1]/statistics/in-packets" -- sample-interval 10s

{
  "source": "172.20.20.13:57400",
  "subscription-name": "default-1777327689",
  "timestamp": 1777327689262295519,
  "time": "2026-04-28T10:08:09.262295519+12:00",
  "prefix": "state/port[port-id=1/1/c1/1]/statistics",
  "updates": [
    {
      "Path": "in-packets",
      "values": {
        "in-packets": "14376890"
      }
    }
  ]
}
{
  "sync-response": true
}
{
  "source": "172.20.20.13:57400",
  "subscription-name": "default-1777327689",
  "timestamp": 1777327699260018112,
  "time": "2026-04-28T10:08:19.260018112+12:00",
  "prefix": "state/port[port-id=1/1/c1/1]/statistics",
  "updates": [
    {
      "Path": "in-packets",
      "values": {
        "in-packets": "14376916"
      }
    }
  ]
}
{
  "source": "172.20.20.13:57400",
  "subscription-name": "default-1777327689",
  "timestamp": 1777327709259895901,
  "time": "2026-04-28T10:08:29.259895901+12:00",
  "prefix": "state/port[port-id=1/1/c1/1]/statistics",
  "updates": [
    {
      "Path": "in-packets",
      "values": {
        "in-packets": "14376945"
      }
    }
  ]
}

Dial-out Telemetry

In general, the SR-OS node performs the role of a gRPC server responding to subscription requests from a gRPC client. However, it is possible for the SR-OS to perform the role of gRPC client, initiating gRPC connections and pushing data to a gRPC server using a Publish RPC. This is referred to as dial-out telemetry

Dial-out subscriptions are configured on the router and are persistent. The configuration is defined with three constituent parts;

• A sensor group to define one or more schema paths to stream

• A destination group specifying the destination address(es) and ports that the router uses to send telemetry data.

• Persistent subscriptions to associate a sensor group with a destination group

The following shows an example of the SR-OS configuration for dial-out telemetry.

system {
        telemetry {
            destination-group "dialout" {
                allow-unsecure-connection
                destination 172.31.255.29 port 57400 {
                    router-instance "Base"
                }
            }
            persistent-subscriptions {
                subscription "dialout" {
                    admin-state enable
                    sensor-group "port-stats"
                    mode sample
                    destination-group "dialout"
                    encoding bytes
                }
            }
            sensor-groups {
                sensor-group "port-stats" {
                    path "/state/port[port-id=1/1/c1/1]/statistics/out-octets" { }
                }
            }
        }
	}

A:admin@PE1# /show system telemetry persistent subscription "dialout"

===============================================================
Telemetry persistent subscription
===============================================================
Subscription Name     : dialout
Administrative State  : Enabled
Operational State     : Up
Subscription Id       : 65
Description           : (Not Specified)
Sensor Group          : port-stats
Destination Group     : dialout
Path Mode             : sample
Sample Interval       : 10000 ms
Encoding              : json-ietf
===============================================================

Setup gNMIc

To make gNMIc simulate a gRPC server, use the listen argument along with an IP address and port to receive publish subscriptions.

gnmic listen -a 172.31.255.29:57400 --insecure
{
  "source": "172.20.20.13:58158",
  "system-name": "PE1",
  "subscription-name": "dialout",
  "timestamp": 1777328434091359417,
  "time": "2026-04-28T10:20:34.091359417+12:00",
  "prefix": "state/port[port-id=1/1/c1/1]/statistics",
  "updates": [
    {
      "Path": "out-octets",
      "values": {
        "out-octets": "5521927017"
      }
    }
  ]
}
{
  "source": "172.20.20.13:58158",
  "system-name": "PE1",
  "subscription-name": "dialout",
  "timestamp": 1777328444090433719,
  "time": "2026-04-28T10:20:44.090433719+12:00",
  "prefix": "state/port[port-id=1/1/c1/1]/statistics",
  "updates": [
    {
      "Path": "out-octets",
      "values": {
        "out-octets": "5521939044"
      }
    }
  ]
}

The GPG Stack Architecture

The GPG Stack (GNMIC · Prometheus · Grafana) serves as a cloud-native observability pipeline for network telemetry. GNMIC connects the gNMI push model with Prometheus's pull-based scrape model.

Telemetry Stack

GNMIC Config — Prometheus Output Mode

subscriptions:
  port_stats_nokia:
    paths:
      - "/state/port[port-id=*]/statistics/in-packets"
      - "/state/port[port-id=*]/statistics/out-packets"
      - "/state/port[port-id=*]/statistics/in-octets"
      - "/state/port[port-id=*]/statistics/out-octets"
    mode: stream
    stream-mode: sample
    sample-interval: 10s
    encoding: json_ietf
  service_state:
    paths:
      - "/state/service/vprn[service-name=*]/oper-state"
    mode: once
  system_facts:
    paths:
      - "configure/system/name"
      - "state/system/version"
    mode: once
  system_resources:
    paths:
      - "/state/system/memory-pools/summary"
      - "/state/system/cpu[sample-period=60]/summary"
    mode: stream
    stream-mode: sample
    sample-interval: 10s
    encoding: json_ietf
targets:
      172.20.20.13:

outputs:
  prometheus-out:
    type: prometheus
    listen: ":9804"
    path: /metrics
    expiration: 10m
    metric-prefix: sros_

Run gNMIc

gnmic --config configs/subscriptions.yml sub --name port_stats_nokia

# Confirm if metrics are being exposed to Prometheus 
curl http://localhost:9804/metrics | head -20
sros__state_port_statistics_in_octets{port_port_id="1/1/c1",source="172.20.20.13",subscription_name="port_stats_nokia"} 0
sros__state_port_statistics_in_octets{port_port_id="1/1/c1/1",source="172.20.20.13",subscription_name="port_stats_nokia"} 5.510908681e+09
sros__state_port_statistics_in_octets{port_port_id="1/1/c2/1",source="172.20.20.13",subscription_name="port_stats_nokia"} 8.342930752e+09
sros__state_port_statistics_in_octets{port_port_id="1/1/c3/1",source="172.20.20.13",subscription_name="port_stats_nokia"} 149554

Prometheus Configuration

Install Prometheus

prometheus.yml

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'gnmic'
    static_configs:
      - targets: ['localhost:9804']

Access Prometheus

http://localhost:9090

#If running on a VM (like your Rocky Linux setup)
http://<VM-IP>:9090

Test Metrics in Prometheus

sros_state_port_statistics are accessible in Prometheus

Grafana Configuration

Install Grafana

Access Grafana

http://<your-ip>:3000

• Username: admin

• Password: admin

Add Prometheus to Grafana

In Grafana:

• Go to Settings → Data Sources

• Add Prometheus

• URL:

http://<your-host-ip>:9090

Build Your First Dashboard

Here's a basic dashboard I've created, named "Nokia SR OS Port Telemetry" using a simple PromQL query: rate(sros__state_port_statistics_in_octets[5m]) * 8, which measures bits per second.

Conclusion

Streaming telemetry is transforming the way modern networks are monitored and operated. Unlike traditional polling methods such as SNMP, telemetry provides continuous, near real-time visibility into device performance, interface utilization, routing behavior, and system health. This shift allows network engineers to move from reactive troubleshooting to proactive operations.

By combining gnmic, Prometheus, and Grafana, organizations can build a scalable observability platform capable of collecting high-frequency metrics and converting them into meaningful dashboards, alerts, and operational insights. Whether monitoring a single Nokia SR OS router or a multi-vendor backbone, telemetry enables faster fault detection, capacity planning, and service assurance.

For network automation teams, streaming telemetry is more than a monitoring tool—it is a foundation for closed-loop automation, where network state can automatically trigger intelligent actions. As networks continue to grow in speed, complexity, and business importance, telemetry becomes essential rather than optional.

"Nornir is not a replacement for Ansible. It's what happens when Python engineers decide they want the power of Ansible's inventory and parallelism without leaving Python."

The Ansible Model

When you write Ansible, you're writing YAML that describes a desired state or sequence of tasks. Ansible translates that YAML into actions. This abstraction serves as both your strength and limitation.

Clean, declarative, and easily understood by your manager. However, if you need to query each device, parse responses, make conditional decisions based on model and current configuration, apply different templates for each device family, and log every step with timing data to a database, your playbook turns into a creative exercise involving set_fact, when conditions, and Jinja2 filters.

Enter Nornir

Nornir is a Python automation framework. It's not a DSL or a YAML interpreter—it's a Python library. You write in Python. Nornir integrates Ansible's strengths in inventory management and parallel task execution into the Python environment, and then lets you take the lead.

Head to head: where they differ

Nornir Framework Overview

Unlike Ansible, which abstracts logic behind a DSL, Nornir remains in Python, offering the full capabilities of the language for data manipulation, error handling, testing, and integration with external systems. Its architecture is centered around three pillars: Inventory, Tasks, and Runners.

Inventory : Defines the devices (hosts), their attributes, and group memberships. Pluggable — SimpleInventory, NetBox, Ansible, custom.

Tasks : Pure Python functions that accept a Task object and run operations on a single host. Composable and independently testable (eg config push).

Runners : Control how tasks are executed across the inventory. ThreadedRunner (default) runs tasks concurrently using a thread pool.

Plugins : Connection drivers (Netmiko, NAPALM, Scrapli) and utility tools (print_result, write_file) extend core functionality.

Results : AggregatedResult and MultiResult objects give full per-host, per-task outcome data — iterable, filterable Python objects.

Inventory Management

Nornir's inventory system is entirely pluggable. One of its standout features is how its inventory concept closely mirrors Ansible's. You have hosts, groups, and variables, and you can even utilize your existing Ansible inventory files with the AnsibleInventory plugin.

For lab and small-scale deployments, SimpleInventory reads from YAML files. For production at 100+ devices, integrating directly with NetBox gives you a single source of truth.

SimpleInventory — file structure

File : config.yaml

inventory:
  plugin: SimpleInventory
  options:
    host_file: inventory/hosts.yaml
    group_file: inventory/groups.yaml
    defaults_file: inventory/defaults.yml

runner:
  plugin: threaded
  options:
    num_workers: 10

File : inventory/groups.yaml

sros:
  platform: nokia_sros
  username: <username>
  password: <password>
  connection_options:
    netmiko:
      extras:
        secret: ""
        global_delay_factor: 2

File : inventory/hosts.yaml

router1:
  hostname: 172.20.20.13
  groups:
    - sros

router2:
  hostname: 172.20.20.14
  groups:
    - sros

Tasks, Runners & Plugins

Understanding the execution model is critical before scaling to a large number of devices. Each task is a Python function. The runner controls concurrency. Plugins provide the connection layer to devices.

The plugin ecosystem

Nornir itself is deliberately minimal — it handles inventory and task running. Everything else is a plugin. The main ones you'll use immediately:

Yes — nornir-ansible is real. You can call Ansible modules from inside a Nornir task. The ecosystems aren't enemies.

ThreadedRunner — concurrency model

The ThreadedRunner utilizes Python's concurrent.futures.ThreadPoolExecutor. Each host receives a thread from the pool. With num_workers set to 50, Nornir can run 50 SSH sessions at once. For 100 devices, this results in two batches.

Use Case : Nokia SROS NTP Deployment Script

Installing Nornir

python -m venv .venv
source .venv/bin/activate
pip install nornir nornir-utils nornir-netmiko nornir-napalm

The Complete Script

Here is the full working script before we break it down line by line. Read it once, then follow the steps below to understand exactly what each part does.

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_config
from nornir_utils.plugins.functions import print_result
from nornir.core.task import Result
from netmiko import ConnectHandler
from datetime import datetime

nr = InitNornir(config_file="config.yaml")

def deploy_services(task):
    device = {
        "device_type": "nokia_sros",
        "host":        task.host.hostname,
        "username":    task.host.username,
        "password":    task.host.password,
        "secret":      "",
    }
    commands = [
        "configure",
        "    system",
        "        time",
        "            ntp",
        "                server 192.168.1.1",
        "                no shutdown",
        "            exit",
        "        exit",
        "    exit",
        "exit",
    ]
    with ConnectHandler(**device) as conn:
        output = conn.send_config_set(commands)
        print(f"[{task.host.name}] Output:\n{output}")
        verify = conn.send_command("show system ntp")
        print(f"[{task.host.name}] Verification:\n{verify}")
    return Result(host=task.host, result=output, changed=True)

start_time = datetime.now()
results = nr.run(task=deploy_services)
end_time = datetime.now()
print_result(results)
print(f"Execution Time: {end_time - start_time}")

Step-by-step breakdown

1. Import the Libraries

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_config
from nornir_utils.plugins.functions import print_result
from nornir.core.task import Result
from netmiko import ConnectHandler
from datetime import datetime

InitNornir loads the framework and inventory. netmiko_send_config is the Nornir plugin task for pushing config — imported but not used directly in this script (we bypass it with raw ConnectHandler instead, due to a nornir-netmiko bug with Nokia SROS 24.10.R5 discovered while testing). print_result gives a formatted per-host output table. Result is the object we return from our task to tell Nornir what happened. ConnectHandler is Netmiko's core SSH connection class. datetime is used to measure total execution time

2. Initialise Nornir from config file

nr = InitNornir(config_file="config.yaml")

This single line reads config.yaml and builds the entire Nornir runtime: the inventory (hosts.yaml + groups.yaml), the runner (ThreadedRunner with 10 workers).

3. Define the task function

def deploy_services(task):

This is a Nornir task — a plain Python function that accepts a single argument called task. Nornir calls this function once per host in your inventory, passing a Task object. Nornir uses threads, this function runs simultaneously across all hosts.

4. Build the device connection dictionary

device = {
    "device_type": "nokia_sros",
    "host":        task.host.hostname,
    "username":    task.host.username,
    "password":    task.host.password,
    "secret":      "",
}

This dictionary is passed directly to Netmiko's ConnectHandler. device_type tells Netmiko which SSH driver to use — nokia_sros loads the Nokia-specific handler that understands SROS prompts and CLI behaviour.

5. Define the CLI commands

commands = [
    "configure",
    "    system",
    "        time",
    "            ntp",
    "                server 192.168.1.1",
    "                no shutdown",
    "            exit",
    "        exit",
    "    exit",
    "exit",
]

In this example Nokia SROS Classic CLI uses a hierarchical config tree. You must navigate down into each level with the context keyword (configure, system, time, ntp) and then back out with exit at each level.

6. Open the SSH connection with ConnectHandler

with ConnectHandler(**device) as conn:

ConnectHandler(**device) unpacks the device dictionary as keyword arguments and opens an SSH session to the router. Using ConnectHandler directly (rather than through nornir-netmiko) bypasses the plugin bug where extras from the Nornir inventory were not being passed through to ConnectHandler.

7. Send the configuration commands

output = conn.send_config_set(commands)
print(f"[{task.host.name}] Output:\n{output}")

send_config_set() sends each command in the list one by one over SSH and captures the router's response after each command. For SROS it handles the prompt detection automatically — it waits for the next prompt before sending the next command. The print statement immediately shows what the router returned

8. Verify the configuration was applied

verify = conn.send_command("show system ntp")
print(f"[{task.host.name}] Verification:\n{verify}")

send_command() sends a single show command and returns the output as a string. Running show system ntp immediately after the config push confirms the NTP server is now present in the running config

9. Return a Result object to Nornir

return Result(host=task.host, result=output, changed=True)

Every Nornir task should return a Result object. host=task.host tells Nornir which device this result belongs to. result=output stores the raw command output in the result

10. Run the task across all hosts and measure time

start_time = datetime.now()
results = nr.run(task=deploy_services)
end_time = datetime.now()

datetime.now() captures the wall-clock time before and after execution

11. Print results and execution time

print_result(results)
print(f"Execution Time: {end_time - start_time}")

print_result() from nornir_utils formats the AggregatedResult into the familiar Nornir output tree

Execution Output

[router1] Output:
configure
A:PE1>config# system
A:PE1>config>system# time
A:PE1>config>system>time# ntp
A:PE1>config>system>time>ntp# server 192.168.1.1
*A:PE1>config>system>time>ntp# no shutdown
*A:PE1>config>system>time>ntp# exit
*A:PE1>config>system>time# exit
*A:PE1>config>system# exit
*A:PE1>config# exit
*A:PE1# exit all
*A:PE1#
[router1] Verification:

===============================================================
NTP Status
===============================================================
Configured         : Yes                Stratum              : -
Admin Status       : up                 Oper Status          : up
Server Enabled     : No                 Server Authenticate  : No
Clock Source       : none
Auth Check         : Yes
Auth Keychain      :
Current Date & Time: 2026/04/14 00:14:27 UTC
===============================================================

deploy_services************************************************
* router1 ** changed : True ***********************************
vvvv deploy_services ** changed : True vvvvvvvvvvvvvvvvvvv INFO

configure
A:PE1>config# system
A:PE1>config>system# time
A:PE1>config>system>time# ntp
A:PE1>config>system>time>ntp# server 192.168.1.1
*A:PE1>config>system>time>ntp# no shutdown
*A:PE1>config>system>time>ntp# exit
*A:PE1>config>system>time# exit
*A:PE1>config>system# exit
*A:PE1>config# exit
*A:PE1# exit all
*A:PE1#

^^^^ END deploy_services ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Conclusion

We explored the fundamental Nornir concepts, such as creating an inventory, defining and executing tasks (with multithread execution), and handling the results. These are the essential elements for developing complex network automation tasks.

Nornir's true power lies in its extensibility through plug-ins. While using Python directly might seem daunting at first, gaining proficiency with it makes Nornir an excellent choice for complete control over your network automation tasks.

With Nornir, you unlock:

• Massive speed improvements

• True parallel execution

• Full Python flexibility

For large-scale Nokia SR OS environments, Nornir becomes a game-changer for automation efficiency.

Why Ansible for Network Automation ?

Network engineers have long relied on manual CLI workflows: SSH into a device, run show commands, copy-paste output into a spreadsheet, make a change, repeat. This approach is slow, prone to errors, and unscalable when managing numerous routers across multiple vendors.

Ansible changes the game. It's agentless, uses SSH/NETCONF under the hood, and treats your network configuration as code — version-controlled, repeatable, and auditable. For a multivendor environment running Cisco IOS-XR, Juniper vMX, and Nokia SR OS, Ansible speaks all three dialects fluently.

Ansible Architecture : The Core building blocks

Here's a visual breakdown of Ansible's architecture:

1. Inventory - Your network Source of Truth

The inventory file informs Ansible about the devices that exist and how to access them. You can use either IP addresses or fully qualified domain names. In the upcoming example we’ll introduce how to create groups. We will organize devices into vendor groups for targeted plays.

File: inventory.yml

[cisco_iosxr]
rtr-cisco-01 ansible_host=172.20.20.15

[juniper_vmx]
rtr-junos-01 ansible_host=172.20.20.16

[nokia_sros]
rtr-nokia-01 ansible_host=172.20.20.13
rtr-nokia-02 ansible_host=172.20.20.14

[core_routers:children]
cisco_iosxr
juniper_vmx
nokia_sros

2. Playbooks - Your automation Scripts

The playbook is a file that contains your automation instructions. In other words, playbooks contain the individual tasks and workflows that you want to use to automate your network. The playbook is written in YAML and consists of one or more plays. Each play, in turn, includes one or more tasks.

Let’s take a look at an example playbook to better understand its structure

---
- name: Run Pre-Change Checks
  hosts: core_routers
  gather_facts: false
  tasks:
    - name: Include vendor-specific pre-check tasks
      include_tasks: "tasks/pre_check_{{ ansible_network_os }}.yml"

Our example playbook provides an overview of the structure to be used. You should already understand the basics of YAML and indentation. Ultimately, you need a YAML list of plays and a YAML list of tasks under the tasks key. Any slight indentation errors will result in error messages from Ansible when running your playbook, so precision is crucial.

3. Modules - The Actions of Ansible

Ansible modules perform a specific operation. For network automation, you'll use vendor-specific collections:

connection types

# group_vars/cisco_iosxr.yml
ansible_network_os: cisco.iosxr.iosxr
ansible_connection: ansible.netcommon.network_cli

# group_vars/juniper_vmx.yml
ansible_network_os: junipernetworks.junos.junos
ansible_connection: ansible.netcommon.netconf

# group_vars/nokia_sros.yml
ansible_network_os: nokia.sros
ansible_connection: ansible.netcommon.network_cli

Variables and Vault Credentials

Hardcoding passwords in playbooks is a career-limiting move. Use group_vars for non-sensitive data and Ansible Vault for secrets.

Since we are testing in a lab environment we are not using Ansible Vault but it is highly recommended in a Production environment.

group_vars/nokia_sros.yml — Non-sensitive defaults

ansible_network_os: nokia.sros
ansible_connection: ansible.netcommon.network_cli
ansible_user: "admin"
ansible_password: "{{ vault_ansible_password }}""

Creating and using Ansible Vault

# Create an encrypted secrets file
ansible-vault create group_vars/all/vault.yml

# Edit it later
ansible-vault edit group_vars/all/vault.yml

Inside the vault file :

# group_vars/all/vault.yml (encrypted at rest)
vault_ansible_password: "cOdeDNetw\(rk2#%\)"

Run playbooks with Vault :

# Prompt for vault password
ansible-playbook precheck.yml --ask-vault-pass

Hands On - Multivendor Pre/Post Change Checks

The scenario involves a maintenance window for BGP configuration changes across core routers. You need to capture the device state before and after the changes, then compare them for any differences.

Project Structure

pre-post-checks/
├── inventory.yml
├── precheck.yml
├── postcheck.yml
├── junos_checks.yml          
├── sros_checks.yml                           
├── reports/
└── group_vars/

Prerequisites

pip install ansible
pip install ansible-pylibssh (optional

Pre-check Playbook

File : precheck.yml

- name: "PRE-CHANGE CHECKS"
  hosts: core_routers
  gather_facts: false
  vars:
    check_phase: "pre"
    timestamp: "{{ lookup('pipe', 'date +%Y%m%d_%H%M%S') }}"
    output_base: "{{ playbook_dir }}/reports"

  tasks:
    - name: Debug output path
      debug:
         msg: "Will create: reports/{{ inventory_hostname }}/{{ timestamp }}"
      delegate_to: localhost

    - name: Create output directory
      shell: mkdir -p "{{ output_base }}/{{ inventory_hostname }}/{{ timestamp }}"
      delegate_to: localhost

    - name: Set output_dir fact per host
      set_fact:
        output_dir: "{{ output_base }}/{{ inventory_hostname }}/{{ timestamp }}" 

    - name: Run Cisco IOS-XR checks
      include_tasks: cisco_checks.yml
      when: ansible_network_os == "cisco.iosxr.iosxr"

    - name: Run Juniper Junos checks
      include_tasks: junos_checks.yml
      when: ansible_network_os == "junipernetworks.junos.junos"

    - name: Run Nokia SR OS checks
      include_tasks: sros_checks.yml
      when: ansible_network_os == "sros"

File : cisco_checks.yml

 - name: "[Cisco] Gather BGP summary"
  cisco.iosxr.iosxr_command:
    commands:
      - show bgp ipv4 unicast summary
      - show bgp ipv6 unicast summary
  register: cisco_bgp_output

- name: "[Cisco] Gather interface status"
  cisco.iosxr.iosxr_command:
    commands:
      - show interfaces brief
      - show ipv4 interface brief
  register: cisco_intf_output

- name: "[Cisco] Gather routing table summary"
  cisco.iosxr.iosxr_command:
    commands:
      - show route summary
      - show route ipv6 summary
  register: cisco_route_output

- name: "[Cisco] Debug output_dir"
  debug:
    msg: "output_dir is: {{ output_dir }}"
  delegate_to: localhost

- name: "[Cisco] Save pre-check output to file"
  copy:
    content: |
      === CISCO IOS-XR PRE-CHECK: {{ inventory_hostname }} ===
      Timestamp: {{ timestamp }}

      --- BGP SUMMARY (IPv4) ---
      {{ cisco_bgp_output.stdout[0] }}

      --- BGP SUMMARY (IPv6) ---
      {{ cisco_bgp_output.stdout[1] }}

      --- INTERFACE STATUS ---
      {{ cisco_intf_output.stdout[0] }}

      --- ROUTE SUMMARY ---
      {{ cisco_route_output.stdout[0] }}
    dest: "{{ output_dir }}/pre_check.txt"
  delegate_to: localhost

File : junos_checks.yml

- name: "[Junos] Gather BGP summary (structured)"
  junipernetworks.junos.junos_command:
    commands:
      - show bgp summary
    display: xml   # NETCONF returns structured XML
  register: junos_bgp_output

- name: "[Junos] Gather interface status"
  junipernetworks.junos.junos_command:
    commands:
      - show interfaces terse
  register: junos_intf_output

- name: "[Junos] Gather routing table"
  junipernetworks.junos.junos_command:
    commands:
      - show route summary
  register: junos_route_output

- name: "[Junos] Extract BGP peer count using XPath"
  set_fact:
    bgp_peer_count: >-
      {{ junos_bgp_output.output[0] | regex_findall('peer-count.*?</peer-count>')
         | length }}

- name: "[Junos] Save pre-check output"
  copy:
    content: |
      === JUNIPER vMX PRE-CHECK: {{ inventory_hostname }} ===
      Timestamp: {{ timestamp }}

      --- BGP SUMMARY ---
      {{ junos_bgp_output.stdout[0] | default(junos_bgp_output.output[0]) }}

      --- INTERFACES ---
      {{ junos_intf_output.stdout[0] }}

      --- ROUTING TABLE SUMMARY ---
      {{ junos_route_output.stdout[0] }}
    dest: "{{ output_dir }}/pre_check.txt"
  delegate_to: localhost

File : sros_checks.yml

- name: "[Nokia] Gather BGP summary"
  community.network.sros_command:
    commands:
      - show router bgp summary
      - show router bgp summary family ipv6
  register: sros_bgp_output

- name: "[Nokia] Gather interface status"
  community.network.sros_command:
    commands:
      - show router interface
      - show port
  register: sros_intf_output

- name: "[Nokia] Gather routing table"
  community.network.sros_command:
    commands:
      - show router route-table summary
  register: sros_route_output

- name: "[Nokia] Save pre-check output"
  copy:
    content: |
      === NOKIA SR OS PRE-CHECK: {{ inventory_hostname }} ===
      Timestamp: {{ timestamp }}

      --- BGP SUMMARY (IPv4) ---
      {{ sros_bgp_output.stdout[0] }}

      --- BGP SUMMARY (IPv6) ---
      {{ sros_bgp_output.stdout[1] }}

      --- INTERFACES ---
      {{ sros_intf_output.stdout[0] }}

      --- ROUTE TABLE SUMMARY ---
      {{ sros_route_output.stdout[0] }}
    dest: "{{ output_dir }}/pre_check.txt"
  delegate_to: localhost

File : group_vars/cisco_ixr.yml

ansible_network_os: cisco.iosxr.iosxr
ansible_connection: ansible.netcommon.network_cli
ansible_user: "<username>"
ansible_password: "<password>"

Run the Playbook

Output :

ansible-playbook -i inventory.yml precheck.yml

PLAY [PRE-CHANGE CHECKS] ***************************************************************

TASK [Debug output path] ***************************************************************
ok: [rtr-cisco-01 -> localhost] => {
    "msg": "Will create: reports/rtr-cisco-01/20260407_103940"
}
ok: [rtr-junos-01 -> localhost] => {
    "msg": "Will create: reports/rtr-junos-01/20260407_103940"
}
ok: [rtr-nokia-01 -> localhost] => {
    "msg": "Will create: reports/rtr-nokia-01/20260407_103940"
}
ok: [rtr-nokia-02 -> localhost] => {
    "msg": "Will create: reports/rtr-nokia-02/20260407_103940"
}

TASK [Create output directory] ***************************************************************
changed: [rtr-nokia-02 -> localhost]
changed: [rtr-nokia-01 -> localhost]
changed: [rtr-cisco-01 -> localhost]
changed: [rtr-junos-01 -> localhost]

TASK [Set output_dir fact per host] ***************************************************************
ok: [rtr-junos-01]
ok: [rtr-cisco-01]
ok: [rtr-nokia-01]
ok: [rtr-nokia-02]

TASK [Run Cisco IOS-XR checks] ***************************************************************
skipping: [rtr-junos-01]
skipping: [rtr-nokia-01]
skipping: [rtr-nokia-02]
included: /labs/kleburu/python-projects/Ansible_Automation/multivendor-validation/pre-post-checks/cisco_checks.yml for rtr-cisco-01

TASK [[Cisco] Gather BGP summary] ***************************************************************
ok: [rtr-cisco-01]

TASK [[Cisco] Gather interface status] ***************************************************************
ok: [rtr-cisco-01]

TASK [[Cisco] Gather routing table summary] ***************************************************************
ok: [rtr-cisco-01]

TASK [[Cisco] Debug output_dir] ***************************************************************
ok: [rtr-cisco-01 -> localhost] => {
    "msg": "output_dir is: /labs/kleburu/python-projects/Ansible_Automation/multivendor-validation/pre-post-checks/reports/rtr-cisco-01/20260407_103940"
}

TASK [[Cisco] Save pre-check output to file] ***************************************************************
changed: [rtr-cisco-01 -> localhost]

TASK [Run Juniper Junos checks] ***************************************************************
skipping: [rtr-cisco-01]
skipping: [rtr-nokia-01]
skipping: [rtr-nokia-02]
included: /labs/kleburu/python-projects/Ansible_Automation/multivendor-validation/pre-post-checks/junos_checks.yml for rtr-junos-01

TASK [[Junos] Gather BGP summary (structured)] ***************************************************************
ok: [rtr-junos-01]

TASK [[Junos] Gather interface status] ***************************************************************
ok: [rtr-junos-01]

TASK [[Junos] Gather routing table] ***************************************************************
ok: [rtr-junos-01]

TASK [[Junos] Extract BGP peer count using XPath] ***************************************************************
ok: [rtr-junos-01]

TASK [[Junos] Save pre-check output] ***************************************************************
changed: [rtr-junos-01 -> localhost]

TASK [Run Nokia SR OS checks] ***************************************************************
skipping: [rtr-cisco-01]
skipping: [rtr-junos-01]
included: /labs/kleburu/python-projects/Ansible_Automation/multivendor-validation/pre-post-checks/sros_checks.yml for rtr-nokia-01, rtr-nokia-02

TASK [[Nokia] Gather BGP summary] ***************************************************************
ok: [rtr-nokia-01]
ok: [rtr-nokia-02]

TASK [[Nokia] Gather interface status] ***************************************************************
ok: [rtr-nokia-02]
ok: [rtr-nokia-01]

TASK [[Nokia] Gather routing table] ***************************************************************
ok: [rtr-nokia-02]
ok: [rtr-nokia-01]

TASK [[Nokia] Save pre-check output] ***************************************************************
changed: [rtr-nokia-01 -> localhost]
changed: [rtr-nokia-02 -> localhost]

PLAY RECAP ***************************************************************
rtr-cisco-01               : ok=9    changed=2    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0
rtr-junos-01               : ok=9    changed=2    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0
rtr-nokia-01               : ok=8    changed=2    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0
rtr-nokia-02               : ok=8    changed=2    unreachable=0    failed=0    skipped=2    rescued=0    ignored=0

File : reports/rtr-cisco-01/20260407_103940/precheck.txt

=== CISCO IOS-XR PRE-CHECK: rtr-cisco-01 ===
Timestamp: 20260407_103948

--- BGP SUMMARY (IPv4) ---
BGP router identifier 10.10.10.3, local AS number 65000
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 2
BGP table nexthop route policy:
BGP main routing table version 2
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process       RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker               2          2          2          2           2           0

Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
10.10.10.1        0 65000  239205  239192        2    0    0     2w3d          0

--- BGP SUMMARY (IPv6) ---
% None of the requested address families are configured for instance 'default'(36210)

--- INTERFACE STATUS ---
Intf       Intf        LineP              Encap  MTU        BW
               Name       State       State               Type (byte)    (Kbps)
--------------------------------------------------------------------------------
                Lo0          up          up           Loopback  1500          0
              Lo100          up          up           Loopback  1500          0
                Nu0          up          up               Null  1500          0
     Mg0/RP0/CPU0/0          up          up               ARPA  1514    1000000
          Gi0/0/0/0          up          up               ARPA  9212    1000000
          Gi0/0/0/1  admin-down  admin-down               ARPA  1514    1000000
          Gi0/0/0/2          up          up               ARPA  1514    1000000

--- ROUTE SUMMARY ---
Route Source                     Routes     Backup     Deleted     Memory(bytes)
local                            2          0          0           416
connected                        1          1          0           416
application fib_mgr              0          0          0           0
vxlan                            0          0          0           0
static                           0          0          0           0
dagr                             0          0          0           0
bgp 65000                        0          0          0           0
isis 0                           6          1          0           1456
Total                            9          2          0           2288

Post-check Playbook

For this playbook we are still using the same construct as the pre-check playbook the only changes done are below

# change the check_phase to post

- name: "POST-CHANGE CHECKS"
  hosts: core_routers
  gather_facts: false
  vars:
    check_phase: "post"

# change the sros_checks.yml like below 

- name: "[Nokia] Save post-check output"
  copy:
    content: |
      === NOKIA SR OS POST-CHECK: {{ inventory_hostname }} ===
      Timestamp: {{ timestamp }}

      --- BGP SUMMARY (IPv4) ---
      {{ sros_bgp_output.stdout[0] }}

      --- BGP SUMMARY (IPv6) ---
      {{ sros_bgp_output.stdout[1] }}

      --- INTERFACES ---
      {{ sros_intf_output.stdout[0] }}

      --- ROUTE TABLE SUMMARY ---
      {{ sros_route_output.stdout[0] }}
    dest: "{{ output_dir }}/post_check.txt"
  delegate_to: localhost

# Run the playbook 

ansible-playbook -i inventory.yml postcheck.yml

Comparison Playbook

The compare.yml playbook finds the most recent pre and post check files for every device — regardless of which timestamp folder they live in — diffs them, and saves a full validation report.

- name: "COMPARE PRE/POST CHECKS"
  hosts: localhost
  gather_facts: false

  tasks:
    - name: Find all device directories
      find:
        paths: "{{ playbook_dir }}/reports/"
        file_type: directory
        recurse: no
      register: device_dirs

    - name: Find latest pre-check for each device
      shell: |
        find "{{ item.path }}" -name "pre_check.txt" | sort | tail -1
      loop: "{{ device_dirs.files }}"
      register: latest_pre
      delegate_to: localhost

    - name: Find latest post-check for each device
      shell: |
        find "{{ item.path }}" -name "post_check.txt" | sort | tail -1
      loop: "{{ device_dirs.files }}"
      register: latest_post
      delegate_to: localhost

............. [truncated]

Sample diff output after the change window:

}
ok: [localhost] => (item=rtr-cisco-01) => {
    "msg": [
        "============================================================",
        "Device     : rtr-cisco-01",
        "Pre-check  : /labs/kleburu/python-projects/Ansible_Automation/multivendor-validation/pre-post-checks/reports/rtr-cisco-01/20260407_103940/pre_check.txt",
        "Post-check : /labs/kleburu/python-projects/Ansible_Automation/multivendor-validation/pre-post-checks/reports/rtr-cisco-01/20260407_111244/post_check.txt",
        "============================================================",
        "--- DIFF ---",
        "1,2c1,2",
        "< === CISCO IOS-XR PRE-CHECK: rtr-cisco-01 ===",
        "< Timestamp: 20260407_103948",
        "---",
        "> === CISCO IOS-XR POST-CHECK: rtr-cisco-01 ===",
        "> Timestamp: 20260407_111252",
        "23c23",
        "< 10.10.10.1        0 65000  239205  239192        2    0    0     2w3d          0",
        "---",
        "> 10.10.10.1        0 65000  239272  239258        2    0    0     2w3d          0"
    ]
}

Key Takeaways

Download Code

All YAML files are here: codednetwork-week-8

YANG ( Yet Another Next Generation) is a data modeling language that defines the structure, semantics, and constraints of configuration and state data for network devices and services. YANG modules outline the hierarchical schema, including nodes, types, constraints, RPCs, and notifications. YANG has become the networking industry standard for data modeling because it is human readable, extensible and easy to learn

A YANG model defines a tree structure and data is mapped into this tree.  A model is defined in a text file and comprises a module and, optionally, submodules, which when compiled together form the tree.

YANG is a way to enforce constraints on data inputs. These may inputs used from an API encoded as XML and JSON. The device will check if the data adheres to the underlying model

YANG Module Definition

module nokia-types-bgp

module nokia-types-bgp {


yang-version "1.1";

namespace "urn:nokia.com:sros:ns:yang:sr:types-bgp";

prefix "types-bgp";

import nokia-sros-yang-extensions     { prefix "sros-ext"; }
import nokia-types-sros               { prefix "types-sros"; }

sros-ext:sros-major-release "rel22";

revision "2022-05-03";

typedef llgr-family-identifiers {
    type enumeration {
        enum "ipv4"                         { value 1; }
        enum "vpn-ipv4"                     { value 2; }
        enum "ipv6"                         { value 3; }
        enum "vpn-ipv6"                     { value 5; }
        enum "l2-vpn"                       { value 6; }
        enum "flow-ipv4"                    { value 10; }
        enum "route-target"                 { value 11; }
        enum "flow-ipv6"                    { value 14; }
        enum "label-ipv4"                   { value 17; }
        enum "label-ipv6"                   { value 18; }
        enum "flow-vpn-ipv4"                { value 23; }
        enum "flow-vpn-ipv6"                { value 24; }
    }

}

A module name is specified in the module nokia-types-bgp section, with nokia-types-bgp as the name of the new YANG module. A yang-version indicates the version number of the YANG definition used by the author, not the module itself. This is typically 1.0 or 1.1. For new modules, it's recommended to start with the latest version.

A prefix is a short name used within YANG modules for quick reference to the modules. An import is used alongside the module name of the YANG module being imported.

A revision number is formatted as a date and should be updated whenever the module changes. A type definition (typedef) defines custom types using standardized YANG elements.

Exploring YANG in Depth

YANG STATEMENTS

Leaf Nodes

• Simple data such as an integer or a string

• Represents a single value

• No children

# YANG

leaf host-name { 
     type string;
     description "Hostname for this system"; 
}

# NETCONF XML 

<host-name>codednetwork.com</host-name>

Leaf-List Nodes

• This is just like leaf statement but there can be multiple instances

• one value of a particular type per leaf

# YANG

leaf-list name-server { 
type string; 
description "List of DNS servers to query"
}

# NETCONF XML
 
<name-server>8.8.8.8</name-server>
<name-server>4.4.4.4</name-server>

List Nodes

• It allows you to create a list of leafs or leaf-lists

• Each entry is structure or a record instance

# YANG

list vlan { 
   key "id";
     leaf id { 
       type int; 
       range 1..4094; 
     } 
     leaf name { 
        type string;
     } 
}

# NETCONF XML 

<vlan> 
  <id>100</id>
  <name>web_vlan</name>
</vlan>
<vlan> 
  <id>200</id>
  <name>app_vlan</name>
</vlan>

Container Nodes

• It is used to group nodes in a subtree

• It only contains child nodes and has no value

• May contain number of child nodes of any type (including leafs, lists, containers and leaf-lists

# YANG

container system {
    container login-control {
       container pre-login message {
              leaf message {
                   type (*); 
                   description
                   "Message displayed prior to the login prompt";
       }
    }
}

# NETCONF XML 

<system> 
      <login-control>
           <pre-login message>
                      <message> Learning Yang is cool </message>
           </pre-login message>
      </login-control>
</system>

What is NETCONF ?

Overview

NETCONF is a standardized IETF configuration management protocol specified in RFC 6241, known as Network Configuration Protocol (NETCONF) . It is secure, connection-oriented, and runs on top of the SSHv2 transport protocol as specified in RFC 6242 . NETCONF is an XML-based protocol that can be used as an alternative to CLI or SNMP for managing an SR OS router

NETCONF uses RPC messaging for communication between NETCONF client and NETCONF server running on SROS. An RPC message and configuration or state data is encapsulated within an XML document. The SR OS NETCONF interface supports configuration, state and various router operations

Client                                      Server  
|=== TRANSPORT ================================| 
|<--- TCP SYN -------------------------------->|
|<-- TCP SYN-ACK ----------------------------->|
|--- SSH handshake + userauth ---------------->| 
|<-- SSH userauth success ---------------------|
|--- SSH subsystem "netconf" request --------->| 
|<-- SSH channel success ----------------------|
|                                              | 
|=== SESSION ==================================|
|<--<hello> session-id=42, capabilities -------|
|---<hello> capabilities --------------------->| 
|                                              |
|=== OPERATIONS ===============================|
|--- <rpc> get-config(running) --------------->|
|<--<rpc-reply> <data>…<data> -----------------|
|                                              |
|=== TEARDOWN =================================| 
|--- <rpc> close-session --------------------->| 
|<--<rpc-reply> <ok/> -------------------------| 
|--- SSH channel close ----------------------->|

message exchange

Protocol Stack

Enabling NETCONF Nokia SROS

# Step 1 - Ensure model-driven mode is enabled 

A:R1# configure system management-interface configuration-mode model-driven

# Step 2 - Enable NETCONF and Auto-save 

(gl)[configure system management-interface]
A:admin@R1# 
    netconf { 
    admin-state enable
    auto-config-save true 
    }

# Step 3 - Select the YANG Modules 

(gl)[configure system management-interface]
A:admin@R1#
    yang-modules { 
       nokia-modules false 
       nokia-combined-modules true
    }

# Step 4 - Create user with NETCONF access 

(gl)[configure local-user { 
        user "netconf" { 
            password "<password-here>" 
            access { 
                netconf true 
            } 
            console { 
               member ["administrative"] 
            } 
        } 
} system security user-params]

# Step 5 - Grant lock and kill permissions 

(gl)[configure system security aaa local-profiles profile "administrative"] A:admin@R1#
    netconf { 
        base-op-authorization {
            kill-session true 
            lock true
        }
    }

NETCONF - Base Operations

NETCONF - Interacting with Nokia SROS

Connect with SSH

The simplest and the easiest way to interact with a router is by using SSH.

ssh admin@<host-ip> -p 830 -s netconf

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
       <capability>urn:ietf:params:netconf:base:1.0</capability>
       <capability>urn:ietf:params:netconf:base:1.1</capability>
       <capability>urn:ietf:params:netconf:capability:candidate:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1
       </capability>
       <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:notification:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:interleave:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:validate:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:validate:1.1
       </capability>
       <capability>urn:ietf:params:netconf:capability:startup:1.0
       </capability>
       <capability>urn:ietf:params:netconf:capability:url:1.0
       scheme=ftp,tftp,file<</capability>
       <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
       </capability>
       <capability>urn:nokia.com:sros:ns:yang:sr:major-release:24
       </capability>
       <capability>urn:ietf:params:xml:ns:yang:iana-if-type?module=iana-if-   
       type&revision=2014-05-08</capability>
       <capability>urn:ietf:params:netconf:capability:yang-library:1.0?    
        revision=2016-06-21&module-set-id=gOPkB60aiVyk5<
       </capability>
    </capabilities>
     </session-id>57677<session-id>
</hello>

truncated capabilities

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabalities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>
]]>]]>

# Retrieve the services
 
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source><candidate/></source> 
    <filter>
      <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
        <service>
        </service>
      </configure>
    </filter>
  </get-config>
</rpc>
]]>]]>

# RPC-REPLY with services 

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0>
   <data>
       <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
           <service>
               <epipe>
                   <service-name>test</service-name>
                   <admin-state>enable</admin-state>
                   <service-id>10</service-id>
                   <customer>1</customer>
                   <spoke-sdp>
                      <sdp-bind-id>10:10</sdp-bind-id>
                      <admin-state>enable</admin-state>
                   </spoke-sdp>
                </epipe>
                <sdp>
                  <sdp-id>10</sdp-id>
                  <admin-state>enable</admin-state>
                  <description>pysros-example</description>
                  <delivery-type>mpls</delivery-type>
                  <far-end> 
                      <ip-address>10.10.10.2</ip-address>
                  </far-end>
                  <lsp>
                    <lsp-name>PE1-to-PE2</lsp-name>
                  </lsp>
                </sdp>
         </service>
       </configure>
   </data>
</rpc-reply>

Connect with netconf-console2

netconf-console2 is a console application built to interact with network devices using NETCONF. It allows engineers and automation systems to send NETCONF Remote Procedure Call (RPC) operations to a device. It can run in two modes:

• Command-line mode: Used to execute one or more RPC operations in a single shell command.

• Interactive (console) mode: Provides an interactive session where a user can issue multiple commands sequentially, with limited support for tab-completion

# Install netconf-console2 
pip install netconf-console2 

# Retrieve configuration 

netconf-console2 --host=<host-ip> -u <username> -p <password> --port=830 --get-config

# Configuration results 

<?xml version='1.0' encoding='UTF-8'?> 
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
            <groups>
                <group> 
                    <name>test</name>
                    <router>
                       <router-name> Base </router-name>
                       <interface>loop</interface>
                       <ip-mtu>444</ip-mtu>
                       </interface>
                    </router>
                <group>              
            </groups>
            <card>
                <slot-number>1</slot-number>
                <card-type>iom-1<card-type>
                <mda>
                   <mda-slot>1</mda-slot>
                   <mda-type>me12-100gb-qsfp28</mda-type>
                </mda>
            </card>

............. [output truncated]

Connect with NETCONF client for Visual Studio Code

This extension adds an interactive NETCONF client to Visual Studio Code, connecting to NETCONF servers such as NOKIA IP routers (SR OS and SRLinux). It brings NETCONF into the editor so you can manage modern network equipment directly from VS Code using the standard NETCONF protocol.

If you're not familiar with Python or using libraries like NAPALM and ncclient to interact with a router running NETCONF, this VS Code extension is perfect for you. The interface is user-friendly and easy to navigate.

Create the connect-name , host-ip and enter the credentials

Click connect icon to start interacting with the Nokia SROS

Base operations options

Other Tools

PYANG

pyang is a YANG validator and converter that checks YANG modules for correctness and generates documentation or code stubs.

Convert YANG into a tree diagram

# Execute the below command 

pyang -f tree nokia-state.yang > nokia-state.tree

nokia-state tree structure sample

Generate html/javascript tree

# Execute the below command 

pyang -f jstree nokia-state.yang > nokia-state.jstree

Then you can browse the YANG on a web browser

Conclusion

The CLI era gave network engineers power and flexibility, but at the cost of machine-readability, validation, and safe rollback. Every vendor implemented their own syntax, every script was fragile, and every change carried the risk of an unrecoverable typo. NETCONF and YANG fundamentally transform the way network configurations are managed , the device exposes a schema, accepts structured configuration, validates every change before it is deployed, and can roll back automatically.

That shift — from text scraping to model-driven management — is not just a technical improvement. It is what makes large-scale network automation reliable enough to trust in production. When your automation toolchain uses YANG, it knows what a valid interface configuration looks like before it ever touches a router. When it uses confirmed commit, a misconfiguration cannot disable a device permanently. When it subscribes to NETCONF notifications, it reacts to events rather than polling every 60 seconds hoping nothing changed.

" The combination of a strongly-typed schema language, a transactional RPC protocol, and a mandatory encrypted transport is not accidental — it is a deliberate architecture designed for the scale and reliability demands of modern network operations "

Managing Nokia SR OS routers, such as the 7750 SR, 7450 ESS, 7210 SAS and the rest of the family, has typically involved dealing with CLI automation through Netmiko or creating a custom NETCONF client. While both methods are functional, they have drawbacks: screen-scraping CLI output can fail with software updates, and manually crafting NETCONF XML payloads is cumbersome and prone to errors.

pySROS is Nokia's answer: pySROS libraries provide a model-driven management interface for Python developers to integrate with supported Nokia routers running the Service Router Operating System (SR OS). The libraries provide an Application Programming Interface (API) for developers to create applications that can interact with Nokia SR OS devices, whether those applications are executed from a development machine, a remote server, or directly on the router

YANG Modeling

YANG is a language that is designed to be readable by both humans and machines in order to model configuration and state information. YANG is rapidly becoming the standard way to model network devices and network device information. YANG is defined in the following RFCs:

• RFC 6020 - YANG - A Data Modelling Language for the Network Configuration Protocol (NETCONF)

• RFC 6021 - Common YANG Data Types

• RFC 7950 - The YANG 1.1 Data Modelling Language

Model paths

At the core of the pySROS libraries are Nokia's model-driven management concepts built into SR OS. Communication between applications developed with pySROS libraries and Nokia SR OS routers is facilitated through model-driven paths that reference elements within the Service Router Operating System. The pySROS libraries use modeled paths in the JSON instance path format, which describes the referenced YANG models, including all YANG lists, list keys, and their values (though these may sometimes be omitted).

To obtain the JSON instance path directly from an SR OS router running software from release 21.7.R1, enter pwc json-instance-path in the MD-CLI within the relevant context.

SR OS pwc json-instance-path output from service configuration

(gl)[/configure service vprn "10" bgp-ipvpn mpls] 
A:admin@R1# pwc json-instance-path 
Present Working Context: /nokia-conf:configure/service/vprn[service-name="10"]/bgp-ipvpn/mpls

SR OS pwc json-instance-path output from BGP State

(gl)[/state router "Base" bgp neighbor "10.10.10.4"] 
A:admin@R1# pwc json-instance-path
Present Working Context: /nokia-state:state/router[router-name="Base"]/bgp/neighbor[ip-address="10.10.10.4"]

Prerequisites and Installation

To use the pySROS libraries, the following pre-requisites must be met:

• one or more SR OS nodes running in model-driven management interface configuration mode

• Running SR OS 21.7.R1 or greater (to execute applications on the SR OS device)

• With NETCONF enabled and accessible by an authorized user (to execute applications remotely)

• Python 3 interpreter of version 3.6 or newer when using the pySROS libraries to execute applications remotely

#Create and activate a virtual environment
python3 -m venv env
source env/bin/activate

#Install pySROS from PyPI
pip install pysros
pip install --upgrade pysros

#Or clone from GitHub
git clone https://github.com/nokia/pysros 
python3 setup.py install

Architecture

On-box vs Off-box execution

pySROS supports two distinct execution modes. Understanding the trade-offs is the first design decision for any automation project.

Off-box: [Python script] ──── NETCONF/SSH ────▶ [SR OS node]
        dev machine / automation server          7750 SR / 7250 IXR

On-box: [SR OS node] ▶ [pyexec /cron /EHS/alias] ▶ [pySROS script]
                                               MicroPython Interpreter

Off-box execution gives you several advantages to name a few: the ability to interact with multiple routers from a single script, executing scripts with a large data set, no impact on CPU / memory, Easier integration with other systems and the most important one is Access to richer Python ecosystem (Prometheus, Grafana, NetBox, Streamlit, etc.)

On-box execution runs inside the router itself via MicroPython — a lean Python 3 implementation designed for constrained environments. Execution time and memory usage are bounded by SR OS to protect routing stability. You can only address the local device and and the script can be triggered via CLI command aliases, EHS event handlers, cron jobs, or the pyexec command.

Getting Started

Lab Setup

We continue using the lab setup we built for our multivendor environment, and this is made possible by Containerlab

Our lab consists of the below components:

Servers:

• Rocky Linux 9.6

• Python 3.9

• pySROS 23.3.3

Network Devices:

• Nokia SR OS 24.10.R5

Making a connection

To access the model-driven interface of SR OS while running a Python application from a remote workstation, use the pysros.management.connect() method. When executing a Python application on SR OS, the same method is used, but its arguments are ignored

File : connect.py

from pysros.management import connect
from pysros.exceptions import *
import sys


def get_connection(): 
    try: connection_object = connect(host="<host-ip>", 
                                     username="username", 
                                     password="password")

    except RuntimeError as error1:
        print("Failed to connect.  Error:", error1)
        sys.exit(-1)
    except ModelProcessingError as error2:
        print("Failed to create model-driven schema.  Error:", error2)
        sys.exit(-2)

if __name__ == "__main__":
    connection_object = get_connection()
    print("\n Connection established successfully \n")

Expected Output

Connection established successfully

Compliance Tool

The compliance script (compliance.py) connects to an SR OS router to validate its configuration against a predefined golden template, which consists of YANG model paths and their expected values.

For each check, it calls c.running.get(path) and compares the returned .data value against the expected string. If the path doesn't exist or the value doesn't match, it's recorded as a violation. At the end it prints a report showing passed vs failed checks, with the full YANG path, expected value, and actual value for each violation.

File : compliance.py

from pysros.management import connect
import sys
import datetime

GOLDEN_CHECKS = [
    # Security baseline
    (
        "/nokia-conf:configure/system/login-control/pre-login   message/message",
        "Authorized access only. All activity is monitored."
    ),
    (
        "/nokia-conf:configure/system/security/telnet-server",
        "False"
    ),
    (
        "/nokia-conf:configure/system/security/ftp-server",
        "True"
    ),

    # NTP must be enabled — correct path is under system/time/ntp
    (
        "/nokia-conf:configure/system/time/ntp/admin-state",
        "enable"
    ),
    # Router-id must exist (we just check presence, not value)
    (
        "/nokia-conf:configure/router[router-name='Base']/router-id",
        None
    ),
    # SNMP community must exist
    (
        "/nokia-conf:configure/system/security/snmp",
        None
    ),
    #  ISIS should be enabled
    (
        "/nokia-conf:configure/router[router-name='Base']/isis[isis-instance='0']/admin-state",
        "enable"
    ),
]

def check_compliance(c, checks):

    violations = []
    passed = 0

    for path, expected in checks:
        try:
            val = c.running.get(path)
            actual = val.data if hasattr(val, "data") else str(val)
            
            if expected is not None and str(actual) != str(expected):
                violations.append((path, expected, actual))
            else:
                passed += 1
       
        except Exception:
            violations.append((path, expected, "MISSING"))
    
        return violations, passed

def print_report(violations, passed, total):
    
    ts = datetime.datetime.utcnow().strftime("%Y-%m-%d %H:%M:%S UTC")
    print()
    print("=" * 70)
    print(f"  Nokia SR OS Config Compliance Report")
    print(f"  Generated: {ts}")
    print("=" * 70)
    print(f"  Checks:  {total}  |  Passed: {passed}  |  Violations: {len(violations)}")
    print("=" * 70)
    
    if not violations:
        print()
        print("  [COMPLIANT]  All checks passed.")
        print()
        return
     
    print()
    print("  VIOLATIONS FOUND:")
    print()
    for i, (path, expected, actual) in enumerate(violations, 1):
        # Shorten very long paths for readability
        short_path = path.split("/")[-1] if "/" in path else path
        print(f"  [{i}] {short_path}")
        print(f"      Full path : {path}")
        print(f"      Expected  : {expected if expected is not None else '(must exist)'}")
        print(f"      Actual    : {actual}")
        print()

if __name__ == "__main__":
    c = connect(host="<host-name>" , username="username" , password="password")

    total = len(GOLDEN_CHECKS)
    violations, passed = check_compliance(c, GOLDEN_CHECKS)

    print_report(violations, passed, total)

    c.disconnect()

Expected Output

=============================================================
 Nokia SR OS Config Compliance 
 Report Generated: 2026-03-23 02:22:26 UTC
=============================================================
 Checks: 7 | Passed: 6 | Violations: 1
=============================================================

 VIOLATIONS FOUND:
 [1] admin-state
     Full path : /nokia-conf:configure/system/time/ntp/admin-state
     Expected  : enable
     Actual    : disable

# Enabling NTP 

[gl:/configure system time ntp]
A:admin@PE1# info json
{ 
 "nokia-conf:admin-state": "enable"
}

# NTP was enabled and all checks passed with no violations 

============================================================
   Nokia SR OS Config Compliance 
   Report Generated: 2026-03-23 09:08:47 UTC
=============================================================
   Checks: 7 | Passed: 7 | Violations: 0
=============================================================

CLI Command Alias

A command alias in SR OS lets you expose a pySROS script as a native MD-CLI command. From the operator's perspective they just type a short command — the Python execution is invisible.

How it works

The script lives on the router's compact flash. SR OS's MD-CLI alias config points at it, and when the operator runs the alias, SR OS invokes the Python script to execute. It's the cleanest way to give network operators custom show commands without requiring them to know Python or pySROS exists.

File : interfaceproto.py

Configuration

# Step 1 - Configure the python-script 

[gl:/configure python python-script "interfaceproto"]
A:admin@PE1# info json
{
    "nokia-conf:admin-state": "enable",
    "nokia-conf:urls": ["cf3:\interfaceproto.py"],
    "nokia-conf:version": "python3"
}

# Step 2 - check the status of the Python Script 
/show python python-script "interfaceproto"
============================================================
Python script "interfaceproto"
============================================================
Description : (Not Specified)
Admin state : inService 
Oper state : inService
Oper state 
(distributed) : inService
Version : python3 
Action on fail: drop 
Protection : none
Primary URL : cf3:\interfaceproto.py
Secondary URL : (Not Specified) 
Tertiary URL : (Not Specified) 
Active URL : primary
Run as user : (Not Specified) 
Code size : 863 
Last changed : 03/23/2026 09:23:04

# Step 3 - Configure the command alias and mount it 

[gl:/configure system management-interface cli md-cli environment command-alias alias "intprotocol"]
info 
admin-state enable 
python-script "interfaceproto" 
mount-point "/show" { }

# Step 4 - Sanity check the alias configured 
A:admin@PE1# /show ?
Aliases: intprotocol - Command-alias

# Step 5 - Run the command protocols will be displayed for each interface 
A:admin@PE1# /show intprotocol
=============================================================
 Router Base Interfaces
=============================================================
 Interface          Oper State IPv4 State IPv4 Address 
 Protocols
-------------------------------------------------------------
 system             up          up        10.10.10.1
 isis mpls rsvp 
 tocisco_xrv9000    up          up        192.168.1.1 
 isis mpls rsvp ldp 
 toPE2              up          up        192.169.1.1 
 isis mpls rsvp ldp 
 loop               dormant     down      N/A
=============================================================

Practical use cases

1. Bulk interface auditing — Iterate over all interfaces across a fleet, collect IP/admin/oper-state into a structured report.

2. EHS event-driven remediation — Trigger a pySROS script via EHS when a BGP session drops. Log context, attempt recovery, or notify an external system.

3. Custom MD-CLI aliases — Wrap a pySROS script as an MD-CLI alias. Operators run a natural command without knowing Python is underneath.

4. Scheduled config compliance — Run a pySROS script via SR OS cron hourly to validate config against a golden template and log deviations.

5. Multi-vendor OpenConfig normalisation — Use OpenConfig YANG modules on SR OS alongside other vendors for a unified config and state model.

Conclusion

pySROS represents a significant change in approaching Nokia SR OS automation. Traditionally, there has been operational friction between tasks performed from a management server and those executed on the router, involving different tools, credentials, failure modes, and duplicated logic. pySROS eliminates this divide by treating the execution context as a runtime detail rather than an architectural limitation.

This is the automation accessibility gap. A skilled network engineer writes a powerful Python script to query BGP neighbors, generate config diffs, or push bulk ACL changes. The script works beautifully — in their terminal, on their machine, with their environment variables set correctly. But the moment that engineer is unavailable, the capability disappears. Colleagues cannot run it. Managers cannot trigger it. The NOC team, the helpdesk, and even other engineers are locked out

"The best automation script is useless if only one person can run it."

The solution is not to simplify the scripts — it is to wrap them in an interface that makes them universally accessible. Web frameworks like Streamlit provide this capability, bridging the gap between powerful automation logic and the teams that need to use it every day.

The Challenge of Terminal-Only Automation

Before exploring the solution, it's important to understand why terminal-based automation struggles to scale across teams.

Expertise Dependency

Running a Python script involves understanding how to use a terminal, navigate directories, manage virtual environments, install dependencies, and set the correct flags and arguments. While network engineers find this routine, it poses a significant barrier for NOC analysts, security auditors, or project managers needing a one-time report. When automation is confined to the terminal, it centralizes power among a few and creates bottlenecks.

Fragile Environments

Scripts that run perfectly in one engineer's environment often fail in another's due to different Python versions, missing libraries, conflicting dependencies, or mismatched environment variables. Reproducing the right execution environment is a technical skill unto itself, and it consumes time that teams do not have during incidents or operational windows.

Auditability Challenges

When multiple engineers share scripts over email or shared drives, there is no audit trail. Who ran the script? Against which devices? With what parameters? What was the output? This opacity creates compliance risks, troubleshooting challenges, and accountability gaps — especially in regulated environments

Lack of Validation

Raw scripts often accept command-line arguments with minimal validation. This can lead to errors, such as passing the wrong subnet, targeting the incorrect device group, or bypassing a confirmation prompt. Without a proper interface, there's no convenient way to implement input validation, confirmation dialogs, or permission controls.

Introducing Streamlit: Rapid UI for Network Automation

Streamlit is an open-source Python framework that allows developers to create web applications directly from Python scripts — no HTML, no JavaScript, no CSS required. For network engineers who already write Python, this is transformative. The same code that powers a script can be surfaced as a clean, interactive web app in a matter of hours

Why Streamlit is Ideal for Network Teams ?

Streamlit was designed with data scientists and engineers in mind, not professional web developers. Its philosophy is that the person who understands the logic should be able to build the interface. For network automation, this is a perfect fit:

•        Pure Python: No new languages to learn. If you can write a Netmiko or NAPALM script, you can build a Streamlit app.

•        Rapid development: A basic interface can be wrapped around an existing script in under an hour.

•        Built-in widgets: Text inputs, dropdowns, file uploaders, progress bars, and data tables are all available with single-line function calls.

•        Real-time output: Streamlit supports streaming output, making it ideal for long-running tasks like multi-device configuration pushes.

•        Easy deployment: Apps run on any server accessible by the team, including VMs, containers, or internal platforms.

How Streamlit Works (Behind the Scenes)

Streamlit follows a script rerun model.

Every time a user interacts with the UI:

• The Python script reruns from top to bottom

• UI state is preserved using session_state

Architecture flow:

User Interaction (Button / Input)
            ↓
Streamlit Reruns Script
            ↓
Updates UI Components
            ↓
Displays New Results

Core Streamlit Components Explained

Text Elements

st.title("Network Config Generator")
st.caption("Generate configs using Jinja2")

Used for headings and descriptions.

Input Widgets

device = st.text_input("Enter Router IP")

Common widgets:

• text_input

• selectbox

• checkbox

• sliders

• file uploader

Layout System (Professional Dashboards)

if st.button("Generate Configuration"):
    run_automation()

Buttons trigger Python logic directly.

Session State: The Most Important Concept

Because Streamlit reruns scripts, it uses:

st.session_state

This acts like memory for:

• Templates

• User inputs

• Generated outputs

Real-World Use Case for Network Engineers

Configuration Generator (Jinja2 + YAML)

In recent articles, we've discussed generating dynamic configurations with Jinja2 in a multi-vendor environment and the significance of configuration validation. Throughout the series, we developed several scripts for practical use. We will reuse our automation scripts and integrate them into an interactive, user-friendly interface. With Streamlit, you can quickly prototype a functional GUI without needing frontend skills.

Streamlit transforms a Python script into a self-service tool, empowering teams with independence while maintaining the engineer's control over the underlying logic.

Streamlit in a Network Configuration Generator

A typical architecture:

User Input (Template + YAML)
            ↓
Streamlit GUI
            ↓
Jinja2 Rendering Engine
            ↓
Generated Configuration Output
            ↓
Download or Deploy to Devices

Comparing Streamlit vs Traditional Web Frameworks

Prerequisites

pip install streamlit 

Run the application

streamlit run app.py 

Try the Correct URL

http://localhost:8501 # On the SAME machine
http://<server-ip>:8501 # If running on a server/VM

Generated Output

Network Configuration Generator UI application

Load Nokia SROS example and Validate :

Nokia SROS example Generate Configuration

Limitations of Streamlit

While Streamlit is excellent for internal tools and dashboards, it is not designed for large-scale enterprise web platforms requiring complex authentication, microservices, or highly customized frontends. However, for automation GUIs and engineering tools, it is one of the most efficient solutions available.

Conclusion: Automation is a Team Sport

Network automation has historically been the domain of individual engineers writing scripts for personal use. Streamlit change that equation entirely. It provide the bridge between powerful automation logic and the diverse teams that need to act on it — without requiring every user to become a Python developer or a terminal power user.

Network automation is only truly effective when it is accessible to everyone. A script limited to a single user is a capability restricted to that individual. In contrast, a web application that any team member can utilize becomes a resource for the entire organization.

Build the script. Then build the interface. Automation is only as powerful as its reach.

Generating configurations with Jinja is powerful. Deploying them safely is engineering.

We explored how to use Jinja2 templates to standardize configurations across vendors. But generating configuration is only half the job.

The real question is:

How do you make sure your generated configuration won’t break production?

Before you push any configuration to production, you need to know if it's correct. One typo can bring down a network. One misconfigured route can create a routing loop. One wrong ACL can block critical traffic.

The golden rule of network automation: Never deploy untested configurations.

Why Configuration Validation Matters ?

Network outages can be extremely costly for enterprises. Most unplanned outages result from human errors during configuration changes rather than hardware failures. Implementing a disciplined pre- and post-change validation workflow significantly reduces this risk by automating the comparison of network states before and after each change window.

In a multi-vendor environment, syntax and behavior differ:

Real Case 1: Interface Description Template Gone Wrong

Scenario

You generate this Jinja template:

interface {{ interface_name }}
 description {{ description }}
 ip address {{ ip_address }} {{ mask }}

It works for:

• Cisco IOS-XR

But your Junos device expects:

set interfaces ge-0/0/0 description "Uplink to Core"
set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24

Real Case 2: BGP Policy Mismatch Across Vendors

Scenario

You template BGP policies for 50 devices.

Your data model:

local_as: 65001
neighbor: 10.0.0.2
remote_as: 65002 

Problem

On IOS-XR:

router bgp 65001
 neighbor 10.0.0.2
  remote-as 65002

On Junos:

set protocols bgp group EBGP neighbor 10.0.0.2 peer-as 65002

But your automation mistakenly renders:

remote-as 65001

Result?

• Session never comes up

• No routing exchange

• Silent failure

Types of Validation

1. Template Validation

Before pushing configurations, validate:

• YAML variables

• Required fields

• Data structure integrity

Example Python Validation

import yaml
from jinja2 import Template, TemplateError

errors = []

def validate(data_text, template_text):
    try:
        yaml.safe_load(data_text)
    except yaml.YAMLError as e:
        errors.append(f"YAML error: {e}")

    try:
        Template(template_text)
    except TemplateError as e:
        errors.append(f"Template error: {e}")

    return errors

1. Syntax Validation

Each vendor supports some form of pre-check.

Nokia SROS Model Driven - Validate

validate

Junos – Commit Check

commit check 

Cisco IOS-XR – Commit Replace (Validate Before Apply)

commit replace

1. Logical Validation

Syntax may pass. But logic may be wrong.

Examples:

• Local AS equals Remote AS in eBGP

• IP address overlaps existing subnet

• Duplicate loopback

• MTU mismatch across link

Example Logical Check in Python

if data["local_as"] == data["remote_as"]:
    raise ValueError("Local AS and Remote AS cannot be equal in eBGP")

1. Pre- and Post-Change Checks

Before applying config:

• Is interface already configured?

• Does BGP session already exist?

• Is policy already attached?

• Is ISIS adjacency healthy?

This ensures:

One must avoid implementing new changes on an already broken network.

After applying config:

• Check BGP state = Established

• Check ISIS adjacency = Up

• Check route present in RIB

• Ping test

Safe Change Workflow in Multi-Vendor Networks

Here's the workflow:

          Inventory Data (YAML)
                    │
            Jinja Rendering
                    │
         Template + YAML Validation
                    │
          Vendor Syntax Check
                    │
          Logical Validation
                    │
          Pre-State Snapshot
                    │
              Deployment
                    │
          Post-State Verification
                    │
            Auto Rollback (if fail)

Config Builder Tool

About this Project

I began my network automation journey in 2018, seeking more efficient ways to perform my job. Initially, everything was manual—logging into devices individually, typing show commands, copying configurations, and hoping nothing would break during a 2 AM change window. Then, I discovered a course by David Bombal "Python Network Programming for Network Engineers", which transformed my approach, and I haven't looked back since.

The Config Builder Tool was one of my first complete project, allowing me to demonstrate to my colleagues the power of network automation. This project is designed to automate the generation of network configurations using Python and Jinja2. The tool has been tested with Nokia SROS routers running releases 22.10.R1 and 24.10.R5, operating in model-driven mode. It utilizes NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) to automate interactions with network devices via NETCONF.

NAPALM offers a configuration method called compare_config, which compares the candidate and running configurations on the SROS target. This is useful for pre-checking before deploying any configurations. This tool is interactive the user will be given a prompt to apply the configurations if required.

Prerequisites

Step 1

Enable MD-CLI on the Nokia SR OS network Device

A:R1# /configure system management-interface cli md-cli auto-config-save
A:R1# /configure system management-interface configuration-mode model-driven

Step 2

Enable NETCONF on the Nokia SR OS network Device

(gl)[configure system management-interface]
A:admin@R1#
    netconf {
        admin-state enable
        auto-config-save true
    }

Select YANG models to use on the Nokia SR OS network Device

(gl)[configure system management-interface]
A:admin@R1#
    yang-modules {
       nokia-modules false
       nokia-combined-modules true
    }

Select NETCONF user and permissions

(gl)[configure local-user system security user-params]
A:admin@R1#
 {
        user “admin" {
            password “admin"
            access {
                netconf true
            }
            console {
                member ["administrative"]
            }
        }
    }

Step 3

Before you begin, ensure you have the following installed:

1. Python 3.x

2. NAPALM library

3. PyYAML and Jinja2 libraries

Repository Structure

├── vars.yml
├── builder.py
└── servicevpls.xml.j2

Usage

1. File: vars.yml

vpls:
  - { name: demo_vpls1, id: 80, saps: [1/1/c3/2:15 , 1/1/c3/3:16] }
  - { name: demo_vpls2, id: 90, saps: [] }
  - { name: demo_vpls3, id: 100, saps: ["1/1/c3/4:17", "1/1/c4/2:18", "1/1/c4/2:19"] }
auto:
  start: 2000000000
  end: 2147483647

1. File: servicevpls.xmls.j2

<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
        <service>
            <customer>
                <customer-name>demo</customer-name>
                <description>NETCONF L2VPN demo Nokia SR OS</description>
                <contact>DEVOps Team</contact>
            </customer>
            <md-auto-id>
                <service-id-range>
                    <start>{{ auto.start }}</start>
                    <end>{{ auto.end }}</end>
                </service-id-range>
                <customer-id-range>
                    <start>{{ auto.start }}</start>
                    <end>{{ auto.end }}</end>
                </customer-id-range>
            </md-auto-id>
{% for svc in vpls %}
          <vpls>
            <service-name>{{ svc.name }}</service-name>
            <customer>demo</customer>
            <admin-state>enable</admin-state>
{% for sap in svc.saps %}
            <sap>
              <sap-id>{{ sap }}</sap-id>
              <admin-state>enable</admin-state>
            </sap>
{% endfor %}
          </vpls>
{% endfor %}
        </service>
</configure>

1. Main Script

import sys
import json
from jinja2 import Environment, FileSystemLoader
from napalm import get_network_driver

#Import YAML from PyYAML
import yaml

def configbuilder ():
    print('''

****************************************************
CONFIG BUILDER TOOL
****************************************************
    ''')

configbuilder()

if len(sys.argv) == 3:
    #Load data from YAML file into Python dictionary
    config = yaml.load(open(sys.argv[1]), Loader=yaml.FullLoader)

    #Load Jinja2 template
    env = Environment(loader = FileSystemLoader('./'), trim_blocks=True, lstrip_blocks=True)
    template = env.get_template(sys.argv[2])

    #Render template using data and print the output
    print('''

****************************************************
PRE-LOADED CONFIGS
****************************************************
    
    ''')
    print(template.render(config))
    
else:

    print("Usage: python3 builder.py <data_yml_file> <jinja_template_file>")
    print()
    print()
    sys.exit();
    
# Return template with data and store it into variable

response = template.render(config)

# Connect to the router and merge config

hostname = '172.20.20.13'
username = 'username'
password = 'password'

def connect ():
   """ This function is used to connect into the network device and prompt a user to commit or discard changes """
   driver = get_network_driver('sros')
   device = driver(hostname=hostname, username=username, password=password)
   device.open()
   device.load_merge_candidate(config=response)

   print()
   print()
   print('''

***************************************************************************
COMPARE AND LOAD CONFIGS
***************************************************************************
         ''')

   print("Results will be displayed when the is a DIFFERENCE between running and candidate configurations ")
   print()
   print("No Results will be displayed if running and candidate have the same configurations")
   print()
   print(device.compare_config())
   print()
   # for json format use the below option
   #print(device.compare_config('json_format':True))
     
   try:
       choice = input("\nWould you like to commit these changes? [y or N]: ")
   except NameError:
       choice = input("\nWould you like to commit these changes? [y or N]: ")
    
   if choice == "y":
       print()
       print(f"Committing the configurations on router {hostname} as {username}")
       print()
       device.commit_config()
   else:
       print()
       print(f"Discarding and not applying the configurations on router {hostname} as {username}")
       print()
       device.discard_config()
       
connect()

1. Expected Output

Rendered configuration template

****************************************************
PRE-LOADED CONFIGS
****************************************************


<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
        <service>
            <customer>
                <customer-name>demo</customer-name>
                <description>NETCONF L2VPN demo Nokia SR OS</description>
                <contact>DEVOps Team</contact>
            </customer>
            <md-auto-id>
                <service-id-range>
                    <start>2000000000</start>
                    <end>2147483647</end>
                </service-id-range>
                <customer-id-range>
                    <start>2000000000</start>
                    <end>2147483647</end>
                </customer-id-range>
            </md-auto-id>
          <vpls>
            <service-name>demo_vpls1</service-name>
            <customer>demo</customer>
            <admin-state>enable</admin-state>
            <sap>
              <sap-id>1/1/c1/2:15</sap-id>
              <admin-state>enable</admin-state>
            </sap>
            <sap>
              <sap-id>1/1/c1/3:16</sap-id>
              <admin-state>enable</admin-state>
            </sap>
          </vpls>
          <vpls>
            <service-name>demo_vpls2</service-name>
            <customer>demo</customer>
            <admin-state>enable</admin-state>
          </vpls>
          <vpls>
            <service-name>demo_vpls3</service-name>
            <customer>demo</customer>
            <admin-state>enable</admin-state>
            <sap>
              <sap-id>1/1/c1/4:17</sap-id>
              <admin-state>enable</admin-state>
            </sap>
            <sap>
              <sap-id>1/1/c2/2:18</sap-id>
              <admin-state>enable</admin-state>
            </sap>
            <sap>
              <sap-id>1/1/c2/3:19</sap-id>
              <admin-state>enable</admin-state>
            </sap>
          </vpls>
        </service>
</configure>

Comparison candidate vs running configuration

***************************************************************************
COMPARE AND LOAD CONFIGS

***************************************************************************

Results will be displayed when the is a DIFFERENCE between running and candidate configurations

No Results will be displayed if running and candidate have the same configurations

[
    "add",
    "configure.service",
    [
        [
            "customer",
            {
                "contact": "DEVOps Team",
                "customer-name": "demo",
                "description": "NETCONF L2VPN demo Nokia SR OS"
            }
        ],
        [
            "md-auto-id",
            {
                "customer-id-range": {
                    "end": "2147483647",
                    "start": "2000000000"
                },
                "service-id-range": {
                    "end": "2147483647",
                    "start": "2000000000"
                }
            }
        ],
        [
            "vpls",
            [
                {
                    "admin-state": "enable",
                    "customer": "demo",
                    "sap": [
                        {
                            "admin-state": "enable",
                            "sap-id": "1/1/c1/2:15"
                        },
                        {
                            "admin-state": "enable",
                            "sap-id": "1/1/c1/3:16"
                        }
                    ],
                    "service-name": "demo_vpls1"
                },
                {
                    "admin-state": "enable",
                    "customer": "demo",
                    "service-name": "demo_vpls2"
                },
                {
                    "admin-state": "enable",
                    "customer": "demo",
                    "sap": [
                        {
                            "admin-state": "enable",
                            "sap-id": "1/1/c1/4:17"
                        },
                        {
                            "admin-state": "enable",
                            "sap-id": "1/1/c2/2:18"
                        },
                        {
                            "admin-state": "enable",
                            "sap-id": "1/1/c2/3:19"
                        }
                    ],
                    "service-name": "demo_vpls3"
                }
            ]
        ]
    ]
]

Device commit prompt

Would you like to commit these changes? [y or N]:

Would you like to commit these changes? [y or N]: N

Discarding and not applying the configurations on router 172.20.20.13 as admin

Key Takeaways

• Never deploy untested configurations

• Use multiple validation layers

• Always take pre-deployment backups

• Capture pre/post state

• Have rollback procedures ready

• Use vendor-native commit checks

Download the Code

All templates and script: configbuildertool

Final Thoughts

If Jinja gives you power…

Validation gives you safety.

Use Case 1: Nokia SR OS Service Configuration

Scenario

You are deploying 50 new customer L3VPN services on Nokia SR OS routers. Each customer requires:

• Unique customer ID

• Service description

• IP interfaces

• BGP Peering

Prerequisites

pip install jinja2
pip install pyyaml 
pip install netmiko #For deployment (optional)

# Install required libraries t 
# It is always essential create a python environment

Jinja2 Template

File: nokia_customer_service.j2

{# Nokia SR OS Customer Service Template #}
{# =================================== #}
{# Customer: {{ customer.name }} #}
{# Date: {{ timestamp }} #}
{# =================================== #}

/configure
#--------------------------------------------------
echo "Creating Customer {{ customer.id }}: {{ customer.name }}"
#--------------------------------------------------

    service
        customer {{ customer.id }} create
            description "{{ customer.name }}"
        exit
        
        {% for vprn in customer.vprns %}
        vprn {{ vprn.service_id }} customer {{ customer.id }} create
            service-name "{{ vprn.name }}"
            description "{{ vprn.description }}"
            autonomous-system {{ vprn.as_number }}
            route-distinguisher {{ vprn.rd }}
            
            {# Configure VPRN Interfaces #}
            {% for interface in vprn.interfaces %}
            interface "{{ interface.name }}" create
                address {{ interface.ip }}/{{ interface.prefix }}
                sap {{ interface.sap }} create
                    description "{{ interface.description }}"
                exit
            exit
            {% endfor %}
            
            {# Configure BGP if present #}
            {% if vprn.bgp %}
            bgp
                group "{{ vprn.bgp.group_name }}"
                    type {{ vprn.bgp.type }}
                    peer-as {{ vprn.bgp.peer_as }}
                    
                    {% for neighbor in vprn.bgp.neighbors %}
                    neighbor {{ neighbor.ip }}
                        description "{{ neighbor.description }}"
                    exit
                    {% endfor %}
                exit
            exit
            {% endif %}
            
            no shutdown
        exit
        {% endfor %}
    exit
exit

Data YAML file

File: customers_data.yaml

---
customers:
  - id: 100
    name: CodedNetwork Corp
    vprns:
      - service_id: 1000
        name: CodedN-CORP-VPRN
        description: Enterprise Corp Main VPRN
        as_number: 65000
        rd: 65000:100
        interfaces:
          - name: to-customer-site-1
            ip: 10.100.1.1
            prefix: 30
            sap: 1/1/c1/1:100
            description: Customer Site 1 Connection
          - name: to-customer-site-2
            ip: 10.100.2.1
            prefix: 30
            sap: 1/1/c2/1:101
            description: Customer Site 2 Connection
        bgp:
          group_name: customer-bgp
          type: external
          peer_as: 65100
          neighbors:
            - ip: 10.100.1.2
              description: Site 1 CE Router
            - ip: 10.100.2.2
              description: Site 2 CE Router
  - id: 101
    name: Tech Startup Inc
    vprns:
      - service_id: 1001
        name: TECH-STARTUP-VPRN
        description: Tech Startup Main VPRN
        as_number: 65001
        rd: 65000:101
        interfaces:
          - name: to-startup-hq
            ip: 10.101.1.1
            prefix: 30
            sap: 1/1/c3/1:200
            description: Startup HQ Connection
        bgp:
          group_name: startup-bgp
          type: external
          peer_as: 65200
          neighbors:
            - ip: 10.101.1.2
              description: HQ CE Router

Nokia SR OS Configuration Generator - Code Overview

#!/usr/bin/env python3
"""
Nokia SR OS Configuration Generator using Jinja2
Generates customer service configurations from YAML data
"""

from jinja2 import Environment, FileSystemLoader
import yaml
from datetime import datetime
import os

def load_data(yaml_file):
    """Load customer data from YAML file"""
    with open(yaml_file, 'r') as f:
        return yaml.safe_load(f)

def generate_config(template_file, data, output_dir='configs_generated'):
    """
    Generate configurations from template and data
    
    Args:
        template_file: Jinja2 template file path
        data: Dictionary with customer data
        output_dir: Directory to save generated configs
    """
    
    # Create output directory
    if not os.path.exists(output_dir):
        os.makedirs(output_dir)
    
    # Set up Jinja2 environment
    env = Environment(
        loader=FileSystemLoader('.'),
        trim_blocks=True,
        lstrip_blocks=True
    )
    
    # Load template
    template = env.get_template(template_file)
    
    # Generate config for each customer
    for customer in data['customers']:
        # Add timestamp to data
        customer['timestamp'] = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
        
        # Render template with customer data
        config = template.render(customer=customer)
        
        # Create filename
        filename = f"{output_dir}/nokia_customer_{customer['id']}_{customer['name'].replace(' ', '_')}.cfg"
        
        # Save to file
        with open(filename, 'w') as f:
            f.write(config)
        
        print(f"✓ Generated: {filename}")
        print(f"  Customer: {customer['name']} (ID: {customer['id']})")
        print(f"  VPRNs: {len(customer['vprns'])}")
        print()

def main():
    """Main execution"""
    print("="*70)
    print("Nokia SR OS Configuration Generator")
    print("="*70)
    print()
    
    # Load data
    print("Loading customer data...")
    data = load_data('customers_data.yaml')
    print(f"✓ Loaded {len(data['customers'])} customers")
    print()
    
    # Generate configurations
    print("Generating configurations...")
    print()
    generate_config('nokia_customer_service.j2', data)
    
    print("="*70)
    print("Generation complete!")
    print("="*70)

if __name__ == "__main__":
    main()

Detailed Step-by-Step Explanation

1. Imports and Setup

from jinja2 import Environment, FileSystemLoader
import yaml
from datetime import datetime
import os

Purpose of each Import

• Jinja2 : Template engine for generating text files

• YAML : Reads structured customer data

• datetime : Adds Timestamps to configs

• os : Creates directories for output files

1. load_data() Function

def load_data(yaml_file):
    with open(yaml_file, 'r') as f:
        return yaml.safe_load(f)

# The function reads a YAML file and returns its contents as a Python dictionary

1. generate_config() Function

if not os.path.exists(output_dir):
    os.makedirs(output_dir)

# Creates a folder called `generated_configs` if it doesn't exist

env = Environment(
    loader=FileSystemLoader('.'),
    trim_blocks=True,
    lstrip_blocks=True
)

# Sets up template engine to look for templates in current directory
#`trim_blocks` and `lstrip_blocks` remove extra whitespace for cleaner output

template = env.get_template(template_file 

# Loads the Jinja2 template file (contains Nokia router config structure with placeholders)

for customer in data['customers']:
    customer['timestamp'] = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
    config = template.render(customer=customer)

# Loops through each customer in the YAML data
# Adds current timestamp to customer data
# Renders the template by replacing placeholders with actual customer values

filename = f"{output_dir}/nokia_customer_{customer['id']}_{customer['name'].replace(' ', '_')}.cfg"
with open(filename, 'w') as f:
    f.write(config)

# Writes the rendered configuration to file

1. main () Function

def main():
    data = load_data('customers_data.yaml')
    generate_config('nokia_customer_service.j2', data)

# Loads customer data from YAML file
# Generates all configuration files

To run the script

python3 nokia_config_generator.py 

Output:

python3 nokia_config_generator.py 

======================================================================
Nokia SR OS Configuration Generator
======================================================================

Loading customer data...
✓ Loaded 2 customers

Generating configurations...

✓ Generated: configs_generated/nokia_customer_100_CodedNetwork_Corp.cfg
  Customer: CodedNetwork Corp (ID: 100)
  VPRNs: 1

✓ Generated: configs_generated/nokia_customer_101_Tech_Startup_Inc.cfg
  Customer: Tech Startup Inc (ID: 101)
  VPRNs: 1

======================================================================
Generation complete!
======================================================================

#generated configuration under configs_generated folder 

ls -l
nokia_customer_100_CodedNetwork_Corp.cfg
nokia_customer_101_Tech_Startup_Inc.cfg

Generated Configuration Example

File: nokia_customer_100_CodedNetwork_Corp.cfg

cat nokia_customer_100_CodedNetwork_Corp.cfg 

/configure
#--------------------------------------------------
echo "Creating Customer 100: CodedNetwork Corp"
#--------------------------------------------------

    service
        customer 100 create
            description "CodedNetwork Corp"
        exit
        
        vprn 1000 customer 100 create
            service-name "CodedN-CORP-VPRN"
            description "Enterprise Corp Main VPRN"
            autonomous-system 65000
            route-distinguisher 65000:100
            
            interface "to-customer-site-1" create
                address 10.100.1.1/30
                sap 1/1/c1/1:100 create
                    description "Customer Site 1 Connection"
                exit
            exit
            interface "to-customer-site-2" create
                address 10.100.2.1/30
                sap 1/1/c2/1:101 create
                    description "Customer Site 2 Connection"
                exit
            exit
            
            bgp
                group "customer-bgp"
                    type external
                    peer-as 65100
                    
                    neighbor 10.100.1.2
                        description "Site 1 CE Router"
                    exit
                    neighbor 10.100.2.2
                        description "Site 2 CE Router"
                    exit
                exit
            exit
            
            no shutdown
        exit
    exit
	

Use Case 2: Nokia SR OS Interface Configuration

Scenario

Configure 48 access ports on a Nokia 7750 SR with:

• Different VLAN assignments

• Port descriptions based on location

• Speed and duplex settings

Jinja2 Template

File: nokia_interface_config.j2

{# Nokia SR OS Interface Configuration Template #}
/configure
{% for interface in interfaces %}
    port {{ interface.port }} create
        description "{{ interface.description }}"
        ethernet
            mode {{ interface.mode }}
            {% if interface.speed %}
            speed {{ interface.speed }}
            {% endif %}
            {% if interface.duplex %}
            duplex {{ interface.duplex }}
            {% endif %}
            encap-type {{ interface.encap_type|default('dot1q') }}
        exit
        no shutdown
    exit
{% endfor %}
exit

Data YAML file

File: interfaces_data.yaml

interfaces:
  - port: "1/1/c1/1"
    description: "Building A - Floor 1 - Room 101"
    mode: "access"
    speed: "1000"
    duplex: "full"
    vlan: 100
    
  - port: "1/1/c2/1"
    description: "Building A - Floor 1 - Room 102"
    mode: "access"
    speed: "1000"
    duplex: "full"
    vlan: 100
    
  - port: "1/1/c3/1"
    description: "Building A - Floor 2 - Conference Room"
    mode: "access"
    speed: "1000"
    duplex: "full"
    vlan: 200
    
  - port: "1/1/c4/1"
    description: "Uplink to Core Switch"
    mode: "network"
    speed: "10000"
    encap_type: "qinq"

Output:

python3 nokia_config_interface_gen.py 

======================================================================
Nokia SR OS Configuration Generator
======================================================================

Loading interface data...
✓ Loaded 4 interfaces

Generating configurations...

✓ Generated: configs_generated/nokia_interface_Building_A_-_Floor_1_-_Room_101.cfg

✓ Generated: configs_generated/nokia_interface_Building_A_-_Floor_1_-_Room_102.cfg

✓ Generated: configs_generated/nokia_interface_Building_A_-_Floor_2_-_Conference_Room.cfg

✓ Generated: configs_generated/nokia_interface_Uplink_to_Core_Switch.cfg

======================================================================
Generation complete!
======================================================================

Use Case 3: Multi-vendor BGP Configuration

Scenario

Generate BGP configuration for Nokia SR OS, Cisco IOS XR, and Juniper routers.

Nokia SROS Template

File: nokia_bgp.j2

/configure
    router bgp
        autonomous-system {{ bgp.local_as }}
        {% for neighbor in bgp.neighbors %}
        neighbor {{ neighbor.ip }}
            peer-as {{ neighbor.remote_as }}
            description "{{ neighbor.description }}"
            family ipv4
            {% if neighbor.password %}
            authentication-key "{{ neighbor.password }}"
            {% endif %}
        exit
        {% endfor %}
    exit
exit

Cisco IOS XR Template

File: cisco_bgp.j2

router bgp {{ bgp.local_as }}
{% for neighbor in bgp.neighbors %}
 neighbor {{ neighbor.ip }}
  remote-as {{ neighbor.remote_as }}
  description {{ neighbor.description }}
  address-family ipv4 unicast
  !
  {% if neighbor.password %}
  password encrypted {{ neighbor.password }}
  {% endif %}
 !
{% endfor %}
!

Juniper Template

File: juniper_bgp.j2

protocols {
    bgp {
        group external {
            type external;
            local-as {{ bgp.local_as }};
            {% for neighbor in bgp.neighbors %}
            neighbor {{ neighbor.ip }} {
                description "{{ neighbor.description }}";
                peer-as {{ neighbor.remote_as }};
                {% if neighbor.password %}
                authentication-key "{{ neighbor.password }}";
                {% endif %}
            }
            {% endfor %}
        }
    }
}

Unified YAML data file

File: bgp_data.yaml

bgp:
  local_as: 65000
  neighbors:
    - ip: "10.1.1.1"
      remote_as: 65001
      description: "Peer to ISP1"
      password: "secret123"
    
    - ip: "10.1.1.5"
      remote_as: 65002
      description: "Peer to ISP2"
      password: "secret123"

Multivendor Python Script

File: generate_multivendor.py

from jinja2 import Environment, FileSystemLoader
import yaml
import os

VENDORS = {
    'nokia': 'nokia_bgp.j2',
    'cisco': 'cisco_bgp.j2',
    'juniper': 'juniper_bgp.j2'
}

def generate_multivendor_config(data_file, output_dir='multivendor_configs'):
    """Generate configs for all vendors from same data"""
    
    # Load data
    with open(data_file, 'r') as f:
        data = yaml.safe_load(f)
    
    # Create output directory
    if not os.path.exists(output_dir):
        os.makedirs(output_dir)
    
    # Set up Jinja2
    env = Environment(loader=FileSystemLoader('.'))
    
    # Generate for each vendor
    for vendor, template_file in VENDORS.items():
        template = env.get_template(template_file)
        config = template.render(**data)
        
        filename = f"{output_dir}/{vendor}_bgp_config.cfg"
        with open(filename, 'w') as f:
            f.write(config)
        
        print(f"✓ Generated {vendor.upper()} configuration: {filename}")

if __name__ == "__main__":
    generate_multivendor_config('bgp_data.yaml')

Output:

python3 generate_multivendor.py 

✓ Generated NOKIA configuration: multivendor_configs/nokia_bgp_config.cfg
✓ Generated CISCO configuration: multivendor_configs/cisco_bgp_config.cfg
✓ Generated JUNIPER configuration:   multivendor_configs/juniper_bgp_config.cfg

Putting It All Together: Complete Workflow

Step 1: Create Templates

Create template files for each configuration type

Step 2: Prepare Data

Create YAML files with customer/site/service data

Step 3: Generate Configurations

python3 generate_multivendor.py

Step 4: Review Generated Configs

Key Takeaways

• Separation of Responsibilities - Templates (structure) vs Data (content)

• Reusability - One template, many configurations

• Consistency - Same structure every time

• Speed - Generate hundreds of configs in seconds

• Maintainability - Update template once, regenerate all configs

Download the Code

All templates and scripts: network-automation-week-3

This week, we are making significant progress by generating configurations dynamically. Rather than manually creating configuration files for each device, we will utilize Jinja2 templates to produce hundreds of configurations from a single data file.

In a real-world scenario, consider the task of configuring 100 new customer sites across Nokia SR OS, Cisco IOS XR, and Juniper routers. Each site requires unique VLANs, IP addresses, and routing configurations. Manually completing this task would take several days. However, using templates, it can be accomplished in just minutes.

Why Choose Jinja2 for Network Automation?

Jinja2 is a versatile and efficient templating engine commonly employed in automation frameworks like Ansible, as well as in custom Python automation scripts. It allows engineers to develop dynamic templates incorporating variables, loops, and conditional logic. This capability makes it particularly well-suited for generating configurations in multi-vendor environments.

Think of it like this:

• A mail merge in Microsoft Word

• A form letter where you fill in the blanks

• A recipe where you substitute ingredients

The Traditional Method (Manual Configuration)

# Customer 1 - Nokia SROS router 
/configure service customer 100 create
description "Customer CodedNetwork Corp"
exit

# Customer 2 - Nokia SROS router 
/configure service customer 200 create
description "Lazyprogrammer INC"
exit

#...... Repeat for a 100 customers 😫

The Modern Approach (Jinja2 Template)

Jinja2 Template:

# Template only once !!! 🙂
/configure service customer {{ customer_id }} create
    description "{{ customer_name }}"
exit

Data (YAML file):

customers:
  - customer_id: 100
    customer_name: "Customer CodedNetwork Corp"
  - customer_id: 200
    customer_name: "Lazyprogrammer INC"

Result: Generate 100 configurations in seconds.

Understanding YAML

YAML (YAML Ain't Markup Language) is a human-readable data serialization format frequently utilized for configuration files and data exchange between languages with varying data structures. It is crafted to be straightforward to read and write, which makes it a favored option for configuration files in numerous applications, including network automation.

Key features of YAML include:

1. Simplicity: YAML is crafted to be straightforward to read and write, with a syntax that is more user-friendly compared to other data serialization formats like JSON or XML.

2. Data Types: YAML supports a variety of data types, including scalars (strings, numbers, Booleans), lists, and dictionaries (also known as maps or hashes).

3. Indentation: YAML uses indentation to denote the structure of data. The level of indentation indicates the hierarchy of data, similar to how Python uses indentation for code blocks.

4. Comments: YAML permits comments, which can be added using the # symbol. This feature is beneficial for including explanations or notes within the configuration files.

5. Compatibility: YAML is compatible with JSON, meaning that any valid JSON file is also a valid YAML file.

In the context of Jinja2 templates, YAML is frequently employed to store structured data that can be integrated into the templates to produce dynamic configurations. This approach facilitates a clear distinction between the data and the template logic, thereby simplifying the management and updating of configurations.

# Key-Value Pairs (Basic Structure)
hostname: core-r1
vendor: nokia
os: sros

# Lists( Arrays) 
interfaces:
  - name: ethernet-1/1
    ip: 10.0.0.1/24
  - name: ethernet-1/2
    ip: 10.0.1.1/24

# Nested Structures
device:
  hostname: core-r1
  vendor: nokia
  routing:
    bgp:
      asn: 65001
      router_id: 1.1.1.1

# Indentation (Critical Rule in YAML)
router:
  bgp:
    asn: 65001

# Strings, Integers, and Booleans
hostname: core-r1        # string
asn: 65001               # integer
enabled: true            # boolean

# Comments in YAML starts with "#"

hostname: core-r1
vendor: nokia  # SR OS platform

Importance of YAML Validation

A YAML validator is a tool or process that ensures a YAML file is syntactically correct, well-structured, and compliant before being utilized in automation pipelines. In network automation, where YAML is used for configuration generation, inventory, and deployments, validation serves as a critical safety layer.

Prevents Automation Failures Prior to Deployment

Automation tools such as Python scripts, Jinja2 templates, and Ansible heavily depend on YAML files. If the YAML is invalid, it can cause the entire pipeline to fail.

Prevents Incorrect Configuration Generation (High Risk)

When utilizing Jinja2 templates, YAML serves as the authoritative source. If the structure is incorrect, the templates may produce incomplete or erroneous configurations.

Safeguards Production Networks Against Human Errors

Most YAML errors result from human mistakes, including:

• Incorrect indentation

• Duplicate keys

• Missing quotes

• Typographical errors

In service provider environments, including core routers, software upgrades, and automation health checks, even a minor YAML error can lead to disruptions in:

• Routing policies

• Interface provisioning

• Telemetry pipelines

A validator functions as a pre-change safety control before deployment

Ensures Data Consistency Across Multi-Vendor Environments

In multi-vendor automation environments (such as Nokia SR OS, Cisco IOS XR, and Junos), YAML is used to model device data. Validators ensure:

• Ensures correct schema structure

• Verifies the presence of required fields (ASN, interfaces, hostname)

• Confirms no missing attributes for specific vendors

This is particularly crucial when creating vendor-specific configurations from a unified template.

Supports CI/CD and Git-Based Automation Pipelines

Modern network teams maintain YAML files in Git repositories to facilitate:

• Version control

• Change tracking

• Automated deployments

Validation in CI/CD Pipelines:

Git Commit → YAML Validation → Jinja2 Render → Lab Test → Production Deploy

If validation fails:

• Deployment is automatically halted

• Prevents incorrect configurations from being applied to devices

Detects Indentation and Syntax Errors (A Common Issue)

YAML is sensitive to indentation, requiring spaces only and not tabs.

A validator promptly identifies:

• Incorrect indentation

• Invalid nesting

• Structural inconsistencies

Enhances Automation Reliability and Scalability

For large-scale automation involving hundreds of routers:

• Valid YAML ensures predictable automation behavior.

• Invalid YAML leads to unpredictable failures.

Benefits include:

• Stable template rendering

• Faster troubleshooting

• Cleaner automation logs

• Reduced rollback scenarios

Essential for Jinja2 Template Rendering (Direct Impact)

Jinja2 consumes YAML as input variables:

data = yaml.safe_load(open("devices.yaml"))
template.render(data)

Security and Compliance Advantages

Validated YAML helps prevent:

• Misconfigured access policies

• Incorrect ACL deployments

• Faulty automation scripts that push unsafe configurations

My preferred YAML Validator is YAML Lint:

Best Practice Workflow for Your Automation Stack

        YAML Inventory File
                |
                v
        YAML Validator (yamllint)
                |
        +-------+--------+
        |                |
      Valid            Invalid
        |                |
        v                v
   Jinja2 Templates   Fix Errors
        |
        v
 Config Generation → Device Deployment → Health Checks

Jinja2 Basics

1. Variables

Variables in Jinja2 are represented by double curly braces {{ }}. These act as placeholders, which are substituted with actual data during the template rendering process.

hostname {{ hostname }}
interface {{ interface_name }}
 ip address {{ ip_address }}

2. Loops

Loops enable you to iterate over lists such as interfaces, VLANs, BGP neighbors, or services. This functionality is particularly beneficial when configuring multiple interfaces or services on a routers

{% for intf in interfaces %}
interface {{ intf.name }}
 description {{ intf.description }}
 ip address {{ intf.ip }}
{% endfor %}

3. Conditionals

Conditionals incorporate logic into templates, enabling configurations to adapt dynamically based on factors such as vendor, device role, or feature flags. This is essential in multi-vendor environments where syntax varies across platforms..

{% if vendor == "cisco" %}
router bgp {{ asn }}
{% elif vendor == "nokia" %}
configure router bgp {{ asn }}
{% elif vendor == "juniper" %}
set protocols bgp group external type external
{% endif %}

4. Filters

Filters in Jinja2 are used to transform or format data before rendering it into the final configuration. They help clean, modify, or standardize values automatically.

Common Networking Use Cases:

• Uppercase interface names

• Formatting IP addresses

• Default values for missing fields

hostname {{ hostname | upper }}
interface {{ interface | default("GigabitEthernet0/0") }}

Advanced Jinja2 Features

1. Macros (Reusable Blocks)

{# Define a macro #}
{% macro interface_config(port, vlan, description) %}
interface {{ port }}
    description "{{ description }}"
    vlan {{ vlan }}
    no shutdown
{% endmacro %}

{# Use the macro #}
{% for intf in interfaces %}
{{ interface_config(intf.port, intf.vlan, intf.desc) }}
{% endfor %}

2. Include Other Templates

{# base_template.j2 #}
/configure
    {% include 'system_config.j2' %}
    {% include 'interface_config.j2' %}
    {% include 'routing_config.j2' %}
exit

3. Custom Filters

def ip_increment(ip, increment=1):
    """Increment IP address"""
    parts = ip.split('.')
    parts[3] = str(int(parts[3]) + increment)
    return '.'.join(parts)

# Add to Jinja2 environment
env.filters['ip_increment'] = ip_increment

4. Usage in template

neighbor {{ base_ip|ip_increment(1) }}
neighbor {{ base_ip|ip_increment(2) }}

5. Conditional Includes

{% if device_type == 'nokia' %}
    {% include 'nokia_specific.j2' %}
{% elif device_type == 'cisco' %}
    {% include 'cisco_specific.j2' %}
{% endif %}

Detailed Internal Jinja2 Logic Flow

How Templates Process Data

        Device Inventory (devices.yaml)
                   |
                   v
        +----------------------+
        | Load Data in Python  |
        | (dict / variables)   |
        +----------+-----------+
                   |
                   v
        +----------------------+
        | Pass Data to Jinja2  |
        |  template.render()   |
        +----------+-----------+
                   |
        +----------+-----------+
        |                      |
        v                      v
+-------------------+   +-------------------+
|   Variables       |   |   Conditionals    |
| {{ hostname }}    |   | if vendor == SR OS|
| {{ interfaces }}  |   | vendor logic      |
+-------------------+   +-------------------+
        |                      |
        +----------+-----------+
                   |
                   v
        +----------------------+
        |        Loops         |
        | for interface in list|
        +----------+-----------+
                   |
                   v
        +----------------------+
        |       Filters        |
        | upper, default, join |
        +----------+-----------+
                   |
                   v
        +----------------------+
        | Final Config Output  |
        | Ready for Deployment |
        +----------------------+

Jinja2 + YAML Workflow (Advanced Automation Process)

   devices.yaml (YAML Inventory)
                    |
                    v
            Python Script (Loader)
                    |
                    v
            Jinja2 Template Engine
                    |
                    v
        Rendered Router Configuration
                    |
                    v
        Deployment (SSH / NETCONF / API)

What’s Next?

In Part 1, we examined the principles of YAML and Jinja2 and their application in dynamic configuration generation. This enables network engineers to transition from static, manual CLI configurations to automated, data-driven deployments. This methodology ensures consistency, minimizes human error, and expedites deployment in production networks.

In Part 2 , we are going to show practical examples of dynamic configuration generation. We will go through a few use cases :

Use Case 1 : Nokia SROS service Configuration

Use Case 2 : Nokia SROS Interface Configuration

Use Case 3: Multivendor BGP Configuration ( Nokia SROS, Juniper, Cisco)

Questions ?

Reach out on LinkedIn!

By the conclusion of this post, you will be equipped to utilize network APIs to automatically gather:

• Device hostnames and software versions

• Interface status

• Device Uptime and Model

No configuration changes, no risk - just reading information the modern way.

Why Use APIs for Information Gathering?

The traditional method (SSH/CLI):

ssh admin@router1
show version | include Version
show interfaces terse
show system uptime
# Now manually copy-paste to Excel 
# Repeat for 50+ devices

The API Approach:

# Collect from 50+ devices in seconds
for device in devices:
  info =get_device_info(device)
# Automatically formatted in structured data

Why is this a superior approach?

1. Speed: Gather data from multiple devices simultaneously

2. Structured Data: Utilize XML/JSON instead of parsing text

3. Consistency: Ensure the same data format every time

4. No Manual Copying: Directly export to Excel, database, or dashboard

5. Automation Ready: Simple to schedule and monitor

6. Error Reduction: Eliminate copy-paste mistakes

Understanding Network APIs

What is an API?

An API (Application Programming Interface) serves as a means for programs to communicate with network devices. It is comparable to a menu at a restaurant:

• The menu displays available options (API documentation)

• You place an order (API call)

• You receive the requested item (API response)

Two Primary Types for Network Devices:

NETCONF

• Uses SSH connection (port 830)

• Structured data (XML)

• Supports transactions and validation

• More powerful, model-driven

NETCONF Session Flow

Client                                  Network Device (Server)
|                                               |
| SSH Connection (port 830) |
| ==========================================>   |
|                                               |
| <hello> (device capabilities) |
| <-------------------------------------------  |
| <hello> (client capabilities) |
| ------------------------------------------->  |
|                                               |
| <rpc message-id="101">                        |
| <lock>                                        |
| <target>                                      |
| <candidate/>                                  |
| </target>                                     |
| </lock>                                       |
| </rpc>                                        |
| ------------------------------------------->  |
|                                               |
| <rpc-reply message-id="101">                  |
| <ok/>                                         |
| </rpc-reply>                                  |
| <-------------------------------------------  |
|                                               |

REST (Representational State Transfer) API

• Uses HTTP/HTTPS

• Usually JSON format

• Simple request/response

• Easy to understand

How REST Works

Client                            Server (Network Device)
|                                          |
| GET /api/v1/interfaces/eth0              |
| ---------------------------------------->|
|                                          |
| HTTP/1.1 200 OK                          |
| Content-Type: application/json           |
| {                                        |
| "name": "eth0",                          |
| "status": "up",                          |
| "speed": "1000Mbps"                      |
| }                                        |
| <----------------------------------------|
|                                          |

REST Operations

HTTP Method   Purpose          Example
-----------   -------          -------
GET           Read resource    GET /api/interfaces
POST          Create resource  POST /api/interfaces
PUT           Update resource  PUT /api/interfaces/eth0
DELETE        Remove resource  DELETE /api/interfaces/eth1
PATCH         Partial update   PATCH /api/interfaces/eth0

When to Use Each Method

Select REST when:

• Utilize REST for straightforward and rapid integrations with network devices.

• It is ideal for modern cloud-native applications.

• Select REST if the vendor offers a well-documented REST API.

• Opt for REST when seeking extensive support for various languages and tools.

Select NETCONF when:

• You need transactional integrity for configuration changes

• Working with critical infrastructure requiring validation

• Managing complex, multi-step configurations

• Rollback capabilities are essential Working with devices that support YANG data models

• Enterprise network automation at scale

Prerequisites

Software Requirements

# Install required Python libraries
pip install ncclient  # For NETCONF
pip install xmltodict # For parsing XML
pip install tabulate  # For pretty tables
pip install requests  # For REST APIs (if needed)

Lab Setup

For this tutorial, you will need access to:

• A Juniper vMX router with NETCONF enabled

Don't have a device? Use containerlab

Enable NETCONF on your device:

Juniper vMX

set system services netconf ssh
set system services netconf rfc-compliant
commit

Verify NETCONF Configuration and Status

admin@juniper> show configuration system services netconf    
ssh;
rfc-compliant;

admin@juniper> show system connections | match 830           
tcp6       0      0  *.830        *.*                                           LISTEN
tcp4       0      0  *.830        *.*                                           LISTEN

Juniper vMX - System Information Accessed via NETCONF

In this example, we are gathering basic information from a Juniper vMX router.

Understanding the Code Structure

from ncclient import manager
import xmltodict
from tabulate import tabulate
import getpass
import csv
from datetime import datetime
import os

Explanation of Each Import

• from ncclient import manager: This import allows us to manage NETCONF sessions with network devices.

• import xmltodict: This library is used to convert XML data into a Python dictionary, making it easier to work with.

• from tabulate import tabulate: This module helps in creating well-formatted tables for displaying data.

• import getpass: This module is used to securely prompt for a password without displaying it on the screen.

• import csv: This library provides functionality to read from and write to CSV files.

• from datetime import datetime: This import allows us to work with dates and times in our code.

• import os: This module provides a way to interact with the operating system, such as handling file paths.

Device Connection Details

# Device details
VMX_HOST = "172.20.20.16"
VMX_PORT = 830
VMX_USER = "admin"
VMX_PASS = getpass.getpass(f"Password for {VMX_USER}@{VMX_HOST}: ")

Why use port 830?

• Port 830 is the standard port for NETCONF over SSH.

• Port 22 is used for regular SSH connections.

• Port 830 provides us with NETCONF capabilities.

Why use getpass?

# Bad - password visible in code and on screen
VMX_PASS = "coded123"
# Good - password not shown when typing
VMX_PASS = getpass.getpass("Password: ")

The Connection Function

def connect_vmx():
    """Connect to Juniper vMX via NETCONF"""
    return manager.connect(
        host=VMX_HOST,
        port=VMX_PORT,
        username=VMX_USER,
        password=VMX_PASS,
        device_params={'name': 'junos'},
        hostkey_verify=False,
        look_for_keys=False,
        allow_agent=False
    )

Breaking Down the Parameters:

• host=VMX_HOST = The IP address for connection

• port=VMX_PORT = Port 830 (used for NETCONF)

• username=VMX_USER = The login username

• password=VMX_PASS = The login password

• device_params={'name': 'junos'} = Informs ncclient that this is a Juniper device

• hostkey_verify=False = Disables SSH key verification (suitable for lab environments, not recommended for production)

• look_for_keys=False = Disables searching for SSH key files

• allow_agent=False = Disables the use of the SSH agent

What manager.connect() returns:

• A connection object that allows us to send commands

• Automatically manages the SSH connection

• Oversees the NETCONF session

Retrieving System Information

def get_vmx_system_info():
    """Get system information from vMX"""
    
    with connect_vmx() as m:
        # Get system information
        result = m.command(command='show version', format='xml')
        data = xmltodict.parse(result.tostring)
        
        # Get uptime
        uptime_result = m.command(command='show system uptime', format='xml')
        uptime_data = xmltodict.parse(uptime_result.tostring)
        
        return data, uptime_data

What is with ... as m?

with connect_vmx() as m:
# Use connection 'm' here
# Connection automatically closes when done

This is a context manager

Benefits:

• Automatically closes connection even if there's an error

• Prevents connection leaks

• Cleaner than manual connect/disconnect

The m.command() method:

result = m.command(command='show version', format='xml')

Breaking it down:

• m.command() = Executes a Junos operational command

• command='show version' = The specific CLI command to be executed

• format='xml' = Retrieves the response in XML format (structured data)

Why use XML instead of text?

Text output:

Hostname: juniper
Model: vmx
Junos: 22.4R1.10

XML output:

<software-information>
  <host-name>juniper</host-name>
  <product-model>vmx</product-model>
  <junos-version>22.4R1.10</junos-version>
</software-information>

XML is:

• Structured (easy to parse)

• Consistent format

• Machine-readable

• Contains all information

Converting XML to Dictionary:

uptime_data = xmltodict.parse(uptime_result.tostring)

This process converts XML data into a Python dictionary:

data ={
   'rpc-reply':{
      'software-information':{
        'host-name':'juniper',
        'product-model':'vmx',
        'junos-version':'22.4R1.110'
       }
    }
}

Extracting and formatting the data

def parse_system_data(sys_data, uptime_data):
    """Parse and extract system information"""
    
    try:
        software = sys_data['rpc-reply']['software-information']
        uptime_info = uptime_data['rpc-reply']['system-uptime-information']
        
        info = {
            'hostname': software.get('host-name', 'N/A'),
            'model': software.get('product-model', 'N/A'),
            'version': software.get('junos-version', 'N/A'),
            'uptime': uptime_info.get('system-booted-time', {}).get('time-length', 'N/A')
        }
        
        return info
        
    except Exception as e:
        print(f"Could not parse system info: {e}")
        return {
            'hostname': 'N/A',
            'model': 'N/A',
            'version': 'N/A',
            'uptime': 'N/A'
        }

Why try/except ?

• The XML structure may vary

• Missing fields will not cause the script to crash

• Ensures graceful error handling

What is .get('key', 'N/A') ?

Safe dictionary access:

# If key exists, return value
# If key doesn't exist, return 'N/A' instead of crashing
value=dictionary.get('key','N/A')

Displaying the information

def display_system_info(system_info):
    """Display system information in formatted output"""
    
    print("="*60)
    print("Juniper vMX Device Information")
    print("="*60)

Creating the headers

print("="*60)
# Prints 60 equal signs

Exporting to CSV

Let's save the collected data to a CSV file for use in Excel:

def export_system_to_csv(system_info, filename=None):
    """Export system information to CSV file"""
    
    if filename is None:
        timestamp = datetime.now().strftime('%Y%m%d_%H%M%S')
        filename = f"vmx_system_info_{timestamp}.csv"
    
    # Create exports directory if it doesn't exist
    export_dir = 'exports'
    if not os.path.exists(export_dir):
        os.makedirs(export_dir)
    
    filepath = os.path.join(export_dir, filename)
    
    with open(filepath, 'w', newline='') as f:
        writer = csv.writer(f)
        
        # Write header
        writer.writerow([
            'Collection Time',
            'Device IP',
            'Hostname',
            'Model',
            'Junos Version',
            'Uptime'
        ])
        
        # Write data
        writer.writerow([
            datetime.now().strftime('%Y-%m-%d %H:%M:%S'),
            VMX_HOST,
            system_info['hostname'],
            system_info['model'],
            system_info['version'],
            system_info['uptime']
        ])
    
    print(f"\n✓ System information exported to: {filepath}")
    return filepath

Complete Output

# Exexute the script 
python3 junos_get_csv.py

============================================================
vMX Device Information Collector
============================================================
Target: 172.20.20.16
Time: 2026-02-11 13:14:13
============================================================

Collecting system information...
✓ System information collected
Collecting interface information...
✓ Interface information collected (10 interfaces)

============================================================
Juniper vMX Device Information
============================================================
Hostname            : juniper
Model               : vmx
Junos Version       : 22.4R1.10
Uptime              : {'@seconds': '2431474', '#text': '4w0d 03:24'}

============================================================
Interface Status
============================================================
+-------------+----------------+---------------+
| Interface   | Admin Status   | Oper Status   |
+=============+================+===============+
| ge-0/0/0    | up             | up            |
+-------------+----------------+---------------+
| gr-0/0/0    | up             | up            |
+-------------+----------------+---------------+
| ip-0/0/0    | up             | up            |
+-------------+----------------+---------------+
| lc-0/0/0    | up             | up            |
+-------------+----------------+---------------+
| lt-0/0/0    | up             | up            |
+-------------+----------------+---------------+
| mt-0/0/0    | up             | up            |
+-------------+----------------+---------------+
| pd-0/0/0    | up             | up            |
+-------------+----------------+---------------+
| pe-0/0/0    | up             | up            |
+-------------+----------------+---------------+
| pfe-0/0/0   | up             | up            |
+-------------+----------------+---------------+
| pfh-0/0/0   | up             | up            |
+-------------+----------------+---------------+

============================================================
Exporting Data
============================================================

✓ System information exported to: exports/vmx_system_info_20260211_131415.csv
✓ Interface information exported to: exports/vmx_interfaces_20260211_131415.csv

============================================================
Collection Summary
============================================================
✓ Device: juniper (172.20.20.16)
✓ Model: vmx
✓ Version: 22.4R1.10
✓ Interfaces Collected: 10
✓ System CSV: exports/vmx_system_info_20260211_131415.csv
✓ Interface CSV: exports/vmx_interfaces_20260211_131415.csv
============================================================

Troubleshooting Common Issues

Issue 1: Connection Timeout

Error:

TimeoutError: timed out

Solutions:

# Increase timeout
m = manager.connect(
  host=device['host'],
  timeout=30, # Increase from default 10 seconds
  ...
)

Issue 2: Authentication Failed

Error:

AuthenticationException: Authentication failed

Solutions:

1. Verify username/password

2. Check user has correct privileges

3. Ensure NETCONF is enabled

Issue 3: XML Parsing Errors

Error:

KeyError: 'software-information'

Solutions:

# Use .get() with defaults
software=data.get('rpc-reply',{}).get('software-information',{})
hostname=software.get('host-name','Unknown')

Issue 4: NETCONF Not Enabled

Error:

Connection refused on port 830

Solutions:

show system connections | match 830 

Key Differences: NETCONF vs. SSH/CLI

Next Steps

Now that you can collect device information, consider the following actions:

1. Schedule Regular Collection - Utilize cron or Task Scheduler

2. Develop a Dashboard - Present data in real-time

3. Track Changes - Compare today's data with yesterday's data.

4. Alert on Differences - Send an email notification when versions change.

5. Export to Database - Store historical data

Key Takeaways

✅ NETCONF is powerful - It offers structured data, supports transactions, and provides validation.

✅ XML is consistent - It maintains the same format consistently.

✅ Python simplifies the process - ncclient manages the complexity

✅ Start with read-only - This approach eliminates the risk of causing disruptions.

✅ Build confidence - Gain expertise in querying before proceeding to configuration.

Conclusion

Congratulations on mastering the use of NETCONF to gather device information from Juniper vMX routers :

• Establish a connection to the device using NETCONF

• Execute operational commands

• Parse XML responses

• Extract and format the data

• Export data to CSV for analysis

Next week, we will utilize Jinja2 templates to dynamically generate configurations across multiple vendors.

Download the code

All the code from this post is available on GitLab:network-automation-week-2

Questions or Feedback?

Connect with me on LinkedIn

In this post, we will develop a practical configuration backup script to automate a common task for network engineers: backing up device configurations across multiple network devices. Instead of manually SSH-ing into each router or switch, you will have a Python script that performs this task automatically and saves timestamped backups.

What you'll learn:

• Efficiently managing multiple device connections

• Implementing error handling for practical scenarios

• Organizing and timestamping backup files

What you'll need:

• A basic understanding of Netmiko (as covered in Part 1)

• Python 3.x installed

• Access to network devices (whether physical, virtual, or via Containerlab)

• A text editor or IDE

By the end of this tutorial, you'll have a working automation script that you can adapt for your own network environment. Let's get started

Building Your First Backup Script

Version 2: Multi-Vendor Support

Now, let's extend this to support Nokia, Cisco, and Juniper devices.

from netmiko import ConnectHandler
from datetime import datetime
import os
import sys

# Device inventory - add your devices here
devices = [
    {
        'device_type': 'alcatel_sros',
        'host': '172.20.20.13',
        'username': 'username',
        'password': 'password',
        'timeout': 60,
        'vendor': 'nokia'
    },
    {
        'device_type': 'cisco_xr',  # Use 'cisco_xe' for IOS-XE, 'cisco_xr' for IOS-XR
        'host': '172.20.20.15',
        'username': 'username',
        'password': 'password',
        'timeout': 60,
        'vendor': 'cisco'
    },
    {
        'device_type': 'juniper_junos',
        'host': '172.20.20.16',
        'username': 'username',
        'password': 'password',
        'timeout': 60,
        'vendor': 'juniper'
    }
]

# Vendor-specific commands
VENDOR_COMMANDS = {
    'nokia': {
        'pager': 'environment no more',
        'config': 'admin display-config',
        'prompt': r'#'
    },
    'cisco': {
        'pager': 'terminal length 0',
        'config': 'show running-config',
        'prompt': r'#'
    },
    'juniper': {
        'pager': 'set cli screen-length 0',
        'config': 'show configuration',
        'prompt': r'[>#]'
    }
}

# Create backup directory if it doesn't exist
backup_dir = 'backups'
if not os.path.exists(backup_dir):
    os.makedirs(backup_dir)
    print(f"Created backup directory: {backup_dir}\n")

def validate_config(config_text, vendor):
    """Validate that configuration was retrieved successfully"""
    if not config_text or len(config_text) < 100:
        return False, "Configuration appears empty or too short"

    # Vendor-specific validation
    validation_keywords = {
        'nokia': ['configure', 'system'],
        'cisco': ['version', 'interface'],
        'juniper': ['system', 'interfaces']
    }

    keywords = validation_keywords.get(vendor, [])
    config_lower = config_text.lower()

    if not any(keyword in config_lower for keyword in keywords):
        return False, f"Configuration doesn't appear to be valid {vendor.upper()} config"

    return True, "Configuration validated"

def backup_device(device_info):
    """Backup a single device and return status"""
    vendor = device_info.get('vendor', 'unknown')
    host = device_info['host']

    print(f"\n{'='*70}")
    print(f"Processing {vendor.upper()} device: {host}")
    print(f"{'='*70}")

    try:
        # Get vendor-specific commands
        commands = VENDOR_COMMANDS.get(vendor)
        if not commands:
            return False, f"Unknown vendor: {vendor}"

        # Create connection parameters (exclude 'vendor' key)
        connection_params = {k: v for k, v in device_info.items() if k != 'vendor'}

        # Connect to device
        print(f"Connecting to {host}...")
#        connection = ConnectHandler(**device_info)
        connection = ConnectHandler(**connection_params)
        print("✓ Connected successfully")

        # Get hostname for filename
#        hostname = connection.find_prompt().strip('#> ')
#        print(f"✓ Device hostname: {hostname}")

        # Get hostname for filename
        raw_hostname = connection.find_prompt().strip('#> ')

        # Clean hostname - remove invalid characters for filenames
        # For Cisco XR: RP/0/RP0/CPU0:hostname becomes hostname
        if ':' in raw_hostname:
            hostname = raw_hostname.split(':')[-1]  # Get part after last colon
        else:
            hostname = raw_hostname

        # Remove any remaining invalid filename characters
        hostname = hostname.replace('/', '_').replace('\\', '_').replace(':', '_')


        # Set terminal parameters
        print("Setting terminal parameters...")
        connection.send_command(commands['pager'], expect_string=commands['prompt'])

        # Retrieve configuration
        print(f"Retrieving configuration from {hostname}...")
        config = connection.send_command(
            commands['config'],
            expect_string=commands['prompt'],
            delay_factor=2
        )

        # Validate configuration
        is_valid, message = validate_config(config, vendor)
        print(f"✓ {message}")

        if not is_valid:
            print(f"⚠ Warning: {message}")
            connection.disconnect()
            return False, message

        # Create timestamp for filename
        timestamp = datetime.now().strftime('%Y%m%d_%H%M%S')

        # Create vendor subdirectory
        vendor_dir = os.path.join(backup_dir, vendor)
        if not os.path.exists(vendor_dir):
            os.makedirs(vendor_dir)

        # Create filename
        filename = f"{vendor_dir}/{hostname}_{timestamp}.txt"

        # Save configuration to file
        with open(filename, 'w', encoding='utf-8') as f:
            f.write(f"# Backup created: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}\n")
            f.write(f"# Device: {hostname} ({host})\n")
            f.write(f"# Vendor: {vendor.upper()}\n")
            f.write(f"# Device Type: {device_info['device_type']}\n")
            f.write(f"# {'='*60}\n\n")
            f.write(config)

        # Verify file was created and has content
        file_size = os.path.getsize(filename)
        print(f"✓ Configuration saved to {filename}")
        print(f"✓ File size: {file_size:,} bytes")

        # Disconnect
        connection.disconnect()
        print("✓ Disconnected successfully")

        return True, filename

    except ConnectionError as e:
        error_msg = f"Connection error: {str(e)}"
        print(f"✗ {error_msg}")
        return False, error_msg

    except Exception as e:
        error_msg = f"Error: {str(e)} (Type: {type(e).__name__})"
        print(f"✗ {error_msg}")
        return False, error_msg

# Main execution
def main():
    """Backup all devices in inventory"""
    print("\n" + "="*70)
    print("MULTI-VENDOR NETWORK DEVICE BACKUP")
    print("="*70)
    print(f"Start time: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
    print(f"Total devices: {len(devices)}\n")

    results = {
        'success': [],
        'failed': []
    }

    # Process each device
    for device in devices:
        success, info = backup_device(device)

        if success:
            results['success'].append({
                'host': device['host'],
                'vendor': device.get('vendor', 'unknown'),
                'file': info
            })
        else:
            results['failed'].append({
                'host': device['host'],
                'vendor': device.get('vendor', 'unknown'),
                'error': info
            })

    # Print summary
    print("\n" + "="*70)
    print("BACKUP SUMMARY")
    print("="*70)
    print(f"Successful: {len(results['success'])}/{len(devices)}")
    print(f"Failed: {len(results['failed'])}/{len(devices)}")

    if results['success']:
        print("\n✓ Successful backups:")
        for item in results['success']:
            print(f"  - {item['vendor'].upper()}: {item['host']}")

    if results['failed']:
        print("\n✗ Failed backups:")
        for item in results['failed']:
            print(f"  - {item['vendor'].upper()}: {item['host']}")
            print(f"    Reason: {item['error']}")

    print(f"\nEnd time: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
    print("="*70 + "\n")

    # Exit with appropriate code
    sys.exit(0 if not results['failed'] else 1)

if __name__ == "__main__":
    main()

Expected Output

python3 multivendorbackup.py

======================================================================
MULTI-VENDOR NETWORK DEVICE BACKUP
======================================================================
Start time: 2026-01-22 21:14:29
Total devices: 3


======================================================================
Processing NOKIA device: 172.20.20.13
======================================================================
Connecting to 172.20.20.13...
✓ Connected successfully
Setting terminal parameters...
Retrieving configuration from PE1...
✓ Configuration validated
✓ Configuration saved to backups/nokia/PE1_20260122_211432.txt
✓ File size: 4,263 bytes
✓ Disconnected successfully

======================================================================
Processing CISCO device: 172.20.20.15
======================================================================
Connecting to 172.20.20.15...
✓ Connected successfully
Setting terminal parameters...
Retrieving configuration from cisco_xrv9000...
✓ Configuration validated
✓ Configuration saved to backups/cisco/cisco_xrv9000_20260122_211434.txt
✓ File size: 2,529 bytes
✓ Disconnected successfully

======================================================================
Processing JUNIPER device: 172.20.20.16
======================================================================
Connecting to 172.20.20.16...
✓ Connected successfully
Setting terminal parameters...
Retrieving configuration from admin@juniper...
✓ Configuration validated
✓ Configuration saved to backups/juniper/admin@juniper_20260122_211435.txt
✓ File size: 1,114 bytes
✓ Disconnected successfully

======================================================================
BACKUP SUMMARY
======================================================================
Successful: 3/3
Failed: 0/3

✓ Successful backups:
  - NOKIA: 172.20.20.13
  - CISCO: 172.20.20.15
  - JUNIPER: 172.20.20.16

End time: 2026-01-22 21:14:35
======================================================================

Lets analyze the script for a clearer understanding

1. from netmiko import ConnectHandler Firstly we import the ConnectHandler from the netmiko library used to connect into network devices

2. from datetime import datetime We then import datetime from the datetime library , to be able to work with time and dates

3. import os which is an operating system library used for working with files and folders

4. import sys used for system-level operations

5. Device Inventory: This is where we define all the devices we want to back up. The devices variable holds our list of all devices. Inside the list, each device is represented by a dictionary

6. vendor_commands A dictionary of dictionaries (nested dictionaries). Each vendor has its own set of commands

7. Create a backup directory if it doesn’t exist. backup_dir = 'backups' a variable is created named backup_dir . This is the name of the folder where we will store the backups. os.path.exists(backup_dir)

   Checks if the folder exists and it returns True if it exists, False if it doesn't

8. The Validation Function def validate_config(config_text, vendor) checks if config_text is empty or None and returns True if it is empty, and False if it has content. The or operator means if either condition is true, the entire expression is true. len(config_text) < 100 Checks if config has fewer than 100 characters. return returns two values to the function false = validation failed and "Configuration appears..." = Error Message .

9. Vendor-Specific Validation involves creating a dictionary of keywords we expect to find. Each vendor's configuration should include certain words. If these words are missing, there could be a problem..

10. def backup_device(device_info): This function takes one input, device_info, which is a dictionary containing the device details. vendor = device_info.get('vendor', 'unknown') uses .get() to safely retrieve the vendor. If the 'vendor' key doesn't exist, it uses 'unknown' as the default. host = device_info['host'] gets the IP address from device_info.

11. Create connection parameters using connection_params = {k: v for k, v in device_info.items() if k != 'vendor'}. The device_info.items() retrieves pairs of (key, value), and for k, v in ... loops through each pair. If k != 'vendor', it doesn't include the vendor, and {k: v ...} creates a new dictionary. Connect to the device.

12. Retrieve the hostname for the filename and sanitize it by removing any characters that are not valid for filenames.

13. connection.send_command(commands['pager'], expect_string=commands['prompt']) used to turn off pagination

14. The commands['config'] is used to retrieve the configuration, and expect_string=commands['prompt'] specifies the prompt to wait for before continuing.

15. is_valid, message = validate_config(config, vendor) calls the validation function. If the validation fails, it prints a warning.

16. Create a timestamp and a vendor directory. Use os.path.join() to combine folder paths.

17. Create the filename using filename = f"{vendor_dir}/{hostname}_{timestamp}.txt" and save the configuration.

18. Verify file creation by checking the file size in bytes with os.path.getsize(filename).

19. Error Handling except ConnectionError as e : Catches only connection-related errors and except Exception as e : Catches any other error

20. The main function main() orchestrates the entire backup process. It calls backup_device() for each device and collects and displays the results.

How It All Works Together

The Complete Flow

1. Script starts
├─> Import libraries
├─> Define device list
├─> Define vendor commands
└─> Create backup directory

2. main() function runs
├─> Print header
├─> Create results dictionary
└─> For each device:
├─> Call backup_device()
│ ├─> Connect to device
│ ├─> Get hostname
│ ├─> Disable paging
│ ├─> Get configuration
│ ├─> Validate configuration
│ ├─> Save to file
│ ├─> Disconnect
│ └─> Return success/failure
│
└─> Add to results (success or failed list)

3. Print summary
├─> Show success count
├─> Show failure count
├─> List successful backups
├─> List failed backups
└─> Exit with status code

Best Practices and Tips

Security Considerations

Avoid hardcoding passwords in scripts. Consider using one of the following approaches:

• Environmental variables

• Encrypted vaults (Ansible Vault, HashiCorp Vault)

• Keyring libraries

• Prompts for passwords at runtime

Example with environment variables:

devices = 
    {
        'device_type': 'alcatel_sros',
        'host': '172.20.20.13',
        'username': os.environ.get('NETWORK_USERNAME'),
        'password': os.environ.get('NETWORK_PASSWORD'),
  
    }

Error Handling

Always implement proper error handling:

• Connection timeouts

• Authentication failures

• Device unreachable

• Insufficient privileges

Logging

Comprehensive logging helps troubleshoot issues:

• Connection attempts

• Successful operations

• Errors with full stack traces

• Execution duration

Backup Retention

Implement a retention policy to manage disk space

Troubleshooting Common Issues

Issue 1: "Authentication failed"

Solution : Verify credentials, check if AAA is configured correctly

Issue 2: "Connection timeout"

Solution : Verify network connectivity, check firewall rules, ensure SSH is enabled

Issue 3: "Command not recognized"

Solution : Verify the backup command for your device type, some platforms use different commands

Issue 4: "Permission denied"

Solution : Ensure the user has proper privilege levels (Cisco: privilege 15, Juniper: superuser class)

Next Steps

Now that you have a functional backup script, consider implementing the following enhancements:

1. Schedule automated backups using cron (Linux) or Task Scheduler (Windows)

2. Add Git integration to track configuration changes over time

3. Implement differential backups to store only changes

4. Add email notifications for backup failures

5. Extend to more device types (Palo Alto, Fortinet etc.)

Conclusion

Congratulations on building your first network automation tool. This script has the potential to save you significant time and serves as a foundation for more advanced automation tasks.

In next week's post, we will explore Network APIs and discuss how to manage network devices using modern API-first approaches on Juniper platforms.

Download the code

All the code from this post is available on GitLab. : network-automation-week-1-part2

Questions or Feedback?

Connect with me on LinkedIn. I'd love to hear about your automation journey!

By the end of this post, you'll have a working script that can save you hours of repetitive work and provide a solid foundation for your automation journey.

Why Network Automation?

Before we jump into code, let's address the elephant in the room: why automate?

• Time Savings: Manually backing up 50 devices is time-consuming, taking hours, whereas automation completes the task in minutes.

• Consistency: Scripts execute tasks without missing steps or making typographical errors.

• Audit Trail: Automated backups with timestamps provide a dependable change history.

• Disaster Recovery: Regular automated backups ensure preparedness for unforeseen events.

• Scalability: As your network expands, automation prevents manual processes from becoming a bottleneck.

Why Coding is Essential for Network Engineers Today?

Modern networks are no longer configured on a device-by-device basis. They are software-driven systems. Acquiring coding skills enables network engineers to transition from manual operators to automation engineers.

Here’s what coding enables:

1. Automation Over Repetition

   Instead of logging into 100 devices:

   • A script can push configs

   • Validate state

   • Roll back safely

2. Expedited Troubleshooting and Enhanced Visibility

   With code, you can:

   • Pull live data from devices

   • Parse outputs (JSON/XML/YANG)

   • Detect anomalies automatically

3. Vendor-Agnostic Networking

   Coding helps you think in models, not commands:

   • YANG models

   • OpenConfig

   • REST / NETCONF / gNMI

4. Career Longevity and Growth

   Roles that increasingly expect coding skills:

   • Network Automation Engineer

   • NetDevOps Engineer

   • SRE (Network-focused)

   • Cloud Network Engineer

"You're either the one who creates the automation, or you're the one being automated." ~ Tom Preston-Werner, co-founder and former CEO of GitHub

Prerequisites

Before we begin, ensure you have:

• Python 3.8 or higher installed

• Basic understanding of Python (variables, functions, loops)

• Access to network devices (lab or production)

• SSH enabled on your network devices

Setting Up Your Environment

Step 1: Create a Virtual Environment

Virtual environments keep your project dependencies isolated and clean.

# Create a new directory for your project
mkdir network-automation
cd network-automation
# Create a virtual environment
python3 -m venv venv
# Activate the virtual environment
# On Linux/Mac:
source venv/bin/activate
# On Windows:
venv\Scripts\activate

Step 2: Install the Required Libraries

We'll use Netmiko , a popular Python library that simplifies SSH connections to network devices.

pip3 install netmiko

Step 3: Set Up a Lab Environment for Testing

In my testing environment, I am utilizing Containerlab. Containerlab is an open-source tool designed for creating network topologies with containerized network devices. It allows you to quickly set up multi-vendor network labs on your laptop without the need for hypervisors or heavy virtual machines, using only lightweight containers.

Multi-Vendor Network Topology:

Understanding Netmiko

Netmiko is a Python library that simplifies SSH connections to network devices, making it easier for network engineers to automate tasks without needing deep software engineering skills

Think of Netmiko as:

“SSH for network engineers, done the right way.”

What issues does Netmiko address?

When you manually SSH into a router, you must manage prompts, paging, privilege modes, and command timing on your own. Netmiko automates these processes. It is designed to interact seamlessly with devices from Nokia, Cisco, Juniper, Arista, HP, and many other vendors, eliminating the need to write custom code for each one.

Key features

• Automatic handling of prompts: Knows when commands finish executing

• Paging disabled: Automatically handles "-- More --" prompts

• Multiple vendors: Just change device_type to support different platforms

• Configuration mode: Built-in methods for entering config mode and sending commands

• Error handling: Can detect command failures

Building Your First Backup Script

Version 1: Single Device Backup

Let's begin with a simple script to back up a single Nokia SROS device.

from netmiko import ConnectHandler
from datetime import datetime
import os
import sys

# Device details
nokia_device = {
    'device_type': 'alcatel_sros',
    'host': '172.20.20.13',
    'username': 'admin',
    'password': 'admin',
    'timeout': 60,  # Increased timeout for large configs
    'session_log': 'netmiko_session.log'  # Optional: log session for debugging
}

# Commands to execute
commands = [
    'environment no more',
    'admin display-config'
]

# Create backup directory if it doesn't exist
backup_dir = 'backups'
if not os.path.exists(backup_dir):
    os.makedirs(backup_dir)
    print(f"Created backup directory: {backup_dir}")

def validate_config(config_text):
    """Validate that configuration was retrieved successfully"""
    if not config_text or len(config_text) < 100:
        return False, "Configuration appears empty or too short"
    
    # Check for common SR OS config indicators
    if 'configure' not in config_text.lower():
        return False, "Configuration doesn't appear to be valid SR OS config"
    
    return True, "Configuration validated"

try:
    # Connect to device
    print(f"Connecting to {nokia_device['host']}...")
    connection = ConnectHandler(**nokia_device)
    print("Connected successfully")
    
    # Get hostname for filename
    hostname = connection.find_prompt().strip('#> ')
    print(f"Device hostname: {hostname}")
    
    # Execute commands
    print("Setting terminal parameters...")
    connection.send_command(commands[0], expect_string=r'#')
    
    print(f"Retrieving configuration from {hostname}...")
    config = connection.send_command(commands[1], expect_string=r'#', delay_factor=2)
    
    # Validate configuration
    is_valid, message = validate_config(config)
    if not is_valid:
        print(f"Warning: {message}")
        response = input("Continue anyway? (y/n): ")
        if response.lower() != 'y':
            print("Backup cancelled")
            connection.disconnect()
            sys.exit(1)
    else:
        print(message)
    
    # Create timestamp for filename
    timestamp = datetime.now().strftime('%Y%m%d_%H%M%S')
    
    # Create filename
    filename = f"{backup_dir}/{hostname}_{timestamp}.txt"
    
    # Save configuration to file
    with open(filename, 'w', encoding='utf-8') as f:
        f.write(f"# Backup created: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}\n")
        f.write(f"# Device: {hostname} ({nokia_device['host']})\n")
        f.write(f"# {'='*60}\n\n")
        f.write(config)
    
    # Verify file was created and has content
    file_size = os.path.getsize(filename)
    print(f"Configuration saved to {filename}")
    print(f"File size: {file_size:,} bytes")
    
    # Disconnect
    connection.disconnect()
    print("Disconnected successfully")
    
except ConnectionError as e:
    print(f"Connection error: {str(e)}")
    print("Check network connectivity and device accessibility")
    sys.exit(1)
    
except Exception as e:
    print(f"An error occurred: {str(e)}")
    print(f"Error type: {type(e).__name__}")
    sys.exit(1)

print("\nBackup completed successfully!")

Expected Output

# Execute the script 
python3 backup.py

Connecting to 172.20.20.13...
Connected successfully
Device hostname: *A:PE1
Setting terminal parameters...
Retrieving configuration from *A:PE1...
Configuration validated
Configuration saved to backups/*A:PE1_20260121_143523.txt
File size: 5,729 bytes
Disconnected successfully

Backup completed successfully!

What’s Next?

You now have a working understanding of SSH connections and basic command execution with Netmiko. In Part 2, we'll use these skills to build a practical script that backs up configurations from multiple devices automatically—the kind of task that saves network engineers hours every week. We will also breakdown the code step-by-step. Even if you've never programmed before, you'll understand exactly how it works.

By the end, you'll have a script that automatically backs up configurations from Nokia, Cisco, and Juniper devices!

Download the code

All the code from this post is available on GitLab: network-automation-week-1

Questions or Feedback?

Connect with me on LinkedIn. I'd love to hear about your automation journey!