Trockenübung

von Benjamin Pfister

ADMIN

2026

2026-06-29T12:00:00

Edge Computing

PRAXIS

026

Infrastructure as Code

Testumgebung

Container

Netze mit Containerlab simulieren

Trockenübung

von Benjamin Pfister

Veröffentlicht in Ausgabe 07/2026 - PRAXIS

Klassische Netzwerksimulatoren stoßen aufgrund ihres hohen Ressourcenbedarfs oft an Grenzen. Containerlab löst dieses Problem durch einen leichtgewichtigen Infrastructure-as-Code-Ansatz, der komplexe Topologien in Containern abbildet. Damit lassen sich sogar Multi-Vendor-Umgebungen automatisiert bereitstellen. So entstehen schnell reproduzierbare und realitätsnahe Testinfrastrukturen für Netzwerke.

Bestehende Anwendungen für Simulation und Emulation wie EVE-NG, GNS3 oder Cisco Modeling Labs agieren vergleichsweise starr und ressourcenintensiv. Bis Netzwerker ein konkretes Feature testen können, vergeht viel Zeit. Zudem erfolgt die Konfiguration klassisch Zeile für Zeile über das CLI. Diese Werkzeuge bieten sich folglich nur bedingt für schnelle Validierungen und reproduzierbare Ergebnisse an, da eine einzelne falsch interpretierte Zeile zu differierenden Ergebnissen führen kann.

Containerlab [1] liefert einen leichtgewichtigen Ansatz, der der zunehmenden Automatisierung und den Infrastructure-as-Code-Ansätzen (IaC) im Netzwerkumfeld gerecht wird.

Optimierte Netzvalidierung durch IaC-Ansatz

Containerlab ist ein Open-Source-Werkzeug, das das Erstellen und Verwalten von Netzwerk-Laborumgebungen durch Containerisierung und deklarative Infrastrukturdefinition vereinfacht. Containerlab stammt ursprünglich von Nokia und unterliegt nun der Weiterentwicklung durch die Projektmitglieder. Seine Grundidee besteht darin, komplexe Netzwerktopologien nicht mehr manuell oder über virtuelle Maschinen (VM), sondern durch YAML-beschriebene Konfigurationen automatisch bereitzustellen. Im Kern nutzt Containerlab Docker als technologische Basis. Admins stellen jedes Netzwerkgerät – Router, Switch oder Firewall – als Docker-Container bereit. Dies bietet gegenüber klassischen VM-basierten Ansätzen erhebliche Vorteile. Da Orchestrierungstools wie Docker-Compose keine einfache Definition von Links zwischen Containern erlauben, schließt Containerlab diese Lücke.

Containerlab [1] liefert einen leichtgewichtigen Ansatz, der der zunehmenden Automatisierung und den Infrastructure-as-Code-Ansätzen (IaC) im Netzwerkumfeld gerecht wird.

Optimierte Netzvalidierung durch IaC-Ansatz

Ein zentraler Unterschied zu traditionellen Ansätzen liegt in der deklarativen Konfiguration. Statt Netzwerkgeräte imperativ zu konfigurieren, beschreiben IT-Profis in einer YAML-Datei die gewünschte Topologie samt Verbindungen. Containerlab übernimmt das Deployment, startet die Container und verbindet sie virtuell. Dabei lassen sich vorbereitete Konfigurationen übergeben, um das Netzwerk direkt in einem definierten Zustand bereitzustellen. Dieser IaC-Ansatz ermöglicht die Versionierung der Konfigurationen über Git und die Nutzung in CI/CD-Pipelines. Zudem binden Admins das virtuelle Netzwerk über eine physische Netzwerkkarte (NIC) in bestehende Hardware ein.

Die Flexibilität von Containerlab zeigt sich in der Unterstützung zahlreicher Netzwerkbetriebssysteme (NOS) als Docker- Container. Das Werkzeug unterstützt Multi-Vendor-Umgebungen, was Interoperabilitätstests zwischen Produkten unterschiedlicher Hersteller ermöglicht. Dazu zählen Nokia SR Linux, Arista cEOS, Juniper vJunos sowie die Open-Source-Varianten FRR und SONiC. Darüber hinaus lassen sich Werkzeuge wie der Traffic-Generator Ostinato integrieren, um synthetische Netzwerklasten zu erzeugen. Neben Netzwerkkomponenten unterstützt Containerlab auch Linux-Hosts, um Server- oder Clientverhalten zu validieren.

