Cisco YANG Modelle nutzen: Validierung und “Config as Data”

Cisco YANG Modelle nutzen ist der Schritt, der Netzwerkautomatisierung von „CLI-Skripten mit Parsern“ zu Config as Data hebt: Konfiguration wird nicht mehr als Text verstanden, sondern als strukturierter Datensatz mit Typen, Beziehungen und Validierungsregeln. Genau darin liegt der große Vorteil für Enterprise-Netze: Sie können Konfigurationen vor dem Ausrollen prüfen, Änderungen präzise diffen, Policies automatisiert erzwingen und Drift zuverlässig erkennen. Gleichzeitig ist YANG kein Selbstläufer. Viele Projekte scheitern, weil YANG-Modelle wie eine „andere Syntax für CLI“ behandelt werden oder weil OpenConfig, Cisco Native und Plattformfähigkeiten nicht sauber abgegrenzt sind. In der Praxis brauchen Sie ein klares Zielbild: Welche Bereiche werden modellgetrieben verwaltet (Interfaces, VRFs, Routing-Policies, Telemetrie, AAA/Management)? Welche Modelle gelten als Standard? Und wie sieht die Validierungskette aus, bevor ein Change ein produktives Gerät erreicht?

Dieser Artikel zeigt, wie Sie Cisco YANG Modelle professionell nutzen – mit Fokus auf Validierung und Config as Data. Sie lernen, wie YANG-Modelle aufgebaut sind (Container, Lists, Leafs, Keys), wie Constraint-Mechanismen (must/when, Typen, Patterns) für Preflight-Checks eingesetzt werden, wie Sie Model Coverage und Versionsdrift managen und wie Sie aus YANG-basierten Daten robuste Deployments über NETCONF/RESTCONF oder andere Controller-Workflows bauen. Der Fokus liegt auf einem Betriebsmodell, das skalierbar und auditierbar ist: Konfiguration als Datenobjekt in Git, Tests in CI, Rollouts in Wellen – und klare Regeln, wann CLI weiterhin sinnvoll ist.

Was „Config as Data“ wirklich bedeutet

„Config as Data“ heißt nicht nur, dass Konfiguration in YAML oder JSON geschrieben wird. Es bedeutet, dass Konfiguration als strukturierter Datensatz verstanden wird, der einem Schema entspricht. Dieses Schema ist in YANG definiert. Dadurch entsteht eine klare Trennung zwischen:

• Daten: Was soll konfiguriert werden? (z. B. Interface = up, MTU = 9000, VRF = BLUE)
• Modell: Wie ist diese Konfiguration strukturiert und welche Regeln gelten? (Typen, Keys, Constraints)
• Transport: Wie wird die Konfiguration zum Gerät gebracht? (z. B. NETCONF, RESTCONF)

In klassischen CLI-Welten ist diese Trennung unscharf: Der „Dateninhalt“ steckt im Text, das „Schema“ ist implizit in der Dokumentation und im Parser, und „Validierung“ passiert oft erst auf dem Gerät. Mit YANG wird das Schema explizit. Das ist die Grundlage, um Validierung nach links zu verlagern – also in die Pipeline, bevor der Change produktiv wird.

YANG-Grundlagen, die Sie im Betrieb wirklich brauchen

YANG ist eine Modellierungssprache. In der Praxis müssen Sie nicht jede Sprachfunktion im Detail kennen, aber einige Konzepte entscheiden darüber, ob Ihr „Config as Data“-Ansatz stabil wird.

• Container: Gruppiert Felder logisch (z. B. /interfaces).
• List: Wiederholbare Objekte mit Keys (z. B. /interfaces/interface[name=…] ).
• Leaf: Ein einzelnes Feld mit Datentyp (z. B. enabled=true).
• Key: Identifiziert eine List-Instanz eindeutig (z. B. Interface-Name, VRF-Name).
• Config vs. State: Viele Modelle trennen Konfiguration und Betriebszustand; Automationscode sollte diese Trennung respektieren.

Die formale Grundlage ist RFC 7950 (YANG 1.1). Für die Praxis ist wichtiger: Ihre Automationslogik muss konsequent mit Keys arbeiten und darf List-Instanzen nicht „halb“ definieren. Viele scheinbar rätselhafte API-Fehler sind in Wahrheit Key- oder Pfadfehler.

OpenConfig vs. Cisco Native: Modellstrategie als Architekturentscheidung

Cisco-Umgebungen bieten typischerweise zwei Modellwelten: herstellerübergreifende Modelle (z. B. OpenConfig) und Cisco Native Modelle. Beide haben legitime Rollen. Entscheidend ist, dass Sie nicht „zufällig“ mischen, sondern bewusst entscheiden, welche Use Cases auf welchem Modell basieren.

