GNS3 vs EVE-NG vs Containerlab: Best Self-Hosted Network Simulation Tools 2026

Why Self-Host Your Network Lab?

Network engineers, students preparing for certifications, and DevOps teams building infrastructure need reliable environments to test topologies, validate configurations, and prototype architectures before touching production hardware. Commercial network simulation platforms like Cisco Packet Tracer or proprietary cloud-based labs come with limitations — restricted device support, session timeouts, and recurring subscription costs.

Running a self-hosted network simulation environment gives you full control over the lab lifecycle. You can run unlimited topologies, save snapshots for rollback, integrate real virtual machines and containers alongside emulated routers, and access the lab from any machine on your network. Whether you’re studying for CCNA/CCNP certifications, testing SD-WAN deployments, or validating container networking before a production rollout, a self-hosted lab is an essential piece of infrastructure.

Three tools dominate the self-hosted network simulation space: GNS3, EVE-NG, and Containerlab. Each takes a fundamentally different approach to network emulation, and choosing the right one depends on your use case, hardware, and the types of devices you need to simulate.

GNS3: The Veteran Network Emulator

GNS3 (Graphical Network Simulator-3) is the most widely known open-source network emulation platform. Originally released in 2008, it has grown into a mature ecosystem with over 2,500 stars on its GUI repository and 988 stars on the server component (last updated April 2026).

GNS3 uses Dynamips for Cisco IOS emulation, QEMU/KVM for full virtual machine support, and docker for container-based nodes. Its graphical desktop client provides a drag-and-drop canvas where you connect virtual routers, switches, firewalls, and PCs with virtual wires.

Architecture

GNS3 follows a client-server model. The GNS3 server runs on your lab host (or a remote machine), and the GNS3 GUI connects to it locally or over the network. This means you can run heavy topologies on a powerful server while controlling everything from a lightweight laptop.

Key Features

• Broad device support: Cisco IOS (via Dynamips), any QEMU-compatible VM (Juniper vSRX, Palo Alto, FortiGate), Docker containers, VirtualBox VMs, and VPCS (simple PC simulator)
• Graphical topology editor: Drag-and-drop interface with real-time packet capture on any link
• Cloud integration: Bridge lab networks to your physical LAN for testing real-world connectivity
• Snapshot and export: Save complete lab states, export topologies as .gns3 files for sharing
• Built-in tools: Wireshark integration, console access to all nodes, built-in terminal

Installation (Server on Ubuntu/Debian)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Install dependencies
sudo apt update
sudo apt install -y python3-pip python3-pyqt5 docker.io qemu-kvm libvirt-daemon-system

# Start and enable services
sudo systemctl enable --now docker
sudo systemctl enable --now libvirtd

# Install GNS3 server
pip3 install gns3-server

# Run the server
gns3server --host 0.0.0.0 --port 3080

Docker Compose Setup

GNS3 can be run via Docker, though the server container still needs access to QEMU and KVM on the host:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

version: "3.8"

services:
  gns3-server:
    image: gns3/gns3-server:latest
    container_name: gns3-server
    restart: unless-stopped
    privileged: true
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./gns3-images:/opt/gns3/images
      - ./gns3-projects:/opt/gns3/projects
      - /dev/kvm:/dev/kvm
    environment:
      - GNS3_SERVER_HOST=0.0.0.0
      - GNS3_SERVER_PORT=3080

The GNS3 GUI client runs natively on your desktop (Linux, Windows, or macOS) and connects to the server URL.

EVE-NG: The Web-Based Network Lab Platform

EVE-NG (Emulated Virtual Environment — Next Generation) is a commercial platform with a free Community Edition. Unlike GNS3, it provides a purely web-based interface — no desktop client required. You access the lab through any browser, making it ideal for multi-user training environments.

The Community Edition supports a wide range of network device images (Cisco, Juniper, Arista, Fortinet) loaded as QEMU VMs. The Professional Edition adds features like multi-user collaborative labs, external authentication, and priority support.

Architecture

EVE-NG runs as a complete Ubuntu-based virtual appliance. It uses QEMU/KVM under the hood for device emulation and provides an HTML5 web interface for topology design. All labs are accessed through the browser, including console sessions via HTML5 terminal (no separate client needed).

Key Features

• Browser-based access: Full lab management from any device with a web browser
• Multi-user support: Multiple students can work on separate labs simultaneously (Pro Edition)
• Wide image compatibility: Load any QEMU-compatible image — Cisco IOS-XR, NX-OS, ASAv, Juniper vMX/vSRX, Arista vEOS, Linux VMs
• Integrated Wireshark: Capture traffic on any link and open directly in Wireshark
• Lab scheduling: Set labs to auto-start and auto-shutdown on a schedule (Pro Edition)
• Cloned topologies: Template-based lab creation for training environments

