NAPALM for Network Engineers

Why NAPALM? Vendor-Neutral Network State

Advanced11 min read

What you'll learn

The exact problem NAPALM solves: normalized state, not orchestration
How NAPALM differs from Netmiko (vendor-specific CLI) and Nornir (execution/orchestration)
That NAPALM is not another automation runner
Where this module's boundary sits: NAPALM alone, not nornir_napalm

🎓 Teach This Lesson

Listen to a guided explanation of this lesson.

Spoken narration isn't supported in this browser.

A different question

Every device this curriculum has automated — since Netmiko Fundamentals — has spoken Cisco IOS. Netmiko sent IOS show/config commands over SSH. Nornir ran those same IOS-specific commands, concurrently, across many hosts. Neither ever had to answer: what if the next device isn't Cisco?

Two different questions, not two versions of the same question

Netmiko and Nornir both answer "how do I execute operations?" — one connection at a time, or many at once. NAPALM answers a completely different question: "how do I read and change network state through one normalized API, regardless of vendor?" It is not a faster Netmiko, not a replacement for Nornir, and not another way to run tasks.

Quick checkConcept check

What question does NAPALM answer that Netmiko and Nornir don't?

How do I run commands against more devices, faster?How do I read and change network state through one normalized API, regardless of vendor?How do I write YAML playbooks instead of Python?How do I schedule automation to run on a timer?

The concrete problem

Without NAPALM — vendor-specific CLI

Cisco IOSshow interfaces -- Cisco-specific text
Juniper Junosshow interfaces terse -- different command, different text
Arista EOSshow interfaces -- same command name, still different text
Three parsers to write and maintain

With NAPALM — one normalized call

driver.get_interfaces()same method, every vendor
Same Python dict shape backis_up, is_enabled, description, speed, ...
One piece of code, three vendors

Quick checkScenario

A team automates Cisco, Juniper, and Arista switches using raw show commands over SSH (Netmiko-style). What has to change per vendor?

Nothing — show commands are identical across all three vendorsThe commands themselves, and the parsing logic for each vendor's different text output — three separate code paths for the same conceptual questionOnly the SSH port numberOnly the Python version

Positioned against what this curriculum already taught

Netmiko (Phase 2.7)vendor-specific CLI, one device at a time
Nornir (Phase 3.4)orchestration -- many devices, concurrently, still vendor-specific commands
NAPALM (this module)vendor-neutral state -- one API, normalized results

Not re-taught here

ConnectHandler, send_command, and Netmiko's exceptions (Phase 2.7) are not repeated in this module — only referenced as the vendor-specific-CLI contrast NAPALM's getters replace. InitNornir(), nr.run(), filtering, and Nornir's concurrency (Phase 3.4) are not repeated either. This module teaches NAPALM alone.

Quick checkMyth check

Is NAPALM a replacement for Nornir?

Yes — NAPALM makes Nornir unnecessaryNo — they solve different problems on different axes: Nornir orchestrates how many devices run a task and when; NAPALM normalizes what a device's state looks like once you're talking to it. A later module (Multi-vendor Automation) combines them through nornir_napalm, but that integration is explicitly not covered hereYes, but only for Cisco devicesNo, because NAPALM cannot connect to devices at all

Quick checkPredict output

A get_interfaces() call against a Cisco IOS device and the same call against a Juniper device (hypothetically, if both were real and reachable) return results with:

Completely different key names, since each vendor formats things differentlyThe same dict shape and key names (is_up, is_enabled, description, mtu, speed, mac_address) — that normalization is NAPALM's entire purposeOnly Cisco devices are supported, so the Juniper call would always failRaw, unparsed CLI text identical to what show interfaces would print

Key takeaways

NAPALM answers a different question than Netmiko or Nornir: not how do I execute, but how do I read/change state through one normalized API across vendors.
The concrete problem: the same conceptual show interfaces means three different commands and three different text formats across Cisco, Juniper, and Arista -- NAPALM's get_interfaces() returns one consistent shape instead.
Netmiko and Nornir are not re-taught in this module -- only referenced as the vendor-specific-CLI baseline NAPALM's getters replace.
nornir_napalm (combining Nornir's orchestration with NAPALM's normalization) is explicitly out of scope here -- it belongs to Multi-vendor Automation, the next planned module.

Done with this lesson?

Next lesson

Drivers and Connecting: get_network_driver()

Ready to practice?

Explore hands-on exercises and assessments for this module

Practice this module