• OpenConfig: Sinnvoll als Standard für Bereiche, die viele Hersteller ähnlich abbilden (Interfaces, grundlegende Routingzustände, Systemmetriken). Vorteil: Portabilität, langfristige Stabilität, Multi-Vendor-Fähigkeit.
• Cisco Native: Sinnvoll für Cisco-spezifische Features, tiefe Plattformfunktionen oder dort, wo OpenConfig nicht vollständig implementiert ist. Vorteil: Feature-Tiefe und Nähe zur Cisco-Realität.
• Hybrid-Ansatz: In großen Netzen oft optimal: OpenConfig für Standardblöcke, Cisco Native für gezielte Ergänzungen.

Wichtig ist Governance: Dokumentieren Sie, welche „Domains“ (z. B. Interface Baseline, BGP Policy, QoS) welches Modell nutzen. Sonst entsteht „Modellsprawl“ – das YANG-Äquivalent zum VLAN-Sprawl.

Model Coverage: Warum „das Modell existiert“ nicht heißt „es ist implementiert“

Ein häufiger Profi-Fallstrick ist die Annahme, dass ein YANG-Modell automatisch auf jeder Plattform und jedem Release vollständig nutzbar ist. In der Realität hängt die Implementierung von IOS XE/NX-OS Versionen, Features und teilweise von Hardware ab. Das führt zu zwei operativen Anforderungen:

• Capability Discovery: Vor Deployments prüfen, welche Modelle, Pfade und Datastores verfügbar sind.
• Regressionstests: Nach Upgrades prüfen, ob Pfade unverändert funktionieren und Daten semantisch gleich bleiben.

Als Referenzplattform für Modelle eignet sich der YANG Catalog, um Module, Versionen und Abhängigkeiten zu identifizieren. Für Cisco-spezifische Modellreferenzen helfen die jeweiligen Plattform-Guides und Modell-Repositories.

Validierung: Der Kernnutzen von YANG in der Automation

Validierung ist der Bereich, in dem YANG gegenüber reinem Templating einen deutlichen Vorteil bietet. YANG kann nicht nur Datentypen definieren, sondern auch Abhängigkeiten und Constraints. Damit können Sie Fehler vermeiden, die in CLI-Welten oft erst im produktiven Change sichtbar werden.

Typen, Ranges und Patterns: „Datenqualität“ erzwingen

YANG-Typen verhindern eine ganze Klasse von Fehlern: eine MTU als String, ein VLAN außerhalb des zulässigen Bereichs, eine IP-Adresse in falschem Format. Patterns und Ranges erlauben zusätzliche Regeln, etwa Naming-Standards oder erlaubte Wertebereiche. In „Config as Data“-Pipelines sollten Sie diese Validierung bewusst nutzen, statt nur „Schema formal erfüllen“ zu wollen.

• Ranges: z. B. Portnummern oder Zeitwerte innerhalb definierter Grenzen.
• Patterns: z. B. Hostname-/Interface-Naming nach Unternehmensstandard.
• Enumerations: z. B. klar definierte Statuswerte (enabled/disabled), statt freie Texte.

must/when: Abhängigkeiten modellieren statt in Runbooks verstecken

Viele Netzwerkregeln sind kontextabhängig: „Wenn VRF aktiv, dann muss Route Distinguisher gesetzt sein“; „Wenn Feature X, dann darf Parameter Y nicht fehlen“. YANG kann solche Logik über must und when ausdrücken. Der Gewinn ist groß: Validierung wird automatisch und wiederholbar.

• when: Ein Feld oder Container gilt nur unter Bedingungen (Feature-Gate im Modell).
• must: Eine Bedingung muss erfüllt sein, sonst schlägt die Konfiguration fehl (Validierungsbarriere).

In der Praxis bedeutet das: Sie können viele „Betriebsregeln“ in das Modell und die Pipeline verlagern. Dadurch sinkt die Wahrscheinlichkeit, dass jemand per Copy-&-Paste eine Konfiguration erzeugt, die formal akzeptiert wird, aber betrieblich falsch ist.

Config as Data im GitOps-Stil: Vom Datenrepo zum Gerät

Ein professioneller Workflow behandelt Konfiguration wie Software: Sie liegt versioniert in Git, wird in CI validiert, wird als Artefakt gerendert (oder direkt als YANG-konformer Payload generiert) und wird erst nach Review ausgerollt. Dafür brauchen Sie klare Ebenen:

