Site icon bintorosoft.com

10.6 Hierarchien und Container in Datenmodellen verstehen

bintorosoft@gmail.com

Wer sich mit Netzwerkautomatisierung, YANG, NETCONF, RESTCONF oder strukturierten Konfigurationsdaten beschäftigt, stößt sehr schnell auf die Begriffe Hierarchie und Container. Für viele Network Engineers wirken diese Konzepte zunächst abstrakt, obwohl sie in der Praxis sehr logisch sind. Netzwerke bestehen aus Objekten, die in Beziehung zueinander stehen: Geräte enthalten Interfaces, Interfaces besitzen Adressen, Routing-Prozesse enthalten Nachbarn, VLAN-Daten gehören zu Standorten oder Rollen. Genau solche Beziehungen werden in Datenmodellen durch Hierarchien und Container sauber beschrieben. Sie helfen dabei, Konfigurations- und Statusdaten logisch zu ordnen, wiederverwendbar zu machen und für Automatisierung, Validierung und API-basierte Prozesse maschinenlesbar bereitzustellen.

Warum Hierarchien in Datenmodellen überhaupt notwendig sind

Netzwerkdaten sind nicht flach organisiert

Ein Netzwerkgerät besteht nicht aus einer ungeordneten Liste einzelner Werte. Es besitzt verschiedene funktionale Bereiche, die wiederum untergeordnete Informationen enthalten. Ein Router hat Interfaces, diese Interfaces haben IP-Adressen, Beschreibungen und Statuswerte. Ein Switch hat VLANs, Trunks und Access-Ports. Ein Routing-Prozess enthält Netzdefinitionen, Nachbarschaften und Timer. Genau deshalb reicht eine flache Liste von Parametern nicht aus.

Diese logischen Zusammenhänge müssen in einem Datenmodell sichtbar werden. Hierarchien schaffen genau diese Ordnung.

Automatisierung braucht klare Beziehungen

Für Menschen ist oft intuitiv klar, dass eine IP-Adresse zu einem bestimmten Port gehört oder dass ein VLAN in einem Layer-2-Kontext verwendet wird. Ein Automatisierungssystem braucht diese Zusammenhänge jedoch explizit. Wenn Daten ohne Hierarchie gespeichert werden, wird der Code komplizierter, fehleranfälliger und schlechter wartbar.

Hierarchische Modelle beantworten diese Fragen direkt durch ihre Struktur.

Was mit Hierarchie in einem Datenmodell gemeint ist

Hierarchie als Baumstruktur

In Datenmodellen werden Informationen häufig als Baum organisiert. Oben stehen allgemeinere Objekte, darunter folgen spezifischere Elemente. Dieses Prinzip ähnelt einem Dateisystem: Ein Hauptordner enthält Unterordner, diese wiederum weitere Inhalte. In Netzwerken ist das genauso sinnvoll.

Eine vereinfachte Struktur könnte so aussehen:

Diese Struktur zeigt sofort, dass Interfaces ein Teil des Geräts sind und Routing-Prozesse ebenfalls zum Gerät gehören, aber einen anderen Bereich bilden.

Hierarchie erzeugt Kontext

Ein Datenwert wird erst durch seinen Kontext wirklich aussagekräftig. Das Wort description allein sagt noch nicht, ob es sich um eine Gerätebeschreibung, eine Interface-Beschreibung oder die Beschreibung einer ACL handelt. Innerhalb einer Hierarchie ist das eindeutig.

Beispiel:

device:
  interfaces:
    interface:
      name: GigabitEthernet0/1
      description: Uplink-to-Core

Hier ist sofort klar, dass sich die Beschreibung auf ein Interface bezieht und nicht auf das Gerät als Ganzes.

Was ein Container in Datenmodellen ist

Container als logische Gruppierung

Ein Container ist ein strukturelles Element, das zusammengehörige Daten bündelt. Er selbst ist in der Regel kein einzelner Endwert, sondern eine Klammer um weitere Objekte, Werte oder Listen. In YANG und anderen strukturierten Modellen ist der Container eines der wichtigsten Grundelemente, weil er Daten logisch organisiert.

Ein Container kann zum Beispiel folgende Gruppen bilden:

Ein einfaches Beispiel:

system:
  hostname: fra-core-rtr01
  domain-name: example.local

Hier fungiert system als Container für mehrere zusammengehörige Parameter.

Container sind keine Listen von Wiederholungen

Ein häufiger Denkfehler ist die Verwechslung von Containern mit Listen. Ein Container gruppiert logisch zusammengehörige Daten. Eine Liste beschreibt dagegen mehrere gleichartige Einträge. Ein Gerät hat typischerweise genau einen Systembereich, aber viele Interfaces. Deshalb ist system oft ein Container, während interfaces meist einen Container enthält, unter dem eine Liste von Interfaces liegt.

