Home
Important
This wiki is a living document. The repository it covers is under active development. New labs, new automation capabilities, and new architectural patterns are added regularly. Pull (git pull) the latest changes before starting any lab session.
This is not a collection of throwaway demo topologies. It is a growing engineering platform built for network engineers who want their labs to do real work — to expose failure modes, validate architectural assumptions, and build the kind of operational intuition that only comes from deliberately breaking things and understanding what happened.
At its core, the repository brings together three disciplines that serious network teams practice together but that most lab repositories treat as separate concerns: topology design, configuration management, and validation automation. The topology files declare what the network looks like. The configuration files declare what the network should do. The automation framework validates whether what it actually does matches what you intended — and tells you when it has drifted away from that intent.
The repositories spans multiple architectural families. Data center Clos fabrics with EVPN-VXLAN are well-represented, including both single-DC and multi-DC patterns with data center interconnect. Service provider and transport scenarios built on Nokia SR OS are also present, covering Segment Routing, MPLS, CsC hierarchies, and multi-AS service models. More families are on the way.
Everything runs on Containerlab, which means the entire stack is declarative, repeatable, and destroyable with a single command. Containerlab sits on top of Docker (or a Docker-compatible container runtime), and together they turn what would otherwise require a rack of physical equipment into a laptop-deployable engineering environment.
| Family | Lab Name | Architecture | Vendor / NOS | Status |
|---|---|---|---|---|
| Data Center | ceos-4s4l |
Single-DC, 4-spine/4-leaf Clos, EVPN-VXLAN | Arista cEOS | Stable, fully automated |
| Data Center + DCI | ceos-2dc-4s4l |
Two-DC, EVPN-VXLAN per DC, EVPN-MPLS DCI | Arista cEOS | Stable, fully automated |
| Service Provider | nokia-sr-mpls |
34-node multi-AS, SR-MPLS, CsC, L2/L3 overlay | Nokia SR OS (Simulator) | In Progress, heavy |
More labs are planned and will follow the same directory and automation pattern as the existing ones, making them easy to discover and consistent to operate.
If you are new to this repository, the dependency chain is short but important. You cannot run a lab without a working container runtime, and you cannot benefit from the automation without a Python environment set up against the netlab-automation package. The path below will get you to a running lab from a standing start.
If you are brand new to Containerlab and Docker:
- Read Start Here to understand what this repository is, what it depends on, and what it will and will not provide for you.
- Work through Installation and Environment Setup to install Docker (or OrbStack on macOS), Containerlab, and the Python toolchain.
- Follow Quick Start to deploy
ceos-4s4l, run a validation, create a baseline, and introduce your first intentional change.
If you are already comfortable with Containerlab:
- Check Repository Concepts to understand how this project is organized and what the separation between topology, config, intent, and automation means in practice.
- Browse the Lab Catalog to choose a topology that matches your learning goals.
- Go directly to the deep lab chapter for the topology you care about.
These are not rigid tracks. They are suggested starting points based on what you are trying to learn or build.
Data Center and EVPN fundamentals. Start with ceos-4s4l. It is the most compact and most thoroughly automated lab in the repository. A single-DC four-spine / four-leaf Clos fabric gives you enough complexity to practice real EVPN behavior — underlay BGP, VTEP peering, L2 stretch, L3 gateway, dual-homed hosts using LACP — without the cognitive load of a multi-site topology. When the single-DC model feels solid, move to ceos-2dc-4s4l to explore the DCI design and how inter-DC service transport works.
Service provider and transport. The nokia-sr-mpls lab is built around Nokia SR OS. It is a 34-device, multi-AS, multi-layer topology that includes Segment Routing, Carrier-Supporting-Carrier (CsC) models, and L2/L3 service overlays. This lab is heavy by design — Nokia SR Simulator nodes consume real memory, and the topology reflects real-world service provider complexity. Read the resource requirements carefully before deploying.
Automation and validation. If your primary interest is the Python automation framework rather than a specific topology, start with Repository Concepts and then read the full Automation Framework chapter. The netlab CLI, the intent-driven check system, and the baseline/drift workflow are all documented there. The ceos-4s4l lab provides the richest set of validation checks and is the best way to see the automation system working end-to-end.
Note
It's important to note that the automation framework described throughout this documentation—including the netlab CLI, intent files, validation modes, baseline/drift workflows, and the current adapter/evidence architecture—will soon be completely revamped and replaced by a significantly more comprehensive automation platform. The next-generation framework will introduce extensive telemetry and observability capabilities, including real-time metric collection, distributed tracing, and rich visualization dashboards. It will feature intelligent autoremediation workflows that can detect, diagnose, and resolve common network issues autonomously, along with sophisticated safety checks and guardrails to prevent dangerous operations in production-like environments.
This new system will support a much broader range of network operating systems, transport protocols, and service models, with pluggable collectors, enriched state correlation, and event-driven automation patterns. Once this transition occurs, the current automation/ directory structure and CLI interfaces will be deprecated, and this wiki will be completely restructured to reflect the new architecture, capabilities, and operational model. Users should expect breaking changes and should plan to migrate their intent files and validation workflows to the new framework when it becomes available.
Operations and failure drills. Every Arista lab comes with both a Python automation suite and a set of shell scripts for targeted validation. The Failure Drills sections in the lab chapters describe failure scenarios that are specifically designed to expose the operating model, convergence behavior, and correctness properties of the topology under stress.
This repository is under continuous development. Labs are updated, extended, and occasionally restructured as the design evolves. The automation framework is expanding to support additional check kinds, broader evidence collection, and better reporting.
Key things to know:
- The
nokia-sr-mplslab is work in progress. The topology is defined and the configuration is partially developed, but full validation coverage via thenetlabautomation framework has not yet been implemented for Nokia SR OS. - Config drift comparison can produce noise in some scenarios due to text canonicalization differences between the repo copy of a config and the device's running representation. This is a known limitation documented in the Automation Framework chapter.
- Pull frequently.
git pullbefore any lab session is strongly recommended.
Tip
As this project evolves, new labs will be added in different "t-shirt sizes" (small, medium, large, extra-large) to accommodate a wide range of compute resource specifications—from lightweight setups suitable for laptops with limited RAM to heavy, production-scale topologies that require dedicated lab servers. These upcoming labs will expand vendor coverage to include Cisco IOS XE, IOS XR, and NX-OS; Juniper Junos and vMX/vQFX; Nokia SR Linux; and other platforms.
They will also explore diverse architectures and technologies beyond data center EVPN/VXLAN, such as campus and branch designs, WAN edge and SD-WAN scenarios, service provider MPLS and segment routing topologies, multi-vendor interoperability labs, IPv6-only or dual-stack environments, and emerging paradigms like application-aware networking and intent-based systems. This will ensure that users with varying hardware constraints, vendor preferences, and learning objectives can find a lab that fits their needs and interests.
| Section | Description |
|---|---|
| Home | This page — project overview and navigation |
| Start Here | What the project is, what it needs, who it is for |
| Installation and Environment Setup | Full stack setup from zero: Docker, Containerlab, Python |
| Quick Start | Fastest path to a running lab and first validation |
| Repository Concepts | How the repo is organized and how to think about it |
| Automation Framework | Deep guide to netlab validation, baselines, and drift |
| Lab Catalog | Overview of all labs with difficulty, scale, and status |
| Lab — ceos-4s4l | Single-DC Clos + EVPN-VXLAN deep dive |
| Lab — ceos-2dc-4s4l | Two-DC EVPN fabric + DCI deep dive |
| Lab — nokia-sr-mpls | Multi-AS SR/MPLS service provider lab |
| How-To Guides | Task-oriented procedures for common operations |
| Reference | Commands, check kinds, intent schema, glossary |
| Troubleshooting | Diagnosis guide for common problems |
| Roadmap and Changelog | Where the project is going and what has changed |