10.2 YANG einfach erklärt für Network Engineers

YANG ist für viele Network Engineers zunächst ein Begriff aus der Welt von NETCONF, RESTCONF und modellgetriebener Automatisierung. In der Praxis ist YANG jedoch vor allem ein strukturierter Weg, Netzwerkdaten eindeutig zu beschreiben. Statt Konfigurationen nur als reine CLI-Befehle zu betrachten, definiert YANG, welche Daten ein Gerät kennt, wie diese Daten aufgebaut sind und welche Regeln für sie gelten. Genau dadurch wird Netzwerkautomatisierung konsistenter, validierbarer und besser skalierbar. Wer moderne Netzwerke betreibt oder automatisiert, profitiert davon, YANG nicht als theoretische Standardsprache zu sehen, sondern als praktisches Werkzeug, um Konfigurations- und Zustandsdaten sauber zu modellieren.

Was YANG überhaupt ist

YANG als Datenmodellierungssprache

YANG ist eine Datenmodellierungssprache, die verwendet wird, um Netzwerk- und Systemdaten strukturiert zu beschreiben. Der Name steht ursprünglich für „Yet Another Next Generation“, wichtiger als der Name ist aber die Funktion: YANG legt fest, wie Konfigurationsdaten, Zustandsdaten, Parameter, Listen, Abhängigkeiten und Datentypen definiert werden.

Ein YANG-Modell beschreibt also nicht direkt die CLI eines Routers oder Switches, sondern die logische Struktur der Daten, mit denen ein Gerät arbeitet. Das ist ein zentraler Unterschied zur klassischen Netzwerkwelt, in der viele Engineers vor allem in Befehlen und Kommandozeilen denken.

• YANG beschreibt Datenstrukturen.
• YANG definiert Datentypen und Wertebereiche.
• YANG modelliert Beziehungen zwischen Objekten.
• YANG ermöglicht Validierung von Eingaben.
• YANG trennt Datenmodell und konkrete Darstellung.

YANG ist nicht NETCONF, nicht RESTCONF und nicht CLI

Ein häufiger Irrtum besteht darin, YANG mit einem Protokoll zu verwechseln. YANG ist kein Transportprotokoll und keine API im eigentlichen Sinn. Es definiert nur das Modell der Daten. NETCONF und RESTCONF sind dagegen Protokolle beziehungsweise Schnittstellen, über die diese modellierten Daten gelesen oder geschrieben werden können.

Vereinfacht gesagt:

• YANG beschreibt, wie Daten aufgebaut sind.
• NETCONF transportiert diese Daten typischerweise per XML.
• RESTCONF stellt modellierte Daten typischerweise über REST-artige APIs bereit.
• CLI ist eine herstellerspezifische textbasierte Bedienoberfläche.

Für Network Engineers ist diese Trennung wichtig, weil sie hilft, moderne Automatisierung richtig einzuordnen. Wer YANG versteht, versteht besser, warum API-basierte Netzwerkkonfiguration strukturierter und kontrollierbarer sein kann als klassisches CLI-Scraping.

Warum YANG für Network Engineers wichtig ist

Weg von unstrukturierten CLI-Texten

Traditionell werden Konfigurationen in Netzwerken oft als freier Text betrachtet. Ein Administrator sendet Befehle an ein Gerät, speichert die Running-Config und analysiert Show-Ausgaben. Das funktioniert, ist aber für Automatisierung nur begrenzt ideal. Text muss geparst werden, Syntax variiert zwischen Plattformen und Abhängigkeiten sind nur indirekt erkennbar.

YANG ersetzt dieses Denken nicht vollständig, bietet aber einen strukturierteren Ansatz. Statt einen Interface-Block als Text zu behandeln, kann das Interface als klar definiertes Datenobjekt modelliert werden.

• Name des Interfaces
• Beschreibung
• IP-Adresse
• Admin-Status
• MTU
• Layer-2- oder Layer-3-Rolle

Das erleichtert nicht nur Konfigurationsänderungen, sondern auch Validierung, Compliance-Prüfung und Abgleich mit Soll-Zuständen.

Automatisierung wird zuverlässiger

Ein großer Vorteil von YANG liegt in der Datenqualität. Wenn ein Modell klar definiert, welche Felder erlaubt sind, welche Datentypen gelten und welche Wertebereiche zulässig sind, sinkt das Risiko fehlerhafter Eingaben. Automatisierung profitiert davon direkt.

• Ungültige Werte können früh erkannt werden.
• Pflichtfelder lassen sich eindeutig definieren.
• Abhängigkeiten zwischen Parametern werden modelliert.
• Tools können Daten standardisiert interpretieren.

Gerade in größeren Umgebungen mit vielen Geräten, Rollen und Templates ist das ein großer Fortschritt gegenüber rein textbasierten Verfahren.

