9. Das Netzwerk#

Die VLAN-Automatisierung lief drei Wochen lang im Labor. Drei Switches, je einer pro Hersteller, jeder Workflow erfolgreich. Das Team war zuversichtlich. Beim ersten Produktionslauf schlugen 23 der 800 Campus-Switches fehl. Alle HPE. Alle liefen auf einer Firmware-Version, die niemand dokumentiert hatte.

Das Playbook prüfte die Fehlerantwort jedes Geräts, nachdem die VLAN-Konfiguration übertragen worden war. Auf moderner HPE-Firmware gibt ein bereits vorhandenes VLAN den Fehlercode duplicate-vlan zurück. Auf dieser älteren Firmware-Version lieferte dieselbe Bedingung vlan-exists. Das Playbook war so geschrieben worden, dass es duplicate-vlan als Idempotenz-Signal behandelte, also als “das existiert bereits, das ist in Ordnung.” Es war nicht darauf ausgelegt, vlan-exists zu behandeln, und betrachtete diese Antwort daher als Fehler. Ein Drittel der HPE-Geräte meldete einen Fehler. Der Rollback lief sauber durch. Das Ticket des Anwendungsteams blieb weitere drei Stunden offen, während das Netzwerkteam manuell prüfte, welche Switches tatsächlich konfiguriert worden waren und welche nicht.

Die Automatisierung war nicht falsch. Das Netzwerk hatte eine Meinung, die niemand dokumentiert hatte.

Sechs Monate später hatte dasselbe Team eine containerlab-Topologie, die Gebäude B spiegelte: 24 Switches, passende Hersteller-Images, mit den HPE-Knoten auf der in der Source of Truth (SoT) gespeicherten Produktions-Firmware-Version. Beim ersten Testlauf des VLAN-Workflows gegen diese Topologie schlugen 8 HPE-Knoten mit genau diesem Fehlercode fehl. Das Team fügte vlan-exists zur Liste der idempotenten Antworten im HPE-Adapter hinzu. Erneuter Durchlauf: alle 24 Knoten erfolgreich. Produktions-Deployment: 800 Switches, null Fehler.

Der Unterschied war kein besserer Code. Es war eine Testumgebung, die die Realität abbildete.

Dieses Kapitel behandelt den Baustein, der in Teil 2 stets implizit vorhanden war: das Netzwerk selbst. Jeder bisher aufgebaute Baustein wurde vom Automatisierungsteam entworfen und verhält sich gemäß seinen dokumentierten Schnittstellen. Das Netzwerk wurde geerbt. Es hat Eigenheiten, unterschiedliche Schnittstellen, Firmware-Inkonsistenzen und Fähigkeiten, die je nach Hersteller, Plattform und Software-Generation variieren. Kapitel 9 behandelt zwei Fragen: Was brauchen wir vom Netzwerk, damit Automatisierung zuverlässig ist, und wie validieren wir Automatisierungslogik sicher, bevor sie die Produktion berührt?

9.1. Grundlagen#

9.1.1. Kontext#

Kapitel 3 stellte Das Netzwerk als einen der sieben Bausteine im NAF Framework vor: der einzige Baustein, den das Automatisierungsteam nicht “besitzt” (er liegt im Zuständigkeitsbereich des Netzwerk-Engineerings). Sie konfigurieren es, beobachten es und modellieren seinen Intent, aber sie haben das Betriebssystem, das Datenmodell oder die API-Schnittstelle nicht gebaut. Diese Abhängigkeit prägt jede Designentscheidung in der darüber liegenden Plattform.

Kapitel 5 behandelte den Schreibpfad des Executor im Detail: wie Automatisierungsrollen, parametrisierte Aufgaben und Idempotenz-Prüfungen funktionieren. Was Kapitel 5 als gegeben voraussetzt, ist dass das Gerät am anderen Ende eine zuverlässige, konsistente Schnittstelle bereitstellt. Kapitel 9 prüft, ob diese Annahme gilt, und was zu tun ist, wenn sie es nicht tut.

Kapitel 6 behandelte den Lesepfad des Collector: gRPC Network Management Interface (gNMI) Streaming-Telemetrie, SNMP-Polling und die Datennormalisierungspipeline. Kapitel 9 behandelt die geräteseitigen Voraussetzungen für diese Pfade: Was muss über das Netzwerkgerät wahr sein, damit der Collector zuverlässig davon lesen kann.

Kapitel 9 schließt Teil 2 ab. Die sechs vorangegangenen Kapitel haben die Automatisierungsplattform aufgebaut: einen Ort zum Speichern von Intent, eine Möglichkeit ihn auszuführen, eine Möglichkeit Ergebnisse zu beobachten, eine Engine zur Koordination von allem und Oberflächen, um es Konsumenten zugänglich zu machen. Dieses Kapitel behandelt das Ding, auf das die Plattform immer ausgerichtet war.

9.1.2. Ziele#

Drei Ziele definieren den Beitrag des Netzwerk-Bausteins zur Automatisierungsplattform:

1. Das gesamte Netzwerkinfrastrukturspektrum verstehen und navigieren. Jede groß angelegte Automatisierungsplattform kann gleichzeitig mit Campus-Switches, Data-Center-Fabrics, Cloud-VPCs, Kubernetes-Overlays, Overlay-Controllern und Legacy-Geräten kommunizieren. Jeder Typ stellt unterschiedliche programmierbare Schnittstellen bereit. Die Plattform muss alle davon handhaben, ohne sich auf eine einzige kleinste gemeinsame Nenner-Abstraktion zu reduzieren.

2. Automatisierungslogik validieren und neues Netzwerkarchitekturdesign unterstützen, bevor die Produktion berührt wird. Simulationsumgebungen dienen zwei Zwecken: Sie sind das Vor-Produktions-Gate, wo Logikfehler, Schnittstellenvertragsverletzungen und gerätespezifische Eigenheiten zu Kosten von Minuten im Labor statt Stunden in einem Produktionsvorfall abgefangen werden, und sie sind die Designumgebung, wo neue Netzwerkarchitekturen untersucht und validiert werden, bevor Hardware bestellt wird.

3. Die Automatisierungsplattform stabil halten, während sich das Netzwerk weiterentwickelt. Neue Hersteller werden hinzugefügt. Firmware-Versionen ändern sich. Neue Infrastrukturtypen kommen hinzu. Die Plattform muss so gestaltet sein, dass sie diesen Wandel durch Abstraktionsstrategien absorbiert, nicht durch Ad-hoc-Patches an jedem Workflow, wenn sich das Netzwerk ändert.

9.1.3. Säulen#

Drei Säulen unterstützen diese Ziele, eine pro Funktionalität:

1. Netzwerkinfrastrukturspektrum und programmierbare Schnittstellen: Die gesamte Bandbreite der Netzwerktypen, die die Plattform automatisieren muss, und die Schnittstelle, die jeder Typ dem Executor und Collector bereitstellt.
2. Simulations- und Testumgebungen: Die Werkzeugkette für die Vor-Produktions-Validierung. Wo verschiedene Lab-Umgebungstypen passen, wie sie sich mit dem Saga-Muster aus Kapitel 7 verbinden und wie man sie skaliert.
3. Abstraktionsstrategien: Strukturelle Ansätze, die es der Automatisierungsplattform ermöglichen, stabil zu bleiben, während sich das zugrunde liegende Netzwerk ändert, unabhängig von Hersteller, Plattformgeneration oder Schnittstellenprotokoll.

9.1.4. Geltungsbereich#

Im Geltungsbereich:

• Die Schnittstellen, über die Executor und Collector Netzwerkgeräte erreichen. Sowohl NETCONF als auch gNMI unterstützen Konfigurations- und Telemetrieoperationen; die Wahl zwischen ihnen pro Anwendungsfall hängt von operativen Stärken ab, nicht von Protokoll-Exklusivität. Das Protokoll wird oft zwischen Bausteinen geteilt; der Operationstyp unterscheidet sich.
• Die Testumgebungen und Methoden, die Automatisierung vor der Produktion validieren
• Abstraktionsstrategien für das Management von Multi-Vendor- und Multi-Plattform-Heterogenität
• Die Auswirkungen von Cloud, Kubernetes und Overlay-Networking auf das Automatisierungsdesign

Außerhalb des Geltungsbereichs:

• Konfigurationsgenerierung und Template-Rendering (Source of Truth (SoT), Kapitel 4)
• Ausführungsmechanik: Wie Automatisierungswerkzeuge eine Aufgabe ausführen (Executor, Kapitel 5)
• Die Telemetrie-Erfassungspipeline: Wie Metriken in die Zeitreihendatenbank fließen (Observability, Kapitel 6)

Die Grenze ist konsistent: Kapitel 9 behandelt die Netzwerkseite jeder Schnittstelle, nicht die Plattformseite.

9.2. Funktionalitäten#

Der Netzwerk-Baustein ist der einzige Baustein im NAF-Framework, den die Automatisierungsplattform nicht kontrolliert. Sie kann nur über das Netzwerk so kommunizieren, wie das Netzwerk es erlaubt. Jede Designentscheidung in den vorangegangenen fünf Kapiteln - wie Intent gespeichert wird, wie die Ausführung funktioniert, wie Telemetrie gesammelt wird, wie Workflows koordiniert werden, wie Konsumenten bedient werden - löst sich letztendlich in eine Frage auf, was das Netzwerkgerät am anderen Ende der Verbindung unterstützt. Dieses Kapitel untersucht diese Einschränkung direkt.

graph LR

    subgraph Ziele
        direction TB
        A1[Das gesamte Netzwerkinfrastrukturspektrum navigieren]
        A2[Automatisierung vor Produktion validieren]
        A3[Plattform stabil halten, während Netzwerk sich entwickelt]
    end

    subgraph Säulen
        direction TB
        B1[Netzwerkinfrastrukturspektrum und programmierbare Schnittstellen]
        B2[Simulations- und Testumgebungen]
        B3[Abstraktionsstrategien]
    end

    subgraph Funktionalitäten
        direction TB
        C1[Programmierbare Schnittstellen]
        C2[Simulations- und Testumgebungen]
        C3[Abstraktionsstrategien]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

9.2.1. Programmierbare Schnittstellen#

