Die Challenge

In den vergangenen Jahren habe ich hauptsächlich EVE-ng bzw. Cisco CML für meine virtuellen Labs genutzt, da ich die notwendigen Ressourcen und Systeme über meinen Arbeitgeber zur Verfügung gestellt wurden. Letztlich ist man dann aber auch immer auf deren Erreichbarkeit und Verfügbarkeit angewiesen, was nicht immer in jeder Situation gewährleistet werden kann. Zudem handelt es sich um Ressourcen, die einem nicht exklusiv zur Verfügung stehen - wenn also gerade Kollegen größere Labs für ihre Projekte laufen lassen, dann bleibt man mitunter erst mal außen vor.

Von daher habe ich nach einer einfachen und lokalen Alternative gesucht, die jederzeit zur Verfügung steht und ad-hoc genutzt werden kann - egal ob ich gerade im Home-Office sitze, mit der Bahn unterwegs bin oder einen Kundentermin wahrnehme.

Dieser Post richtet sich also vor allem an jene, die Labs schnell und unkompliziert direkt auf ihrem Laptop bzw. Desktop laufen lassen wollen. Da ich sowohl privat als auch beruflich Windows nutze, beziehen sich die Inhalte entsprechend auf Windows-Systeme als Ausgangsbasis.

Die Lösung

Ich habe daher schon seit einigen Jahren Containerlab verfolgt - einem Tool, dass die Definition und Nutzung von Container-basierten Labs nach Infrastructure-as-Code Prinzipien in einfacher Art und Weise nutzbar macht. Im Jahr 2021 bin ich zum ersten mal auf Containerlab aufmerksam geworden.

Zu Beginn des Projekts, dass von Nokia entwickelt wurde, stand nachvollziehbarer Weise primär der Support für Nokias eigenes Container-basiertes NOS Nokia SR Linux im Fokus. Mit der Zeit ist der Support für weitere Hersteller ausgebaut wurden und neben reinen containerisierten Nodes können inzwischen (dank der vrnetlab-Integration) auch die “klassischen” VM-basierten Nodes in die Labs integriert werden, die man bspw. auch in EVE-ng, CML und GNS3 nutzt. Zudem gab es mit der eigens entwickelten VS Code Extension auch viele nützliche Erweiterungen in Bezug auf User-Interface und -Experience, die sowohl den Ein- als auch Umstieg erheblich erleichtern.

Wie einfach das benötigte Setup auf einem herkömmlichen Windows 11 System ist, möchte ich hier kurz zusammenfassen. Das Ziel wird es sein, ein kleines und einfaches Arista-Lab mit zwei Nodes auf dem lokalen Laptop laufen zu lassen.

Also legen wir los..

Der Plan

Für die Nutzung von Containerlab wird prinzipiell ein Linux-basiertes System erwartet, auf dem Docker läuft. Auch wenn das jetzt vielleicht wie ein Widerspruch zum eigentlichen Ziel des Posts klingt, stellt das keinen Show-Stopper dar. Um diese Voraussetzungen zu schaffen, nutzen wir WSL2 (Windows-Subsystem-Linux), also im Prinzip eine kleine Linux-VM auf Windows.

Der einfachste Weg, um Containerlab unter Windows zu nutzen ist die eigens entwickelte Containerlab WSL-Distribution, die bereits alle notwendigen Pakete, Tools und natürlich Containerlab selbst vorinstalliert hat.

Als Entwicklungsumgebung bzw. “Frontend” werden wir Visual Studio Code inkl. der Containerlab Extension nutzen, um ein paar zusätzliche Komfortfunktionalitäten nutzen zu können.

Zu guter Letzt müssen wir nur noch die notwendigen Arista cEOS Lab Container vom Hersteller herunterladen und einbinden. Danach kann die Topologie mit wenigen Zeilen im YAML-Format definiert und per CLI gestartet werden.

Schritt 1 - Die Basics: VS Code und WSL2

Zu Beginn stellen wir sicher, dass die notwendigen Basics mit Visual Studio Code und WSL2 installiert sind. Sofern das bereits der Fall ist, kann dieser Schritt übersprungen werden.

