Containerlab Guide: Building Ultra-Lightweight Network Labs with Docker for NetDevOps – ITFROMZERO

Table of Contents

Deploying a Network Lab in 5 Minutes (Quick Start)

If you’re tired of waiting for GNS3 or EVE-NG to devour 32GB of RAM just to run a few routers, try Containerlab. Warning: You might never want to go back to traditional virtual machines (VMs) again. All you need is a Linux machine with Docker installed, and you’re ready to go.

Install Containerlab quickly with a single command:

bash <(curl -sL https://get.containerlab.dev)

Let’s build a 2-node Linux topology to see its speed. Create a file named simple-lab.yaml:

name: lab-demo
topology:
  nodes:
    node1:
      kind: linux
      image: alpine:latest
    node2:
      kind: linux
      image: alpine:latest
  links:
    - endpoints: ["node1:eth1", "node2:eth1"]

Now, deploy the lab:

sudo containerlab deploy -t simple-lab.yaml

In less than 10 seconds, you’ll have two Alpine containers directly connected via the eth1 interface. To clean up, simply run sudo containerlab destroy -t simple-lab.yaml. Everything will be wiped clean without leaving any system clutter.

What is Containerlab and Why is it a Game Changer?

Containerlab doesn’t replace Docker. It acts as an “orchestrator.” It automatically creates containers, sets up virtual interface pairs (veth pairs), and connects them according to your topology. Instead of each router being a heavy multi-GB virtual machine, each node is now just a lightweight process on Linux.

The best part is the Infrastructure as Code (IaC) mindset. The entire network topology is now encapsulated in a single text file. You can easily push it to Git, share it with colleagues, or integrate it into CI/CD pipelines to automate ECMP Routing on Linux configuration testing.

Decoding the Topology File Structure

The YAML file is the soul of every Containerlab project. You only need to master these three core components:

name: The lab identifier, used as a prefix to distinguish containers.
nodes: The list of devices. You can use kind: linux for servers, or specialized types like Nokia SR-Linux, Arista cEOS, or Cisco 8000V.
links: Defines physical connections. For example, ["node1:eth1", "node2:eth1"] “plugs a cable” between the eth1 ports of two nodes.

Note that Containerlab always automatically creates a management network. Each device will have an eth0 interface that receives an IP from the Docker bridge, allowing you to SSH in for configuration immediately.

Real-world Experience: Hunting “Ghost” Network Errors

I once encountered a tough case: random packet loss during peak hours. Recreating the environment on physical hardware was impossible due to the high risk of service disruption. I decided to use Containerlab to rebuild the entire topology consisting of 6 routers running FRRouting (BGP/OSPF) and performed deep network troubleshooting on Linux. By pushing simulated traffic through iperf3, I discovered the issue was inconsistent MTU configurations. Specifically, an intermediate hop was set to MTU 1450 while others were 1500, causing large packets to be dropped—a detail I confirmed using ethtool Linux. Thanks to Containerlab, I found the cause in just 2 hours instead of struggling for a week with physical equipment.

Advanced: Connecting the Lab to Physical Networks

Sometimes you need lab nodes to access the Internet or connect to a real switch in the office. Containerlab handles this via the bridge node type.

topology:
  nodes:
    br-ex:
      kind: bridge
    router1:
      kind: linux
      image: frrouting/frr
  links:
    - endpoints: ["router1:eth1", "br-ex:eth1"]

In this example, br-ex will attach directly to an existing Linux bridge on the host machine. This is a perfect bridge for testing real-world services like DNS or DHCP servers within your virtual lab environment.

Tips for Optimizing Performance

After spending a lot of time working with Containerlab, here are three key takeaways:

Enable Graph Mode: When your topology exceeds 10 nodes, use the command sudo containerlab graph -t lab.yaml. It opens a visual web interface to help you check physical connections faster.
Don’t Forget to Mount Volumes: Containers lose data when deleted. Use the binds attribute to save configuration files from the container to the host machine’s disk.
Monitor RAM: Although very lightweight, running 50 Arista cEOS routers can still consume 16GB of RAM. Use docker stats to monitor resources regularly.

Mastering Containerlab is a vital stepping stone toward professional NetDevOps. Instead of wasting time crimping cables or waiting for virtual machines to boot, you can now focus entirely on designing and optimizing network architectures.