Das Netzwerk ist von Natur aus heterogen. Es ist keine einheitliche Sache. Es ist ein Spektrum von Infrastrukturtypen, die über Jahre angesammelt wurden, oft parallel von verschiedenen Teams aufgebaut (Eigentümerschaft und Organisationsgrenzen werden in Kapitel 13 behandelt), jeder mit eigenem Schnittstellenmodell, Abstraktionsniveau und Automatisierungsreifegrad. Eine moderne Automatisierungsplattform kann gleichzeitig Campus-Switches, Data-Center-Fabrics, Cloud-VPCs, Overlay-Controller, Kubernetes-Cluster, Service-Provider-WAN-Infrastruktur und von Hyperscalern verwaltete Weiterleitungsebenen umfassen. Die Plattform muss all das handhaben. Der Infrastrukturtyp bestimmt, welche Schnittstelle verfügbar ist; die Automatisierungsplattform passt sich dieser Realität an, statt eine einheitliche Schnittstelle zu fordern.

9.2.1.1. Das Netzwerkinfrastrukturspektrum#

Dies ist ein überblickartiger Überblick über verschiedene Netzwerkinfrastrukturszenarien, mit denen Sie möglicherweise umgehen müssen, abhängig von der Art Ihres Unternehmens:

• Campus- und Branch-Switching ist das Kernszenario, das ich als Beispiel in Teil 2 verwendet habe: Multi-Vendor-physische Switches (Cisco, Arista, HPE, Extreme). Moderne Campus-Geräte stellen Command Line Interface (CLI), NETCONF und gRPC Network Management Interface (gNMI) gleichzeitig bereit. Der Automatisierungsreifegrad ist hoch für Geräte der letzten fünf bis sieben Jahre; er ist lückenhaft für Legacy-Geräte, die noch auf jahrzehntealter Firmware laufen.

• Data-Center-Fabric-Topologie ist typischerweise Leaf-Spine, oft von einer kleineren Herstellermenge: Arista, Cisco Nexus oder automatisierungsnative Open-Networking-Plattformen. Die Schnittstelleneinheitlichkeit ist höher als im Campus; das Change-Management ist strenger. EVPN/VXLAN-Overlays fügen eine Management-Ebene über der Fabric hinzu, die möglicherweise eine eigene API hat, getrennt von der einzelnen Geräteschnittstelle. SONiC-basierte Plattformen (Cisco 8000, Nvidia Spectrum) sind zunehmend in Hyperscaler-beeinflussten DC-Deployments präsent; ihre Konfigurationsschnittstelle ist eine strukturierte Datenbank statt CLI oder NETCONF und wird im Abschnitt über Abstraktionsstrategien weiter behandelt.

• Service-Provider- und WAN-Infrastruktur (Carrier-grade Router, MPLS-Netzwerke, Segment-Routing-Fabrics) hat eigene Automatisierungsherausforderungen: Skalierung, Protokollkomplexität und die doppelte Sorge um Control-Plane-Konfiguration und Traffic-Engineering-Policy. NETCONF und YANG-Modelle sind in diesem Bereich gut etabliert; Hersteller wie Cisco IOS-XR und Junos haben ausgereifte YANG-Abdeckung. Die Automatisierungsplattform zielt oft auf einen Controller (SR-PCE, Crosswork, NSO) statt auf einzelne Geräte.

• Cloud-Networking: AWS VPC, Azure VNet, GCP VPC und andere. REST-APIs mit Eventual-Consistency-Semantik. Es gibt kein Konzept “eine Konfiguration pushen” und auf eine synchrone Bestätigung warten. Der Executor behandelt asynchrone Operationen: erstellen, abfragen, verifizieren. Infrastructure-as-Code-Werkzeuge passen gut zu diesem Modell. Die Automatisierungsplattform muss das andere Konsistenzmodell berücksichtigen und keine synchrone Apply-and-Confirm-Semantik annehmen.

• SD-WAN und Overlay-Netzwerke (Cisco SD-WAN, Versa, VMware VeloCloud) werden Controller-managed betrieben. Das Automatisierungsziel ist die Controller-API, nicht das einzelne Gerät. Das physische Underlay existiert weiterhin, wird aber vollständig durch die Abstraktion des Overlays verwaltet. Das betrifft sowohl Ausführung als auch Observability: Der Executor schreibt Policy an den Controller; Telemetrie über Traffic, Pfadauswahl und Policy-Enforcement fließt ebenfalls über die Northbound-Schnittstelle des Controllers, nicht direkt von den physischen Underlay-Geräten.

• Kubernetes-Networking auf der CNI-Schicht kehrt das Gerätemodell vollständig um. Das Netzwerk wird durch Kubernetes-API-Objekte definiert: NetworkPolicy, Services, Ingress und Custom Resources von CNI-Plugins wie Cilium, Calico oder Flannel. Das Gerät verschwindet als Automatisierungsziel. Die Kubernetes-API ist die Schnittstelle. Netzwerkpolicies sind Code, keine Gerätekonfiguration. Dies ist das Modell, auf das andere konvergieren: deklarativer Intent, Controller-abgeglichener Zustand, kein direkter Gerätezugriff.

• DPUs und SmartNICs (Nvidia BlueField, Intel IPU, Marvell Octeon) repräsentieren eine Verschiebung, wo Netzwerkverarbeitung stattfindet. In modernen Data Centers werden DPUs neben CPUs auf jedem Server installiert, um Netzwerkfunktionen auszulagern: VXLAN-Kapselung, Verschlüsselung, Firewall-Policy-Durchsetzung, Load-Balancing und Mikrosegmentierung. Das lagert diese Funktionen von der Host-CPU und von Netzwerk-Appliances auf die SmartNIC-Firmware aus. Die Konsequenz für die Automatisierung: “das Netzwerkgerät” ist nicht mehr nur ein Switch oder Router im Rack. Funktionen, die früher über dedizierte Netzwerk-Appliance-APIs verwaltet wurden, werden jetzt über die DPU-Management-Ebene und das Hersteller-SDK verwaltet - eine neue Schnittstellenkategorie, die Standard-NETCONF- und gRPC Network Management Interface (gNMI)-Werkzeuge noch nicht sauber erreichen.

• Open Networking (SONiC, DENT, OPX) betreibt Network Operating System (NOS)-Software auf Commodity-Hardware. SONiCs Konfigurationsschnittstelle ist eine Redis-Datenbank mit einem Yet Another Next Generation (YANG)-strukturierten Schema, strukturell verschieden von CLI oder NETCONF und von Anfang an programmatisch ausgelegt. Zunehmend präsent in Hyperscaler-beeinflussten Data Centers und groß angelegten Enterprise-DC-Deployments. SONiC ist bemerkenswert, weil es von Anfang an für Automatisierung entworfen wurde: Die Schnittstelle ist eine strukturierte Datenbank, kein für programmatischen Zugriff angepasstes CLI.

• Virtuelle Netzwerkfunktionen koexistieren in vielen Umgebungen mit physischer Infrastruktur. Eine Software-Firewall, die Traffic über policy-definierte Pfade einschleust, ein virtueller Load-Balancer, der Trafficverteilung über Anwendungscluster verwaltet, ein Software-basierter BGP-Route-Reflector: Das sind alles Automatisierungsziele, die Management-Schnittstellen von Hersteller-REST-APIs bis NETCONF verwenden. Sie werden oft zusammen mit dem physischen Inventar über dasselbe SoT und denselben Executor verwaltet, benötigen aber separate Adapter-Pfade, weil ihre Schnittstellenmodelle von physischen Geräten abweichen.

• Wireless-Controller (Cisco DNA, Aruba Central, Juniper Mist) sind Controller-basiert; das Automatisierungsziel ist die Controller-API. Relevant immer dann, wenn VLAN-Provisionierung sich auf Wireless-SSIDs zusammen mit kabelgebundenen Switch-Ports erstreckt, wie es im Campus-Szenario der Fall wäre.

Der Punkt ist nicht, jeden Infrastrukturtyp erschöpfend aufzuzählen. Es geht darum festzustellen, dass eine Plattform, die ein nicht triviales Netzwerk automatisiert, gleichzeitig mit mehreren Typen interagiert. Der Executor und Collector müssen jede Operation an den richtigen Schnittstellentyp weiterleiten. Die Source of Truth (SoT) muss Intent auf einer Ebene über der einzelnen Schnittstelle modellieren. Die Komplexität des Netzwerks ist die Designbeschränkung, die die Plattform absorbieren soll.

9.2.1.2. Schnittstellentypen#

Jeder Infrastrukturtyp stellt einen oder mehrere Schnittstellentypen für die Automatisierungsplattform bereit. Derselbe physische Switch kann alle drei gleichzeitig bereitstellen. Die Plattform passt sich an, was verfügbar ist, mit Präferenzen, die Zuverlässigkeit, Struktur und Skalierung widerspiegeln. Kein Schnittstellentyp ist ein universelles Mandat; die richtige Wahl hängt davon ab, was das Gerät unterstützt und was die Operation erfordert.

• Command Line Interface (CLI) über Secure Shell (SSH) ist universell, legacy und fragil. Screen-Scraping und Textparser brechen, wenn Firmware-Updates die Ausgabeformatierung ändern oder neue Felder hinzufügen. Fehlercodes sind über Hersteller und Firmware-Versionen hinweg inkonsistent. CLI ist immer noch die einzige Option für ältere Geräte. Die Empfehlung ist, seine Verwendung zu minimieren und zu vermeiden, Workflows zu bauen, die darauf für mehr als die Geräte angewiesen sind, die keine Alternative haben (letzter Ausweg). Eine Interface-Beschreibung setzen sieht so aus:

interface GigabitEthernet0/1
 description uplink-to-core

• NETCONF ist strukturiert, transaktional und korrekt, wenn es funktioniert. Es unterstützt atomare Operationen und Rollback, und sein Datenmodell ist maschinenlesbar. Die Transportschicht ist generell zuverlässig; die Datenmodellschicht ist, wo die Lücken liegen. Die Qualität der YANG-Modelle der Hersteller variiert erheblich: Ein Gerät mag NETCONF-Unterstützung behaupten, aber unvollständige oder proprietäre Modelle für Funktionen haben, die die Plattform benötigt. IETF- und OpenConfig-YANG-Modelle standardisieren die Intent-Schicht; herstellernative YANG-Modelle füllen die Lücken. Dieselbe Interface-Beschreibung via NETCONF:

<config>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>GigabitEthernet0/1</name>
      <description>uplink-to-core</description>
    </interface>
  </interfaces>
</config>

• RESTCONF ist das HTTP-basierte Äquivalent von NETCONF, das dieselben YANG-Modelle verwendet, aber über REST-Semantik bereitgestellt wird. Es ist nützlich, wenn Teams mit HTTP-Werkzeuge vertrauter sind als mit NETCONFs XML/SSH-Transport. Das Datenmodell ist dasselbe; nur der Transport unterscheidet sich. Die Hersteller-Unterstützung ist weniger einheitlich als NETCONF. Dieselbe Interface-Beschreibung via RESTCONF:

PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1
Content-Type: application/yang-data+json

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/1",
    "description": "uplink-to-core"
  }
}

• gRPC Network Management Interface (gNMI) und gNOI sind gRPC Remote Procedure Call (gRPC)-basierte Protokolle. gRPC Network Management Interface (gNMI) übernimmt Telemetrie und Konfigurations-Lesen/Schreiben; gNOI übernimmt operative Befehle. Modern und skalierungsfreundlich. Die Hersteller-Unterstützung ist ausgereift bei Arista und neueren Cisco-Plattformen; sie ist lückenhaft bei HPE und Legacy-Geräten. Kapitel 6 behandelte gNMI aus der Collector-Perspektive. Kapitel 9 behandelt die geräteseitigen Voraussetzungen: Das Gerät muss gNMI-Subscriptions auf der OS-Version unterstützen, auf die die Plattform abzielt. Nvidia Spectrum Switches mit SONiC stellen gNMI nativ neben der CONFIG_DB-Schnittstelle bereit, was sie zu den automatisierungsfreundlichsten Plattformen sowohl für Konfiguration als auch Telemetrie macht. Dieselbe Interface-Beschreibung via gNMI SetRequest:

path:  /interfaces/interface[name=GigabitEthernet0/1]/config/description
value: "uplink-to-core"

• Hersteller-REST-APIs (eAPI, NX-API, Cumulus NVUE und ähnliche) sind maschinenlesbar, aber nicht über Hersteller hinweg standardisiert. Nützlich als Lückenfüller, wenn NETCONF oder gNMI für eine bestimmte Operation fehlt oder unvollständig ist. Nvidia Cumulus Switches stellen NVUE (eine strukturierte REST-API mit konsistentem JSON-Schema) als ihre primäre programmatische Schnittstelle bereit; Arista und Cisco Nexus stellen eAPI bzw. NX-API als Alternativen zu NETCONF bereit. Behandeln Sie diese als Adapter-Schicht-Anliegen, nicht als Grundlage für eine herstellerneutrale Plattform. Dieselbe Interface-Beschreibung via Arista eAPI (JSON-RPC über HTTPS):

{
  "jsonrpc": "2.0",
  "method": "runCmds",
  "params": {
    "version": 1,
    "cmds": [
      "interface GigabitEthernet0/1",
      "description uplink-to-core"
    ],
    "format": "json"
  },
  "id": "1"
}

• Cloud- und Controller-APIs folgen REST-Mustern mit Eventual Consistency. Das asynchrone Operationsmodell ist eine Designanforderung, keine Einschränkung, die umgangen werden soll. Für SD-WAN, Wireless und DPU-Management-Ebenen ist die Controller-API oft die einzige verfügbare Schnittstelle. Eine Beschreibung zu einem AWS VPC hinzuzufügen illustriert das Muster: eine getaggte Ressourcenaktualisierung, die asynchron übermittelt wird, ohne synchrone Bestätigung, dass die Änderung angewendet wurde:

POST https://ec2.eu-west-1.amazonaws.com/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AWS4-HMAC-SHA256 ...

Action=CreateTags
&ResourceId.1=vpc-0a1b2c3d4e5f67890
&Tag.1.Key=Description
&Tag.1.Value=uplink-to-core
&Version=2016-11-15

• Die Kubernetes-API ist deklarativ, Controller-abgeglichen und über Hersteller hinweg konsistent. NetworkPolicy, Services und CNI Custom Resources sind die Automatisierungsziele. Es gibt keinen direkten Gerätezugriff; der API-Server ist die einzige Schnittstelle. Eine Netzwerkisolierungsrichtlinie für den app-payments-Service:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-payments-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: app-payments
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app-payments

• SONiC CONFIG_DB (Redis) ist die native Schnittstelle für SONiC-basierte Plattformen. Statt eines Protokolls, das auf dem OS aufgesetzt ist, ist es der eigene Konfigurationsspeicher des OS: eine Redis-Datenbank mit einem YANG-strukturierten Schema. Die Automatisierung schreibt JSON-Einträge direkt in CONFIG_DB; der interne orchagent-Daemon von SONiC gleicht den Intent mit den Hardware-Weiterleitungstabellen ab. gNMI ist parallel für Telemetrie-Reads verfügbar. Dies ist architektonisch verschieden von CLI, NETCONF oder REST: Die Schnittstelle ist der Datenspeicher selbst. Abschnitt 9.2.3.4 behandelt dies ausführlicher. Dieselbe Interface-Beschreibung in CONFIG_DB via JSON-Patch (angewendet mit config load):

{
  "PORT": {
    "Ethernet0": {
      "description": "uplink-to-core",
      "admin_status": "up"
    }
  }
}

9.2.1.3. Schnittstellenauswahl pro Gerät#

Wenn ein Gerät mehrere Schnittstellen bereitstellt, muss die Plattform eine pro Operationstyp wählen und diese Wahl konsistent beibehalten. Ein Campus-Switch, der gleichzeitig Command Line Interface (CLI), NETCONF und gRPC Network Management Interface (gNMI) bereitstellt, erfordert eine Entscheidung, keinen Mix-and-Match-Ansatz, der je nach Workflow oder Ingenieurpräferenz variiert.

Empfohlene Hierarchie, angewendet pro Operationstyp. Sowohl gRPC Network Management Interface (gNMI) als auch NETCONF unterstützen Konfigurations-Writes und Telemetrie-Reads; die folgende Präferenz spiegelt operative Stärken wider, keine Protokoll-Exklusivität:

• gRPC Network Management Interface (gNMI) bevorzugt für Telemetrieerfassung (Streaming-Subscriptions, strukturiert, skalierungsfreundlich; gNMI Set ist auch ein valider Konfigurationspfad)
• NETCONF bevorzugt für Konfiguration (transaktional, Rollback-fähig; NETCONF get und get-config sind gleichwertig für Statuslesungen)
• RESTCONF oder Hersteller-REST-API als Fallback, wenn NETCONF für eine bestimmte Funktion unvollständig ist
• Command Line Interface (CLI) als letzter Ausweg nur für Legacy-Geräte

Was der Executor von der Schnittstelle braucht: Idempotency oder zumindest zuverlässige Fehlercodes, die “existiert bereits” von “fehlgeschlagen” unterscheiden, strukturierte Fehlerantworten und Statusverifizierungsfähigkeit nach dem Anwenden. Das HPE-Problem vlan-exists vs. duplicate-vlan war genau ein Versagen der zweiten Bedingung: Die Fehlercode-Semantik änderte sich zwischen Firmware-Versionen.

Was der Collector braucht: strukturierte Lesungen, Streaming-Telemetrie-Subscriptions und konsistente Datenmodelle, damit die Observability-Schicht keine gerätespezifischen Parser benötigt. gRPC Network Management Interface (gNMI) ist das bevorzugte Subscription-Protokoll, wo unterstützt: Es ist strukturiert, hierarchisch und Schema-validiert am Gerät, was das geräteweise Textparsing eliminiert, das das SNMP-Zeitalter dominierte. Aber jeder Subscription-Mechanismus, der strukturierte, zeitnahe Daten liefert, erfüllt dieselbe Funktion. SNMP-Polling bleibt für Legacy-Geräte valide, wo gNMI nicht verfügbar ist. Syslog liefert strukturierte Ereignisse für logbasierte Observability. OpenTelemetry (OTel) ist ein aufkommender Standard, den es zu beobachten gilt: ursprünglich für Anwendungs-Observability entworfen, gewinnt es als herstellerneutraler Transport für Netzwerktelemetrie, Metriken und Traces an Bedeutung. Die Protokollwahl des Collectors ist eine Funktion dessen, was das Gerät unterstützt; die Observability-Schicht sollte nicht wissen müssen, welcher Transport verwendet wurde.

Die Source of Truth (SoT) zeichnet den beabsichtigten Zustand für jedes Geräteattribut auf, auf dem die Plattform operiert: beabsichtigte VLAN-Konfiguration, beabsichtigte BGP-Nachbarschaftsbeziehungen, beabsichtigte Interface-Beschreibungen und beabsichtigte OS-Version. Die OS-Version verdient hier besondere Erwähnung, weil sie nicht nur die Konfigurations-Drift-Erkennung beeinflusst, sondern die Adapter-Pfadauswahl selbst: Der Executor verzweigt nach OS-Version, wenn sich dieselbe Firmware eines Herstellers zwischen Releases unterschiedlich verhält. Das ist kein Sonderfall für die OS-Version; es ist dasselbe Intent-versus-Realität-Muster, angewendet auf jedes Attribut, das die Plattform verwaltet. Die gewünschte OS-Version ist das, was das Operationsteam genehmigt hat; die laufende Version ist das, was Observability beobachtet. Wenn sie abweichen, ist diese Abweichung ein Signal: Das Gerät könnte hinter einem geplanten Upgrade zurückliegen, oder eine ungeplante Änderung ist aufgetreten. Die Plattform braucht beide Datenpunkte, um zu entscheiden, ob sie fortfahren oder blockieren soll.

Dieser Unterschied ist in der Praxis wichtig. Das SoT sagt, ein Gerät sollte AOS-CX 10.13 laufen. Der Collector meldet, dass es 10.12.1006 läuft. Die Plattform hat zwei Optionen: Ausführung blockieren, bis die OS-Version abgeglichen ist, oder mit dem 10.12-Adapter-Pfad fortfahren. Die richtige Antwort hängt von der Change-Management-Policy des Teams ab, aber die Plattform braucht beide Datenpunkte, um die Entscheidung zu treffen. Das SoT liefert den Intent; Observability liefert die Realität.

9.2.2. Simulations- und Testumgebungen#

Das Netzwerk ist Produktionsinfrastruktur. Anders als ein Anwendungs-Backend gibt es standardmäßig keinen Staging-Server zum Testen. Einen zu bauen ist die Aufgabe dieser Funktionalität.

