Live multivendor containerlab fabric

NAPALM Live Lab

Senior network engineering — AI-native network operations tooling.

A Flask dashboard that runs a live multivendor CLOS-EVPN fabric — Arista cEOS, Nokia SR Linux, and FRRouting — and shows the honest truth about NAPALM's multivendor promise, node by node and getter by getter. Plus a secure Command Console running 2,361 curated operational commands against real lab gear.

19
multivendor nodes
2,361
curated commands
3
vendor stacks
76
hermetic tests
Why this exists

NAPALM promises one API for every vendor.
This lab shows where that promise frays.

NAPALM's pitch is a single Python API that talks to any vendor — call get_bgp_neighbors() and you get the same normalized data structure whether the box runs Arista EOS, Cisco IOS-XR, or Juniper Junos. It's a genuinely good abstraction, and for the vendors with first-class drivers it largely delivers. But the moment you build a real multivendor fabric, the promise frays in ways the marketing never mentions — and the gaps are exactly where you find out the hard way, usually mid-automation, against production.

This lab makes those gaps visible and reproducible instead of surprising. It runs a live multivendor CLOS-EVPN fabric (3 spine + 6 leaf, mixing Arista cEOS, Nokia SR Linux, and FRRouting) plus a 10-router 3-Tier FRR network, and shows you — node by node, getter by getter — what NAPALM actually returns versus what it claims to.

First-class

cEOS — Arista

The eos driver ships in core NAPALM and talks eAPI over HTTPS. The standard getters work. This is what "NAPALM works" looks like.

Community

SR Linux — Nokia

No core driver — coverage comes from the separate napalm-srl package over JSON-RPC. Real, but a different package on a different cadence, with coverage not 1:1 with EOS. Labeled as community-sourced, not pretended equal.

No driver

FRR — FRRouting

No NAPALM driver exists. The lab doesn't fake one — FRR is collected via docker exec … vtysh -c "<cmd> json", mapped into NAPALM-shaped dicts and tagged method: exec, napalm_supported: false. You see the seam.

🍎 The macOS-can't-route-to-containers problem — solved by a sidecar

On Docker Desktop for Mac, the host has no route to container management IPs — you can't open an eAPI/JSON-RPC session from your laptop to 172.20.20.x the way native Linux Docker allows. NAPALM needs that L3 reachability, so on a Mac it simply can't connect. The fix is a sidecar pattern: a napalm-runner container attached to the lab's management networks runs the real NAPALM drivers from inside the fabric, and the host dispatches collection to it over docker exec (argv list, never a shell). Because every collection path — runner for eos/srl, vtysh for FRR — is docker exec-based, the exact same code runs identically on macOS and Linux. No VPN, no route add, no host-networking hacks, no "works on my Linux box" caveat.

Who it's for

Built for engineers who need the truth before they commit code.

📚

Network engineers learning NAPALM

Run real getters against real (containerized) multivendor devices instead of reading driver docs and guessing what the output looks like.

🧭

Architects evaluating NAPALM's coverage

Decide whether NAPALM can underpin an automation platform across an Arista/Nokia/FRR estate — with the coverage matrix before writing thousands of lines against an abstraction that's thinner than advertised on half the fleet.

🛠️

Automation developers doing lab-driven dev

A reproducible, disposable fabric to write and test collection/audit code against — known topology, known BGP/EVPN state, zero risk to production.

🎯

Job seekers building a portfolio

A demonstrable running artifact: a live multivendor fabric, a real NAPALM coverage matrix, and a security-conscious command console — concrete evidence of containerlab fluency, not a slide deck.

What you get

Honest engineering, end to end.

Every benefit below is computed from real collection against a live fabric — no marketing-grade "supports all vendors."

🧮

Honest coverage matrix

Per-node, per-getter pass/fail computed from real collection — napalm_native vs exec_fallback vs unreachable, broken out by driver. You see exactly where the abstraction holds and where it doesn't.

napalm_nativeexec_fallbackper-getter
⌨️

Command Console — 2,361 commands

A curated catalog of 2,361 single-line multivendor commands, executed live against lab nodes with the right CLI wrapper per vendor: Cli for cEOS, vtysh for FRR, sr_cli for SR Linux.

Clisr_clivtysh2,361 cmds
🌐

Multivendor topology

Arista cEOS, Nokia SR Linux, and FRRouting in one CLOS-EVPN fabric plus a 10-router 3-Tier network. True multivendor, not single-vendor cosplay — the mix is where tooling actually breaks.

cEOSSR LinuxFRRCLOS-EVPN
🚀

Real NAPALM via sidecar

A napalm-runner container runs the real drivers from inside the fabric, dispatched over docker exec. Sidesteps the Docker-Desktop routing wall — identical behavior on macOS and Linux.

docker execrunner sidecarmac = linux
🔒

Secure read-only console

Hostnames validated against a fabric allowlist; commands run as an argv list (no shell, no injection); a read-only guard permits only show/display/get/ping-class verbs; newlines and control chars rejected.

allowlistargv-onlyread-only guard
🧪

76 hermetic tests

A fixed containerlab topology with known state means repeatable results run-to-run. 76 hermetic pytest tests cover the collection backend, the security guard, and the catalog loader.

pytesthermeticall passing
The coverage matrix

Three vendors. Three tiers of truth.

No papered-over seams. Each vendor is collected the way it actually has to be, and labeled honestly in the UI.

Vendor / NOS NAPALM tier Transport / method What you get
Arista cEOS Full eos driver · eAPI / HTTPS Core NAPALM driver. Standard getters work. Falls back to Cli -c "show version | json" if eAPI is down.
Nokia SR Linux Partial napalm-srl · JSON-RPC Community package, separate maintenance cadence. Getter coverage not 1:1 with EOS. Labeled community-sourced — not pretended equal.
FRRouting Exec fallback vtysh -c "… json" No NAPALM driver. Collected via vtysh, mapped into NAPALM-shaped dicts. Tagged napalm_supported:false; LLDP / environment marked unsupported with reason.

Cross-vendor command cheat-sheet

Same intent, different CLI. SR Linux has no show running-config — it uses info. A Cisco/Arista command on an SRL node returns an honest device parse error, not a tool bug.

TaskArista cEOSFRR (vtysh)Nokia SR Linux
Running configshow running-configshow running-configinfo from running
BGP summaryshow ip bgp summaryshow ip bgp summaryshow network-instance default protocols bgp neighbor
Routing tableshow ip routeshow ip routeshow …default route-table ipv4-unicast summary
Live stateshow …show …info from state …
The elevator pitch

NAPALM Live Lab is a Flask dashboard that runs a live, multivendor containerlab fabric — Arista cEOS, Nokia SR Linux, and FRRouting across a 9-node CLOS-EVPN spine/leaf plus a 10-router 3-Tier network — and shows you the truth about NAPALM's multivendor promise: full coverage on cEOS, partial community coverage on SR Linux, and no driver at all on FRR (collected honestly via vtysh and labeled as such). Real NAPALM runs inside a sidecar container so the whole thing behaves identically on a macOS laptop and on Linux, with no host-to-container routing hacks. On top of the live coverage matrix it adds a Command Console that runs 2,000+ curated multivendor operational commands behind a read-only, allowlist-guarded, shell-injection-proof execution layer — so you can learn NAPALM, evaluate its real multivendor coverage, and develop lab-driven automation against true multivendor gear without a single piece of physical hardware.