Das Grundprinzip von YANG in einfachen Worten

YANG modelliert Hierarchien

YANG arbeitet mit einer Baumstruktur. Daten werden hierarchisch organisiert. Ein Gerät kann beispielsweise einen Bereich für Interfaces besitzen, darunter einzelne Interfaces und darunter wiederum Parameter wie Beschreibung, IP-Adresse oder Shutdown-Status.

Vereinfacht sieht das logisch etwa so aus:

• device
  • interfaces
    • interface
      • name
      • description
      • enabled
      • ipv4

Diese Hierarchie ist für Network Engineers gut nachvollziehbar, weil sie der realen Struktur vieler Gerätekonfigurationen entspricht. Der Unterschied ist, dass YANG diese Struktur formal und maschinenlesbar definiert.

YANG beschreibt Regeln, nicht nur Felder

Ein YANG-Modell sagt nicht nur, dass es ein Feld namens mtu gibt. Es kann auch definieren, dass dieses Feld vom Typ Integer ist, nur bestimmte Werte annehmen darf oder in bestimmten Fällen optional beziehungsweise verpflichtend ist.

Das ist ein zentraler Mehrwert: Das Modell dient gleichzeitig als Struktur- und Validierungsgrundlage.

• String, Integer, Boolean und andere Datentypen
• Bereiche für erlaubte Zahlenwerte
• Enumerationen für definierte Auswahlwerte
• Abhängigkeiten zwischen Elementen
• Listen mit eindeutigen Schlüsseln

Wichtige YANG-Bausteine für den Praxisalltag

Module und Namespace

YANG organisiert Modelle in Modulen. Ein Modul ist eine logisch zusammengehörige Definition eines Datenbereichs. Zum Beispiel kann ein Modul Interfaces, VLANs oder Routingparameter modellieren. Jedes Modul besitzt einen eindeutigen Namespace und meist ein Präfix.

Das ist wichtig, weil Modelle dadurch sauber getrennt und wiederverwendbar bleiben. Verschiedene Hersteller oder Standards können eigene Module definieren, ohne sich gegenseitig zu überschreiben.

Ein sehr einfaches Beispiel:

module example-interfaces {
  namespace "http://example.com/interfaces";
  prefix ex-if;
}

Für den operativen Alltag muss ein Network Engineer nicht jedes Detail des Namespace-Konzepts auswendig kennen. Entscheidend ist zu verstehen, dass YANG sauber strukturierte und voneinander trennbare Modelle verwendet.

Container

Ein container gruppiert zusammengehörige Daten. Er funktioniert wie ein logischer Ordner in der Baumstruktur. Ein Container selbst ist meist kein einzelner Wert, sondern eine Sammlung von untergeordneten Elementen.

Beispiel:

container interfaces {
}

In diesem Container könnten dann Listen von Interfaces oder globale Interface-Parameter liegen.

Leaf

Ein leaf ist ein einzelner Datenwert. Das ist einer der wichtigsten YANG-Bausteine. Ein Hostname, eine Beschreibung, eine MTU oder ein Boolean-Wert wie enabled sind typische Leafs.

Beispiel:

leaf hostname {
  type string;
}

Oder für einen administrativen Status:

leaf enabled {
  type boolean;
}

List

Mit list werden wiederholbare Strukturen modelliert. Interfaces sind ein klassisches Beispiel: Ein Gerät hat nicht nur ein Interface, sondern viele. Jedes Interface wird durch einen Schlüssel eindeutig identifiziert, oft über den Namen.

list interface {
  key "name";

  leaf name {
    type string;
  }

  leaf description {
    type string;
  }
}

Damit beschreibt YANG sauber, dass ein Gerät mehrere Interfaces besitzt und jedes Interface einen eindeutigen Namen haben muss.

Leaf-list

Eine leaf-list ist eine Liste einfacher Werte. Das ist nützlich, wenn nicht komplexe Objekte, sondern nur mehrere Einzelwerte benötigt werden, beispielsweise NTP-Server oder DNS-Server.

leaf-list ntp-server {
  type string;
}

Für die Praxis ist das hilfreich, weil viele Netzwerkparameter genau diesem Muster folgen.

Wie ein einfaches YANG-Modell aussehen kann

Beispiel für Interface-Daten

Ein stark vereinfachtes Modell für Interfaces könnte so aussehen:

module simple-device {
  namespace "http://example.com/simple-device";
  prefix sd;

  container interfaces {
    list interface {
      key "name";

      leaf name {
        type string;
      }

      leaf description {
        type string;
      }

      leaf enabled {
        type boolean;
      }

      leaf mtu {
        type uint16;
      }
    }
  }
}

Dieses Modell beschreibt:

• Es gibt einen Container namens interfaces.
• Darin gibt es eine Liste von interface-Einträgen.
• Jedes Interface wird über name eindeutig identifiziert.
• Jedes Interface kann eine Beschreibung, einen Admin-Status und eine MTU haben.