Das Testen von Netzwerkautomatisierung war schon immer schwieriger als das Testen von Anwendungscode. Ein Netzwerk ist ein verteiltes System mit vielen Komponenten, die das Automatisierungsteam nicht kontrolliert: benachbarte ASes an Peering-Punkten, vorgelagerte Transit-Provider, kundenverwaltete CPE, Wireless-Clients und von Dritten betriebene Cloud-Infrastruktur. Ein Service-Provider, der eine Routing-Policy-Änderung testet, kann keinen Mock-BGP-Peer von einem Transit-Provider hochfahren, um das vollständige Verhalten zu validieren. Ein Unternehmen, das einen WAN-Failover-Workflow testet, kann nicht kontrollieren, wie der MPLS-Provider reagiert. Die in diesem Abschnitt beschriebenen Simulationsumgebungen sind der beste verfügbare Ersatz: Sie reproduzieren, was das Team kontrolliert, akzeptieren die Grenzen dessen, was sie nicht können, und fokussieren die Validierung auf die Logikschicht, wo Bugs tatsächlich leben.

Die Testpyramide aus Kapitel 2 (Unit, Integration, End-to-End) gilt direkt hier. Unit-Tests validieren individuelle Automatisierungsmodule in Isolation, typischerweise mit Mock-Geräteantworten. Integrationstests validieren mehrstufige Interaktionen: Die SoT-API gibt die erwartete Datenstruktur zurück, der Executor übersetzt sie korrekt, die Geräteantwort wird korrekt behandelt. End-to-End-Tests validieren den vollständigen Workflow gegen etwas, das sich wie ein echtes Netzwerkgerät verhält. Simulationsumgebungen sind die End-to-End-Schicht.

9.2.2.1. Umgebungstypen#

Die richtige Umgebung hängt davon ab, was der Test validieren muss. Es gibt ein Spektrum von kostengünstigen Umgebungen mit geringer Treue, die für routinemäßige CI/CD-Pipelines geeignet sind, bis hin zu Umgebungen mit hoher Treue, die es wert sind, für Produktions-Konfidenz-Tests zu investieren.

• Container-basierte Emulation verwendet leichtgewichtige Netzwerk-OS-Images, die als Container laufen und durch virtuelle Links verbunden sind. Der Topologie-Start dauert Sekunden. Es ist die praktische Standard-Wahl für routinemäßige CI/CD: Das Automatisierungsteam läuft denselben Workflow-Code gegen eine containerisierte Topologie bei jeder Änderung und fängt Logikfehler vor der Produktion ab. Data-Plane-Verhalten wird nicht repliziert, aber Control-Plane-Verhalten und Management-Schnittstellenverhalten reichen aus, um Automatisierungslogik zu testen.

• VM-basierte Emulation betreibt vollständige NOS-Images als virtuelle Maschinen. Sie bietet breitere Hersteller-Abdeckung, realistischeres NOS-Verhalten inklusive Data Plane und eignet sich für Protokoll-Design-Tests und Multi-Vendor-Interoperabilitätsszenarien. Der Kompromiss: höhere Ressourcenkosten, langsamerer Start und begrenzte Integration mit automatisierten Pipelines. Nicht praktisch für routinemäßige Commit-Level-Tests.

• Physische Hardware-Labs werden von vielen großen Organisationen betrieben: ein Rack echter Switches und Router, das oft die Produktionsarchitekturmuster spiegelt. Das bietet die höchste Treue für hardware-spezifische Verhaltensweisen, Performance-Tests und Szenarien, wo Emulation das Geräteverhalten nicht genau reproduziert. Die Kosten sind erheblich: Kapitalinvestition, Strom und Platz sowie der operative Aufwand, die Lab-Topologie mit der Produktionsarchitektur synchron zu halten. Labs, die von Produktionsmustern abweichen, vermitteln falsches Vertrauen. Der Wert ist real; die Wartungsdisziplin ist die Herausforderung.

• Digitale Zwillinge sind lebende Replikate der Produktionstopologie, gespeist durch die Source of Truth (dieselben Gerätemodelle, Topologie und aktuelle beabsichtigte Konfiguration) und aktuellen Zustand aus Observability. Ein digitaler Zwilling spiegelt, wie die Produktion gerade tatsächlich aussieht, keine Annäherung. Die operative Kosten sind erheblich: Die Synchronisation zwischen dem digitalen Zwilling und der Produktion zu pflegen erfordert kontinuierliche Abgleichung. Es ist eine Reifegrad-Investition, geeignet für Teams, die ihre Plattform bereits im Maßstab validiert haben und das höchste Niveau an Vor-Produktions-Vertrauen benötigen.

Container-basierte Emulation ist der praktische Ausgangspunkt für die meisten Teams. Sie startet in Sekunden, integriert sich nativ mit CI/CD-Pipelines und deckt moderne Campus- und Data-Center-Ausrüstung ab, die in der Mehrzahl der Automatisierungsanwendungsfälle verwendet wird. Die Investition in den Aufbau dieser Umgebung zahlt sich beim ersten Vorfall aus, den sie verhindert.

9.2.2.2. Werkzeugkette für container-basierte und VM-basierte Emulation#

Das container-basierte Ökosystem hat mehrere Werkzeuge mit unterschiedlichen Rollen, die oft verwechselt werden:

• containerlab instanziiert und verdrahtet container-basierte Netzwerk-OS-Images. Von Roman Dodin erstellt und in der Netzwerkautomatisierungsgemeinschaft weit verbreitet, hat containerlab sich zum De-facto-Standard für container-basierte Netzwerk-Labs entwickelt. Es orchestriert direkt Docker-Container (Arista cEOS, FRR, SONiC, VyOS und andere) und verbindet sie mit virtuellen Links, die in einer Topologiedatei definiert sind. containerlab startet die Topologie und liefert ein laufendes Lab in Sekunden. Eine minimale Drei-Knoten-Topologiedatei sieht so aus:

  Wenn Teams skalieren, wird das Ausführen von containerlab auf einer einzelnen Maschine zum Engpass. clabernetes verteilt containerlab-Topologien über einen Kubernetes-Cluster und ermöglicht mehrere Simulationsläufe parallel sowie die Skalierung des Vor-Produktions-Gates, während die Plattform wächst.

name: building-b-sim
topology:
  nodes:
    cisco-1:
      kind: ceos
      image: ceos:17.9.4
    arista-1:
      kind: ceos
      image: ceos:4.31.2F
    hpe-1:
      kind: vr-aoscx
      image: vrnetlab/vr-aoscx:10.12.1006
  links:
    - endpoints: ["cisco-1:eth1", "arista-1:eth1"]
    - endpoints: ["arista-1:eth2", "hpe-1:eth1"]

• netlab abstrahiert die Topologiedefinition oberhalb von containerlab. Von Ivan Pepelnjak erstellt, lässt netlab den Ingenieur beschreiben, was die Topologie erreichen soll, statt wie man sie verdrahtet: “diese drei Knoten betreiben BGP”, “diese Knoten sind im selben VLAN”. netlab interpretiert diese Beschreibung und rendert sie in eine containerlab-Topologiedatei plus erste Gerätekonfigurationen pro Hersteller. Denken Sie daran als deklarative Beschreibung des Labs: Der Ingenieur definiert den Service; netlab generiert die Infrastrukturdefinition. Wenn das Ziel ist, Automatisierungslogik gegen eine Topologie zu testen, die ein Produktionsnetzwerkmodell spiegelt, ist netlab der richtige Ausgangspunkt; containerlab ist das, was es instanziiert. Eine minimale netlab-Topologie für dasselbe Drei-Knoten-Szenario:

nodes:
  cisco-1:
    device: iosxe
    image: ceos:17.9.4
  arista-1:
    device: eos
  hpe-1:
    device: aoscx

links:
  - cisco-1:
    arista-1:
  - arista-1:
    hpe-1:

vlans:
  app-payments:
    id: 210
    links: [ cisco-1, arista-1, hpe-1 ]

• vrnetlab überbrückt container-basierte und VM-basierte Emulation. Manche Hersteller stellen keine nativen Container-Images bereit. vrnetlab verpackt Hersteller-VM-Images in Container und macht sie in einer containerlab-Topologie verwendbar. So testet man gegen ein Cisco IOS-XR- oder Junos-Gerät in einer containerlab-Umgebung, ohne zu einer VM-basierten Plattform zu wechseln.

• EVE-NG und GNS3 sind VM-basierte Emulationsplattformen mit breiter Hersteller-Abdeckung, GUI-basiertem Topologiedesign und vollständigem NOS-Verhalten inklusive Data-Plane-Forwarding. Der Kompromiss: höhere Ressourcennutzung, langsamerer Start und begrenzte CI/CD-Integration. Das sind die richtigen Wahlmöglichkeiten für Protokoll- und Design-Tests, Legacy-Plattformen und Multi-Vendor-Interoperabilitätsszenarien.

• Cisco Modeling Labs ist Ciscos kommerzielle VM-Lab-Plattform mit einer REST-API für partielle CI/CD-Integration. Die richtige Wahl für Cisco-zentrierte Umgebungen, die Zugang zu IOS-XE-, IOS-XR- und NX-OS-VMs in einem verwalteten, gemeinsam genutzten Lab benötigen.

9.2.2.3. Validierungsrahmen#

Die Validierung, dass ein Gerät ein bestimmtes Schnittstellenprotokoll oder einen YANG-Pfad korrekt unterstützt, ist Teil der in Kapitel 5 (Execution) und Kapitel 6 (Observability) beschriebenen Arbeit: Das Execution-Kapitel behandelt die Validierung von Konfigurationsschnittstellen, bevor man sich auf sie in Produktions-Workflows verlässt; das Observability-Kapitel behandelt die Validierung von Erfassungspfaden und die Bestätigung, dass Subscriptions Daten im erwarteten Format zurückgeben.

Ein Szenario verdient spezifische Behandlung im Simulationskontext: Wellen-Validierung. Nachdem die Simulation bestanden hat, aber bevor man sich zum vollen Produktionsumfang verpflichtet, führen manche Teams einen strukturierten Validierungspass gegen die erste Welle durch. pyATS bietet ein Test-Framework für das Schreiben strukturierter Geräteinteraktionstests mit reichem Parsing und Zustandsvergleich. Robot Framework ist ein breiteres schlüsselwortgetriebenes Testautomatisierungs-Framework mit netzwerkspezifischen Bibliotheken. Beide ermöglichen es einem Team, den erwarteten Post-Change-Zustand als ausführbare Assertions zu kodieren: Nach dem Deployment von VLAN 210 in Welle 1, bestätigen dass VLAN 210 auf allen Switches existiert, dass die Interface-Zuordnungen korrekt sind und dass die Observability-Schicht den erwarteten Zustand sieht. Das verbindet sich direkt mit Abschnitt 9.2.2.4: die strukturierte Validierungsschicht, die einen bestandenen Simulationslauf von echtem operativen Vertrauen vor dem Fortfahren zur nächsten Welle trennt.