Wie Hierarchien und Container zusammenarbeiten

Container bilden die Knoten der Hierarchie

Eine Hierarchie entsteht in der Praxis häufig dadurch, dass Container und untergeordnete Elemente schrittweise ineinander verschachtelt werden. Container bilden dabei die logischen Ebenen des Baums.

Beispielhaft:

device:
  system:
    hostname: ham-dist-sw01
  interfaces:
    interface:
      name: GigabitEthernet1/0/48
      description: Uplink-to-Core

Hier ist device die oberste Ebene, darunter folgen die Container system und interfaces. Innerhalb von interfaces liegen dann die eigentlichen Interface-Daten.

Ohne Hierarchie entstehen unklare Modelle

Würde man dieselben Daten flach speichern, sähe das möglicherweise so aus:

hostname: ham-dist-sw01
interface_name: GigabitEthernet1/0/48
interface_description: Uplink-to-Core

Das funktioniert bei kleinen Beispielen, skaliert aber schlecht. Schon bei mehreren Interfaces oder zusätzlichen Funktionen wird die Struktur unübersichtlich. Hierarchien und Container verhindern genau dieses Problem.

Praxisbezug: Hierarchien in Netzwerkkonfigurationen

Auch die CLI ist oft hierarchisch aufgebaut

Viele Network Engineers kennen Hierarchien bereits aus der CLI, auch wenn sie sie nicht immer so benennen. In Cisco IOS wechselt man beispielsweise vom globalen Konfigurationsmodus in einen Interface-Kontext oder in einen Routing-Kontext. Genau das ist im Grunde eine hierarchische Struktur.

Ein Interface-Kontext in der CLI:

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

Hier ist interface GigabitEthernet0/1 funktional ein Container-Kontext, in dem untergeordnete Parameter gesetzt werden.

Ein Routing-Kontext:

router ospf 10
 router-id 10.255.0.1
 passive-interface default
 no passive-interface GigabitEthernet0/1

Auch hier wird deutlich: Bestimmte Werte gehören logisch zu einem bestimmten Funktionsbereich. Datenmodelle machen diese Struktur explizit und maschinenlesbar.

Der Unterschied zur CLI-Struktur

Obwohl die CLI oft hierarchisch wirkt, ist sie primär für Menschen und Gerätebedienung gemacht. Datenmodelle hingegen sind explizit für strukturierte Datenrepräsentation gedacht. Sie beschreiben nicht nur, in welchem Kontext ein Befehl steht, sondern formal, welche Objekte existieren, welche Werte sie haben dürfen und wie sie zueinander in Beziehung stehen.

Typische Hierarchieebenen in Netzwerkdatenmodellen

Geräteebene

Auf der obersten Ebene stehen meist Daten, die für das gesamte Gerät gelten. Dazu zählen globale Systemparameter, Management-Einstellungen oder Plattforminformationen.

Beispiel:

device:
  hostname: ber-edge-rtr01
  role: edge-router
  mgmt_ip: 192.0.2.5

Funktionsbereiche unterhalb des Geräts

Darunter folgen typische Funktionsbereiche, die als Container modelliert werden können.

Jeder dieser Bereiche kann wiederum eigene Unterstrukturen enthalten.

Objektebene innerhalb eines Funktionsbereichs

Innerhalb eines Containers befinden sich oft konkrete Objekte. Im Interface-Bereich sind das die einzelnen Ports, im Routing-Bereich einzelne Protokolle oder Instanzen, im VLAN-Bereich konkrete VLAN-Einträge.

Beispiel:

interfaces:
  - name: GigabitEthernet1/0/10
    description: User-LAN-Floor3
    mode: access
    access_vlan: 30

Hier ist der Bereich interfaces die logische Klammer, darunter folgen die einzelnen Interface-Objekte.

Container in YANG einfach erklärt

Der Container als formales Modellierungselement

In YANG ist der container ein definierter Baustein, um Daten zu gruppieren. Er wird verwendet, wenn ein Bereich logisch zusammengehörige Unterelemente enthält. Das ist besonders hilfreich bei Systemdaten, Routing-Bereichen oder Interface-Sammlungen.

Ein stark vereinfachtes YANG-Beispiel:

container system {
  leaf hostname {
    type string;
  }

  leaf domain-name {
    type string;
  }
}

Der Container system gruppiert hier zwei zusammengehörige Konfigurationswerte.

Container und Untercontainer

Container können wiederum weitere Container enthalten. Dadurch entstehen saubere Hierarchien. Das ist sinnvoll, wenn ein Bereich groß genug ist, um nochmals logisch unterteilt zu werden.

Beispielhaft:

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

Hier enthält der Container routing den Untercontainer ospf. So bleibt das Modell sauber gegliedert.

Warum diese Struktur für Automatisierung wichtig ist

Klare Datenpfade für APIs und Tools

