Containerlab baut WAN- und DCI-Strecken als YAML-Topologie Vendor-neutrales Container-Tool für Rechenzentrumsnetze

Das Tool „Container Lab“ orchestriert containerisierte Router, Switches und Open-Source-Routing-Software in deklarativ definierten Topologien. Über eine einzige YAML-Datei verbindet das Tool mehrere Fabrics, simuliert WAN-Strecken zwischen Rechenzentren und stellt eine Multi-Vendor-Lab-Umgebung auf jeder Linux-Maschine bereit.

Containerlab startete vor fünf Jahren als Inkubationsprojekt der SR-Labs-Gruppe bei Nokia und hat sich zu einem vendor-neutralen Open-Source-Standard für containerbasierte Netzwerk-Labs entwickelt. Die Software schließt eine Lücke der klassischen Container-Orchestrierung.

Denn „Docker-Compose“ verbindet zwar Container, eignet sich aber nicht für die Punkt-zu-Punkt-Verkabelung zwischen Netzwerk-Knoten. Containerlab übernimmt den fehlenden Wiring-Schritt und steuert zugleich das Lifecycle-Management von Topologien aus mehreren unterstützten Network Operating Systems. (In dem nachfolgenden Video zeigen die Entwickler ausführlicher die Möglichkeiten.)

Open-Source-Werkzeug für vendor-neutrale Netzwerk-Labs

Containerlab ist ein Linux-natives CLI-Tool, das „Docker“-Container als Knoten einer Topologie verbindet und Lifecycle-Operationen über die Befehle deploy, destroy, inspect, save, exec, generate und graph ausführt. Roman Dodin startete das Projekt 2020 bei Nokia und veröffentlichte es unter der Apache-2.0-Lizenz.

Das Repository srl-labs/containerlab auf Github bündelt die Entwicklung. Andere Hersteller und Community-Mitglieder steuern Kind-Definitionen für ihre eigenen Netzwerkbetriebssysteme bei.

Die Liste umfasst „Nokia SR Linux“, „Nokia SR OS“, „Arista Ceos“, „Cisco XRD“, „Cisco 8000“, „Juniper CRPD“, „Sonic“, „Cumulus VX“, „Aruba AOS-CX“, „Huawei VRP“ und „IP Infusion Ocnos“. Test-Traffic-Generatoren der Hersteller Keysight (IXIA-C), Ostinato und Spirent (TestCenter) laufen als Containerlab-Knoten neben den Routing-Systemen.

Datacenter-Switch mit modularen Apps von Nokia

Der Switch wird zum Linux-Host

Im Vergleich zu klassischen Lab-Plattformen, darunter „EVE-NG“ und „GNS3“, setzt Containerlab konsequent auf Container statt vollständige virtuelle Maschinen. Container starten in Sekunden, beanspruchen wenig RAM und CPU und lassen sich über Image-Layer reproduzierbar verteilen.

Für ältere virtuelle Router ohne native Container-Variante integriert Containerlab das Open-Source-Projekt „vrnetlab“. Über die vrnetlab-Integration laufen „Juniper VMX“, „Cisco CSR1000v“, „Palo Alto PAN“ und ähnliche Plattformen in einer Containerlab-Topologie neben den nativen Container-Knoten.

Installation und Topologie als YAML-Datei

Die Installation erfolgt über ein einzeiliges Setup-Script:

Das Skript installiert Docker, Containerlab und die Github-CLI in einem Aufruf. Containerlab ist als deb- und rpm-Paket für „amd64“ und „arm64“ verfügbar und läuft auf „Ubuntu“, „Debian“, „RHEL“, „CentOS Stream“, „Fedora“ und „Rocky Linux“.

Ein Symlink "clab" verkürzt sämtliche Aufrufe. Die Distribution verfügt über eine eigene Unix-Gruppe "clab_admins" für die sudo-lose Ausführung privilegierter Befehle. Mitglieder der Gruppe nutzen das Tool ohne sudo-Aufruf vor jedem Kommando.

Die Topologie definiert ein YAML-File mit dem Suffix ".clab.yml". Das Format folgt einem schlanken Schema. Der Block "name" enthält den Lab-Namen, der Block "topology" gliedert sich in die Abschnitte "nodes" und "links".