Für Network Engineers ist wichtig: Dieses Modell erzeugt noch keine Cisco-CLI. Es beschreibt nur die Struktur der Daten, aus denen Konfigurationen oder APIs arbeiten können.

YANG und echte Netzwerkdaten

Konfiguration und State-Daten

YANG kann sowohl Konfigurationsdaten als auch Zustandsdaten modellieren. Diese Unterscheidung ist in der Praxis sehr relevant.

• Konfigurationsdaten sind Werte, die gesetzt werden sollen, etwa IP-Adresse oder Beschreibung.
• Statusdaten sind Betriebsinformationen, etwa Interface-Status, Paketfehler oder aktuelle Nachbarschaften.

Ein Interface kann also im Modell sowohl die konfigurierte MTU als auch den operativen Status enthalten. Dadurch wird YANG nicht nur für Provisionierung interessant, sondern auch für Monitoring, Telemetrie und Validierung.

Beispielhafte Struktur eines Interfaces

Praktisch könnte ein modellierter Datenausschnitt so interpretiert werden:

interface:
  name: GigabitEthernet0/0
  description: Uplink-to-Core
  enabled: true
  mtu: 1500

Oder in JSON-ähnlicher Darstellung:

{
  "name": "GigabitEthernet0/0",
  "description": "Uplink-to-Core",
  "enabled": true,
  "mtu": 1500
}

Der Mehrwert liegt darin, dass diese Struktur nicht frei erfunden ist, sondern durch das YANG-Modell formal beschrieben und validierbar ist.

YANG im Zusammenspiel mit NETCONF und RESTCONF

NETCONF als strukturierter Transportweg

NETCONF ist ein Protokoll, das häufig zusammen mit YANG eingesetzt wird. Es ermöglicht das Lesen, Bearbeiten und Löschen von Konfigurationsdaten auf Geräten. Die Daten orientieren sich an den zugrundeliegenden YANG-Modellen.

Typische Vorteile gegenüber klassischer CLI-Automatisierung:

• Klar strukturierte Daten statt frei formatierter Textausgaben
• Transaktionsorientierte Änderungen
• Bessere Validierung vor dem Commit
• Trennung von Running-, Candidate- und Startup-Konfiguration je nach Plattform

Im Cisco-Umfeld sind bestimmte CLI-Befehle hilfreich, um modellgetriebene Schnittstellen zu aktivieren oder zu prüfen:

netconf-yang
restconf
ip http secure-server
show netconf-yang sessions
show running-config | include netconf|restconf

Je nach Plattform und Softwarestand variiert die konkrete Syntax, das Grundprinzip bleibt aber gleich: Das Gerät stellt YANG-basierte Daten über standardisierte Schnittstellen bereit.

RESTCONF für API-orientierten Zugriff

RESTCONF nutzt HTTP beziehungsweise HTTPS und greift auf modellierte Daten typischerweise in XML- oder JSON-Darstellung zu. Für Engineers, die bereits mit REST-APIs arbeiten, ist RESTCONF oft leichter zugänglich als NETCONF.

Der eigentliche Vorteil gegenüber beliebigen REST-Endpunkten liegt darin, dass die Daten nicht nur lose dokumentiert sind, sondern einem formalen Modell folgen. Das macht Automatisierung konsistenter und vorhersehbarer.

Warum YANG im Multi-Vendor-Betrieb relevant ist

Standardisierung über Plattformgrenzen hinweg

Ein zentrales Problem traditioneller Netzwerkautomatisierung ist die Herstellerabhängigkeit der CLI. Selbst einfache Funktionen wie Interface-Beschreibung, VLAN-Zuweisung oder Routingparameter unterscheiden sich syntaktisch zwischen Plattformen. YANG kann helfen, diese Unterschiede auf einer höheren Ebene zu abstrahieren.

Ein Interface bleibt fachlich ein Interface, unabhängig davon, ob es auf Cisco IOS, IOS XE, NX-OS oder einer anderen Plattform läuft. Wenn mehrere Systeme ähnliche YANG-Modelle oder standardisierte OpenConfig-Modelle unterstützen, wird Interoperabilität leichter.

• Weniger Fokus auf herstellerspezifische Textsyntax
• Mehr Fokus auf fachliche Datenobjekte
• Bessere Grundlage für plattformübergreifende Tools
• Einfachere Validierung gemeinsamer Standards

OpenConfig als praktisches Beispiel

Im Zusammenhang mit YANG begegnet Network Engineers oft der Begriff OpenConfig. Dabei handelt es sich um herstellerübergreifende Datenmodelle, die von Netzwerkbetreibern und Herstellern unterstützt werden. Ziel ist, gemeinsame Strukturen für Themen wie Interfaces, BGP, VLANs oder Telemetrie zu definieren.

