Network Automation with Python — Netmiko, NAPALM & Nornir

① Why "CCNA + automation" is the 2026 hire signal

Think of how you message 50 friends about a meet-up. You don't open 50 chats and type the same line 50 times — you make one WhatsApp broadcast. Network automation is exactly that idea, for routers and switches. You write the change once, and a script applies it to every device in seconds.

For years a CCNA alone was enough to land a network job. Not anymore. Hiring data for 2026 says the same thing everywhere: manual, type-it-in-by-hand roles are shrinking, and the demand is moving to engineers who can automate. Cisco even rebuilt the CCNA, CCNP and CCIE blueprints to include Python and automation — so the exam itself now assumes you can script.

The money follows the skill. In India a plain CCNA fresher starts around ₹4.5–7 LPA, but engineers who add automation, SD-WAN or cloud-network skills move into ₹9–16 LPA roles much faster — and a security-plus-automation profile (say PCNSE) can reach ₹20–30 LPA with a few years. The job title to watch is Network Automation Engineer / DevNet Specialist — and those postings almost all list the same stack: Python, Netmiko, NAPALM, Nornir.

② The three tools, decoded

Almost every job posting names the same trio: Netmiko, NAPALM, Nornir. They are not competitors you choose between forever — they're three layers you add as you grow. Let's lock the vocabulary first, then meet each one.

First, four words you'll keep hearing

Tap each card — guess the meaning before you flip it.

Netmiko — the SSH workhorse you start with

Netmiko logs into a device over SSH and types commands for you — then captures the text that comes back. It's built on top of Paramiko so you don't touch raw SSH plumbing. Because the device replies as plain text, you "read" it with screen-scraping (or, better, TextFSM templates). Use it when: you can already configure the device by hand and just want to do it across many. For a lab or fewer than ~50 devices, plain Netmiko in a for loop is perfect.

NAPALM — one clean voice for many vendors

NAPALM sits one level higher. Instead of raw text, it gives you vendor-independent structured data: ask get_facts() on a Cisco, Arista or Juniper box and you get the same dictionary shape back — model, serial, uptime, interfaces — no regex per vendor. Its real superpower is safe config changes: load a candidate config, run compare_config() to see the exact diff (a dry-run), then commit_config() — and if it's wrong, rollback(). Use it when: you run mixed vendors, or any change where "show me the diff and let me undo it" matters.

Nornir — the parallel engine for scale

Nornir isn't a replacement — it's the runner that wraps the other two. It manages your inventory and executes a task across hundreds of devices in parallel (real Python threading), with built-in grouping and result handling. The same job that takes ~40 minutes one-device-at-a-time with a Netmiko loop finishes in under 3 minutes through Nornir. Use it when: you've outgrown the simple loop — a few hundred devices, or you want to run "this task on just the Mumbai branch routers".

③ Build it — your first script

Enough theory. Here's the whole pipeline in code you can copy. The shape never changes: read an inventory → connect → do the task → verify. Picture it first, then we'll write each piece.

Step 1 — Netmiko: push a VLAN to one switch

This is the "hello world" of network automation. Real, copy-pasteable, with a lab IP from the 10.20.4.x range.

from netmiko import ConnectHandler

switch = {
    "device_type": "cisco_ios",
    "host": "10.20.4.11",
    "username": "netadmin",
    "password": "use-an-env-var-here",   # see Section 4 — never hardcode
}

config = ["vlan 99", "name MGMT"]

conn = ConnectHandler(**switch)
print(conn.send_config_set(config))   # push it
conn.save_config()                    # write mem
print(conn.send_command("show vlan brief | include 99"))  # verify
conn.disconnect()

configure terminal
SW-BR11(config)#vlan 99
SW-BR11(config-vlan)#name MGMT
SW-BR11(config-vlan)#end
SW-BR11#
99   MGMT      active

That last line is the whole point — the switch itself reports VLAN 99 active. To do all 200 switches, you wrap these lines in a for loop over your inventory. That's it.

 1  from netmiko import ConnectHandler
 2
 3  switch = {
 4      "device_type": "cisco_ios",
 5      "host": "10.20.4.11",
 6      "username": "netadmin",
 7      "password": os.environ["SW_PASS"],   # 🔒 from env, not hardcoded
 8  }
 9  conn = ConnectHandler(**switch)
10  print(conn.send_config_set(["vlan 99", "name MGMT"]))

Step 2 — NAPALM: see the diff before you commit

This is the habit that keeps you employed. NAPALM loads the change as a candidate, shows you the exact diff, and only commits when you're sure. If it's wrong, you discard — nothing touched the device.

import napalm

driver = napalm.get_network_driver("ios")
dev = driver(hostname="172.16.10.2", username="netadmin",
             password="use-an-env-var-here")
dev.open()

dev.load_merge_candidate(filename="add_ntp.cfg")
print(dev.compare_config())     # DRY RUN — show me the diff first

# only now decide:
dev.commit_config()             # apply  ... or dev.discard_config() to abort
dev.close()

+ntp server 172.16.0.10
+ntp server 172.16.0.11

You saw the two lines that would be added before anything changed. That preview is your safety net — and it's why NAPALM is the grown-up choice for production changes.

$ python safe_change.py
# --- compare_config() dry-run ---
+ ntp server 172.16.0.10
+ ntp server 172.16.0.11
# diff looks right → commit_config()
committed.
$ ssh netadmin@172.16.10.2 'show run | inc ntp'
ntp server 172.16.0.10   ✓ confirmed on the device
ntp server 172.16.0.11   ✓

Step 3 — Nornir: same task, 500 devices, in parallel

When the loop gets slow, Nornir takes over. You define the inventory once, then run a task across every matching host concurrently.

from nornir import InitNornir
from nornir_netmiko.tasks import netmiko_send_config

nr = InitNornir(config_file="config.yaml")        # reads inventory.yaml
branch = nr.filter(site="mumbai")                  # just Mumbai branch

result = branch.run(
    task=netmiko_send_config,
    config_commands=["vlan 99", "name MGMT"],
)
print(f"Done on {len(result)} devices")

Done on 480 devices
SW-BR-MUM-001 ... ok
SW-BR-MUM-002 ... ok
... (all in parallel — total 2m 41s, not 38m)

④ Don't break prod — the 5 mistakes

Automation is a force multiplier — for good and bad. A typo you'd make on one switch by hand now hits 2,000 in seconds. In October 2025, an automated process inside AWS hit a timeout edge case and cascaded into a ~15-hour disruption. Scripts that ran fine in a small lab can behave very differently in production. Here are the five disciplines that keep your automation from becoming the outage.

1. Be idempotent. Running your script twice should leave the device in the same state as running it once. If a retry can add a duplicate ACL line or apply a change twice, you don't have automation — you have a loaded gun. Check "is it already there?" before you add.

2. Handle errors and timeouts. One unreachable device should not freeze the whole run. Wrap each device in try/except, set sensible Netmiko timeouts, and log the failures instead of crashing. The AWS outage above was, at its core, an unhandled timeout that cascaded.

3. Always dry-run. Use NAPALM's compare_config() (or a "show me what would change" mode) before every commit. Reading the diff is a 10-second habit that prevents 10-hour incidents.

4. Mind the blast radius — test in a lab first. Prove every change in EVE-NG, GNS3 or Cisco CML before prod, then roll out to a small canary group, then the fleet. Never all 2,000 at once on the first run.

5. Never hardcode secrets. No passwords in the .py file. Read them from an environment variable (os.environ["SW_PASS"]) or a vault. Hardcoded credentials are the security finding that gets your script — and you — flagged in audit.