# Network Automation with Python — Netmiko, NAPALM & Nornir Source: https://ai.techclick.in/blog_network_automation_python Markdown: https://ai.techclick.in/blog_network_automation_python.md Publisher: Techclick Infosec Pvt Ltd Learn network automation with Python the job-ready way — when to use Netmiko vs NAPALM vs Nornir, your first push-config-to-50-devices script, and the 5 mistakes that cause real outages. Built for CCNA-level engineers in India. Network Automation with Python — Netmiko, NAPALM & Nornir student learning map A visual study map for Network Automation with Python — Netmiko, NAPALM & Nornir showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Network Automation with Python — Netmiko, NAPALM... Python · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Why "CCNA + automation" is the... 4. Practice ② The three tools, decoded How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Network automation means becoming a full-time programmer — or, the opposite belief, that a plain CCNA is still enough to get hired in 2026. Both are wrong. You don't need to be a developer — about 20 lines of Python and the right library will push config to 500 devices. And a plain CCNA now competes with thousands of identical resumes. The combination that actually gets you the call-back is CCNA + automation . By the end of this lesson you'll have written the script that proves you have it. ⚡ Quick answer Network automation with Python means using small scripts to configure and check many network devices at once instead of typing into each one. The three tools you'll actually use: Netmiko (push CLI over SSH — your starting point), NAPALM (clean, vendor-independent data + safe commit/rollback), and Nornir (run the same task across hundreds of devices in parallel). Start with Netmiko on day one; reach for NAPALM when you have mixed vendors; add Nornir when you outgrow a simple loop. ## ① 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. 👉 So far: automation = "configure once, apply to many". It's now the line item that separates a fresher's resume from the pile. 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. Aditya at a Lucknow ISP faces this His manager asks him to add one management VLAN to 200 branch switches before Monday. By hand, that's a full weekend of console work — and one typo on switch #147 that nobody will notice until it breaks. Likely cause The task isn't hard — it's repetitive . Humans are slow and error-prone at "do this exact thing 200 times". Diagnosis This is the textbook case for automation: identical change, many devices, tight deadline. One config block → loop over an inventory → apply everywhere Fix A ~20-line Netmiko script reads the 200 switches from a list and pushes the VLAN to each. Weekend job becomes a 5-minute run. Verify The script ends by running show vlan brief on each switch and logging which ones actually show VLAN — proof from the device, not from "the script said OK". Quick check · Q1 of 10 Aditya can configure one switch perfectly, but a 200-switch VLAN rollout would take him all weekend by hand. What single skill turns that overnight job into a 5-minute one? a) Memorising more CLI commands b) Network automation with a Python library like Netmiko c) A faster console cable d) Asking for three more teammates Correct: b. The job is repetitive, not complex — that's exactly what a script is for. More commands (a) or faster cables (c) don't remove the 200× repetition; more people (d) just multiplies the typo risk. Pause & Predict Before we name the tools — guess: roughly how many lines of Python do you think it takes to push one command to a switch? Type your guess. Reveal answer Answer: About 5–8 lines. Import the library, define the device (host, username, password, type), connect, send the command, print the result. That's the whole "hello world" of network automation — you'll see it in Section 3. ## ② 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. 🔑 SSH tap to flip The secure "remote control" you already use to reach a device's CLI. Netmiko automates typing into that same SSH session — so anything you can do by hand, it can do in code. 📦 API / getter tap to flip A clean "ask a question, get structured data back" door. NAPALM getters return facts as ready-to-use Python dictionaries — no screen-scraping. So what: no fragile regex per vendor. 📋 Inventory tap to flip Your list of devices (hostnames, IPs, credentials, groups) kept in a file. Nornir reads it so your script says "run on all branch routers" instead of hardcoding 600 IPs. So what: the list lives in one place. ♻️ Idempotent tap to flip Run it once or ten times — same final result, no duplicates, no damage. The #1 property of safe automation. So what: a retry can't double-apply an ACL and break traffic. ### 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". Colour key Netmiko (SSH / CLI) NAPALM (vendor-neutral API) Nornir (parallel / at scale) wraps the others Figure 1 — Which tool should you reach for? Start from "What's the job?". If you just need to push CLI and you're getting started, choose Netmiko. If you need clean multi-vendor data with safe commit and rollback, choose NAPALM. If you have hundreds of devices and want parallel, grouped runs, choose Nornir — which can call the other two underneath. - Pick by the job in front of you — not by hype What's the job? start here "Push CLI, I'm just starting" few devices · screen-scrape OK Netmiko "Clean data + safe change" multi-vendor · diff · rollback NAPALM "Hundreds of devices" parallel · grouped runs Nornir Nornir wraps the other two It runs Netmiko or NAPALM tasks — in parallel, across your inventory. So you rarely "drop" a tool — you stack them. trusted / your tooling the scale "aha" wraps the others The decision is "what's the job?", not "which is best?". Netmiko to start, NAPALM for clean multi-vendor + safe change, Nornir to run either at scale. Figure 2 — Netmiko vs NAPALM vs Nornir at a glance A matrix comparing the three tools across: what it is, best at, multi-vendor structured data, runs in parallel, commit and rollback, and where to start. Netmiko is the SSH starting point, NAPALM gives structured data and safe commits, Nornir adds parallel execution and is the framework that runs the others. Netmiko NAPALM Nornir Compare on the 5 things that matter on the job What it is SSH + send CLI Vendor-neutral API Inventory + runner Best at quick config push facts + safe commit scale + grouping Clean structured data ✗ (you parse text) ✓ built-in getters via NAPALM Runs in parallel ✗ (you loop) ✗ (you loop) ✓ native threads Commit + rollback ✗ ✓ compare/commit/rollback via NAPALM Start here? ✓ Day 1 when multi-vendor when 100s of devices Golden rule: start with Netmiko → add NAPALM for clean/safe → add Nornir for scale. They stack. Read it left to right: capability grows as you climb the stack. The ✗ marks aren't weaknesses — they're just "that's another tool's job". ### ▶ How a Netmiko push actually runs The four steps every config script follows. Press Play for the healthy path, then Break it to see the most common failure. ① Connect ConnectHandler() opens an SSH session to the switch at 10.20.4.11 . ▼ ② Send config send_config_set() types the VLAN lines into config mode — exactly as you would by hand. ▼ ③ Save save_config() writes running-config to startup so the change survives a reboot. ▼ ④ Verify send_command('show vlan brief') reads it back — proof from the device. Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Sneha at Infosys faces this Her team runs Cisco IOS, Arista EOS and Juniper Junos. She needs one report of "uptime + serial number" from all of them — and her first Netmiko script needs a different regex for every vendor's output. It's becoming a mess. Likely cause Netmiko returns raw text, which looks different on each vendor — so she's screen-scraping three times. Diagnosis This is the multi-vendor data problem NAPALM was built for. Swap raw text → NAPALM get_facts() structured dict Fix One NAPALM call returns the same dictionary shape for all three vendors. No per-vendor regex — she reads facts['serial_number'] everywhere. Verify She spot-checks one serial against the device's own show version — the structured value matches the box. Quick check · Q2 of 10 Sneha wants one script that pulls clean, vendor-independent facts from Cisco, Arista and Juniper — without writing a different regex per vendor. Which library fits best? a) Netmiko on its own b) NAPALM c) Paramiko d) Notepad++ Correct: b. NAPALM's getters return the same structured dictionary across vendors — no regex. Netmiko (a) and Paramiko (c) hand you raw text you'd still have to parse per vendor; Notepad++ (d) is a text editor. Pause & Predict A Netmiko loop over 500 devices runs them one after another. If each device takes ~5 seconds, why does Nornir finish the same job ~13× faster? Type your guess. Reveal answer Answer: Nornir runs many devices at the same time (parallel threads) instead of waiting for each to finish before starting the next. 500 × 5s in series ≈ 40 min; 500 in parallel ≈ a couple of minutes. Same per-device work — just not standing in a queue. ## ③ 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. Figure 3 — Where your script sits Your laptop runs a Python script that reads an inventory file of hosts and credentials. Netmiko reaches devices over SSH; NAPALM reaches them over an API or NETCONF. Nornir wraps the script to run the task across the whole fleet of routers, switches and firewalls in parallel. Your laptop — Nornir runs it all in parallel Python script push_vlan.py inventory.yaml hosts · IPs · credentials · groups secrets from env / vault never hardcoded in the script SSH · Netmiko API / NETCONF · NAPALM Your fleet Routers Switches Firewalls 10.x / 172.16.x / 192.168.x Cisco · Arista · Juniper · Fortinet your code & inventory (trusted) the connection (SSH / API) Nornir = parallel wrapper One script, one inventory file, two ways to reach a device (SSH for Netmiko, API/NETCONF for NAPALM) — and Nornir running the whole thing across the fleet at once. ### 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. push_vlan.py 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() Expected output 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. 🖥️ This is the screen you'll actually work in — your editor with push_vlan.py open, ready to run. (Recreated for clarity — your VS Code / PyCharm will match this.) VS Code — push_vlan.py — netauto 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" ])) ▸ TERMINAL $ python push_vlan.py SW-BR11(config)#vlan 99 ✓ VLAN 99 pushed in 1.8s ### 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. safe_change.py 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() Expected output (the diff — nothing applied yet) +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. ### ▶ NAPALM's safe-change loop — never commit blind The discipline that separates a junior from a senior. Press Play , then Break it to see what happens when you skip the dry-run. ① Load candidate load_merge_candidate() stages the change — the device is still untouched. ▼ ② Compare (dry-run) compare_config() prints the exact diff. You read it like a code review. ▼ ③ Commit Diff looks right → commit_config() applies it. Wrong → discard_config() . ▼ ④ Verify + rollback ready Re-check with a getter; if it misbehaves, rollback() is your undo button. Press Play to step through the safe path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset 🖥️ The terminal you'll watch during a change — NAPALM showing the diff, then the device confirming the result. (Recreated for clarity — real labels and commands.) netadmin@jump-host: ~/netauto $ 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. run_fleet.py 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") Expected output Done on 480 devices SW-BR-MUM-001 ... ok SW-BR-MUM-002 ... ok ... (all in parallel — total 2m 41s, not 38m) 👉 So far: Netmiko pushes the config, NAPALM previews + commits safely, Nornir runs it across the fleet in parallel. That's the whole job in three tools. Priya at TCS faces this Her Nornir job needs to run only on the Mumbai branch routers, but it ran on every device in the inventory — including the Delhi data-centre cores. Scary, but nothing broke because she'd dry-run it. Likely cause Her filter() matched a key that didn't exist, so it silently selected all hosts. Diagnosis Print the selected hosts before running the task — always confirm the target set. filter → print(nr.inventory.hosts.keys()) → THEN run Fix Correct the group key ( site="mumbai" ) and add a count check that aborts if the target list is unexpectedly large. Verify Re-run with the fix — the host list now prints 480 Mumbai devices, not 2,000. Quick check · Q3 of 10 A serial Netmiko for-loop over 480 branch routers runs for ~38 minutes, but the change window is only 15. The config itself is correct. What's the cleanest fix? a) Buy faster routers b) Delete the verification step to save time c) Run the same task through Nornir so devices are configured in parallel d) Split the change across three nights Correct: c. The bottleneck is doing devices one at a time. Nornir runs them in parallel — ~38 min becomes ~3. New hardware (a) is overkill, dropping verification (b) is dangerous, and splitting nights (d) just delays the work. Pause & Predict In the NAPALM example, what's the one line you must never skip before commit_config() ? Type your answer. Reveal answer Answer: compare_config() — the dry-run diff. Reading the diff before committing is the difference between "I added two NTP lines" and "I accidentally removed a routing statement". Always look before you commit. ## ④ 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. 💡 Pro tip — the golden rule Treat every automation run like a deploy: lab → dry-run diff → small canary → fleet . The engineers who never cause outages aren't more careful by accident — they bake these four gates into the script itself. ⚠ Common mistake — "it worked in the lab" The symptom: a change passes on your one test switch, then wipes a live VLAN off 300 production switches. The cause is almost always a negation command ( no vlan 99 ) or a non-idempotent step applied at scale without a dry-run. Lab success ≠ prod safety. ✅ Prove it from the device, not the script Your script printing "success" only means the command was sent. Real verification is reading state back from the box — show vlan brief , a NAPALM getter, a ping. If you can't prove it from the device, you haven't verified it. Figure 4 — Cheat-sheet: the 5 rules that keep automation off the incident bridge Five tiles: be idempotent, handle errors and timeouts, always dry-run the diff, test in a lab and use a canary group to limit blast radius, and never hardcode secrets. A footer states the golden pipeline: lab, dry-run, canary, fleet. Pin this above your desk 1 Be idempotent Run it twice → same result. A retry must never double- apply a change. 2 Handle errors try/except + timeouts per device. One dead box must not freeze the run. 3 Always dry-run compare_config() before every commit. Read the diff like a code review. 4 Limit blast radius Test in EVE-NG / GNS3 / CML → small canary group → then the whole fleet. Never all at once. 5 Never hardcode secrets os.environ["SW_PASS"] or a vault — never a password in the .py file. The golden pipeline — bake it into every script lab test → dry-run diff → canary group → fleet If you can't prove the change from the device, you haven't finished. Five rules, one pipeline. The amber and red tiles (dry-run, secrets) are the two most engineers skip — and the two that cause the loudest incidents. Karthik at a Mumbai bank faces this His cleanup script ran no vlan 99 to remove an old test VLAN. It worked perfectly in the lab. In production it wiped VLAN 99 off 300 switches that were carrying live ATM traffic. Phones started ringing. Likely cause A destructive negation command, applied at scale, with no dry-run and no canary group. The lab switch didn't carry real traffic, so the blast radius was invisible there. Diagnosis Two missing gates: a diff before commit, and a staged rollout. compare_config() diff → canary 5 switches → watch → then fleet Fix Rebuild the change with NAPALM (so rollback() exists), preview the diff, run on 5 non-critical switches first, confirm traffic is fine, then roll forward. Verify After each stage, show vlan brief and a synthetic ping across VLAN 99 confirm the path is healthy before widening the rollout. Quick check · Q4 of 10 Karthik's no vlan 99 worked in the lab but wiped a live VLAN off 300 production switches. Which discipline would have caught this before the damage? a) Using a faster SSH library b) Hardcoding the password so it runs quicker c) A dry-run diff (compare_config) plus a lab test and a small canary group first d) Running it during business hours so someone notices faster Correct: c. The diff shows the destructive change before it lands, and a canary group limits the blast radius to a few switches. Faster SSH (a) just breaks things faster, hardcoded secrets (b) are a separate risk, and noticing during business hours (d) means the damage already happened. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Netmiko or Scrapli — which should I learn in 2026? Do I still need Ansible if I know Nornir? How do I store device passwords safely? Netmiko or NAPALM for daily config backups? How do I test scripts without touching production? Is Python enough, or do I need Go too? Pre-curated from Python docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which Python library is the SSH workhorse most engineers start with for pushing CLI config to network devices? a) Netmiko b) Pandas c) Flask d) NumPy Correct: a. Netmiko is the SSH/CLI library for network devices. Pandas (data analysis), Flask (web apps) and NumPy (maths) are general Python tools — none of them talk to a switch. Q6 · Apply You need vendor-independent structured facts (model, serial, uptime) plus a config merge with rollback. Which tool is purpose-built for that? a) Paramiko b) Netmiko c) NAPALM d) Requests Correct: c. NAPALM gives vendor-neutral getters plus commit/compare/rollback. Paramiko (a) and Netmiko (b) return raw text with no rollback; Requests (d) is a generic HTTP library. Q7 · Apply Your inventory has grown to 600 devices across 5 regions and you want grouped, parallel task runs while still reusing Netmiko/NAPALM underneath. What do you adopt? a) A much bigger for-loop b) Nornir c) Excel macros d) Telnet Correct: b. Nornir manages inventory + grouping and runs tasks in parallel, calling Netmiko/NAPALM as plugins. A bigger loop (a) is still serial; Excel macros (c) and Telnet (d) aren't automation frameworks. Q8 · Analyze A script auto-retries a failed step. Because the operation is not idempotent, the retry adds the same ACL line twice and breaks traffic. What property was missing? a) More bandwidth b) A faster CPU c) A Telnet fallback d) Idempotency — the same result no matter how many times it runs Correct: d. Idempotency means a re-run leaves the device in the same state — so a retry can't double-apply. Bandwidth (a), CPU (b) and Telnet (c) have nothing to do with the duplicate line. Q9 · Analyze Mid-run, your automation hangs on one unreachable device and the entire job freezes with no error. Which fix addresses the root cause? a) A sensible timeout plus try/except error handling around each device b) Removing all logging c) Running the script as root d) Disabling the inventory file Correct: a. A per-device timeout plus try/except lets one dead box fail gracefully and the run continue. Removing logging (b), root (c) or disabling inventory (d) don't address the hang — and make things worse. Q10 · Evaluate A teammate wants to push a firmware change to all 2,000 production devices at 10 a.m. "because it tested fine on one switch." For a bank's core network, what is the right call and why? a) Approve — one successful test is enough b) Approve, but run it twice for safety c) Approve at 10 a.m. so staff can watch it live d) Reject — stage it: lab test → dry-run diff → small canary group in the change window → then the fleet Correct: d. One test doesn't prove fleet safety. A staged rollout (lab → diff → canary → fleet) inside a change window contains the blast radius. Approving outright (a), running twice (b) or doing it live at peak (c) all risk a bank-wide outage. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: Why do we run compare_config() before commit_config() ? Then compare to the expert version. Compare with expert answer Expert version: compare_config() is a dry-run — it shows the exact diff of what would change, without changing anything. Reading that diff first is how you catch a destructive line (like a stray no vlan 99 ) before it hits 300 live switches. Commit blind and the device teaches you; commit after a diff and the preview teaches you. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Netmiko · NAPALM · Nornir at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Network automation Using scripts to configure, check and monitor many network devices at once, instead of typing into each one by hand. Netmiko A Python library (built on Paramiko) that automates SSH/CLI sessions to network devices — your day-one tool for pushing config. NAPALM A Python library that returns vendor-independent structured data and offers safe config changes with compare, commit and rollback. Nornir A pure-Python framework that manages your inventory and runs tasks across hundreds of devices in parallel, calling Netmiko/NAPALM underneath. Paramiko The low-level Python SSH library that Netmiko wraps, so you don't deal with raw SSH plumbing. SSH The secure remote-access protocol you already use to reach a device's CLI; Netmiko automates typing into that session. Getter A NAPALM method like get_facts() that returns device data as a ready-to-use Python dictionary — no regex needed. Idempotent A change that gives the same result whether you run it once or ten times — no duplicates, no damage on retry. Inventory Your list of devices (hosts, IPs, credentials, groups) kept in a file, so a script can say "run on all branch routers". Dry-run / diff A preview (NAPALM compare_config() ) that shows exactly what would change, before anything actually changes. Commit / rollback Apply a staged change (commit) or undo it (rollback) — NAPALM's safety net for production edits. Blast radius How many devices a change can affect at once. Automation makes it huge — staged rollouts keep it small. Canary group A small first group of devices you change and watch before rolling out to the whole fleet. Screen-scraping / TextFSM Pulling values out of raw CLI text. TextFSM / NTC-templates turn that text into clean fields so you skip fragile regex. #### 📚 Sources ipSpace.net — Ivan Pepelnjak, "Paramiko, Netmiko, NAPALM or Nornir?" . blog.ipspace.net - APNIC Blog — "Automation tools: Paramiko, Netmiko, NAPALM, Ansible, Nornir or…?" . blog.apnic.net - Full Stack Networker — "Network Automation with Python Libraries Netmiko, NAPALM and Nornir." fullstacknetworker.com - cloudmylab — "Network Automation Challenges: 5 Mistakes Engineers Make (and How to Avoid Them)." blog.cloudmylab.com - PyNet Labs — "What is Python for Network Engineers? Its Importance in 2026." pynetlabs.com - Networkers Home — "Network Automation Career — Skills, Certifications & 2026 Roadmap." networkershome.com - TechTarget — "Advanced skills drive networking job market in 2026." techtarget.com/searchnetworking ### What's next? You can now push and verify config across a fleet with Python. Next, point those same instincts at a live cloud-managed API — the Meraki Dashboard — where the device speaks JSON over HTTPS instead of CLI over SSH. Same automation mindset, different door. Next · Meraki API Automation → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt