Site icon bintorosoft.com

10.7 Praktische Beispiele mit YANG-Modellen einfach erklärt

bintorosoft@gmail.com

YANG wirkt auf viele Network Engineers zunächst theoretisch, weil es nicht wie klassische CLI-Konfiguration aussieht. In der Praxis wird YANG aber vor allem dann verständlich, wenn man es an konkreten Netzwerkaufgaben betrachtet. Genau dort zeigt sich der eigentliche Nutzen: YANG beschreibt Konfigurations- und Statusdaten strukturiert, nachvollziehbar und maschinenlesbar. Anstatt ein Interface, einen NTP-Server oder einen Routing-Prozess nur als herstellerspezifische Befehlsfolge zu sehen, werden diese Elemente als Datenobjekte mit klar definierten Feldern modelliert. Praktische Beispiele helfen deshalb am besten, um YANG einzuordnen. Sie zeigen, wie sich bekannte Netzwerkkonzepte wie Interfaces, VLANs, IP-Adressen oder Systemparameter in strukturierte Modelle übersetzen lassen und warum das für Automatisierung, Validierung und API-basierte Netzwerke so wertvoll ist.

Warum praktische YANG-Beispiele für Network Engineers wichtig sind

Von CLI-Denken zu Datenmodellen

Viele Engineers denken bei Netzwerken zunächst in Befehlen. Das ist nachvollziehbar, weil die tägliche Arbeit oft über die CLI erfolgt. Ein Interface wird mit interface, description, ip address und no shutdown konfiguriert. YANG arbeitet jedoch auf einer anderen Ebene. Es beschreibt nicht primär die Befehle, sondern die Datenstruktur dahinter.

Ein klassisches CLI-Beispiel:

interface GigabitEthernet0/1
 description Uplink-to-Core
 ip address 192.0.2.2 255.255.255.252
 no shutdown

Ein YANG-basiertes Denken fragt stattdessen:

Praktische Beispiele übersetzen genau diese Fragen in eine verständliche Struktur.

YANG wird durch bekannte Netzwerkobjekte greifbar

Sobald bekannte Themen wie Interfaces, VLANs, NTP, Routing oder Benutzerkonten modelliert werden, wird YANG deutlich verständlicher. Denn inhaltlich modelliert YANG nichts Fremdes. Es beschreibt genau die Objekte, mit denen Network Engineers ohnehin täglich arbeiten.

Grundidee: Ein YANG-Modell beschreibt Daten, nicht direkt CLI

Was ein Modell tatsächlich liefert

Ein YANG-Modell definiert, welche Daten vorhanden sind, wie sie heißen, welchen Datentyp sie haben und in welcher Beziehung sie zueinander stehen. Das Modell ist also die strukturierte Beschreibung eines Netzwerkbereichs. Es ist weder ein Protokoll noch direkt die Konfiguration selbst.

Ein stark vereinfachtes Beispiel für einen Interface-Bereich in YANG:

container interfaces {
  list interface {
    key "name";

    leaf name {
      type string;
    }

    leaf description {
      type string;
    }

    leaf enabled {
      type boolean;
    }
  }
}

Dieses Modell sagt aus:

Das Modell erzeugt noch keine CLI, aber es beschreibt sauber die Struktur der Daten.

Wie daraus echte Geräteinteraktion wird

Wenn ein Gerät YANG-Modelle unterstützt, können diese Daten über Schnittstellen wie NETCONF oder RESTCONF gelesen oder geschrieben werden. Dadurch wird nicht mehr mit freiem Text gearbeitet, sondern mit klar strukturierten Datenobjekten. Das ist einer der wichtigsten Unterschiede zur klassischen CLI-Automatisierung.

Praktisches Beispiel: Ein Hostname als einfachster Einstieg

Ein einzelner Systemwert modelliert

Der einfachste YANG-Anwendungsfall ist ein einzelner globaler Parameter wie der Hostname. Er zeigt gut, wie ein einzelner Wert als strukturiertes Datenfeld modelliert wird.

Vereinfachtes Modell:

container system {
  leaf hostname {
    type string;
  }
}

Die dazugehörige Datenrepräsentation könnte logisch so aussehen:

system:
  hostname: fra-core-rtr01

Die passende CLI auf einem Cisco-Gerät wäre:

hostname fra-core-rtr01

Hier wird das Grundprinzip deutlich: YANG beschreibt den Wert als Datenobjekt, nicht als Kommandozeile. Das Gerät oder die API-Logik übernimmt die konkrete Umsetzung.

Warum selbst dieses einfache Beispiel nützlich ist

Auch ein einzelner Hostname zeigt bereits die Vorteile eines strukturierten Modells:

Praktisches Beispiel: Interfaces mit Beschreibung und Admin-Status

Interfaces als Liste modellieren

