Lab Reproduktion ist im Telco- und Provider-Engineering eine der zuverlässigsten Methoden, um Topologie- und Policy-Änderungen sicher vorzubereiten. Statt eine neue IGP-Hierarchie, BGP-Policy, Segment-Routing-Variante, EVPN-Design oder DDoS-Steering-Logik direkt in Produktion zu testen, wird die relevante Teil-Topologie in einer Laborumgebung nachgebildet – typischerweise mit Containerlab (containerbasiert, sehr schnell, Infrastructure-as-Code) oder EVE-NG (VM-basiert, visuell, sehr flexibel). Der entscheidende Punkt ist dabei nicht „wir haben ein Lab“, sondern wir können reale Effekte reproduzierbar nachstellen: Konvergenzzeiten, FRR/TI-LFA-Coverage, Route-Leaks, Prefix-Explosion, MTU-Blackholes, ECMP-Imbalance, RR-Partitionen oder Service-Chain-Asymmetrie. In Telco-Netzen ist das besonders wertvoll, weil viele Probleme erst im Zusammenspiel entstehen: zwischen Underlay und Overlay, zwischen Vendoren, zwischen Policies und Failure Domains. Ein gutes Lab ist deshalb topologie- und intentgetrieben: Es basiert auf einer Source of Truth (z. B. NetBox/CMDB), nutzt Blueprints und Templates, und ist so aufgebaut, dass Tests automatisiert laufen (Pre-/Post-Checks, Failure Scenarios). Dieser Artikel zeigt, wie Sie Topologie in Containerlab und EVE-NG modellieren, wie Sie sinnvolle Lab-Schnitte wählen (welche Teile müssen hinein, welche nicht), wie Sie Konfigurationen reproduzierbar erzeugen, und wie Sie mit einem Testkatalog die wichtigsten Risiken vor Changes erkennen – ohne dass das Lab zur Spielwiese wird.
Warum Lab-Reproduktion in Telco-Topologien so wichtig ist
Telco-Netze sind groß und heterogen: Core, Metro, Access, Interconnect, Service Edges, DC Fabrics. Jede dieser Domänen hat eigene Protokolle, Failure Domains und Betriebsrisiken. Viele Vorfälle entstehen durch scheinbar kleine Änderungen: ein BGP-Exportfilter, ein Timerprofil, ein MTU-Overhead, ein FRR-Tuning oder eine neue Route Reflector Hierarchie. Lab-Reproduktion reduziert dieses Risiko, weil sie die Wirkung sichtbar macht, bevor Kunden betroffen sind.
- Change Risk senken: Policies, Konvergenz und Failure Handling lassen sich vorab validieren.
- Interoperabilität testen: Multi-Vendor/Feature-Mix (z. B. EVPN, SR, BFD) lässt sich in kontrollierter Form prüfen.
- Evidence-by-Design: Expected vs. Observed wird dokumentierbar und wiederholbar.
- Training und Runbooks: NOC/Engineering kann Incident-Szenarien üben, ohne Produktionsrisiko.
Leitprinzip: Ein Lab ist ein Testinstrument, kein Simulationsfilm
Ein Lab muss nicht die ganze Welt nachbauen. Es muss die relevanten Abhängigkeiten und Failure Domains so abbilden, dass die Fragen des Changes beantwortbar sind.
Containerlab vs. EVE-NG: Wann welches Tool sinnvoll ist
Beide Plattformen können ähnliche Ziele erreichen, unterscheiden sich aber im Ansatz. Containerlab ist ideal für schnelle, wiederholbare Topologien als Code und passt hervorragend zu CI/CD und Intent Validation. EVE-NG ist stark, wenn Sie viele unterschiedliche Image-Typen, GUI-Workflows, komplexe Multi-VM-Setups oder Schulungsumgebungen benötigen. In vielen Organisationen existieren beide: Containerlab für Engineering-Pipelines, EVE-NG für visuelle Labs und komplexe Gerätevarianten.
- Containerlab: Schnell, leichtgewichtig, Git-freundlich, hervorragend für reproduzierbare Testläufe und kleine bis mittlere Topologien.
- EVE-NG: Sehr flexibel bei Image-Arten, GUI-orientiert, gut für Trainings und große visuelle Szenarien, meist höherer Ressourcenbedarf.
- Gemeinsame Stärke: Beide ermöglichen „Topology as Code/Artifact“ – wenn Sie Disziplin bei Versionierung und Templates haben.
- Praktische Realität: Containerlab für Standard-Router-Container und Automationsläufe, EVE-NG für exotische Images und komplexe Multi-VM-Szenarien.
Designregel: Entscheiden Sie nach Workflow, nicht nach Geschmack
Wenn Ihr Ziel CI-Checks und schnelle Iteration ist, ist ein codezentriertes Lab oft besser. Wenn Ihr Ziel visueller Unterricht und heterogene Images ist, liefert eine GUI-orientierte Plattform Vorteile.
Lab-Schnitt richtig wählen: Welche Topologie muss ins Lab?
Der häufigste Fehler ist, entweder zu viel oder zu wenig nachzubauen. Zu viel macht das Lab langsam, teuer und schwer zu pflegen. Zu wenig macht Ergebnisse wertlos, weil relevante Interaktionen fehlen. Ein guter Lab-Schnitt ist „minimal ausreichend“: er enthält die Komponenten, die das Verhalten bestimmen.
- Control-Plane Fokus: Für IGP/BGP/RR/TE reicht oft ein stark reduzierter Graph mit realistischen Rollen und Policies.
- Data-Plane Fokus: Für MTU/QoS/ECMP brauchen Sie Engpässe und repräsentative Pfade, nicht unbedingt alle PoPs.
- Service Fokus: Für VRFs, L2VPN/L3VPN, CGNAT/Firewall-Chain müssen Servicekanten und Symmetrie abgebildet sein.
- Failure Domains: Mindestens ein PoP-Cluster, eine Regionkopplung (DCI) und ein Interconnect-Edge, wenn diese im Change betroffen sind.
Ein pragmatisches Minimalprinzip
Wenn Sie einen Change validieren wollen, identifizieren Sie zuerst: Welche Protokolle, welche Policies und welche Engpässe bestimmen das Verhalten? Nur diese Teile gehören zwingend ins Lab.
Topologie als Code: Struktur, Namenskonventionen und Wiederverwendbarkeit
Damit Lab-Reproduktion nachhaltig ist, muss die Topologie als Artefakt versioniert werden: klare Ordnerstruktur, konsistente Geräte- und Linknamen, und Parameterisierung nach Regionen/PoPs. So können Sie denselben Blueprint für verschiedene Szenarien instanziieren, ohne jedes Lab neu zu bauen.
- Namensschema: Region-PoP-Rolle-Index (z. B. „DE-BER-CORE01“), analog zum Produktionsnetz.
- Link-Labels: Linkklasse (DCI/IXP/TRANSIT/ACCESS), um Policies und Tests zu steuern.
- Layer-Trennung: L1/L2/L3/Services in getrennten Dateien/Modulen, verknüpft über IDs.
- Parameterisierung: IP-Pools, ASNs, VRF-IDs, Communities als Variablen statt Hardcoding.
Anti-Pattern: Lab-Topologien ohne Identität
Wenn Geräte „R1/R2“ heißen und Links keine Bedeutung tragen, wird jeder Test zur Handarbeit. Identität und Labels machen Labs skalierbar.
Konfiguration reproduzierbar erzeugen: Templates, Blueprints und Source of Truth
Ein Lab wird erst dann wertvoll, wenn Konfigurationen konsistent sind. Handkonfiguration ist langsam und erzeugt Drift. Der bessere Weg ist: Blueprints und Templates, deren Variablen aus einer Source of Truth oder aus einem Lab-Datenmodell kommen. So können Sie dieselbe Renderlogik für Lab und Produktion nutzen, nur mit unterschiedlichen Scopes.
- Blueprint pro Rolle: Core (IGP, MPLS/SR, FRR), Edge (eBGP, Policies), PE (VRFs, RT/RD), RR (Hierarchy).
- Template-Inputs: Interfaces, IPs, ASNs, Peer-Typen, QoS/CoPP-Profile als strukturierte Daten.
- Config Rendering: „Render“ als reproduzierbarer Schritt, versioniert und testbar.
- Golden Defaults: Explizite Timerprofile, MTU-Standards, Guardrails (Max-Prefix, Export-Whitelist).
Designregel: Lab-Konfigs sollten „produktionsähnlich“ sein
Ein Lab ist kein Ort für kreative Sonderkonfigurationen. Nutzen Sie möglichst dieselben Blueprints und nur lab-spezifische Anpassungen (z. B. kleinere Prefix-Sets, reduzierte Kapazitäten).
Was im Lab wirklich getestet werden sollte: Ein Telco-Testkatalog
Der Testkatalog ist der Kern der Lab-Reproduktion. Statt „ping geht“, brauchen Sie Tests, die reale Risiken abdecken: Routing-Leaks, Konvergenz, FRR, Anycast-Verhalten, MTU und QoS. Ein guter Katalog ist in Pre-Checks (vor Change) und Post-Checks (nach Change) strukturiert und enthält Failure Scenarios.
- Routing-Guardrails: Export nur Whitelist, Max-Prefix aktiv, no-transit Policies, Community Contract.
- Konvergenz: IGP/BGP Stabilität, RR-Ausfalltests, Update-Raten, Flap-Resistenz.
- FRR/TI-LFA: Coverage-Checks (welche Links/Nodes sind geschützt), Failover-Pfadprüfung.
- ECMP/Hashing: Lastverteilung, Rehashing nach Link-Ausfall, Hotspot-Erkennung.
- MTU/PMTUD: Overlays/Labels, MSS-Clamping, Blackhole-Prevention.
- QoS: Klassentreue, Queue-Drops unter Last, Failover-Profil auf Backup-Pfaden.
- Services: VRF-Isolation, L2VPN/L3VPN Pfade, Service Chains (symmetrische Pfade bei stateful Funktionen).
Expected vs. Observed als Pflichtartefakt
Definieren Sie pro Test, was erwartet wird (Intent), und speichern Sie die beobachteten Ergebnisse. So wird das Lab zu einem Nachweisinstrument und nicht zu einem einmaligen Experiment.
Failure Scenarios im Lab: Link-, Node- und Region-Events reproduzieren
Telco-Designs müssen im Fehlerfall funktionieren. Deshalb sind Failure Scenarios nicht optional. Sie sollten mindestens Link-Ausfall, Node-Ausfall und eine Form von Region-/DCI-Störung testen. Ziel ist nicht, jeden denkbaren Fall zu simulieren, sondern die wichtigsten Failure Domains und Schutzmechanismen zu validieren.
- Link Down: Uplink aus, Ringsegment cut, DCI-Link weg; prüfen: FRR, Konvergenz, SLO-nahe KPIs.
- Node Down: Edge-Router aus, RR-Knoten aus, Aggregationsknoten aus; prüfen: Blast Radius und Stabilität.
- Partition: DCI isoliert, Managementpfad gestört; prüfen: Split-Brain-Risiken, RR-Consistency, Service-Fallback.
- Soft Failures: Congestion, Loss/Delay-Injected, MTU reduziert; prüfen: Degradation statt Ausfall.
Designregel: Erst „boring“ Failures, dann „nasty“ Failures
Beginnen Sie mit klaren Hard-Down-Events, dann testen Sie realistischere Soft Failures. Viele echte Incidents sind Degradations, keine Totalausfälle.
Kapazität und Realismus: Was Labs können und was nicht
Ein Lab kann nicht immer echte Line-Rate oder Bufferverhalten reproduzieren, insbesondere wenn virtuelle Images genutzt werden. Trotzdem kann es sehr wertvoll sein, wenn Sie wissen, was Sie messen können: Control-Plane-Verhalten, Policy-Wirkung, Konvergenzlogik, MTU-Overhead, path selection. Für QoS/Buffering sollten Sie Ergebnisse eher qualitativ (Correctness) als quantitativ (exakte Drops) interpretieren – oder gezielt Hardware-in-the-loop ergänzen.
- Sehr gut testbar: Routing Policies, Prefix-Filter, RR-Hierarchien, Konvergenzmechaniken, MTU/PMTUD.
- Eingeschränkt testbar: Exakte Queue-Drops, Microbursts, ASIC-spezifische Hashingdetails.
- Ergänzbar: Kleine Hardware-Pods oder Traffic-Generatoren für realistische Data-Plane-Tests.
- Wichtig: Ergebnisse als „Intent erfüllt/gefährdet“ bewerten, nicht als exakte Performance-Garantie.
Anti-Pattern: Lab-Ergebnisse 1:1 als SLA-Nachweis behandeln
Labs liefern starke Indikatoren, aber nicht immer exakte Performancewerte. Nutzen Sie Labs, um Risiken zu finden und Correctness zu beweisen, und ergänzen Sie Performance dort, wo Hardwareverhalten entscheidend ist.
Automatisierung: Labs in CI/CD und Intent Validation integrieren
Der große Hebel entsteht, wenn Lab-Reproduktion Teil Ihrer Change-Pipeline wird. Topologie wird als Code instanziiert, Konfiguration wird gerendert, Tests laufen automatisch, und nur bei „grün“ wird ein Canary-Deploy freigegeben. So wird das Lab von einer manuellen Übung zu einem systematischen Qualitätsprozess.
- Ephemeral Labs: Topologie für einen Testlauf hochfahren, testen, wieder abbauen – spart Ressourcen.
- Regression Tests: Bei jeder Policy-Änderung laufen Standard-Tests (Leaks, Max-Prefix, RR-Health).
- Canary Gate: Lab grün → Canary Domain in Produktion → Wellen-Rollout mit Stop/Go Gates.
- Evidence Archive: Testreports, Logs und „Expected vs. Observed“ versioniert speichern.
Designregel: Lab-Tests müssen schnell und deterministisch sein
Wenn Tests unzuverlässig oder zu langsam sind, verlieren sie Akzeptanz. Bauen Sie Tests so, dass sie reproduzierbar sind und in sinnvollen Zeitfenstern laufen.
Multi-Vendor im Lab: Interoperabilität gezielt prüfen
Gerade in Telco-Netzen ist Multi-Vendor häufig Realität. Labs sind ideal, um Interoperabilitätsrisiken zu prüfen: Timerprofile, BFD-Verhalten, BGP-Optionen, EVPN-Details, SR-Policies. Der Schlüssel ist ein Interop Blueprint: ein minimales, getestetes Feature-Set, das netzweit gilt, plus eine Version-Matrix.
- Interop Blueprint: Welche Optionen sind erlaubt? Welche sind verboten? Welche Defaults müssen explizit gesetzt werden?
- Version-Matrix: Unterstützte Kombinationen aus SW/HW/Images, keine Wildwüchse.
- Corner Cases: RR-Partition, Graceful Restart, ECMP-Multipath, EVPN DF-Handling – gezielt testen.
- Vergleichbarkeit: Gleiche Tests, gleiche Intents, gleiche Reports – unabhängig vom Vendor.
Anti-Pattern: Interop nur „Session up“ testen
Sessions sind der Anfang. Die Probleme kommen bei Failures, bei Scale, bei Policies und bei Upgrades. Testen Sie genau diese Dimensionen.
Typische Fallstricke und wie man sie vermeidet
- Lab zu groß: Lösung: minimaler Lab-Schnitt, Fokus auf relevante Failure Domains und Protokolle.
- Lab zu anders als Produktion: Lösung: gleiche Blueprints/Templates, nur kleinere Parameter; Rollen und Policies identisch.
- Manuelle Konfig: Lösung: Render-Pipeline, versionierte Templates, Source of Truth Inputs.
- Keine Tests: Lösung: Testkatalog als Pflicht, Pre-/Post-Checks, Failure Scenarios.
- Keine Dokumentation: Lösung: Expected vs. Observed, Reports versionieren, Lessons in Blueprints zurückspielen.
- Performance falsch interpretiert: Lösung: Correctness vs. Performance trennen, Hardwaretests ergänzen, wo nötig.
Praktische Leitlinien: Topologie in Containerlab/EVE-NG modellieren
- Mit dem Intent starten: Welche Fragen soll das Lab beantworten (Leak-Guardrails, FRR, MTU, EVPN, RR)? Daraus den Lab-Schnitt ableiten.
- Topologie als Code führen: Versionierung, Namensschema, Linklabels, Layer-Trennung und Parameterisierung.
- Produktionstreue Blueprints nutzen: Rollenbasierte Templates, explizite Timerprofile, Guardrails (Max-Prefix, Export-Whitelist).
- Testkatalog etablieren: Routing-/Policy-Checks, Konvergenz, FRR/TI-LFA, MTU/PMTUD, QoS-Correctness, Service-Intents.
- Failure Scenarios üben: Link/Node/Partition/Soft Failures, Expected vs. Observed dokumentieren.
- CI/CD integrieren: Ephemeral Labs für Regression Tests, Canary Gate vor Produktion, Evidence Archive.
- Multi-Vendor gezielt testen: Interop Blueprint und Version-Matrix, Corner Cases statt nur „Sessions up“.
- Realismus bewusst managen: Data-Plane-Performance nur dort bewerten, wo Lab es trägt; Hardwaretests ergänzen, wenn nötig.
- Ergebnisse operationalisieren: Findings in Blueprints, Policies und Runbooks zurückführen, damit das Lab dauerhaft Nutzen liefert.