Jeder Knoten erhält einen Namen, einen Kind-Wert, optional ein "type" und ein "image". Links verbinden zwei Endpunkte über die Notation 'endpoints: ["node1:interface1", "node2:interface2"]'. Containerlab erkennt sowohl Linux-Interface-Namen als auch Hersteller-Alias-Bezeichnungen und bildet beide auf dieselbe virtuelle Verbindung ab. Editor-Plug-ins für Visual Studio Code liefern Syntax-Highlighting, JSON-Schema-Validierung und Inline-Hilfe direkt im YAML-File.

Im Anschluss an die Topologie-Definition startet "sudo containerlab deploy" das Lab. Containerlab pullt fehlende Container-Images, legt Docker-Netzwerke an, verkabelt die Endpunkte über veth-Pairs und gibt eine Tabelle mit Container-Namen, IPv4-/IPv6-Adressen und Status aus.

Der Befehl "containerlab inspect" listet aktive Labs samt Knoten. Mit "containerlab destroy" und der Option "--cleanup" baut der Operator das Lab zurück und entfernt optional die Konfigurationsverzeichnisse. Über "containerlab save" persistiert der Operator den Running-Stand jedes Knotens. Die generate-Funktion erzeugt CLOS-Topologien beliebiger Tiefe und Breite mit einem einzigen Kommando.

Nodes, Kinds und Links als Bausteine

Ein Kind beschreibt die Eigenschaften eines Hersteller-Knotens. Containerlab bringt die fertigen Kind-Definitionen für jedes unterstützte Network Operating System mit und kapselt die teils komplexen Startup-Anforderungen. Ein nokia_srlinux-Knoten startet anders als ein arista_ceos- oder ein juniper_crpd-Knoten, der Anwender sieht davon im YAML-File jedoch nichts.

Im Kinds-Block legt der Operator gemeinsame Eigenschaften, darunter image und type, für alle Knoten desselben Kinds einmal fest. In der defaults-Sektion setzt der Operator Werte für die gesamte Topologie. Eine groups-Sektion fasst Knoten unterschiedlicher Kinds zu logischen Einheiten zusammen, zum Beispiel zu Spines, Alpine-Clients oder Debian-Clients.

Links lassen sich in zwei Formaten definieren. Das Brief-Format komprimiert die Verbindung in eine kurze Liste mit der Notation endpoints: ["srl:e1-1", "ceos:eth1"]. Das Extended-Format erlaubt zusätzliche Felder pro Endpunkt, darunter MAC-Adresse, IPv4-Adresse, IPv6-Adresse, MTU und benutzerdefinierte Variablen.

Containerlab unterstützt Interface-Alias-Bezeichnungen, so dass die Hersteller-spezifische Notation "ethernet-1/1" direkt in der Topologie steht und Containerlab transparent auf den internen Linux-Interfacenamen "e1-1" abbildet. Die Architektur einzelner Kinds, das YANG-Datenmodell und die CLI-Modi des SR-Linux-Kinds beschreibt unser Beitrag zu SR-Linux "Switch wird zum Linux-Host" im Detail.

Link-Typen für WAN- und Inter-DC-Strecken

Containerlab unterscheidet mehrere Link-Typen. Der Typ veth ist die Standardverbindung zwischen zwei Knoten. Der Typ mgmt-net hängt einen Endpunkt an das Management-Netzwerk des Container-Runtimes an.

Der Typ macvlan koppelt einen Knoten an eine bestehende Host-Schnittstelle, der Typ host fügt einen Endpunkt direkt in den Default-Namespace ein. Die Typen vxlan und vxlan-stitched öffnen die Topologie für verteilte Setups.

Mit vxlan terminiert ein VTEP im Host-Namespace, Containerlab schiebt das Tunnel-Interface in den Container. Die vxlan-stitched-Variante kombiniert den Tunnel mit tc-Regeln zwischen einer veth-Verbindung und dem vxlan-Tunnel, so dass der Container ein gewöhnliches Ethernet-Interface sieht.

Über die vxlan-Link-Typen koppelt Containerlab Lab-Knoten unterschiedlicher Hosts zu einer einzigen Topologie. Damit baut der Operator Multi-Site-Szenarien mit zwei oder mehr Rechenzentren auf separater Hardware auf, die über ein routbares Underlay (zum Beispiel Wireguard oder direktes IP-Routing) miteinander sprechen.

Containerlab dokumentiert das Setup als Multi-Node Labs und erlaubt eine fast beliebige Verteilung der Knoten über Hosts hinweg. Der Typ dummy stellt zusätzlich eine virtuelle Schnittstelle ohne Gegenstelle bereit, was sich für Tests eignet, bei denen das Network Operating System einen Port sehen soll, ohne Pakete senden zu müssen.