Interfaces sind eines der besten Beispiele, um YANG zu verstehen. Ein Gerät hat viele Interfaces, und jedes Interface besitzt mehrere Attribute. Genau dafür ist die Kombination aus Container, Liste und einzelnen Leafs ideal.

Ein vereinfachtes YANG-Modell:

container interfaces {
  list interface {
    key "name";

    leaf name {
      type string;
    }

    leaf description {
      type string;
    }

    leaf enabled {
      type boolean;
    }
  }
}

Eine zugehörige Datenstruktur könnte so aussehen:

interfaces:
  interface:
    - name: GigabitEthernet0/1
      description: Uplink-to-Core
      enabled: true
    - name: GigabitEthernet0/2
      description: Server-Link
      enabled: false

Die entsprechende CLI könnte lauten:

interface GigabitEthernet0/1
 description Uplink-to-Core
 no shutdown

interface GigabitEthernet0/2
 description Server-Link
 shutdown

Hier wird besonders gut sichtbar, dass YANG die fachliche Struktur beschreibt, während die CLI nur die gerätespezifische Darstellung ist.

Welche Vorteile dieses Beispiel in der Praxis hat

Praktisches Beispiel: IPv4-Adresse auf einem Interface

Ein Interface mit untergeordneter IP-Struktur

In der Praxis haben Interfaces oft weitere Unterstrukturen. Eine IPv4-Adresse gehört nicht einfach global ins Gerät, sondern zu einem konkreten Interface. Genau hier zeigen sich Hierarchien in YANG besonders anschaulich.

Ein vereinfachtes Modell könnte logisch so aussehen:

container interfaces {
  list interface {
    key "name";

    leaf name {
      type string;
    }

    container ipv4 {
      leaf address {
        type string;
      }

      leaf prefix-length {
        type uint8;
      }
    }
  }
}

Datenbeispiel:

interfaces:
  interface:
    - name: GigabitEthernet0/1
      ipv4:
        address: 192.0.2.2
        prefix-length: 30

CLI-Darstellung:

interface GigabitEthernet0/1
 ip address 192.0.2.2 255.255.255.252

Hier zeigt sich ein wichtiger Punkt: Die IP-Adresse ist nicht nur eine freie Textzeile, sondern Teil einer Unterstruktur innerhalb des Interfaces.

Warum diese Hierarchie für Automatisierung wichtig ist

Praktisches Beispiel: NTP-Server als wiederholbare Liste

Mehrere gleichartige Werte modellieren

NTP ist ein gutes Beispiel für eine Konfiguration mit mehreren gleichartigen Einträgen. Viele Geräte verwenden mehrere Zeitserver. In YANG lässt sich das als Liste einfacher Werte oder als strukturierte Liste modellieren.

Ein einfaches Beispiel:

container system {
  leaf-list ntp-server {
    type string;
  }
}

Datenrepräsentation:

system:
  ntp-server:
    - 10.10.10.10
    - 10.10.10.11

Passende CLI:

ntp server 10.10.10.10
ntp server 10.10.10.11

Das Modell zeigt hier klar, dass es sich um mehrere Werte derselben Art handelt.

Praktischer Nutzen im Netzwerkbetrieb

Praktisches Beispiel: VLANs auf einem Switch

Logische Objekte mit ID und Name

VLANs sind ein sehr typisches Netzwerkobjekt und eignen sich gut für modellgetriebete Beschreibungen. Ein VLAN ist mehr als nur eine Zahl. Es hat häufig auch einen Namen und einen Einsatzzweck.

Ein vereinfachtes Modell:

container vlans {
  list vlan {
    key "vlan-id";

    leaf vlan-id {
      type uint16;
    }

    leaf name {
      type string;
    }
  }
}

Datenbeispiel:

vlans:
  vlan:
    - vlan-id: 10
      name: MGMT
    - vlan-id: 30
      name: CLIENT_FLOOR3

Die entsprechende CLI könnte so aussehen:

vlan 10
 name MGMT

vlan 30
 name CLIENT_FLOOR3

Hier wird deutlich, dass YANG ein VLAN als strukturiertes Objekt mit eindeutiger Kennung modelliert.

Warum dieses Beispiel praxisrelevant ist

Praktisches Beispiel: OSPF-Grundparameter modellieren

Routing als eigener Funktionsbereich

Routing-Protokolle sind komplexer als einzelne Systemwerte, aber gerade deshalb ein gutes Beispiel für YANG. Sie zeigen, wie sich funktionale Bereiche logisch trennen lassen.

Ein stark vereinfachtes OSPF-Modell:

container routing {
  container ospf {
    leaf process-id {
      type uint16;
    }

    leaf router-id {
      type string;
    }
  }
}

Datenrepräsentation:

routing:
  ospf:
    process-id: 10
    router-id: 10.255.0.1

CLI-Darstellung:

router ospf 10
 router-id 10.255.0.1