Installation (Community Edition)

EVE-NG is distributed as an Ubuntu-based OVA/ISO that you install on bare metal or in a VM:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Download the Community Edition ISO from eve-ng.net
# Install on a VM with at least:
#   - 4 vCPUs, 8 GB RAM (16+ GB recommended)
#   - 80 GB disk (SSD strongly recommended)
#   - Bridged network adapter

# After installation, access the web interface:
# http://<eve-ng-ip>/

# Default credentials (change immediately!):
#   Admin / eve

For Docker enthusiasts, EVE-NG itself isn’t distributed as a container — it runs as a full OS appliance. However, you can deploy it on a KVM host managed by the same machine running your other self-hosted services:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Create a VM for EVE-NG using virt-install
virt-install \
  --name eve-ng \
  --ram 8192 \
  --vcpus 4 \
  --disk path=/var/lib/libvirt/images/eve-ng.qcow2,size=80,format=qcow2 \
  --network bridge=virbr0 \
  --cdrom /path/to/UNetLab-2.0.3-85-community.iso \
  --os-type linux \
  --os-variant ubuntu22.04 \
  --graphics vnc,listen=0.0.0.0 \
  --noautoconsole

Containerlab: The Modern Container-Native Approach

Containerlab is the newest entrant in the network simulation space, created by Nokia’s networking team and rapidly gaining adoption with over 2,500 stars on GitHub (last updated April 2026). Written in Go, it takes a fundamentally different approach: instead of emulating traditional routers with QEMU, it runs network operating systems as Docker containers.

This container-native approach means labs spin up in seconds rather than minutes, consume far less RAM, and integrate naturally with CI/CD pipelines. Containerlab uses a YAML-based topology definition, making labs version-controllable and automatable.

Architecture

Containerlab runs as a single binary on Linux. It manages Docker containers, Linux network namespaces, and virtual ethernet pairs to create network topologies defined in YAML. Each node in your lab is a Docker container running a containerized NOS (Network Operating System) like Nokia SR Linux, Arista cEOS, or Cisco XRd.

Key Features

• YAML topology files: Define entire labs in code — version control, share, and reproduce with git
• Lightweight: Container-based nodes use megabytes of RAM instead of gigabytes
• Fast startup: Labs deploy in seconds, not minutes
• CI/CD integration: Run network tests as part of your pipeline (GitHub Actions, GitLab CI)
• Extensible kind system: Supports Nokia SR Linux, Arista cEOS, Cisco XRd, FRR, OpenBSD, Linux bridges, and custom Docker images
• Automatic cleanup: containerlab destroy removes all nodes, links, and configs in one command
• Built-in topology visualization: containerlab inspect shows live topology with node states

Installation

1
2
3
4
5

# Install Containerlab (single command)
bash -c "$(curl -sL https://get.containerlab.dev)"

# Verify installation
sudo containerlab version

Docker Compose + Containerlab Workflow

While Containerlab itself isn’t a Docker Compose service, you can manage your lab infrastructure alongside other services. Here’s a typical setup where Containerlab runs on a dedicated lab host:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

# Define your topology in lab.yaml
cat > lab.yaml << 'YAML'
name: spine-leaf

topology:
  nodes:
    spine1:
      kind: nokia_srlinux
      type: ixrd2l
    spine2:
      kind: nokia_srlinux
      type: ixrd2l
    leaf1:
      kind: nokia_srlinux
      type: ixrd2l
    leaf2:
      kind: nokia_srlinux
      type: ixrd2l
    client1:
      kind: linux
      image: ghcr.io/hellt/network-multitool
    client2:
      kind: linux
      image: ghcr.io/hellt/network-multitool

  links:
    - endpoints: ["spine1:e1-1", "leaf1:e1-1"]
    - endpoints: ["spine1:e1-2", "leaf2:e1-1"]
    - endpoints: ["spine2:e1-1", "leaf1:e1-2"]
    - endpoints: ["spine2:e1-2", "leaf2:e1-2"]
    - endpoints: ["leaf1:e1-3", "client1:eth1"]
    - endpoints: ["leaf2:e1-3", "client2:eth1"]
YAML

# Deploy the lab
sudo containerlab deploy -t lab.yaml

# Inspect the topology
sudo containerlab inspect

# Access a node's CLI
sudo docker exec -it clab-spine-leaf-spine1 sr_cli

# Destroy when done
sudo containerlab destroy -t lab.yaml --cleanup