Validierung von Designs und Troubleshooting

Containerlab hat sich als Werkzeug für Netzwerkteams in der Planung und für Schulungsumgebungen etabliert. Dies liegt an der Fähigkeit, komplexe Topologien schnell und reproduzierbar in Containern abzubilden. Die einfache Bereitstellung und der geringe Ressourcenbedarf machen es besonders für virtuelle Trainings attraktiv. Vor dem Rollout neuer Software-Releases validieren IT-Verantwortliche Netzwerkgeräte in isolierten oder hybriden Umgebungen, um Funktionen unter realistischen Bedingungen zu testen. Durch die Skalierbarkeit lassen sich Testfälle schnell anpassen und wiederholen, was die Qualitätssicherung beschleunigt.

Tritt im produktiven Netzwerk ein Fehler auf, hilft Containerlab dabei, die betroffene Topologie nachzubilden und das Problem gezielt zu reproduzieren. So analysieren Admins Konfigurations- oder Interoperabilitätsprobleme sowie potenzielle Bugs isoliert, ohne die In- frastruktur zu gefährden. Vor der Implementierung neuer Architekturen evaluieren Teams innovative Ansätze wie Segment Routing, EVPN oder SD-WAN in einem Proof-of-Concept (PoC). Dies minimiert Risiken, bevor Sie Konzepte in das produktive Netzwerk übertragen.

Ein "Digitaler Zwilling" der Produktionsumgebung dient als mächtiges Werkzeug für Planung und Wartung. Mit Containerlab erstellen Sie Staging-Umgebungen, die die reale Infrastruktur widerspiegeln. Änderungen testen Sie vorab, um die Stabilität zu erhöhen und Ausfallzeiten zu reduzieren. In heterogenen Netzwerken ermöglicht das Werkzeug zudem Inter- operabilitätstests zwischen Produkten verschiedener Hersteller, um Kompatibilitätsprobleme frühzeitig zu erkennen.

Bild 1: Nach dem Deployment eines Labors zeigen sich die gestarteten Container mit Namen, Betriebssystem und IP-Adressen.

Performancevorteile und Grenzen der Emulation

Zu den Stärken von Containerlab zählen die Performance und Ressourceneffizienz. Die Container-Technologie verursacht im Vergleich zu virtuellen Maschinen deutlich weniger Overhead, sodass komplexe Topologien auf einem einzigen Host betrieben werden können. Die Skalierbarkeit ist ideal für CI/CD-Pipelines und automatisierte Tests. Grenzen zeigen sich jedoch beim Realismus und der Hardwarenähe. Container-Images emulieren die Softwareebene, können aber nicht alle hardwarebezogenen Funktionen abbilden.

Da Leistungsmerkmale oft im ASIC oder PHY implementiert sind – wie MACsec oder spezifische QoS-Mechanismen –, weicht das Verhalten in der Simulation mitunter von physischer Hardware ab. Ein weiteres Hindernis stellen Lizenzen und Images dar. Nicht alle Hersteller bieten offizielle Container-Images an, oder sie fordern spezielle Lizenzen, die den Einsatz in Testumgebungen erschweren. Containerlab ist daher nicht das richtige Werkzeug für die exakte Nachbildung von Hardwareperformance oder die Validierung von ASIC-spezifischen Funktionen. In solchen Fällen bleiben physische Labore unverzichtbar.

Skripte und APIs steuern die Laborumgebung

Die Steuerung der Umgebungen erfolgt über ein intuitives CLI oder das API. Den API-Server müssen Sie jedoch dediziert aktivieren. Mit einfachen Befehlen oder API-Requests erstellen und beenden Sie Labore, während die YAML-Dateien als zentrale Konfigurationsquelle dienen. Praktisch ist die Möglichkeit, Netzwerkbedingungen wie Latenz, Packet Loss oder Jitter zwischen den Containern zu simulieren.