Ein minimaler pyATS-Test, der VLAN-Präsenz nach dem Deployment bestätigt:

from pyats import aetest

class VlanValidation(aetest.Testcase):
    @aetest.test
    def verify_vlan_exists(self, device):
        output = device.parse('show vlan brief')
        assert 210 in output['vlans'], f"VLAN 210 missing on {device.name}"

    @aetest.test
    def verify_vlan_name(self, device):
        output = device.parse('show vlan brief')
        assert output['vlans'][210]['name'] == 'app-payments'

Dieselbe Prüfung in Robot Framework mit der NAPALM-Bibliothek, mit explizitem Setup und lesbaren Schlüsselwort-Namen:

*** Settings ***
Library    Collections
Library    napalm    WITH NAME    NAPALM

*** Variables ***
@{DEVICES}    cisco-1    arista-1    hpe-1

*** Test Cases ***
VLAN 210 Is Present On All Switches After Deployment
    FOR    ${hostname}    IN    @{DEVICES}
        Connect And Check VLAN    ${hostname}    210    app-payments
    END

*** Keywords ***
Connect And Check VLAN
    [Arguments]    ${hostname}    ${vlan_id}    ${vlan_name}
    NAPALM.Open    ${hostname}
    ${vlans}=    NAPALM.Get VLANs
    Dictionary Should Contain Key    ${vlans}    ${vlan_id}
    Should Be Equal    ${vlans}[${vlan_id}][name]    ${vlan_name}
    [Teardown]    NAPALM.Close

9.2.2.4. Simulation als Vor-Produktions-Saga-Tor#

Kapitel 7 beschrieb das Saga-Muster (Saga Pattern): einen mehrstufigen Workflow, bei dem jeder Schritt eine entsprechende Kompensationsmaßnahme hat, die ausgeführt wird, wenn ein späterer Schritt fehlschlägt. Die Saga behandelt Fehler in der Produktion. Simulation fügt den Schritt vor dem Beginn der Saga hinzu: den Workflow zuerst gegen eine Simulationsumgebung ausführen. Wenn der Simulationslauf fehlschlägt, erfolgt keine Produktionsänderung. Nur wenn die Simulation besteht, geht der Workflow zum Produktionsziel über.

flowchart LR
    SoT["SoT-Export (Topologie + OS-Versionen)"]
    Lab["Simulationsumgebung (containerlab-Topologie)"]
    Workflow["Workflow-Ausführung (gleicher Code wie Produktion)"]
    Pass{Bestanden?}
    Prod["Produktions-Ausführung (Orchestrator: voller Umfang)"]
    Fix["Untersuchen und beheben (kein Produktions-Impact)"]

    SoT --> Lab --> Workflow --> Pass
    Pass -- Ja --> Prod
    Pass -- Nein --> Fix --> Workflow

Das ist das Vor-Produktions-Tor: Simulation als erste Prüfung, bevor der Produktions-Saga-Umfang beginnt. Ein Fehler in der Simulation wird abgefangen, bevor ein Produktionsgerät berührt wird.

Praktische Implementierung:

1. Die Source of Truth exportiert die Topologiedefinition für den Zielumfang, einschließlich OS-Versionen pro Gerät.
2. Die Simulationsumgebung wird mit passenden Hersteller-Images instanziiert, wobei OS-Versionen auf den im SoT beabsichtigten Zustand gepinnt werden.
3. Derselbe Workflow, der in der Produktion laufen wird, läuft zuerst gegen das Simulationsziel.
4. Jeder Schritt, der in der Simulation fehlschlägt, löst eine Untersuchung aus, bevor die Produktionsausführung fortgesetzt wird.

Progressive Rollout-Wellen

Das Bestehen der Simulation bedeutet nicht, den gesamten Produktionsumfang auf einmal zu deployen. Für groß angelegte Rollouts ist die Simulation das erste Tor in einer Reihe progressiv größerer Wellen, jede mit ihrer eigenen Validierungsprüfung, bevor die nächste Welle fortgesetzt wird. Das ist eines meiner liebsten Muster, um Vertrauen bei kritischen Deployments aufzubauen, ähnlich dem beliebten Canary-Muster aus der Software-Entwicklung.

Ein Team, das einen neuen Workflow in 100 Data Centern deployed, könnte es so strukturieren: Simulation (virtuelle Topologie) → 1 Pilotstandort → 2 Standorte → 4 → 8 → 16 → verbleibende Standorte. Jede Welle validiert, dass der Workflow auf der vorherigen Welle korrekt ausgeführt wurde, bevor sie sich ausweitet. Wenn Welle 4 einen Fehler aufdeckt, den die Simulation nicht abgefangen hat (ein hardware-spezifisches Verhalten, ein standortspezifischer Zustand), stoppt der Rollout, das Problem wird behoben und die Wellensequenz setzt ab dem Fehlerpunkt fort.

flowchart LR
    Sim["Simulation"] --> W1["Welle 1 (1 Standort)"] --> W2["Welle 2 (2 Standorte)"] --> W3["Welle 3 (4 Standorte)"] --> W4["Welle N (voller Umfang)"]
    W1 -- Fehler --> Fix["Untersuchen + beheben"]
    W2 -- Fehler --> Fix
    W3 -- Fehler --> Fix
    Fix --> Sim

Der Orchestrator steuert die Wellenprogression. Das SoT scopt jede Welle nach Standort, Gebäude oder Gerätegruppe. Validierungstore zwischen Wellen sind explizite Workflow-Schritte: Der Orchestrator prüft die Observability-Schicht auf erwarteten Zustand, bevor er fortfährt. Dieses Muster gilt unabhängig davon, ob der Umfang 100 Data Center oder 800 Campus-Switches sind: Das Prinzip ist, den Explosionsradius eines unvorhergesehenen Fehlers zu begrenzen, während mit jeder erfolgreichen Welle Vertrauen aufgebaut wird.

Grenzen der Simulation: Container-Images reproduzieren nicht alle Firmware-Verhaltensweisen. Ein Container-Image läuft typischerweise mit aktuellem NOS-Code; ältere firmware-spezifische Eigenheiten sind möglicherweise nicht reproduzierbar, es sei denn, das Image ist auf eine bestimmte Version gepinnt. Simulation fängt Logikfehler, Schnittstellenvertragsverletzungen, Yet Another Next Generation (YANG)-Modell-Lücken und topologiebezogene Fehler ab. Es garantiert nicht, dass jeder mögliche Gerätezustand, der in der Produktion angetroffen wird, getestet wurde. Das Ziel ist signifikante Risikoreduktion, nicht null Risiko.

Das Snowflake-Problem: Simulation ist am zuverlässigsten, wenn das Produktionsnetzwerk konsistenten Architekturmustern folgt. Ein Netzwerk mit Hunderten individuell angepasster Konfigurationen, jede mit einzigartigem Zustand und Geschichte, ist schwieriger akkurat in der Simulation darzustellen. Das ist ein Grund, warum Automatisierungsarchitekturprinzipien (standardisierte Designmuster, Golden Templates, SoT-getriebene Konfiguration) Tests effektiver machen: Ein gut entworfenes Netzwerk ist besser simulierbar. Der Wert der Simulation potenziert sich mit der Qualität des Netzwerkdesigns, das es repräsentiert. Den Aufbau dieser Reproduzierbarkeit erfordert enge Partnerschaft mit Netzwerk-Ingenieuren, nicht nur Automatisierungs-Ingenieuren: Der Netzwerk-Ingenieur, der versteht, welche Standorte wirklich identisch sind und welche versteckte Ausnahmen tragen, ist derjenige, der die Simulation repräsentativ machen kann. Die Qualität der Simulation ist ein gemeinsamer Output der Netzwerkdesiplin und der Automatisierungsplattform.

9.2.3. Abstraktionsstrategien#

Das Netzwerk ist von Natur aus heterogen, und nicht nur in dem Sinne, dass sich Hersteller unterscheiden. Jede Automatisierungsplattform, die im Maßstab operiert, umfasst gleichzeitig physisches Switching, Cloud-Infrastruktur, Overlay-Controller, Service-Provider-WAN-Infrastruktur und Legacy-Geräte. Jedes spricht eine andere Sprache. Die Automatisierungsplattform darf nicht jedes Mal neu aufgebaut werden, wenn ein neuer Infrastrukturtyp hinzukommt.

Dieser Abschnitt handelt davon, die Automatisierungsschicht so zu gestalten, dass sie Veränderungen absorbiert statt darunter zu brechen: nicht nur die heutige Heterogenität zu handhaben, sondern für die Infrastrukturtypen zu gestalten, die nächstes Jahr hinzugefügt werden.

Moderne Automatisierungsplattformen erstrecken sich gleichzeitig über mehrere Infrastrukturdomänen. Die Architektur, die dies sauber handhabt, gilt unabhängig davon, ob der Betreiber ein großes Unternehmen, ein Service-Provider ist, der WAN und Kunden-Edge gleichzeitig verwaltet, oder ein Hyperscaler, der Data-Center-Fabric neben Cloud-Networking-Overlays betreibt. Der Schlüsselpunkt: Der Executor schreibt und der Collector liest durch dieselbe Geräteschnittstelle (gRPC Network Management Interface (gNMI)/NETCONF für physische Geräte, REST für Cloud und Controller), daher ist das Schnittstellenprotokoll ein gemeinsames Anliegen für beide Bausteine, keine separate Designentscheidung pro Baustein.

flowchart LR
    SoT["Source of Truth"]
    Orch["Orchestrator"]
    Obs["Observability"]

    subgraph Physische["Physische Domäne"]
        PhysIF["Netzwerkschnittstelle (NETCONF/gNMI)"]
        PhysNet["Campus, DC-Fabric, WAN-Geräte"]
        PhysIF --- PhysNet
    end

    subgraph Cloud["Cloud-Domäne"]
        CloudIF["Netzwerkschnittstelle (async REST)"]
        CloudNet["Cloud-VPCs / Networking"]
        CloudIF --- CloudNet
    end

    subgraph Overlay["Overlay-Domäne"]
        OvIF["Netzwerkschnittstelle (Controller-API)"]
        OvNet["SD-WAN / MPLS PCE / Overlay"]
        OvIF --- OvNet
    end

    SoT --> Orch
    Orch -->|Executor schreibt| PhysIF
    Orch -->|Executor schreibt| CloudIF
    Orch -->|Executor schreibt| OvIF
    PhysIF -->|Collector liest| Obs
    CloudIF -->|Collector liest| Obs
    OvIF -->|Collector liest| Obs

