Containerlab vs GNS3: labs as code or a drag-and-drop GUI

Containerlab and GNS3 both build network labs, but they start from opposite ends. Containerlab reads a YAML file and wires up containers on a Linux host. GNS3 gives you a canvas and runs almost any emulator behind it. This page compares them as of October 2026 and shows a two-router Containerlab lab that we deployed and tested.

The short verdict

• Pick Containerlab if your devices exist as containers (SR Linux, cEOS, cRPD, XRd, FRR, Linux), you want labs in Git, or you want to start labs from CI.
• Pick GNS3 if you want a desktop GUI, need Dynamips, IOU, VirtualBox or VMware nodes, or you are studying with classic Cisco images.

At a glance

How you build a lab

This is the real difference.

Containerlab takes a topology file. Nodes have a kind (for example nokia_srlinux, arista_ceos or linux) and an image, and links list two endpoints. containerlab deploy creates the containers, connects their interfaces with veth pairs and prints a table of management addresses. containerlab destroy removes it all. Since the lab is a text file, you can review it in a pull request, copy it, and start the same lab in a CI job.

GNS3 starts from a canvas. You add devices from templates or appliances, draw links, and right-click to start nodes and open consoles. Projects are saved as .gns3 files and the server has a REST API, but most people use the GUI. That makes GNS3 friendlier when you are learning, and slower when you want ten copies of the same lab.

The gap has narrowed. The Containerlab apps add a visual topology editor that reads and writes the same .clab.yml files. They come as a VS Code extension, a web app and a desktop app for Linux, macOS and Windows, and they can deploy labs, open terminals, capture packets and set link impairments. The labs still run on a Linux host.

A two-router lab in Containerlab

Here is a small topology: two FRR containers joined by one link, with an address on each end.

  r1 (eth1) 10.0.12.1/30 ---------- 10.0.12.2/30 (eth1) r2

name: frr-pair

topology:
  nodes:
    r1:
      kind: linux
      image: quay.io/frrouting/frr:10.7.1
      exec:
        - ip addr add 10.0.12.1/30 dev eth1
    r2:
      kind: linux
      image: quay.io/frrouting/frr:10.7.1
      exec:
        - ip addr add 10.0.12.2/30 dev eth1
  links:
    - endpoints: ["r1:eth1", "r2:eth1"]

Save it as frr-pair.clab.yml and deploy it on a Linux host with Docker:

sudo containerlab deploy -t frr-pair.clab.yml

Containerlab pulls the image, creates the two containers and the link, and runs the exec commands. The containers are named clab-<lab>-<node>, here clab-frr-pair-r1 and clab-frr-pair-r2. Test the link:

docker exec clab-frr-pair-r1 ping -c 3 10.0.12.2

64 bytes from 10.0.12.2: seq=2 ttl=64 time=0.056 ms

--- 10.0.12.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.055/0.097/0.181 ms

Now add 50 ms of delay with 5 ms of jitter on r1's side of the link:

sudo containerlab tools netem set -n clab-frr-pair-r1 -i eth1 --delay 50ms --jitter 5ms
docker exec clab-frr-pair-r1 ping -c 3 10.0.12.2

64 bytes from 10.0.12.2: seq=2 ttl=64 time=51.888 ms

--- 10.0.12.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 48.108/50.757/52.275 ms

Remove the lab when you are done:

sudo containerlab destroy -t frr-pair.clab.yml --cleanup

We ran this with containerlab 0.81.0 and FRR 10.7.1; the output above is trimmed. To build the same lab in GNS3, you would import an FRR Docker template, place two nodes, draw the link and set the addresses in each console. Same result, more clicks, no file to commit.

What each one runs

Containerlab is at its best with container network OSes: Nokia SR Linux, Arista cEOS, Juniper cRPD, Cisco XRd, FRR and plain Linux. Its list of kinds also covers many VM-based images, such as Cisco CSR 1000v, Catalyst 8000v, Nexus 9000v and Juniper vMX. Those run through vrnetlab, which packages a VM inside a container. You build each image yourself from a disk image you are licensed to use, and the docs say the host needs nested virtualization when it is a VM. Cisco IOL is a container kind: the docs say it comes from the CML reference platform ISO and needs no VM. Cisco licenses those CML images for use within CML only, so check your licence before you run them anywhere else.

GNS3 runs Dynamips, IOU, QEMU/KVM, VirtualBox and VMware VMs, and Docker containers on Linux. Its appliance catalogue describes how to run many vendor images. You still supply the vendor images. GNS3 is the only one of the two that runs old IOS images on emulated Cisco hardware through Dynamips.

Where they run

Containerlab needs a Linux host with Docker and sudo rights, or membership of the clab_admins group when you install from a package. The install page lists Debian, Ubuntu, RHEL-family and Fedora, on amd64 and arm64. On Windows it runs inside WSL. On macOS the docs recommend a Linux VM (for example in OrbStack) or a devcontainer, with ARM-native images where possible.

GNS3 installs as a desktop app on Windows, macOS and Linux. On Windows and macOS, most images run in the GNS3 VM, which GNS3 recommends running in VMware for nested virtualization. That VM is where most GNS3 setup trouble starts; our GNS3 troubleshooting guide covers the usual errors.

Impairments and capture

Containerlab sets impairments per interface with containerlab tools netem set: delay, jitter, loss, rate and corruption. A new call replaces the previous settings on that interface. If you want to see what that tool does underneath, our post on simulating latency and loss with tc netem walks through it. For capture, the docs use the node's network namespace, for example ip netns exec clab-frr-pair-r1 tcpdump -nni eth1, or pipe tcpdump over SSH into Wireshark.

GNS3 sets packet filters on links from the GUI (delay and jitter, loss, frequency drop, corruption, BPF) and can suspend a link. Capture is a right-click on a link that opens Wireshark.

Which to pick

• Labs in Git, CI tests, container NOS: Containerlab.
• CCNA or CCNP study with classic Cisco images: GNS3, or Cisco Modeling Labs for licensed images.
• A laptop with Windows and no Linux experience: GNS3 is easier to start with; Containerlab in WSL works but expects you to be at home in a Linux shell.
• Hundreds of nodes on one server: Containerlab, since containers use far less memory than VMs.
• You want both: draw and learn in GNS3, then keep repeatable labs in Containerlab.

For more options, including EVE-NG, CML and netlab, see our GNS3 alternatives overview.

Where Isothrum fits

Isothrum's editor sits between the two: you draw the lab in your browser like in GNS3, with no account, and get plain files like Containerlab. It exports isoloom.yml plus Docker Compose, Vagrant, Proxmox, Kubernetes and cloud files, and it opens existing .gns3 projects. Each cable or LAN can carry latency, jitter, loss and bandwidth limits. You run the exported files with those tools; a desktop app that runs labs locally is coming soon.