FRRouting Example with Containerlab

For labs using open-source routing protocols, FRR (Free Range Routing) works perfectly as a container kind:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

name: bgp-lab

topology:
  nodes:
    r1:
      kind: linux
      image: frrouting/frr:v9.0.2
      binds:
        - r1/frr.conf:/etc/frr/frr.conf
    r2:
      kind: linux
      image: frrouting/frr:v9.0.2
      binds:
        - r2/frr.conf:/etc/frr/frr.conf

  links:
    - endpoints: ["r1:eth1", "r2:eth1"]

1
2
3
4

sudo containerlab deploy -t bgp-lab.yaml

# Shell into router r1
sudo docker exec -it clab-bgp-lab-r1 vtysh

Feature Comparison

How to Choose

Choose GNS3 if:

• You’re studying for Cisco or multi-vendor certifications and need to run real IOS images
• You prefer a graphical drag-and-drop interface
• You need to simulate legacy hardware or use proprietary vendor images
• You want the largest community and most tutorials available online

Choose EVE-NG if:

• You run a training lab or classroom with multiple concurrent students
• You want browser-only access from any device
• You need the broadest possible device image compatibility
• You’re willing to pay for the Pro Edition’s multi-user features

Choose Containerlab if:

• You’re a DevOps engineer testing container networking or SDN topologies
• You want labs defined as code, version-controlled in Git
• You need fast spin-up/tear-down for CI/CD pipelines
• You’re working with containerized NOS platforms (SR Linux, cEOS, XRd)
• Resource efficiency matters — you want to run larger topologies on the same hardware

For most certification students, GNS3 remains the go-to choice due to its extensive documentation and community support. For network automation engineers and DevOps teams, Containerlab’s YAML-based, Git-friendly workflow is a game-changer. And for training organizations managing multiple students, EVE-NG’s web-based multi-user environment is unmatched.

FAQ

Can I run GNS3, EVE-NG, and Containerlab on the same machine?

Yes, but resource contention is a concern. GNS3 and EVE-NG both use QEMU/KVM, while Containerlab uses Docker. If you have 32+ GB of RAM, a modern CPU with virtualization support, and fast NVMe storage, you can run all three. Use GNS3 or EVE-NG for heavy VM-based labs and Containerlab for lightweight container networking tests.

What are the minimum hardware requirements for a self-hosted network lab?

For small topologies (3-5 nodes): 8 GB RAM, 4 CPU cores, and 50 GB storage. For medium labs (10-20 nodes): 16-32 GB RAM, 8 CPU cores, and 100+ GB SSD. Containerlab requires significantly less — a spine-leaf topology with 6 container nodes uses under 2 GB total RAM.

Does Containerlab support Cisco IOS images?

Not directly. Containerlab runs containerized network operating systems, not full VM images. For Cisco, you can use Cisco XRd (containerized IOS-XR) or run traditional IOS images through GNS3 or EVE-NG. Containerlab also supports FRRouting as an open-source alternative for BGP, OSPF, and IS-IS testing.

Is EVE-NG Community Edition truly free?

Yes, the Community Edition is free to use for personal and educational purposes. It supports all the core features: QEMU-based device emulation, web-based topology editor, Wireshark integration, and HTML5 console access. The Pro Edition adds multi-user labs, external authentication, lab scheduling, and priority support.

Can I use Containerlab with my existing Docker Compose infrastructure?

Absolutely. Containerlab uses Docker under the hood, and its containers coexist with your Docker Compose services. You cprometheusonitoring stack (Prometheus, Grafana) alongside your network lab and connect them via Docker networks. Just ensure Containerlab’s virtual bridges don’t conflict with your existing Docker bridge subnets.

How do I back up my network lab configurations?

With GNS3, export your project (.gns3 file) and the image directory. With EVE-NG, copy the lab directory from /opt/unetlab/labs/. With Containerlab, your YAML topology file and any bind-mounted config files are already version-controllable — store them in Git alongside your infrastructure code.

Which tool is best for learning network automation?

Containerlab is the strongest choice for network automation workflows. Its YAML-defined topologies pair naturally with Ansible, Nornir, or Python scripts for configuration management. You can write an automation playbook, deploy a Containerlab topology, run your tests, and destroy the lab — all in a single CI/CD pipeline.

For related reading, sekubernetes vs K0s vs Talos Kubernetes guide](../k3s-vs-k0s-vs-talos-linux-self-hosted-kubernetes-guide-2026/) for container orchestration fundamentals, the eBPF networking observability guide for modern network monitoring techniques, and the container runtimes comparison to understand the Docker engine layer that Containerlab builds on.