Für die Praxis bedeutet das: Ein Tool kann sich eher an einem standardisierten Modell orientieren statt an dutzenden individuellen CLI-Varianten.

Typische Vorteile von YANG im Netzwerkbetrieb

Bessere Datenqualität

Durch definierte Datentypen, Wertebereiche und Strukturen sinkt die Wahrscheinlichkeit fehlerhafter Eingaben. Das ist besonders bei Automatisierung, Templates und API-Workflows wertvoll.

Einfachere Validierung

Wenn das Modell klar sagt, was erlaubt ist, können Tools Konfigurationen bereits vor der Übertragung prüfen. Das reduziert Fehlkonfigurationen und verbessert die Betriebssicherheit.

Saubere Trennung von Daten und Darstellung

YANG beschreibt, was ein Interface, ein Routingprozess oder ein VLAN fachlich ist. Die Frage, wie diese Information angezeigt oder übertragen wird, ist davon getrennt. Genau das macht moderne Automatisierung so viel flexibler als reines CLI-Scripting.

Bessere Grundlage für Telemetrie und State-Abfragen

YANG ist nicht nur für Konfiguration wichtig. Auch operative Zustandsdaten lassen sich damit strukturiert modellieren. Das unterstützt Monitoring, Streaming Telemetry und automatisierte Validierung.

Herausforderungen und typische Missverständnisse

YANG ersetzt nicht automatisch alle CLI-Kenntnisse

Für Network Engineers bleibt CLI-Wissen weiterhin wichtig. Fehlersuche, Plattformverständnis und operative Diagnose basieren oft nach wie vor auf klassischen Show-Befehlen und Plattformlogik. YANG ergänzt dieses Wissen, ersetzt es aber nicht vollständig.

Herstellerunterstützung ist nicht immer identisch

Nicht jedes Gerät unterstützt dieselben Modelle oder denselben Reifegrad modellgetriebener APIs. Manche Plattformen bieten umfassende native und OpenConfig-Modelle, andere nur Teilmengen. Deshalb muss in Projekten immer konkret geprüft werden, welche Modelle und Schnittstellen tatsächlich verfügbar sind.

Der Einstieg wirkt abstrakt

Viele Engineers empfinden YANG anfangs als theoretisch, weil es nicht direkt wie CLI aussieht. Dieser Eindruck verschwindet meist, sobald klar wird, dass YANG im Kern nur eine formale Beschreibung bekannter Netzwerkobjekte ist: Interfaces, IP-Adressen, Routing, VLANs, Benutzer, Services.

Praxisnahe Denkhilfe für Network Engineers

Von der CLI zur Datenstruktur umdenken

Ein guter Einstieg in YANG besteht darin, bekannte CLI-Blöcke gedanklich in strukturierte Objekte zu zerlegen. Statt sofort an den gesamten Interface-Block zu denken, wird gefragt:

• Wie heißt das Objekt?
• Welche Attribute hat es?
• Welche Werte sind erlaubt?
• Welche Attribute sind Pflicht?
• Welche Abhängigkeiten bestehen?

Ein klassischer CLI-Block wie:

interface GigabitEthernet1/0/24
 description Uplink-to-dist-sw01
 ip address 192.0.2.1 255.255.255.252
 no shutdown

wird dann logisch zu:

name: GigabitEthernet1/0/24
description: Uplink-to-dist-sw01
ipv4_address: 192.0.2.1
prefix_length: 30
enabled: true

Genau dieses strukturierte Denken ist die Brücke zwischen klassischem Network Engineering und modellgetriebener Automatisierung.

Best Practices für den Einstieg in YANG

• YANG zuerst als Datenmodell und nicht als Protokoll verstehen.
• Mit bekannten Objekten wie Interfaces, VLANs oder NTP-Servern beginnen.
• CLI-Konfigurationen gedanklich in strukturierte Felder zerlegen.
• Den Unterschied zwischen Konfigurations- und Statusdaten sauber erfassen.
• NETCONF und RESTCONF als Transportwege im Zusammenhang mit YANG einordnen.
• Bei Multi-Vendor-Projekten standardisierte Modelle wie OpenConfig prüfen.
• Plattformspezifische Modellunterstützung immer konkret verifizieren.
• YANG als Grundlage für Validierung, Automatisierung und Compliance nutzen.
• Nicht versuchen, sofort alle Sprachdetails auswendig zu lernen.
• Mit kleinen, praxisnahen Modellen beginnen und Verständnis schrittweise vertiefen.

Damit wird YANG für Network Engineers von einem abstrakt wirkenden Standard zu einem sehr praktischen Konzept: Es beschreibt Netzwerkinformationen so, dass Menschen, Geräte und Automatisierungstools dieselbe Struktur verstehen und konsistent verarbeiten können.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.