Dieses Beispiel zeigt, wie ein Routing-Prozess als eigener Container modelliert werden kann, getrennt von Interfaces oder Systemparametern.

Was sich daraus für Engineers ableiten lässt

Praktisches Beispiel: Statusdaten eines Interfaces

YANG ist nicht nur für Konfiguration nützlich

Ein besonders wichtiger Punkt ist, dass YANG nicht nur Konfigurationsdaten modelliert. Auch Statusdaten lassen sich strukturiert beschreiben. Für Monitoring, Troubleshooting und Validierung ist das enorm wertvoll.

Ein vereinfachtes Modell für operative Interface-Daten:

container interfaces-state {
  list interface {
    key "name";

    leaf name {
      type string;
    }

    leaf oper-status {
      type string;
    }

    leaf in-errors {
      type uint32;
    }

    leaf out-errors {
      type uint32;
    }
  }
}

Datenbeispiel:

interfaces-state:
  interface:
    - name: GigabitEthernet0/1
      oper-status: up
      in-errors: 0
      out-errors: 0

Vergleichbare CLI-Quellen wären:

show ip interface brief
show interfaces GigabitEthernet0/1
show interfaces counters errors

Der Vorteil des Modells liegt darin, dass diese Informationen nicht mühsam aus Text extrahiert werden müssen, sondern strukturiert vorliegen.

Warum Statusmodelle im Betrieb so wichtig sind

Praktisches Beispiel: Konfiguration und Status gemeinsam denken

Ein Access-Port als vollständiger Anwendungsfall

Ein besonders praxisnaher YANG-Denkansatz ist die Kombination aus Konfiguration und Statusdaten für denselben Netzwerkbereich. Nehmen wir einen Access-Port auf einem Switch.

Konfigurationssicht:

interface:
  name: GigabitEthernet1/0/10
  description: User-LAN-Floor3
  mode: access
  access-vlan: 30
  enabled: true

Statussicht:

interface-state:
  name: GigabitEthernet1/0/10
  oper-status: up
  input-errors: 0
  output-errors: 0

Passende CLI-Konfiguration:

interface GigabitEthernet1/0/10
 description User-LAN-Floor3
 switchport mode access
 switchport access vlan 30
 no shutdown

Passende CLI-Statusprüfung:

show interfaces status
show interfaces GigabitEthernet1/0/10
show vlan brief

Genau hier wird YANG im Alltag besonders interessant: Ein Engineer kann nicht nur beschreiben, wie der Port aussehen soll, sondern auch strukturiert prüfen, ob er tatsächlich so arbeitet.

Der Nutzen für Automatisierung und Compliance

YANG-Beispiele im Zusammenhang mit NETCONF und RESTCONF

Warum YANG in APIs seine volle Stärke zeigt

Viele praktische Vorteile von YANG werden besonders deutlich, wenn Geräte NETCONF oder RESTCONF unterstützen. Dann können die modellierten Daten direkt gelesen oder geschrieben werden, ohne dass freie CLI-Texte verarbeitet werden müssen.

Relevante Cisco-Kommandos zur Aktivierung oder Prüfung modellgetriebener Schnittstellen können beispielsweise sein:

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

Diese Befehle sind kein Teil von YANG selbst, zeigen aber, wie modellgetriebete Daten im realen Netzwerkbetrieb nutzbar gemacht werden.

Was Engineers daraus praktisch mitnehmen können

Typische Denkfehler bei YANG-Beispielen

Zu stark in CLI-Kommandos denken

Ein häufiger Fehler besteht darin, jedes YANG-Modell 1:1 als Ersatz für eine bestimmte CLI-Zeile zu sehen. Das greift zu kurz. YANG beschreibt nicht primär einzelne Befehle, sondern Datenstrukturen. Mehrere CLI-Zeilen können zu einem einzigen Objekt im Modell gehören.

Zu kompliziert beginnen

Viele Engineers starten mit sehr komplexen Routing- oder Service-Modellen und verlieren dabei den Überblick. Sinnvoller ist ein Einstieg mit einfachen, bekannten Objekten:

Gerade diese einfachen Beispiele machen die Logik von YANG am schnellsten verständlich.

Konfigurations- und Statusmodelle verwechseln

Ein weiterer häufiger Fehler ist die Vermischung von Soll- und Ist-Daten. YANG kann beides modellieren, aber beides erfüllt unterschiedliche Zwecke. Wer beide sauber trennt, versteht praktische YANG-Beispiele deutlich schneller.

Best Practices für das Arbeiten mit einfachen YANG-Beispielen

So werden praktische YANG-Beispiele zu einer sehr direkten Lernhilfe für Network Engineers: Sie zeigen, dass YANG keine abstrakte Theorie ist, sondern eine strukturierte Darstellung genau der Netzwerkobjekte, die im täglichen Betrieb ohnehin konfiguriert, überwacht und automatisiert werden.

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:

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

Exit mobile version