Containerlab läuft auf Linux, Windows mit WSL2 sowie macOS, wobei es bei Apple Silicon Einschränkungen gibt. Die Hardwareanforderungen an CPU und RAM variieren je nach Art und Anzahl der eingesetzten Container-Images. Sie sollten hierzu die Datenblätter der jeweiligen Hersteller prüfen und die geplante Quantität berücksichtigen. Für Linux führen wir das All-in-One-Installationsskript von der Projektwebseite auf einem Host aus. Über den folgenden Befehl installieren Sie alle Komponenten:

curl -sL https://containerlab.dev/setup | sudo -E bash -s "all"

Das Paket umfasst Docker, Docker- Compose, Containerlab und das Werkzeug "gh". Der Installationsnutzer benötigt sudo-Berechtigungen. Das Skript prüft die Systemumgebung, installiert Abhängigkeiten und lädt die aktuelle Version von Containerlab herunter. Alternativ binden wir die Repositorys in die jeweilige Paketverwaltung ein. Listing 1 zeigt die Installation über das Skript sowie über den Paketmanager Apt unter Ubuntu Linux.

Listing 1: Installation von Containerlab über All-in-One Skript oder Apt

#Setup-Skript

sudo curl -sL https://containerlab.dev/setup | sudo -E bash -s "all”

#Apt-Installation

echo "deb [trusted=yes] https://netdevops.fury.site/apt/ /” | \

sudo tee -a /etc/apt/sources.list.d/ netdevops.list

sudo apt update && sudo apt install containerlab

Unter Windows 11 erfolgt die Installation über das Windows Subsystem for Linux (WSL). Dazu richten Sie zunächst über den Befehl wsl --install die Umgebung ein. Im Anschluss laden Sie Containerlab von der Release-Seite herunter und führen die Datei per Doppelklick aus. Danach lässt sich das Werkzeug über wsl -d Containerlab starten.

Unter macOS mit Apple Silicon existieren verschiedene Betriebsvarianten. Die erste Option erfordert die Installation einer Docker-Engine wie Docker Desktop direkt auf dem Host-Betriebssystem. Da der macOS-Kernel kein direkter Ersatz für Linux ist, fehlen ihm spezifische Funktionen wie Netlink-APIs, auf die Containerlab angewiesen ist. Daher führt das System die Docker-Engine in einer eigenen VM aus. Alternativ betreiben Sie ein Linux-System als VM unter VMware Fusion, UTM oder OrbStack, um darin die Docker-Engine und Containerlab auf nativer Linux-Basis zu nutzen.

Docker-Images erweitern die Multi-Vendor-Umgebung

Nach der Installation importieren Sie die Docker-Images (Listing 2). Die Nokia-SR-Linux-Images lassen sich bei Bedarf während des Deployments über docker pull ghcr.io/nokia/srlinux herunterladen. Andere Varianten wie Arista cEOS müssen Sie vorab als Container bereitstellen. Dies erfordert eine kostenlose Registrierung auf der Herstellerwebseite, um das offizielle Image zu beziehen.

Listing 2: Container-Import von Arista cEOS und Nokia SR-Linux

# Import Arista cEOS

docker import cEOS-lab-4.35.2F.tar ceos:4.35.2F

# Download Nokia SR Linux

docker pull ghcr.io/nokia/srlinux

# Download Nokia SR Linux, Tagging und Upload in ein eigenes Repository

sudo docker pull ghcr.io/nokia/srlinux:25.10

sudo docker tag ghcr.io/nokia/srlinux:25.10 registry.zcs.miriquidi-net.works:9443/clab/nokia_srlinux:25.10

sudo docker push registry.zcs.miriquidi-net.works:9443/clab/nokia_srlinux:25.10

Den Import in die lokale Docker-Umgebung führen Sie für die Version 4.35.2F beispielsweise mit folgendem Befehl durch:

docker import cEOS-lab-4.35.2F.tar ceos:4.35.2F