VS Code kann im einfachsten Fall über den Microsoft Store installiert werden. Alternativ kann man es auch über die folgende URL manuell herunterladen und installieren: https://code.visualstudio.com/

WSL2 wird unter Windows 11 mit folgendem Powershell-Command installiert bzw. aktiviert:

wsl --install 

Anmerkung

Unter Windows 10 ist das WSL-Setup etwas aufwendiger. Details können der offiziellen Containerlab-Doku entnommen werden

Zur Verifikation kann das Powershell-Command wsl -v genutzt werden:

PS C:\> wsl -v
WSL version: 2.6.3.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.71
MSRDC version: 1.2.6353
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.7623

Hinweis

Die WSL version sollte dabei mind. Version 2.4.4.0 sein.

Schritt 2 - Die All-in-One Distribution: WSL Containerlab

Im nächsten Schritt kann die aktuellste Version der Containerlab WSL Distribution unter folgendem Link heruntergeladen werden: https://github.com/srl-labs/wsl-containerlab/releases/latest

Containerlab WSL

Nach dem Download, kann die Containerlab WSL-Distribution einfach durch Doppelklick der .wsl Datei installiert und aktiviert werden. Im Rahmen des Installationsprozesses können noch verschiedene Einstellungen bzgl. der gewünschten Shell-Variante (zsh / bash / bash mit 2-Line Prompt) und zusätzlichen Fonts gewählt werden. Diese können je nach Vorlieben gewählt werden, machen aber für die reine Funktionalität keinen Unterschied.

Installing: C:\clab-0.72.0-1.0.wsl
Distribution successfully installed. It can be launched via 'wsl.exe -d Containerlab'
Launching Containerlab...
Welcome to Containerlab's WSL distribution

Applying system kernel settings for inotify...
System kernel settings applied.
1) zsh
2) bash with two-line prompt
3) bash (default WSL prompt)


Please select which shell you'd like to use: 2

bash with two-line prompt selected.
Would you like to install FiraCode Nerd Font? (y/N) N
Installing Containerlab completions for BASH...

SSH keys successfully copied. You can SSH into Containerlab WSL passwordless with: 'ssh clab@localhost -p 2222' (Ensure Containerlab WSL is open)

[*][Laptop][/mnt/c]
└──>

Nach erfolgter Installation kann der Status mit Powershell-Command wsl -l -v verifiziert werden:

PS C:\> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-24.04    Stopped         2
  Containerlab    Running         2

Schritt 3 - Vorbereiten der Entwicklungsumgebung

Wie bereits zu Beginn beschrieben, soll VS Code als Entwicklungsumgebung bzw. “Frontend” dienen. Wir starten an dieser Stelle also VS Code und öffnen über den Button Open a Remote Window (mit ‘><’ Symbol) in der unteren linken Ecke ein neues Remote-Fenster, wählen dann Connect to WSL using Distro… und Selektieren die Containerlab Distribution.

Anmerkung

Sollte das nicht wie beschrieben möglich sein, dann muss ggf. noch die WSL Extension über den Extension Manager in VS Code nachinstalliert werden.

Öffnen der Remote Connection in der Containerlab WSL VS Code öffnet dann ein neues Fenster, was direkt in der Containerlab WSL läuft. Der Button unten links macht das deutlich: WSL: Containerlab

Bevor jetzt ein neuer Ordner geöffnet wird, sollte noch die offizielle Containerlab Extension über den VS Code Extension Manager installiert werden. Diese steht dann für VS Code Sessions innerhalb der WSL zur Verfügung.

Containerlab VS Code Extension

Schritt 4 - Integration der Arista cEOS Lab Node

Von Haus aus kommt Containerlab ohne vorinstallierte Container-Images oder sonstige Nodes. Sofern die die benötigten Images nicht dynamisch von einer Container-Registry geladen werden können, müssen sie offiziell über die jeweiligen Hersteller-Websites und unter Voraussetzung der benötigten Berechtigungen bezogen werden.

Wir wechseln also von unserer VS Code Session in der WSL kurz zurück auf den Windows Host, um den Browser zu öffnen. Auf der Arista Website kann unter Software Download (Account vorausgesetzt) die gewünschte Version von Arista cEOS Lab heruntergeladen werden - in diesem Beispiel verwende ich das File cEOS64-lab-4.34.4M.tar.xz Arista cEOS Download