Die Source of Truth modelliert den vollständigen Intent über alle Topologietypen als einheitliches Servicemodell. Der Orchestrator enthält Verzweigungen nach Netzwerkdomäne. Der Executor leitet basierend auf SoT-Daten an den richtigen Adapter weiter. Observability erstreckt sich über alle Schichten und speist unabhängig vom zugrunde liegenden Infrastrukturtyp dieselbe Datenpipeline.

Die entscheidende architektonische Disziplin: Die Verzweigung erfolgt im Executor und Orchestrator, nicht im SoT. Das SoT hält ein einziges Intent-Modell für den Service. Wie dieser Intent auf verschiedenen Infrastrukturtypen realisiert wird, ist ein Executor-Anliegen.

9.2.3.1. Dimensionen der Heterogenität#

Bevor man eine Abstraktionsstrategie wählt, hilft es, die Achse der Heterogenität zu verstehen, die diese Strategie absorbieren muss. Nicht alle Heterogenität ist dasselbe Problem.

Jede Zeile ist eine Unterschiedsachse, die die Plattform handhaben muss, ohne dass das SoT sie kodieren muss. Das Intent-Modell bleibt einheitlich; Executor und Orchestrator absorbieren die Variation. Die Strategien in den folgenden Abschnitten behandeln wie.

9.2.3.2. Adapter-Muster im Executor und Collector#

Der häufigste Ausgangspunkt und die am weitesten implementierte Strategie. Ein Automatisierungsmodul pro Hersteller, alle akzeptieren dieselbe Eingabedatenstruktur aus dem SoT. Das SoT speichert herstellerneutralen Intent; die Adapter-Schicht des Executors übersetzt pro Hersteller zur Ausführungszeit. Dasselbe Prinzip gilt für den Collector: ein Erfassungsmodul pro Hersteller oder Protokoll, alle liefern eine normalisierte Datenstruktur an die Observability-Pipeline. Ein Hersteller, der gNMI spricht, verwendet einen Adapter; ein Hersteller, der SNMP-Polling oder proprietäres REST erfordert, verwendet einen anderen. Die Observability-Schicht sieht dasselbe Datenschema unabhängig von der vorgelagerten Erfassungsmethode.

flowchart LR
    SoT["SoT-Intent (herstellerneutral): vlan_id=210, vlan_name=app-payments"]
    Exec["Executor"]
    CiscoA["Cisco-Adapter: IOS-XE NETCONF"]
    AristaA["Arista-Adapter: eAPI / EOS"]
    HPEA["HPE-Adapter: NETCONF + OS-Versions-Fehlerbehandlung"]
    CiscoD["Cisco Catalyst"]
    AristaD["Arista 7050"]
    HPED["HPE Aruba 6300"]

    CollGNMI["Collector: gNMI-Adapter"]
    CollSNMP["Collector: SNMP-Adapter"]
    Obs["Observability-Pipeline (normalisiertes Schema)"]

    SoT --> Exec
    Exec --> CiscoA --> CiscoD
    Exec --> AristaA --> AristaD
    Exec --> HPEA --> HPED

    CiscoD --> CollGNMI --> Obs
    AristaD --> CollGNMI
    HPED --> CollSNMP --> Obs

Praktisch zu bauen und gut verstanden. Der Wartungsaufwand wächst, wenn das Geräteinventar sich diversifiziert: Jeder neue Hersteller oder jede neue OS-Version erfordert einen neuen oder aktualisierten Adapter. Das Adapter-Muster (Adapter Pattern) skaliert gut für eine definierte Herstellermenge; es wird lästig, wenn die Plattform einen großen und häufig sich ändernden Gerätekatalog unterstützen muss.

9.2.3.3. Community- und industrie-gesteuerte YANG-Modelle#

Zwei Industrieorganisationen veröffentlichen die herstellerneutralen YANG-Modelle, die die Adapter-Arbeit pro Hersteller reduzieren. IETF-Modelle (als RFCs und Internet-Drafts veröffentlicht) definieren grundlegende Datenstrukturen: ietf-interfaces, ietf-routing, ietf-bgp. OpenConfig-Modelle, entwickelt von einem Betreiber-Konsortium (Google, AT&T, Deutsche Telekom und andere), decken ähnliches Terrain mit einem operativ fokussierteren Schema und schnelleren Iterationszyklen ab. Beide ermöglichen es der Automatisierungsplattform, Intent einmal gegen ein Standardmodell zu schreiben und zu erwarten, dass es auf jedem konformen Gerät funktioniert.

Ein YANG-Modul, das eine Schnittstelle definiert, sieht so aus (vereinfacht aus ietf-interfaces):

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name      { type string; }
      leaf description { type string; }
      leaf enabled   { type boolean; default true; }
    }
  }
}

Dieselbe Struktur erscheint in OpenConfig (openconfig-interfaces) und in herstellernativen Modellen, aber mit unterschiedlichen Pfaden, unterschiedlichen Leaf-Namen und unterschiedlicher Standard-Semantik. Das YANG-Modul definiert das Schema; das Protokoll (NETCONF oder gNMI) transportiert die Daten; die Adapter-Schicht bildet zwischen dem Standard und der Hersteller-Realität ab.

Die praktische Realität von OpenConfig: Hersteller-Implementierungen variieren in der Vollständigkeit. Ein Gerät mag OpenConfig-Unterstützung behaupten, aber nur eine Teilmenge des Modells implementiert haben: Lesen funktioniert, Schreiben nicht; oder das Interface-Modell funktioniert, aber das BGP-Modell fehlt.

Jenseits fehlender Pfade ist das heimtückischere Problem inkonsistente Daten. Ein Gerät gibt einen Wert für einen OpenConfig-Pfad zurück, aber in der falschen Einheit, mit einem anderen Typ oder mit Feldern, die null sein sollten, aber mit herstellerspezifischen Standardwerten gefüllt sind. Eine gRPC Network Management Interface (gNMI)-Subscription, die im SAMPLE-Modus funktioniert, kann im ON_CHANGE-Modus auf demselben Gerät still versagen.

Das sind keine seltenen Grenzfälle. Sie sind die alltägliche Realität des Betriebs einer Multi-Vendor-Plattform, die sich in der Produktion auf OpenConfig verlässt. Der Standard funktioniert auf dem Papier; die Hersteller-Implementierung erfordert dieselbe geräteweise Untersuchung, die der Standard beseitigen sollte. OpenConfig reduziert diese Arbeit erheblich, beseitigt sie aber nicht. Planen Sie geräteweise Tests ein, bevor Sie sich auf einen neuen OpenConfig-Pfad in der Produktionsautomatisierung verlassen.

Eine Anmerkung zu YANG-Modellfamilien

Drei Familien von Yet Another Next Generation (YANG)-Modellen koexistieren in Produktionsnetzwerken, und das Verständnis der Unterschiede ist wichtig für die Wahl, welche anzusteuern:

• IETF-Modelle werden durch den IETF-Standardisierungsprozess entwickelt und als RFCs oder Internet-Drafts veröffentlicht. Sie sind die grundlegenden Standards: ietf-interfaces, ietf-routing, ietf-bgp. Die Akzeptanz ist breit, aber langsam; der Prozess ist gründlich, dauert aber Jahre. Hersteller-Implementierungen kommen oft zwei bis vier Jahre nach der Veröffentlichung.
• OpenConfig-Modelle werden vom OpenConfig-Konsortium entwickelt, einer betreibergesteuerten Gruppe (Google, AT&T, Deutsche Telekom und andere). OpenConfig iteriert schneller als IETF und ist operativ fokussierter. Es deckt viele derselben Funktionsbereiche wie IETF-Modelle ab, aber mit unterschiedlichen Schema-Design-Entscheidungen. Die meisten Produktions-gNMI-Deployments verwenden OpenConfig-Pfade.
• Herstellernative Modelle sind jedes Herstellers eigene Erweiterungen: cisco-ios-xe-native, junos-conf-root, arista-eos-augments. Diese stellen Funktionen bereit, die die Standardmodelle nicht abdecken, und sind oft für alles erforderlich, was über die kleinsten gemeinsamen Nenner-Funktionen hinausgeht, die IETF und OpenConfig adressieren. Nokia ist ein Extremfall: Fast alle operativen Daten auf SR OS sind nur über Nokia-spezifische YANG-Modelle zugänglich (nokia-conf, nokia-state). Die Standardmodelle decken eine dünne Oberfläche ab; herstellernative Modelle sind für jede sinnvolle Automatisierung auf dieser Plattform zwingend.

Abstraktion erkauft Uniformität auf Kosten des Feature-Zugangs. Jeder Hersteller hat proprietäre Fähigkeiten ohne Äquivalent in Standardmodellen. Ein Team, das OpenConfig verwendet, muss wählen: das Feature ignorieren, eine Hersteller-Erweiterung hinzufügen oder einen herstellerspezifischen Override-Pfad pflegen. Es gibt keine saubere Antwort. In der Praxis konzentriert sich die meiste Automatisierungsarbeit auf Funktionen, die gut von Standardmodellen abgedeckt werden (VLANs, BGP, Interfaces); proprietäre Features sind wichtig, aber selten der Kern-Anwendungsfall. Standards kommen auch mit Akzeptanzverzögerung: Ein Hersteller implementiert möglicherweise ein IETF-Modul zwei bis vier Jahre nach der Veröffentlichung, und nur auf neueren Plattformen. Verknüpfen Sie Feature-Nutzung an die im SoT aufgezeichnete OS-Version, statt einheitliche Unterstützung anzunehmen.

9.2.3.4. SONiC und Open Networking#

SONiCs Konfigurationsschnittstelle ist eine Redis-Datenbank mit einem YANG-strukturierten Schema: einheitlich, programmatisch und von Anfang an für Automatisierung entworfen. Die herstellerspezifische Adapter-Arbeit, die in Multi-Vendor-physischen Umgebungen Aufwand verbraucht, gilt hier nicht. Dieselbe Automatisierungslogik funktioniert über alle SONiC-basierten Plattformen hinweg unabhängig vom zugrunde liegenden Hardware-Hersteller.

Ein VLAN-Eintrag in der SONiC CONFIG_DB sieht so aus:

{
  "VLAN": {
    "Vlan210": {
      "vlanid": "210"
    }
  },
  "VLAN_MEMBER": {
    "Vlan210|Ethernet0": {
      "tagging_mode": "untagged"
    }
  }
}