• Source of Truth: Daten (z. B. YAML/JSON) oder direkt YANG-konforme Payloads.
• Schema/Model: YANG-Modelle als Contract.
• CI: Validierung, Linting, Policy-Checks, Golden Samples.
• CD/Deploy: Rollout-Engine (NETCONF/RESTCONF, Controller, Automation Runner).

Der zentrale Punkt: Änderungen werden nicht „live am Gerät“ entworfen, sondern als Datenänderung in Git. Das verbessert Auditierbarkeit und reduziert Drift.

Differenzen modellbasiert bilden: Saubere Diffs statt Text-Rauschen

Viele Teams sind an CLI-Diffs gewöhnt, die durch Reihenfolge, Defaults und Formatierung stark rauschen. YANG-basierte Diffs können auf Strukturebene arbeiten: Welche Pfade ändern sich, welche List-Instanzen sind betroffen, welche Werte ändern sich tatsächlich? Das ist besonders wertvoll für Change Reviews, weil der Impact klarer sichtbar wird.

• Pfadbasierter Diff: /interfaces/interface[name=Gi1/0/1]/config/enabled: false → true
• List-Scoped Diff: Nur ein Neighbor in einer BGP-Neighbor-Liste ändert sich, nicht die gesamte Konfiguration.
• Policy-Checks: Diffs können gegen Regeln geprüft werden (z. B. „keine Änderungen an AAA außerhalb Change Window“).

Für diese Art von Diffs ist es entscheidend, dass Ihre Datenobjekte deterministisch sind: Listen sortieren, Keys konsequent verwenden, und keine zufälligen Labels erzeugen.

Validierungsschichten: Schema, Semantik und Betriebsregeln

In Enterprise-Automation reicht „Schema validiert“ selten aus. Ein stabiler Ansatz nutzt mehrere Validierungsschichten:

• Schema-Validierung: YANG-konforme Payloads, korrekte Typen und Pflichtfelder.
• Semantik-Validierung: Existieren referenzierte Objekte? (VLAN/VRF/Interface vorhanden, Feature aktivierbar)
• Policy-Validierung: Entspricht die Konfiguration Unternehmensstandards? (Naming, Logging, AAA, Security Baseline)
• Preflight-Validierung: Ist das Gerät bereit? (CPU, Nachbarschaften, Management-Zugriff, Zeit/NTP)

YANG hilft primär bei Schema- und Teilen der Semantik-Validierung. Policy- und Preflight-Checks kommen typischerweise aus Ihrer Betriebslogik (z. B. Tests, Regeln, Gatekeeper in CI/CD).

Praktische Patterns: „Small, owned domains“ statt „alles modellieren“

Ein häufiger Expertenfehler ist, direkt „die gesamte Gerätekonfiguration“ modellgetrieben verwalten zu wollen. Das erzeugt enorme Komplexität und kollidiert mit Legacy-Bereichen. Besser ist ein Domain-Ansatz: Sie definieren klar abgegrenzte Konfigurationsdomänen, die vollständig „owned“ sind. Beispiele:

• Management Baseline: NTP, Syslog, AAA, SSH, SNMPv3/Telemetry – mit klaren Standards.
• Interface Profile: Access-/Uplink-Profile als Datenobjekte, gerollt nach Rolle/Standort.
• Routing Policies: Prefix-Listen, Route-Maps, Communities als strukturierte Daten.
• VRF-/Tenant-Domäne: VRF-Lifecycle, RD/RT, SVI-Parameter als modellierte Objekte.

Domain-Ownership verhindert, dass zwei Tools denselben Bereich widersprüchlich konfigurieren. Das ist essenziell, um „Config as Data“ stabil zu betreiben.

Interoperabilität: YANG-Modelle als Brücke zwischen Tools

Ein großer Vorteil von YANG ist, dass es Tool-Ökosysteme verbindet: NETCONF/RESTCONF, gNMI/Telemetry, Controller, Validierungsframeworks und CI/CD können denselben Modellraum teilen. Dadurch entsteht ein konsistentes Betriebsmodell:

• Konfiguration: NETCONF/RESTCONF schreibt modellierte Config.
• State und Telemetrie: gNMI/MDT streamt modellierten State.
• Compliance: Policies prüfen modellierte Daten, statt Text zu parsen.
• Audits: Änderungen sind als Datenänderungen nachvollziehbar (Git History + Modellpfade).

Das reduziert die klassische Fragmentierung, in der Monitoring, Automation und Compliance jeweils eigene „Wahrheiten“ über das Netz haben.

Versionsdrift und Modelländerungen: Stabilität durch Tests und Pinning

