Building a Vendor-Agnostic E2E Testing Ecosystem with Netlab#

Leandro Lerena & Andy Griesbeck - Zebbra AG

• Why: "Automation fails in surprising ways the moment it hits production" — this is one of the more rigorous public answers: make network automation testable like software, with real CI-runnable tests against virtual topologies.
• What: Two coupled contributions. (1) A transactional workflow model: workflows move through NEW → VALID → SCHEDULED → LOCKING → RUNNING → COMPLETED / FAILED_SAFE / FAILED_UNSAFE, with a locking phase that derives and exclusively locks context to prevent the race conditions that silently drop concurrent config changes (their interleaving example shows actor A's port change lost under non-atomic updates). Function blocks are marked pure / idempotent / rollback-aware, letting the orchestrator retry safely and distinguish clean failures from ones needing manual review. (2) A Remote Lab service: a FastAPI orchestrator that provisions netlab/Containerlab topologies on the fly; pytest decorators (@fb_test_case, @fb_test_case_with_lab) make a full virtual fixture (Cisco IOL, Nokia SR Linux, FRR) one line of test code. Vendor-agnosticism comes from a capability-contract pattern — one AdminStateCapability interface, per-vendor plugins (Scrapli for IOL, Netmiko for SR Linux), zero vendor logic in the function block. Developer preview at github.com/zebbra/neops-remote-lab.
• How: Typed function-block SDK + capability interfaces + pytest fixtures wrapping netlab topology.yaml; teardown guarantees zero residual state so CI and multiple engineers can share one lab.
• Where applicable: Any team doing network automation with virtualizable platforms. Coverage is bounded by which vendors have plugins (IOL, SR Linux, FRR shown); the transactional model itself is stack-independent.