Alternativ stellen Sie die Images in einem eigenen Repository wie Harbor [2] bereit. Dies ermöglicht es, die Dateien vor der Nutzung notwendigen Sicherheitsprüfungen zu unterziehen. Durch diese zentrale Vorhaltung wird das Deployment in größeren Infrastrukturen konsistenter und sicherer.

Bei macOS ist zu beachten, dass aktuelle Varianten mit M1-, M2- oder M3-Prozessoren auf Apple Silicon basieren. Folglich benötigt die Infrastruktur spezifische Container-Image-Varianten für ARM64. Diese stehen beispielsweise für Nokia SR Linux, Arista EOS und FRR bereit. Eine alternative Option für den Betrieb auf ARM-Macs stellt die Verwendung von "Devcontainern" dar. Diese eignen sich insbesondere im Zusammenspiel mit VS Code, um einen Container als Entwicklungsumgebung zu nutzen. Durch die Datei "devcontainer.json" definieren Sie die Umgebung für das Projekt.

Einige Netzwerk-Betriebssysteme wie Cisco NX-OS stehen nicht nativ als Container zur Verfügung. In diesem Fall nutzen Sie das Drittanbieter-Werkzeug VRnetlab [3], um virtuelle Maschinen in einen Docker-Container umzuwandeln. Da Cisco-Images in der Regel einen Supportvertrag erfordern, beziehen Sie zunächst den VRnetlab-Fork für Con- tainerlab über GitHub:

git clone https://github.com/ srl-labs/vrnetlab

Anschließend wechseln Sie mit cd vrnetlab/cisco/n9kv/ in das Unterverzeichnis der Komponente, etwa für einen virtuellen Cisco Nexus 9000, und kopieren das zuvor bezogene QCOW2-Image hinein. Der Dateiname muss exakt dem Muster "n9kv-.qcow2" entsprechen. Der Befehl make docker-image erstellt daraufhin das Docker-Image "vrnetlab/cisco_n9kv:".

Bild 2: Mit Draw.io lässt sich die Testumgebung als Grafik exportieren.

Cloudbasierte Umgebungen und IDE-Integration

Möchten Sie keine lokale Installation durchführen, bietet sich GitHub Code- spaces an. Darüber steht eine vollständige, cloudbasierte Infrastruktur bereit, sodass lokale Ressourcen und Einrichtungsaufwände entfallen. Wenn Sie das Labor in Codespaces öffnen, nutzt GitHub das Devcontainer-Image von Containerlab, das alle erforderlichen Werkzeuge und Abhängigkeiten enthält. Für den Zugriff genügen ein Webbrowser, ein GitHub-Account und die benötigten Images.

Zusätzlich zur Devcontainer-Erweiterung existiert für Visual Studio Code eine dedizierte Containerlab-Erweiterung. Diese liefert einen Überblick über laufende Labore, Container sowie Links und bietet eine grafische Topologieansicht. Über ein Kontextmenü lassen sich Labore ohne das CLI bereitstellen, beenden oder als Grafik exportieren. Auch die Verbindung zu entfernten Containerlab-Hosts ist über dieses Werkzeug möglich.

Netzwerk-Topologien per YAML definieren

Um die Funktionsweise von Containerlab zu verstehen, dient als Praxisbeispiel eine einfache Leaf-Spine-Architektur mit zwei Gateways zur Anbindung an externe Netzwerke. Ein solches Szenario bildet die Basis für kleine Rechenzentrumsstrukturen. Sie erstellen dazu gemäß dem IaC-Ansatz eine YAML-Datei. Diese folgt dem Namensschema ".clab.yml" und definiert die gesamte Topologie des Labors (Listing 3).

Listing 3: Lab-Topologie einer Leaf-Spine Architektur

name: dcf-demo

topology:

nodes:

dc-gw01:

kind: nokia_srsim

image: localhost/nokia/srsim:25.10.R1

license: license-sros25.txt

dc-gw02:

kind: nokia_srsim

image: registry.intra.miriquidi-net.works:9443/clab/nokia_sros:25.10.R1

license: license-sros25.txt

spine01:

kind: nokia_srlinux

image: registry.intra.miriquidi-net.works:9443/clab/nokia_srlinux:25.10

spine02:

kind: nokia_srlinux