Dieses JSON wird direkt über sonic-cfggen oder die SONiC-Management-REST-API in Redis geschrieben. Es gibt kein CLI zum Parsen, kein XML zum Konstruieren. Die Automatisierungsplattform schreibt strukturierte Daten; SONiCs orchagent gleicht sie mit den Hardware-Weiterleitungstabellen ab.

Das ist die Designrichtung, für die Open Networking eintritt: eine Netzwerkschnittstelle, die für Automatisierung entworfen wurde statt dafür angepasst zu werden. Teams, die SONiC-basierte Plattformen neben traditionellen Geräten einführen, werden den SONiC-Adapter am einfachsten zu schreiben und am zuverlässigsten zu betreiben finden.

• Hersteller-Angebote: SONiC hat sich weit über seine Microsoft-Azure-Ursprünge hinaus entwickelt. Die meisten großen Switch-Silicon-Hersteller bieten jetzt SONiC-basierte Plattformen an: Microsoft Azure SONiC (die vorgelagerte Referenz), Arista mit SONiC-kompatiblen Management-APIs auf ausgewählten Plattformen, Cisco 8000 Series mit Broadcom-basierter SONiC-Unterstützung, Dell OS10 (das eine SONiC-abgeleitete Architektur verwendet), Nvidia Spectrum-Plattformen, die SONiC als erstklassige Option betreiben, und eine wachsende Anzahl von ODM-Herstellern (Edgecore, Celestica, UfiSpace), die markierte SONiC-Plattformen liefern. Das Ökosystem hat sich so weit entwickelt, dass eine SONiC-basierte Plattform auf jeder Preis- und Performance-Stufe kommerziell verfügbar ist.

• Ausgereifte Anwendungsfälle: Data-Center-Leaf-Spine-Fabrics sind das am weitesten etablierte Deployment. Hyperscaler betreiben SONiC seit über einem Jahrzehnt im Maßstab; Enterprise-Data-Centers folgen jetzt. EVPN/VXLAN-Overlay, BGP-Routing, ECMP-Load-Balancing und 400G/800G-Interface-Unterstützung sind gut validiert. Die Automatisierungsgeschichte ist stark: gNMI, YANG und das Redis-gestützte CONFIG_DB sind native Schnittstellen. Eine SONiC-Flotte kann mit denselben Werkzeugen verwaltet werden, die jede andere gNMI-fähige Plattform verwalten.

• Neue Horizonte: SONiC beginnt, außerhalb der traditionellen DC-Fabric aufzutauchen. Disaggregierte Routing-Plattformen (wo SONiC auf hochport-Routern statt nur Switches läuft) erweitern das Open-NOS-Modell auf Routing-Anwendungsfälle. SONiC enthält jetzt Segment-Routing-Unterstützung: SRv6 (Segment Routing über IPv6) ist in upstream SONiC verfügbar und wird in der Produktion von Service-Providern verwendet, die SONiC-basierte Plattformen für Traffic-Engineering und Network-Slicing betreiben. Manche Service-Provider evaluieren SONiC auch für Peering-Edge und Breitband-Aggregation. Campus-SONiC-Deployments bleiben selten, sind aber technisch machbar; das Hardware-Ökosystem für Campus-Formfaktoren ist weniger ausgereift. Für Teams, die heute neue Plattformen aufbauen, ist die Frage nicht mehr, ob SONiC im DC produktionsreif ist: Das ist es. Die offene Frage ist, ob der SONiC-Fork des Herstellers und der Release-Rhythmus während der Lebensdauer der Plattform mit dem Upstream ausgerichtet bleiben werden.

9.2.3.5. Koexistenz während der Firmware-Migration managen#

Das Adapter-Muster setzt eine bekannte, stabile OS-Version pro Gerät voraus. Während eines rollierenden Firmware-Upgrades bricht diese Annahme: Geräte in derselben Rolle, verwaltet von derselben Automatisierungsplattform, betreiben tagelang oder wochenlang gleichzeitig unterschiedliche OS-Versionen. Die Abstraktionsschicht, die gestern auf Firmware 10.12 funktionierte, funktioniert möglicherweise auf Firmware 10.13 erst, nachdem ein neuer Adapter-Pfad hinzugefügt wurde.

Das SoT sollte die beabsichtigte OS-Version aufzeichnen (das Ziel nach der Migration) und der Collector sollte die aktuelle OS-Version als operativen Zustand surfacen. Bevor der Executor Konfiguration anwendet, sollte er die aktuelle OS-Version aus dem Collector oder der Observability-Pipeline lesen und den geeigneten Adapter-Pfad wählen, nicht die beabsichtigte Version als bereits deployed annehmen.

Ein konkreter Mechanismus: Der Executor fragt den Observability-Baustein (oder eine leichtgewichtige Vor-Ausführungs-Prüfung gegen das Gerät selbst) nach der laufenden OS-Version ab. Das Adapter-Register bildet OS-Versionsbereiche auf Adapter-Implementierungen ab. Der Executor ruft den richtigen Adapter basierend auf dem aktuellen Zustand auf, nicht auf SoT-Intent. Sobald ein Gerät upgraded ist und die laufende Version mit dem Intent übereinstimmt, stabilisiert sich die Adapter-Auswahl. Während des Migrationsfensters können zwei Adapter-Pfade für denselben Hersteller gleichzeitig aktiv sein.

Das Implementierungsbeispiel in Abschnitt 9.3 demonstriert dieses Muster direkt: Der HPE-Adapter-Bug wurde ausgelöst, weil eine Firmware-Version vlan-exists und eine andere duplicate-vlan für dieselbe Bedingung zurückgab. Die Behebung war eine versionsspezifische Fehlerbehandlung im Adapter-Register. Jede Automatisierungsplattform, die eine Multi-Versions-Flotte verwaltet, wird auf diese Art von Problem stoßen. Das Kodieren von versionsspezifischer Adapter-Logik, gesteuert durch die aktuelle OS-Version, die vom Collector gelesen wird, ist die systematische Gegenmaßnahme. Kapitel 11 behandelt, wie die OS-Versions-Zuordnungen als plattformweiter Katalog statt als playbook-spezifische Konstanten gepflegt werden.

Die organisatorische Implikation: Jemand muss die OS-Versions-Verfolgung im SoT, das Adapter-Versions-Register und den Upgrade-Sequenzierungs-Workflow besitzen. Diese drei Artefakte bilden das Upgrade-Automatisierungssystem. Ohne explizite Eigentümerschaft driften sie unabhängig und die Zuverlässigkeit der Plattform verschlechtert sich mit jedem Firmware-Release.

9.2.4. Das Netzwerk als Einschränkung für jeden Baustein#

Die drei in diesem Abschnitt behandelten Bereiche - programmierbare Schnittstellen, Simulationsumgebungen und Abstraktionsstrategien - sind keine isolierten Themen. Sie beschreiben den Einfluss des Netzwerks auf jeden Baustein im NAF-Framework.

Die Schnittstellenfähigkeiten des Netzwerks schränken ein, was der Executor tun kann: Ein Gerät, das nur CLI unterstützt, zwingt den Adapter des Executors in fragiles Screen-Scraping; ein Gerät mit ausgereifter gNMI-Unterstützung ermöglicht zuverlässige Konfiguration und Streaming-Telemetrie. Die Erfassungsunterstützung des Netzwerks schränkt ein, was der Collector aufnehmen kann: Ein Gerät, das einen benötigten OpenConfig-Pfad nicht implementiert, erfordert eine herstellerspezifische Umgehungslösung oder eine Erfassungslücke. Die Topologie des Netzwerks schränkt ein, was der Orchestrator sicher parallelisieren kann: Eine Batch-Größe, die für eine flache Access-Layer sicher ist, kann für eine Spine-Leaf-Fabric katastrophal sein, wo gleichzeitige Änderungen an mehreren Spine-Knoten das Netzwerk partitionieren können.

Das SoT-Datenmodell spiegelt diese Einschränkungen wider. OS-Versions-Felder steuern die Adapter-Auswahl. Schnittstellentyp-Felder steuern die Erfassungsmethode. Topologiebeziehungen steuern die Orchestrator-Parallelitätsregeln. Ein SoT, das das Geräteinventar aufzeichnet, ohne automatisierungsrelevante Attribute aufzuzeichnen (Schnittstellenfähigkeiten, OS-Version, Topologierolle), ist auf eine Weise unvollständig, die sich nur zur Ausführungszeit offenbart.

Jede architektonische Entscheidung in Teil 2 hat eine entsprechende Netzwerkschicht-Einschränkung, die dieses Kapitel aufdeckt. Das Netzwerk ist nicht nur das Ziel der Automatisierung. Es formt jeden Baustein, der auf es wirkt, und diese Einschränkungen müssen im Datenmodell der Plattform, der Adapter-Logik und der Workflow-Konfiguration kodiert sein. Automatisierung, die das Netzwerk als einheitliche Oberfläche behandelt, wird die Heterogenität ein fehlgeschlagenes Deployment nach dem anderen entdecken.

9.3. Implementierungsbeispiel#

9.3.1. Von der Simulation zur Produktion#

Der Campus-VLAN-Workflow ist bereit. Acht Wochen Entwicklung, drei Hersteller modelliert, Idempotenz gegen ein Drei-Knoten-Lab getestet. Das Team möchte ihn in der Produktion deployen: 800 Switches, Gebäude A bis F. Bevor das passiert, läuft er gegen die Simulation.

Dieses Beispiel folgt der Vor-Produktions-Tor-Sequenz, die in Abschnitt 9.2.2.4 beschrieben wird, unter Verwendung des Gebäude-B-Umfangs als Simulationsziel: 24 Switches, 8 Cisco, 8 Arista, 8 HPE.

Schritt 1: Topologie aus der Source of Truth exportieren

Das SoT enthält das Gebäude-B-Switch-Inventar mit beabsichtigten OS-Versionen:

• 8 Cisco Catalyst 9300: IOS-XE 17.9.4
• 8 Arista 7050: EOS 4.31.2F
• 8 HPE Aruba 6300: AOS-CX 10.12.1006 (ältere Firmware-Linie, pre-10.13)

Der SoT-Export produziert eine netlab-Topologiedefinition: Knotentypen, herstellerspezifische Image-Tags, die auf beabsichtigte OS-Versionen abgebildet werden, und den VLAN-Zustand, mit dem die Simulation starten soll (bestehende VLANs 100, 150 und 200 bereits auf allen Switches konfiguriert, den Produktionszustand spiegelnd).

Schritt 2: Die Simulationsumgebung instanziieren