Das Image hat eine Größe von ca. 600MB und kann im Anschluss über den Windows Explorer auf das Filesystem der Containerlab WSL Instanz kopiert werden: Linux > Containerlab > home > clab

Von dort aus wechseln wir wieder zurück in die VS Code Session in der WSL. Wir öffnen ein Terminal unter View > Terminal und landen auf der Shell-CLI im Home-Verzeichnis des Users clab, in das wir gerade das Image-File kopiert haben.

Mit dem Command docker import cEOS64-lab-4.34.4M.tar ceos:4.34.4M wird das Image in die lokale Docker-Umgebung integriert und kann im Anschluss verwendet werden.

Anmerkung

Der Import-Vorgang kann je nach System-Performance bis zu wenigen Minuten dauern. Hier einfach etwas Geduld mitbringen

Zur Überprüfung des erfolgreichen Import-Vorgangs kann der docker images Befehl genutzt werden:

[*][LAPTOP][~]
└──> docker images
REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
ceos         4.34.4M   1fcc82be442a   20 seconds ago   2.54GB

Schritt 5 - Definition der Topologie und starten des Labs

Nun sind bereits alle notwendigen Voraussetzungen erfüllt, um das Lab zu definieren und zu nutzen. Wir legen in der laufenden Bash-Session mit mkdir labs einen neuen Order für unsere Lab-Files an und öffnen diesen über VS Code als Arbeitsumgebung.

Eine einfache Lab-Topologie mit zwei cEOS Nodes, die miteinander jeweils über den Port eth1 verbunden sind, ist im YAML-Format schon mit wenigen Zeilen einsatzfähig:

name: cEOS-lab

topology:
  kinds:
    arista_ceos:
      image: ceos:4.34.4M
  nodes:
    node1:
      kind: arista_ceos
    node2:
      kind: arista_ceos
  links:
  - endpoints: [node1:eth1, node2:eth1]

Anmerkung

Achtet beim Kopieren und Einfügen, dass die Einrückungen der einzelnen Paremeter YAML-konform sind. Ansonsten wird euer Lab nicht starten.

Speichert das File unter dem Namen cEOS-lab.clab.yml im aktuellen Ordner ab, um es im Anschluss mit dem Befehl clab deploy -t cEOS-lab.clab.yml starten zu können. Alternativ könnt ihr das Lab auch über die Funktionalitäten der Containerlab Extension starten.

Der Output sollte in etwa so wie hier aussehen:

[*][LAPTOP][~/labs]
└──> clab deploy -t cEOS-lab.clab.yml 
09:13:00 INFO Containerlab started version=0.72.0
09:13:00 INFO Parsing & checking topology file=cEOS-lab.clab.yml
09:13:00 INFO Creating docker network name=clab IPv4 subnet=172.20.20.0/24 IPv6 subnet=3fff:172:20:20::/64 MTU=0
09:13:00 INFO Creating lab directory path=/home/clab/labs/clab-cEOS-lab
09:13:00 INFO Creating container name=node1
09:13:00 INFO Creating container name=node2
09:13:01 INFO Running postdeploy actions for Arista cEOS 'node1' node
09:13:01 INFO Created link: node1:eth1 ▪┄┄▪ node2:eth1
09:13:01 INFO Running postdeploy actions for Arista cEOS 'node2' node
09:13:59 INFO Adding host entries path=/etc/hosts
09:13:59 INFO Adding SSH config for nodes path=/etc/ssh/ssh_config.d/clab-cEOS-lab.conf
╭─────────────────────┬──────────────┬─────────┬───────────────────╮
│         Name        │  Kind/Image  │  State  │   IPv4/6 Address  │
├─────────────────────┼──────────────┼─────────┼───────────────────┤
│ clab-cEOS-lab-node1 │ arista_ceos  │ running │ 172.20.20.3       │
│                     │ ceos:4.34.4M │         │ 3fff:172:20:20::3 │
├─────────────────────┼──────────────┼─────────┼───────────────────┤
│ clab-cEOS-lab-node2 │ arista_ceos  │ running │ 172.20.20.2       │
│                     │ ceos:4.34.4M │         │ 3fff:172:20:20::2 │
╰─────────────────────┴──────────────┴─────────┴───────────────────╯