Link-Impairments für realistische DCI-Bedingungen

Eine reine Topologie-Definition reicht für Funktionstests, ein realistisches DCI-Verhalten verlangt jedoch Verzögerungen, Jitter und Paketverluste. Containerlab bringt den Befehl "containerlab tools netem set" mit, der über das Linux-Traffic-Control-Subsystem (tc) Link-Impairments auf jedem virtuellen Interface setzt.

Der Parameter "--delay" definiert die Round-Trip-Latenz, "--jitter" die Streuung, "--loss" die Paketverlustrate. Mit "containerlab tools netem reset" entfernt man sämtliche Impairments wieder, mit "containerlab tools netem show" listet er die aktuelle Konfiguration.

Damit lassen sich konkrete DCI-Strecken nachbauen. Ein Leaf-Spine-Verbund mit einer konfigurierten Latenz von zum Beispiel 20 Millisekunden zum zweiten Standort, einer Jitter-Vorgabe von einer Millisekunde und einem Paketverlust von 0,1 Prozent bildet typische Bedingungen einer Glasfaser-Verbindung über ein WAN ab. Tests mit BGP-Konvergenzzeiten, OSPF-Hello-Intervallen und vxlan-EVPN-Routenpropagation laufen damit unter Bedingungen, die der Produktion ähneln.

Digital Twin der Produktion mit Netbox-Integration

Containerlab bildet die Grundlage für einen Digital Twin der Produktion. Ein Digital Twin repliziert einen Ausschnitt oder die gesamte Produktion in einer virtuellen Umgebung und erlaubt Vorab-Tests von Änderungen, Migrationen und neuen Designs. Die Open-Source-Software „nrx“ liest die Inventardaten aus „Netbox“ und generiert daraus automatisch eine Containerlab-Topologie-Datei.

Das Mapping erfolgt über Tags in Netbox. Geräte mit einem definierten Tag landen in der Lab-Topologie, das Device-Type-Feld bestimmt das Containerlab-Kind. Eine Mapping-Datei steuert die Auflösung der Hersteller-Modelle auf die passenden Container-Images. Nach dem Erzeugen der YAML-Datei startet "containerlab deploy" das Lab, ein Configuration-Management-Tool (zum Beispiel ein Python-Script mit pynetbox und RESTCONF oder Ansible mit der Containerlab-Inventory-Datei) verteilt Konfiguration aus Netbox auf die Lab-Knoten.

Mit der branching-Funktion von Netbox isoliert der Operator anstehende Änderungen in einem eigenen Branch und testet sie zuerst gegen den Digital Twin. Erst nach erfolgreichem Test fließt der Branch in den Main-Branch und damit in die Produktions-Automation zurück. Das Verfahren entspricht einem klassischen „Gitops“-Workflow für Netzwerkinfrastruktur und reduziert das Risiko von Konfigurationsfehlern im Produktivbetrieb.

CI/CD-Pipelines und Skalierung über Clabernetes

Das Single-Binary-Konzept und die deklarativen YAML-Topologien machen Containerlab zu einem Testbed für CI/CD-Pipelines. „Gitlab CI“, „Github Actions“ und beliebige andere CI-Systeme starten Lab-Topologien mit einem einzigen Kommando. Jeder Pipeline-Run baut das Lab frisch auf, prüft Routing-Tabellen, BGP-Sessions oder gRPC-Telemetrie und baut die Topologie nach dem Test wieder ab. „Github Codespaces“ binden die Cloud-IDE in den Workflow ein, so dass ein Pull-Request automatisch einen Container mit Containerlab samt Lab-Topologie startet und der Reviewer den Stand direkt in der Cloud begutachtet.

Für Topologien, die einen einzelnen Host übersteigen, gibt es „Clabernetes“. Die Komponente nimmt eine Containerlab-Topologie entgegen und verteilt die Knoten als Pods über einen Kubernetes-Cluster.

Damit skalieren Labs über die Grenzen einer einzelnen Maschine hinaus und nutzen vorhandene Kubernetes-Infrastruktur als Lab-Ressource. Die „Visual-Studio“-Code-Extension ergänzt den Workflow um eine grafische Topologie-Ansicht, Live-Validierung der YAML-Dateien und SSH-Buttons für jeden Knoten.

(ID:50862899)