Lab Environments Part 5: Container-Native - containerlab and netlab

Part 4 closed out the GUI-topology tools. This part is a different paradigm entirely: no drag-and-drop canvas, topology described as a YAML file, and network operating systems running as containers instead of full VMs. It’s the third answer named in Part 1, something that behaves like the network for testing automation, and it maps directly onto ground this site has already covered: the OSPF on Linux and Container Networking series both built topologies from network namespaces, veth pairs, and bridges rather than a GUI, for the same reason this category exists: the primitives were the point, not the polish.

containerlab.

Declarative YAML topology, one command to bring it up, one to tear it down. First reviewed as a promising newcomer back in 2021, and five years on it’s matured into a genuinely polished platform: as of a March 2026 review of v0.73, it supports rootless operation, has a full VS Code extension with a graphical topology editor on top of the YAML, integrated packet capture, multiple graph export formats, and officially supports macOS (both Apple Silicon and Intel) and Windows via WSL2, not just Linux. It runs real containerized network OSes rather than approximations: Arista cEOS, Nokia SR Linux, FRR, Cumulus/NVIDIA Linux, and Cisco’s own containerized images where Cisco ships them. It’s become the default lab engine for NetDevOps-oriented teams and SONiC developers specifically, because topology-as-code fits into a CI pipeline in a way a GUI canvas never will, spin up, run a test suite against it, tear it down, repeat on every commit.

netlab.

Built by ipSpace.net (formerly published under the name netsim-tools), netlab sits a layer above containerlab, libvirt, and Docker rather than competing with them directly. It describes topology, IP addressing, and routing design, OSPFv2, OSPFv3, EIGRP, IS-IS, BGP, MPLS/VPN, EVPN, in one YAML file, then generates and deploys the initial device configuration across whichever of its three backing providers (VirtualBox, libvirt/KVM, or Docker) is pointed at. The device list is genuinely broad: Arista EOS, Cisco IOS, IOS XE, and NX-OS, Cumulus Linux, Dell OS10, Fortinet, FRRouting, Junos, Mikrotik, Nokia SR OS. It’s backed by an actual automated test suite, over a hundred integration tests covering initial configs, BGP, DHCP, IS-IS, OSPFv2, OSPFv3, VLANs, VRFs, and VXLAN as of mid-2024, which is a meaningfully different level of rigor than “it worked on my laptop.”

Where this trades against Part 3.

containerlab and netlab give up the polished drag-and-drop canvas of EVE-NG or GNS3 in exchange for a topology that lives in git, diffs cleanly in a pull request, and rebuilds itself in a CI job without a human clicking anything. That’s the same tradeoff the Container Networking series made deliberately when it built topologies with ip netns and iptables instead of a GUI: useful when the actual target under test is your own automation or tooling, the wrong fit when the goal is exam-style CLI practice or a topology you want to see and click through. It’s also worth noting plainly that not every device exists as a container image the way it exists as a full VM appliance, FortiGate-VM and ASAv, for instance, don’t have containerized equivalents, so this category doesn’t replace Part 3 so much as sit alongside it for a different job.

Part 6 closes the series: renting the compute layer from Part 2 instead of owning it, a comparison table across all five categories, and a decision framework to actually pick one.