Am Ende des Deploy-Vorgangs wird eine Zusammenfassung der bereitgestellten Nodes inkl. deren IPv4/v6-Adressen angezeigt, die auf den Management-Interfaces (eth0) konfiguriert wurden.

Schritt 6 - Am Ziel: Verwendung des Labs

Ab diesem Punkt kann das Lab verwendet werden. Ihr könnt euch auf die einzelnen Nodes bspw. mithilfe der Containerlab Extension (über die Menüleiste links) per SSH verbinden, um Konfigurationen vorzunehmen. Darüber hinaus visualisiert die Extension auch die Topologie und ihr bekommt eine Übersicht über alle Interfaces inkl. Status und der Möglichkeit Packet Captures (mittels Edgeshark-Integration) zu erstellen.

Lab in Containerlab Extension

[*][LAPTOP][~/labs]
└──> ssh admin@clab-cEOS-lab-node1
Warning: Permanently added 'clab-ceos-lab-node1' (ED25519) to the list of known hosts.
(admin@clab-ceos-lab-node1) Password: 
Last login: Sun Feb  8 10:09:05 2026 from 3fff:172:20:20::1
node1>en
node1#conf t
node1(config)#interface Ethernet 1
node1(config-if-Et1)#no switchport 
node1(config-if-Et1)#ip address 10.1.1.1/30
node1(config-if-Et1)#

Hinweis

Die Standard-Credentials für Arista cEOS sind admin/admin

Wenn das Lab nicht mehr benötigt wird, kann es mit dem Befehl clab destroy -t cEOS-lab.clab.yml wieder abgeschaltet werden

[*][LAPTOP][~/labs]
└──> clab destroy -t cEOS-lab.clab.yml             
11:00:57 INFO Parsing & checking topology file=cEOS-lab.clab.yml
11:00:57 INFO Parsing & checking topology file=cEOS-lab.clab.yml
11:00:57 INFO Destroying lab name=cEOS-lab
11:00:58 INFO Removed container name=clab-cEOS-lab-node1
11:00:59 INFO Removed container name=clab-cEOS-lab-node2
11:00:59 INFO Removing host entries path=/etc/hosts
11:00:59 INFO Removing SSH config path=/etc/ssh/ssh_config.d/clab-cEOS-lab.conf

Anmerkung

Die Config der Nodes wird bei Arista cEOS automatisch im jeweiligen Lab-Ordner für die einzelnen Nodes (z.B. clab-cEOS-lab/node1/flash/startup-config) gesichert, wenn die Config auf der cEOS CLI per write memory Command gesichert wird. Beim nächsten Deploy wird diese Config dann wieder in den Container geladen.

Alternativ können die aktuell laufenden Configs für sämtliche Nodes über das Containerlab-Command containerlab save gesichert werden. Das ist gerade für größere Labs praktisch.

Fazit

Damit steht euch nun eine kleine lokale Testumgebung für einfache Lab Use-Cases zur Verfügung, die ihr jederzeit direkt von eurem Windows-System starten starten könnt. Das ganze Setup inkl. der Downloads ist (je nach Internet-Bandbreite) in ca. 15 Minuten und mit einer Handvoll Klicks und Befehlen erledigt.

Auch wenn diese Setup nicht unbedingt für alle Lab-Anforderungen die richtige Lösung ist, soll es in erster Linie auch nur eine Alternative darstellen, die man zumindest einmal ausprobieren sollte. Zudem verdeutlicht sie das Potential von Containerlab und container-basierten Labs, auch wenn bisher noch nicht alle Hersteller auch konsequent entsprechende containerisierte Nodes zur Verfügung stellen.

Fun Fact

Ich habe die komplette Vorgehensweise bspw. erfolgreich auf meinem Surface Pro 6 von 2019 mit 8 GB RAM und Core i5-8250U CPU verprobt - inkl. beider cEOS Nodes 🤓

Wie man aber perspektivisch auch die Grenzen des lokalen Systems überwinden kann, ohne wiederum auf üppig ausgestattete Server-Hardware angewiesen zu sein, werde ich in einem späteren Post aufgreifen.