netlab rendert den SoT-Export in eine containerlab-Topologiedatei. containerlab läuft auf einem gemeinsam genutzten Linux-Simulationshost in der CI-Umgebung des Teams (ein Bare-Metal-Server mit 64 GB RAM, ausreichend für 24 leichtgewichtige cEOS/vrnetlab-Container gleichzeitig). Die HPE-Knoten verwenden ein vrnetlab-verpacktes AOS-CX-Image, das auf 10.12.1006 gepinnt ist und der beabsichtigten OS-Version aus dem SoT entspricht. containerlab startet die Topologie. Alle 24 Knoten sind innerhalb von neunzig Sekunden oben und antworten auf NETCONF und gRPC Network Management Interface (gNMI).

Schritt 3: Den Kapitel-7-VLAN-Workflow gegen das Simulationsziel ausführen

Der Orchestrator löst den Workflow mit dem Simulationsinventar als Zielumfang statt des Produktionsinventars aus. Die ersten vier Workflow-Schritte werden ohne Probleme abgeschlossen:

• ServiceNow-Webhook empfangen, geparst, gegen SoT-Schema validiert
• Vor-Prüfung: VLAN 210 existiert nicht in der Simulation (korrekt)
• SoT mit VLAN-210-Intent aktualisiert
• Approval-Tor: im Simulationsmodus automatisch genehmigt

Der fünfte Workflow-Schritt, Fan-out-Ausführung über alle 24 simulierten Switches via Executor, liefert Fehler.

Ergebnisse: 8 Cisco-Knoten bestehen. 8 Arista-Knoten bestehen. 8 HPE-Knoten schlagen fehl.

Fehler von HPE-Knoten: vlan-exists. Die Idempotenz-Prüfung im HPE-Adapter behandelte duplicate-vlan als Keine-Operation, hatte aber keinen Handler für vlan-exists. Der Executor gab einen Fehler zurück, was die Saga-Kompensation auslöste: VLAN 210 von allen Knoten entfernt, die es empfangen hatten.

Es hat keine Produktionsänderung stattgefunden. Die Kosten des Fehlers sind die Container-Startzeit und eine dreißigminütige Untersuchung.

Schritt 4: Diagnostizieren und beheben

Das Team prüft die AOS-CX-10.12-Release-Notes. Der vlan-exists-Fehler wurde in 10.11.1 eingeführt und ersetzte duplicate-vlan für die Dupliziert-VLAN-Erkennung. Das 10.13-Release kehrte zu duplicate-vlan zurück, um die Konsistenz mit dem Rest der Aruba-Produktlinie zu wahren.

Behebung: vlan-exists zur Idempotenz-Fehlercode-Liste im HPE-Adapter hinzufügen. Das SoT wird mit einer Notiz zur OS-Versions-Grenze aktualisiert (10.11 bis 10.12.x gibt vlan-exists zurück; 10.13+ gibt duplicate-vlan zurück).

Vor dem erneuten Durchlauf kodiert das Team den erwarteten Post-Change-Zustand als pyATS- oder Robot-Framework-Test: Nach Abschluss des Workflows bestätigen, dass VLAN 210 auf allen 24 Simulationsknoten existiert und dass die Saga-Kompensation nicht ausgelöst wurde. Diese Assertion wird zu den Simulationsbestehens-Kriterien hinzugefügt: Das Simulationstor schließt sich nur, wenn sowohl der Workflow abgeschlossen ist als auch die Validierungsassertions bestehen.

Schritt 5: In der Simulation erneut ausführen

Der korrigierte Adapter läuft gegen dieselbe containerlab-Topologie. Alle 24 Knoten bestehen. Die Saga wird ohne Kompensation abgeschlossen. Das SoT zeigt VLAN 210 auf allen Gebäude-B-Knoten.

Schritt 6: Produktions-Deployment

Der Orchestrator löst denselben Workflow gegen den vollständigen Produktionsumfang aus: 800 Switches, Gebäude A bis F. Jeder Schritt läuft durch dasselbe Saga-Muster, das in der Simulation validiert wurde. Null Fehler auf HPE-Knoten. Das ServiceNow-Ticket des Anwendungsteams schließt sich automatisch, wenn der Orchestrator abgeschlossen ist. Die Observability-Schicht validiert die VLAN-210-Präsenz auf allen Interfaces im erwarteten Zeitfenster.

Was das demonstriert

Die Simulationsumgebung ist kein Verifizierungsschritt, der übersprungen werden kann, wenn sich das Team sicher fühlt. Sie ist das Vor-Produktions-Tor im Saga-Muster. Eine Simulationstopologie, die die Produktionstopologie und OS-Versionen spiegelt, ist die minimal viable Testumgebung für ein Team, das Automatisierung im Campus-Maßstab deployed. Die Investition ist containerlab-Setup, OS-Versions-gepinnte Images und ein SoT-Exportmechanismus. Die Rendite ist die Fähigkeit, gerätespezifische Bugs abzufangen, bevor sie zu Vorfällen werden.

Die Simulation fing diesen Bug nicht ab, weil das Testen ausgefallen war, sondern weil die OS-Version in der Simulation mit der Produktion übereinstimmte und die Plattform denselben Workflow-Code dagegen ausführte. Die Treue der Simulationsumgebung zum Produktionszustand ist das, was den Abfang möglich macht. Eine Simulationsumgebung, die die neuesten Hersteller-Images verwendet, hätte ihn verpasst.

Kapitel 10 behandelt, wie Simulationsumgebungen als Teil der Plattform operationalisiert werden: containerlab-Topologien in der Versionskontrolle pflegen, sie mit SoT-Exporten nach einem Zeitplan synchronisieren und sie in CI/CD-Pipelines integrieren, damit das Simulationstor automatisch bei jeder Workflow-Änderung ausgeführt wird.

9.4. Zusammenfassung#

Kapitel 9 schließt Teil 2 ab, indem es den Baustein behandelt, auf den die Automatisierungsplattform immer ausgerichtet war: das Netzwerk selbst.

Drei Ideen verankern das Kapitel.

Das Netzwerk ist nicht einheitlich. Jede groß angelegte Automatisierungsplattform interagiert gleichzeitig mit Campus-Switching, Data-Center-Fabric, Cloud-VPCs, Kubernetes-Overlays, Overlay-Controllern und Legacy-Geräten. Jedes stellt eine unterschiedliche Schnittstelle bereit, operiert unter unterschiedlicher Konsistenzsemantik und hat unterschiedliche Automatisierungsreife. Die Plattform absorbiert diese Heterogenität durch die Schnittstellenauswahl-Hierarchie (gRPC Network Management Interface (gNMI) für Telemetrie, NETCONF für Konfiguration, Command Line Interface (CLI) als letzter Ausweg), OS-Versions-Verfolgung in der Source of Truth und herstellerspezifische Adapter im Executor.

Simulationsumgebungen sind das Vor-Produktions-Tor. Container-basierte Emulation bietet realistische, schnelle, CI/CD-integrierte Umgebungen, in denen Automatisierungslogik gegen Topologie und OS-Versionen getestet wird, die die Produktion spiegeln. Fehler in der Simulation sind günstig. Fehler in der Produktion sind teuer. Die Treue der Simulationsumgebung zum Produktionszustand ist das, was das Tor bedeutsam macht.

Abstraktionsstrategien verlängern die Plattform-Lebensdauer. Das Adapter-Muster handhabt die heutige Multi-Vendor-physische Umgebung. OpenConfig und YANG-Übersetzung drängen in Richtung herstellerneutraler Modelle, die den langfristigen Adapter-Wartungsaufwand reduzieren. SONiC eliminiert die Adapter-Arbeit vollständig für Plattformen, die es unterstützen. Keine dieser Strategien bietet eine perfekte Antwort; jede beinhaltet Kompromisse zwischen Uniformität und Feature-Zugang. Die richtige Wahl hängt vom Gerätekatalog des Teams, der operativen Kapazität und davon ab, wie viel ihrer Automatisierungsarbeit in die Standard-Feature-Abdeckung fällt.

Mit Kapitel 9 ist Teil 2 abgeschlossen. Sechs Kapitel haben alle sieben Bausteine des NAF-Frameworks behandelt: Source of Truth, Collector und Observability (zusammen in Kapitel 6), Execution, Orchestration, Presentation und Das Netzwerk. Das sind keine unabhängigen Werkzeuge. Das SoT versorgt den Executor mit dem Intent, den er braucht, und den Collector mit dem erwarteten Zustand zur Validierung. Der Orchestrator sequenziert beides, handhabt Fehler und surfact Fortschritt zur Präsentationsschicht. Das Netzwerk sitzt unter all dem: die Einschränkung, die das Design jedes anderen Bausteins geprägt hat, und der Ort, wo Automatisierung letztendlich ein Ergebnis produziert oder scheitert.

Teil 3 wendet sich vom Aufbau der Bausteine zum Betrieb der Plattform im Maßstab: Engineering für Zuverlässigkeit, Gestaltung für Sicherheit und Compliance und Behandlung der Automatisierungsplattform als Produkt mit eigenem Lebenszyklus und operativen Anforderungen.

Referenzen und weiterführende Literatur#

• Network Programmability and Automation, Matt Oswalt, Christian Adell, Scott Lowe, Jason Edelman (O’Reilly, 2. Aufl. 2023). Der umfassendste praktische Leitfaden zu Netzwerkautomatisierungswerkzeugen, der NETCONF, gNMI, YANG-Modelle und Automatisierungs-Frameworks ausführlich behandelt.
• Network Programmability with YANG, Benoit Claise, Loe Clarke, Jan Lindblad (Pearson, 2019). Die definitive Referenz zu YANG-Datenmodellierung: wie IETF- und OpenConfig-Modelle strukturiert sind, wie man YANG-Module liest und schreibt und wie NETCONF und RESTCONF sie verwenden.
• Cisco pyATS: Network Test and Automation Solution, John Capobianco, Dan Wade (Cisco Press). Ein umfassender Leitfaden zu pyATS und Genie für Netzwerk-Testautomatisierung: Testskripte, Parser, strukturierte Zustandsvalidierung und CI/CD-Pipeline-Integration.
• Infrastructure as Code, Kief Morris (O’Reilly, 2. Aufl. 2021). Nicht netzwerkspezifisch, aber grundlegend für das Verständnis, wie die Prinzipien hinter reproduzierbarer, testbarer, versionskontrollierter Infrastruktur direkt auf das Netzwerkautomatisierungs-Plattformdesign anwendbar sind.

💬 Found something to improve? Send feedback for this chapter