Automatisierungssysteme müssen Daten gezielt lesen und schreiben können. Hierarchien und Container sorgen dafür, dass ein bestimmter Wert einen klaren Pfad besitzt. Statt nach freiem Text zu suchen, kann ein Tool gezielt auf einen definierten Bereich zugreifen.

Beispielsweise logisch:

Solche Pfade machen strukturierte APIs, Validierung und gezielte Änderungen überhaupt erst praktikabel.

Wiederverwendbarkeit und Wartbarkeit

Wenn Modelle sauber hierarchisch aufgebaut sind, lassen sie sich leichter erweitern. Ein neuer Bereich für Telemetrie, QoS oder VRFs kann in die bestehende Struktur integriert werden, ohne andere Teile unübersichtlich zu machen.

Genau das ist ein großer Unterschied zu flachen Datenstrukturen oder hartkodierten Skripten.

Beispiele aus der Praxis

Interface-Daten in einer sinnvollen Hierarchie

Ein sauber modelliertes Interface ist selten nur ein einzelner Name. Meist gehört es in eine Hierarchie mit mehreren Attributen.

device:
  interfaces:
    - name: GigabitEthernet1/0/24
      description: Uplink-to-fra-dist-sw01
      mode: trunk
      native_vlan: 99
      allowed_vlans:
        - 10
        - 20
        - 30

Diese Struktur zeigt:

Daraus kann dann CLI generiert werden:

interface GigabitEthernet1/0/24
 description Uplink-to-fra-dist-sw01
 switchport mode trunk
 switchport trunk native vlan 99
 switchport trunk allowed vlan 10,20,30

Routing-Daten logisch gruppieren

Auch Routing eignet sich hervorragend für hierarchische Modelle. Globale Routingdaten gehören in einen eigenen Bereich, darunter folgen Protokolle und deren spezifische Parameter.

device:
  routing:
    ospf:
      process_id: 10
      router_id: 10.255.0.1
      passive_default: true

Die zugehörige CLI könnte so aussehen:

router ospf 10
 router-id 10.255.0.1
 passive-interface default

Die Hierarchie macht deutlich, dass diese Werte nicht allgemein zum Gerät, sondern speziell zum OSPF-Bereich gehören.

Hierarchien bei Konfigurations- und Statusdaten

Konfigurationsdaten hierarchisch beschreiben

Konfigurationsdaten folgen meist einer klaren funktionalen Gliederung. Das hilft bei Provisionierung, Standardisierung und Versionsverwaltung.

Dadurch wird das Modell besser lesbar und kann direkt als Grundlage für Templates oder API-Calls dienen.

Statusdaten ebenfalls strukturiert ordnen

Auch Statusdaten profitieren stark von Hierarchien. Ein Gerät besitzt Statusdaten auf globaler Ebene und innerhalb einzelner Funktionsbereiche. Interfaces haben Link-Status und Fehlerzähler, Routing-Prozesse haben Nachbarschaften, NTP hat Synchronisationsstatus.

Typische operative Prüfungen per CLI:

show ip interface brief
show interfaces counters errors
show ip ospf neighbor
show ntp associations

In einem Modell können solche Informationen logisch ähnlich angeordnet sein wie die Konfigurationsdaten. Das erleichtert Soll-Ist-Vergleiche erheblich.

Typische Fehler beim Verständnis von Hierarchien und Containern

Alles auf einer Ebene speichern

Ein häufiger Fehler besteht darin, alle Werte flach nebeneinander abzulegen. Das mag bei sehr kleinen Datensätzen funktionieren, wird aber schnell unübersichtlich.

Gerade bei mehreren Interfaces, VLANs oder Routinginstanzen ist ein flaches Modell langfristig kaum wartbar.

Container mit echten Datenwerten verwechseln

Ein Container ist in der Regel keine eigentliche Nutzinformation wie Hostname oder IP-Adresse. Er ist die logische Gruppierung für solche Informationen. Wer Container und Werte nicht sauber trennt, baut unklare oder inkonsistente Modelle.

Zu tiefe Verschachtelung ohne echten Nutzen

Hierarchien sind sinnvoll, aber nicht jede zusätzliche Ebene ist automatisch gut. Wenn Modelle ohne fachlichen Mehrwert zu tief verschachtelt werden, leidet die Lesbarkeit. Die Struktur sollte logisch, aber pragmatisch bleiben.

Best Practices für Hierarchien und Container in Datenmodellen

Damit werden Hierarchien und Container von abstrakten Modellbegriffen zu einem sehr praktischen Werkzeug für Network Engineers: Sie schaffen Ordnung in komplexen Netzwerkinformationen, machen Zusammenhänge maschinenlesbar und bilden die Grundlage für saubere Automatisierung, strukturierte APIs und verlässliche Soll-Ist-Vergleiche im täglichen Netzwerkbetrieb.

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