Advanced
Multi-vendor Automation
Nornir orchestration + NAPALM normalized state, combined through nornir_napalm -- one workflow running unmodified across a mixed-vendor fleet, with driver selection resolved automatically from inventory.
Nornir and NAPALM each solve half of a real problem on their own; this module closes the gap between them with nornir_napalm. You'll see exactly how a host's platform field in Nornir inventory becomes the correct NAPALM driver automatically, with no if/elif dispatch code written by hand, then run normalized getters across a genuinely mixed-vendor fleet and handle the fact that NAPALM's exception normalization isn't perfectly uniform across vendors -- IOS, EOS, and Junos fail differently against the same scenario. You'll also compose napalm_configure from primitives already built in NAPALM for Network Engineers.
Next up
Why Multi-vendor Automation Is Hard, and How nornir_napalm Closes the Gap
0 / 5 completeLessons
- 1
Why Multi-vendor Automation Is Hard, and How nornir_napalm Closes the Gap
What's still missing after Nornir and NAPALM individually -- and how nornir_napalm, a real, thin, seven-task plugin, connects Nornir's orchestration to NAPALM's normalized state without inventing a new framework.
Advanced12 min readNext up - 2
Driver Selection from Inventory: platform and nornir_napalm's Connection Plugin
The module's single most important mechanism, verified directly from source: how a host's platform field in Nornir inventory becomes the exact NAPALM driver that connects to it -- no if/elif, no dispatch code, written by hand.
Advanced13 min read - 3
Running Normalized Getters Across a Mixed Fleet with napalm_get
One nr.run(task=napalm_get, ...) call, executed for real against a 4-host mixed-vendor-shaped inventory -- three succeeding with genuinely different vendor-flavored data, one failing -- with napalm_get's real, batched result structure verified directly.
Advanced14 min read - 4
Per-Device Failure Handling and a Composed Config Workflow
Real, verified proof that NAPALM's exception normalization is not perfectly uniform across vendors -- IOS, EOS, and Junos fail differently against the same unreachable-address scenario -- plus napalm_configure, verified as a genuine composition of Phase 3.5's own candidate-config primitives.
Advanced15 min read - 5
Capstone: One Workflow, Three Vendors
Every piece of this module -- driver selection from inventory, batched normalized getters, and per-device failure isolation -- combined into one real, runnable compliance check that treats a Cisco-like, an Arista-like, and a Juniper-like host with the exact same validation code.
Advanced17 min read
Practice this module
Apply what you just covered -- hands-on practice and a knowledge check for this module.