In großen Netzen ist Versionsdrift unvermeidlich: Geräte laufen auf unterschiedlichen Releases, YANG-Modelle entwickeln sich, und neue Features werden eingeführt. Ein professionelles Modellmanagement enthält daher:

• Modell-Pinning: Für produktive Pipelines definieren Sie, welche Modellversionen unterstützt werden.
• Golden Devices: Repräsentative Geräte pro Plattform/Release für Regressionstests.
• Contract Tests: Tests, die prüfen, ob Pfade existieren und Semantik gleich bleibt (nicht nur „Antwort kommt“).
• Upgrade-Runbooks: Nach Upgrades werden Modellpfade und Deployments validiert.

Ohne diese Disziplin passieren die typischen „mystischen Fehler“: ein Pfad liefert plötzlich keine Daten, ein Pflichtfeld wird anders bewertet, oder ein Feature-Gate greift anders. Tests sind die beste Versicherung dagegen.

Security und Governance: YANG-basierte Automation ist Management Plane

Config as Data ist ein mächtiger Hebel – und damit ein Hochwertziel. Wer Config as Data betreibt, muss Management Plane Hardening ernst nehmen: segmentierte Zugänge, starke Authentifizierung, RBAC, Audit-Logging und saubere Schlüssel-/Zertifikatsprozesse.

• Management-VRF/OOB: Modell-APIs nur über Management-Zonen, nicht über User-Netze.
• RBAC: Service Accounts minimal berechtigen; Domänenrechte klar trennen (z. B. Routing vs. AAA).
• Audit: Änderungen müssen nachvollziehbar sein (Git + AAA Accounting + Syslog).
• PKI/NTP: TLS und Zertifikate benötigen stabile Zeit und Lifecycle-Management.

Ein praktischer Punkt: YANG senkt die „Fehlerquote“ durch Validierung, aber erhöht die Bedeutung von Zugriffskontrollen, weil ein korrektes Datenobjekt sehr schnell sehr viele Geräte ändern kann.

Typische Fallstricke beim Einsatz von Cisco YANG Modellen

• „YANG ist CLI in JSON“: Falscher Ansatz. Lösung: Modell als Contract verstehen, Datenobjekte sauber strukturieren.
• Unklare Modellstrategie: OpenConfig und Cisco Native werden beliebig gemischt. Lösung: Domain-Entscheidung und Mapping dokumentieren.
• Keys nicht korrekt genutzt: Listen werden falsch adressiert. Lösung: Keys strikt im Datenmodell führen und testen.
• Replace statt Patch: Große Container werden ersetzt, Nebenwirkungen entstehen. Lösung: gezielte Updates in owned Domains.
• Keine Capability Checks: Modellpfade nicht auf Plattform verfügbar. Lösung: Capability Discovery, Golden Tests.
• Keine Governance: Jeder kann Modelländerungen pushen. Lösung: RBAC, Review-Prozess, Change Gates.

Best Practices als Blueprint für Validierung und Config as Data

• Modellstrategie festlegen: OpenConfig für Standards, Cisco Native für Tiefe – bewusst und dokumentiert.
• Domänen definieren: Kleine, owned Konfigbereiche modellgetrieben verwalten, nicht „alles auf einmal“.
• Mehrstufig validieren: Schema + Semantik + Policy + Preflight; CI als Gatekeeper.
• Model-basierte Diffs: Pfadbasierte Diffs für Reviews, deterministische Datenstrukturen.
• Capabilities prüfen: Modell- und Feature-Verfügbarkeit je Plattform/Release automatisiert erkennen.
• Tests und Pinning: Golden Devices, Contract Tests, Modellversionen pinnen.
• Security ernst nehmen: Management-VRF, RBAC, Audit, PKI/NTP und kontrollierte Rollouts.

Outbound-Referenzen

• RFC 7950 (YANG 1.1) als formale Grundlage für YANG-Modelle, Typen und Constraints.
• YANG Catalog für Recherche von YANG-Modulen, Abhängigkeiten und Modellversionen.
• OpenConfig für herstellerübergreifende Modelle und Standardpfade.
• RFC 6241 (NETCONF) als Referenz für NETCONF-basierte Konfigurationsoperationen auf modellierten Datastores.
• RFC 8040 (RESTCONF) für HTTP-basierte modellgetriebene Konfiguration und Abfragen.
• Cisco IOS XE Configuration Guides für plattformspezifische YANG-/NETCONF-/RESTCONF-Implementierungen und Feature-Gates.
• Cisco NX-OS Configuration Guides für NX-OS-spezifische Unterschiede in Modellabdeckung, Feature-Aktivierung und Datacenter-Patterns.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.