Lab Environments Part 1: Why Lab, and How to Choose

Most of the lab work referenced on this site has been documented from real infrastructure: a Proxmox host (pve) running VLANs and VMs for the Sn1per and BloodHound series, a dedicated FortiManager lab built on that same Proxmox box, OSPF running across a mix of Cisco IOS-XE, FortiOS, Junos, and a Linux router with FRR. None of that happened because Proxmox is the only option. It happened because it was the right fit for what those series needed, and each of the others would have been the wrong fit for different reasons.

That’s the actual starting point for choosing a lab environment: not “which tool is best,” but “what do I need this lab to be.” Three honest answers cover most cases.

A real vendor OS, running for real. If the point of the lab is passing an exam that tests exact CLI behavior, or validating a config before it goes into a production FortiGate or IOS-XE box, a simulation that’s merely close is worse than useless, it teaches wrong muscle memory. This is what the network emulation platforms in Part 3 and the vendor-official platforms in Part 4 are for.

A close-enough simulation of topology and protocol behavior. Teaching someone how OSPF DR/BDR election works, or how a routing table gets built, doesn’t require the exact CLI of a real FortiGate. It requires the behavior to be right. This is a legitimate, cheaper answer for teaching and for quick sanity checks, and it’s exactly where a tool like Packet Tracer earns its keep instead of being a lesser EVE-NG.

Something that behaves like the network, for testing your own code. If what you’re actually validating is a Python script, an Ansible playbook, or a CI pipeline, the network itself doesn’t need to be real hardware or even a full VM. It needs to expose the same interfaces and protocol behavior your automation talks to. This is the container-native territory in Part 5, and it’s the same reasoning behind why the Container Networking series built topologies from ip netns and iptables instead of a GUI: the primitives were the point, not the polish.

The real bottleneck is rarely the platform.

Every emulator in this series is inert without vendor images: IOSv, vIOS, ASAv, FortiGate-VM, vJunos. Cisco, Fortinet, and Juniper all gate those behind a support contract, a CCO account, or an NFR agreement, not behind a download button. Budgeting for a lab should start with “which images can I actually get hold of,” because that answer constrains everything else more than the platform choice does.

Licensing in this space has moved a lot in the last two years, and none of it in a stable direction.

EVE-NG’s free Community Edition, the 63-node build most existing guides still point to, reached end-of-support and end-of-life in June 2026 and was not carried into version 7. The free path in v7 is now a “Freemium” mode capped at 7 nodes; the paid Professional tier runs 150 EUR, up to 1024 nodes, tied to a single VM or machine. Cisco Modeling Labs sits in a different place: CML-Free now permits 5 nodes with no time limit at all (a real permanent tier, not a trial), Personal is $199/year for 20 nodes, Personal Plus is $349/year for 40, the only difference between those two being node count. VMware Workstation Pro has gone the other way entirely, it’s been fully free for personal, educational, and commercial use since March 2025, though Broadcom now requires an account to download it at all. Standalone ESXi has flipped twice: discontinued as a free hypervisor in February 2024, reinstated in April 2025, still free as of this writing. Check current terms before planning a lab budget around any single one of these. They’ve all changed since the last time most write-ups were published.

The taxonomy for the rest of this series.

Five categories, each doing a genuinely different job:

Hypervisor foundations (Part 2) — Proxmox, ESXi, VMware Workstation/Fusion. The compute layer most of the rest of this list runs as a guest on top of.

Network emulation platforms (Part 3) — EVE-NG, GNS3, pnetlab. Real vendor images, wired into a topology, running under a hypervisor.

Vendor-official all-in-one (Part 4) — Cisco Modeling Labs and Packet Tracer. Single-vendor, but the image licensing question is answered for you.

Container-native (Part 5) — containerlab and netlab. Topology as YAML, network OSes as containers, built for automation testing rather than a topology canvas.

Cloud-hosted (Part 6) — renting the compute instead of owning it, plus vendor-hosted sandboxes.

This series stays at the overview level on purpose. The next full deep dive picks up Proxmox specifically, building on the same pve host and vmbr-bridge pattern already used for the FortiManager lab, the Sn1per re-verification work, and the BloodHound graph testing, because that’s the platform already proven out on real infrastructure rather than the one that merely looks best in a comparison table.