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!