Moderne Netzwerke bestehen nicht nur aus Konfigurationen, die auf Geräten gesetzt werden, sondern auch aus laufenden Betriebsinformationen, die den tatsächlichen Zustand der Infrastruktur abbilden. Für Network Engineers ist es deshalb entscheidend, zwischen Konfigurationsdaten und Statusdaten zu unterscheiden. Beide Datenarten sind für Betrieb, Automatisierung, Monitoring, Troubleshooting und Compliance unverzichtbar. Modelle für Konfiguration und Statusdaten helfen dabei, diese Informationen strukturiert, konsistent und maschinenlesbar zu beschreiben. Genau dadurch werden Netzwerkprozesse reproduzierbarer, besser prüfbar und deutlich einfacher zu automatisieren. Wer Netzwerke nicht nur manuell verwalten, sondern skalierbar betreiben möchte, muss verstehen, wie diese beiden Datenwelten zusammenhängen und worin sie sich unterscheiden.
Was mit Konfigurationsdaten und Statusdaten gemeint ist
Konfigurationsdaten beschreiben den gewünschten Zustand
Konfigurationsdaten enthalten alle Werte, die aktiv auf einem Gerät definiert werden, um sein Verhalten festzulegen. Sie beschreiben also den Soll-Zustand eines Routers, Switches, einer Firewall oder eines WLAN-Controllers. Dazu gehören alle Einstellungen, die ein Administrator bewusst setzt, damit ein Gerät eine bestimmte Funktion erfüllt.
- Hostname und Domain-Name
- IP-Adressen auf Interfaces
- VLAN-Zuweisungen
- Routing-Protokolle und statische Routen
- Access Control Lists
- SNMP-, Syslog- und NTP-Parameter
- AAA- und SSH-Konfiguration
Ein klassisches Beispiel für Konfigurationsdaten auf einem Cisco-Gerät ist die Definition eines Interfaces:
interface GigabitEthernet0/1
description Uplink-to-Core
ip address 192.0.2.2 255.255.255.252
no shutdown
Diese Zeilen legen fest, wie das Interface arbeiten soll. Genau das ist der Kern von Konfigurationsdaten: Sie definieren die beabsichtigte Betriebsweise.
Statusdaten beschreiben den tatsächlichen Betriebszustand
Statusdaten zeigen, wie sich das Gerät oder ein bestimmter Dienst aktuell verhält. Sie bilden also den Ist-Zustand ab. Diese Daten entstehen nicht primär dadurch, dass ein Administrator sie setzt, sondern durch den laufenden Betrieb des Geräts, seiner Protokolle und seiner Verbindungen.
- Ist ein Interface administrativ aktiv und operativ up?
- Welche Nachbarn hat OSPF oder BGP aktuell?
- Wie hoch ist die CPU- oder Speicherauslastung?
- Welche MAC-Adressen sind gelernt?
- Welche Routen befinden sich in der Routing-Tabelle?
- Ist der NTP-Server erreichbar und synchronisiert?
Typische CLI-Befehle für Statusdaten sind:
show ip interface brief
show interfaces status
show ip route
show spanning-tree
show bgp summary
show ntp associations
Diese Ausgaben beschreiben nicht nur, was konfiguriert wurde, sondern was das Gerät tatsächlich gerade sieht und tut.
Warum die Trennung beider Datenarten so wichtig ist
Konfiguration allein reicht für den Betrieb nicht aus
Ein Gerät kann formal korrekt konfiguriert sein und trotzdem im Betrieb Probleme haben. Ein Interface kann eine IP-Adresse besitzen, aber physisch down sein. Ein OSPF-Prozess kann konfiguriert sein, aber keine Nachbarschaften aufbauen. Ein NTP-Server kann eingetragen sein, aber nicht erreichbar sein. Deshalb reicht es nicht, nur Konfigurationsdaten zu betrachten.
- Konfiguration zeigt die Absicht.
- Status zeigt die Realität.
- Beides zusammen ergibt ein vollständiges Bild.
Gerade in der Automatisierung ist diese Unterscheidung essenziell. Wer nur Konfiguration ausrollt, aber den Status nicht prüft, erkennt viele Fehler erst zu spät oder gar nicht.
Statusdaten ohne Kontext sind ebenfalls nicht genug
Umgekehrt sind reine Statusdaten ohne Soll-Zustand oft schwer zu bewerten. Wenn ein Interface down ist, ist das nicht automatisch ein Fehler. Vielleicht soll es absichtlich deaktiviert sein. Wenn ein OSPF-Adjacency fehlt, muss zunächst klar sein, ob dort überhaupt eine Nachbarschaft erwartet wird. Statusdaten gewinnen ihren Wert also häufig erst im Vergleich mit einem definierten Konfigurationsmodell.
Modelle als strukturierte Beschreibung von Daten
Warum Datenmodelle im Netzwerk nützlich sind
Ein Datenmodell beschreibt Informationen nicht als freien Text, sondern als strukturierte Objekte mit Eigenschaften, Datentypen und Beziehungen. Im Netzwerkkontext bedeutet das: Interfaces, VLANs, IP-Präfixe, Routen oder Betriebszustände werden logisch und maschinenlesbar definiert.
Statt nur eine CLI-Konfiguration zu sehen, kann ein Interface beispielsweise modelliert werden als:
name: GigabitEthernet0/1
description: Uplink-to-Core
enabled: true
ipv4_address: 192.0.2.2
prefix_length: 30
Und ergänzend als Statusdaten:
name: GigabitEthernet0/1
oper_status: up
line_protocol: up
input_errors: 0
output_errors: 0
Diese Trennung ist besonders hilfreich für Automatisierung, Validierung und Monitoring.
Modelle schaffen Klarheit zwischen Soll und Ist
Wenn Konfigurationsdaten und Statusdaten sauber modelliert sind, lassen sich Soll-Ist-Vergleiche präzise durchführen. Ein System kann dann erkennen:
- Ein Interface soll aktiv sein, ist aber operativ down.
- Ein NTP-Server ist konfiguriert, aber nicht synchron.
- Ein Routing-Prozess ist vorhanden, aber ohne erwartete Nachbarn.
- Ein VLAN ist definiert, aber auf einem Gerät nicht aktiv.
Genau deshalb sind Modelle nicht nur für Provisionierung, sondern auch für Prüf- und Betriebsprozesse so wichtig.
Typische Beispiele für Konfigurationsdaten im Netzwerk
Management- und Basisparameter
Viele Konfigurationsdaten beschreiben die administrative Grundfunktion eines Geräts. Diese Werte ändern sich selten spontan, sondern werden bewusst definiert.
- Hostname
- Management-IP
- Default Gateway oder Management-VRF
- SSH- und AAA-Parameter
- NTP- und Syslog-Server
- SNMP-Konfiguration
Ein Beispiel:
hostname fra-access-sw01
ip domain-name example.local
ntp server 10.10.10.10
ntp server 10.10.10.11
logging host 10.20.20.20
ip ssh version 2
Diese Werte definieren die gewünschte Betriebsbasis des Geräts.
Interface- und VLAN-Konfigurationen
Besonders häufig werden Konfigurationsdaten auf Port- und VLAN-Ebene benötigt. Sie definieren, welche Rolle ein Interface hat und wie es im Layer-2- oder Layer-3-Design eingebunden ist.
interface GigabitEthernet1/0/10
description User-LAN-Floor3
switchport mode access
switchport access vlan 30
spanning-tree portfast
spanning-tree bpduguard enable
Hier wird klar festgelegt, dass es sich um einen Access-Port im VLAN 30 handelt, inklusive zusätzlicher Layer-2-Schutzfunktionen.
Routing- und Sicherheitsparameter
Auch Routing und Security sind klassische Konfigurationsbereiche. Dazu gehören statische Routen, OSPF-Instanzen, BGP-Peerings oder ACL-Regeln.
router ospf 10
router-id 10.255.0.1
passive-interface default
no passive-interface GigabitEthernet0/0
network 10.10.10.0 0.0.0.255 area 0
Oder eine einfache ACL:
ip access-list standard MGMT-ACL
permit 10.20.30.40
deny any
All diese Informationen beschreiben, wie das Gerät konfiguriert sein soll.
Typische Beispiele für Statusdaten im Netzwerk
Interface-Zustände und Fehlerzähler
Der Status eines Interfaces gehört zu den wichtigsten operativen Daten. Hier zeigt sich, ob eine konfigurierte Verbindung tatsächlich funktioniert.
Relevante Befehle:
show ip interface brief
show interfaces
show interfaces counters errors
Typische Statusinformationen:
- Administrativer Status
- Operativer Link-Status
- Line Protocol
- Fehlerzähler
- Bandbreitennutzung
- Duplex- und Speed-Aushandlung
Ein Interface kann also konfiguriert und administrativ aktiv sein, aber trotzdem wegen Kabel-, SFP- oder Gegenstellenproblemen operativ down sein.
Routing- und Nachbarschaftsinformationen
Routing-Statusdaten sind essenziell, um die tatsächliche Funktion von Layer-3-Netzen zu bewerten. Sie zeigen, welche Nachbarn bestehen, welche Routen aktiv sind und wie das Gerät aktuelle Pfade berechnet.
show ip route
show ip ospf neighbor
show bgp summary
show standby brief
- Welche Routen sind aktiv?
- Welche OSPF- oder BGP-Nachbarn sind up?
- Welcher HSRP-Router ist aktuell aktiv?
- Sind Redundanzmechanismen im erwarteten Zustand?
Diese Informationen lassen sich nicht allein aus der Konfiguration ableiten, sondern entstehen im Live-Betrieb.
Layer-2- und Betriebszustände
Auch auf Layer 2 existieren zahlreiche wichtige Statusdaten. Sie zeigen, welche VLANs aktiv sind, welche MAC-Adressen gelernt wurden oder in welchem Zustand sich Spanning Tree befindet.
show vlan brief
show mac address-table
show spanning-tree
show etherchannel summary
Gerade in Campus- und Data-Center-Netzen sind solche Daten für Troubleshooting und Validierung unverzichtbar.
Wie Konfigurations- und Statusmodelle zusammenarbeiten
Soll-Ist-Vergleich als zentrales Prinzip
Der größte Nutzen strukturierter Modelle entsteht, wenn Konfigurations- und Statusdaten gemeinsam betrachtet werden. Automatisierung und Compliance-Systeme vergleichen dann den gewünschten Zustand mit der tatsächlichen Realität.
Beispiele:
- Ein Interface soll aktiviert sein, ist aber down.
- Eine statische Route soll vorhanden sein, fehlt aber in der Routing-Tabelle.
- Ein NTP-Server ist konfiguriert, aber das Gerät ist nicht synchronisiert.
- Ein Trunk soll VLAN 30 führen, aber das VLAN ist operativ nicht aktiv.
Solche Abweichungen lassen sich nur erkennen, wenn beide Datenarten modelliert und systematisch verglichen werden.
Validierung nach Konfigurationsänderungen
Nach automatisierten oder manuellen Changes reicht es nicht aus, nur zu prüfen, ob die CLI erfolgreich geschrieben wurde. Es muss auch kontrolliert werden, ob die Änderung funktional wirksam wurde.
Beispielhafter Ablauf:
- Konfigurationsdaten erzeugen und ausrollen
- Gerät übernimmt die neue Konfiguration
- Statusdaten werden ausgelesen
- Ergebnis wird gegen den erwarteten Zielzustand geprüft
So wird aus einem reinen Deployment ein kontrollierter Betriebsprozess.
Modelle in modernen Netzwerk-APIs und Automatisierung
Warum strukturierte Schnittstellen beide Datenarten brauchen
Modellgetriebene APIs wie NETCONF oder RESTCONF arbeiten nicht nur mit Konfigurationsdaten, sondern oft auch mit operativen Zuständen. Das ist ein großer Vorteil gegenüber reinem CLI-Scraping. Systeme können gezielt unterscheiden, ob sie Konfigurationswerte setzen oder Statusinformationen abfragen.
- Konfigurationsmodelle für gewünschte Einstellungen
- Statusmodelle für operative Zustände
- Klare Trennung zwischen beschreibbaren und lesbaren Daten
Diese Trennung verbessert Datenqualität, Automatisierung und Fehlersicherheit.
YANG als Modellierungsgrundlage
In vielen modernen Umgebungen werden Konfigurations- und Statusdaten durch YANG-Modelle beschrieben. YANG legt fest, welche Felder existieren, welche Datentypen erlaubt sind und wie Daten hierarchisch aufgebaut sind. Dabei kann ein Modell sowohl Konfigurationsdaten als auch State-Daten definieren.
Für Network Engineers bedeutet das:
- Ein Interface wird nicht nur als CLI-Block betrachtet.
- Es wird als Datenobjekt mit Konfiguration und Zustand modelliert.
- Automatisierung kann gezielt lesen, schreiben und validieren.
Praktische Anwendung im Netzwerkbetrieb
Provisionierung neuer Geräte
Bei neuen Routern oder Switches werden zuerst Konfigurationsdaten benötigt. Dazu gehören Hostname, Management-IP, Basis-Security, NTP, Syslog und Interface-Definitionen. Diese Daten können aus einer Source of Truth stammen und per Template oder API ausgerollt werden.
Beispielhafte Basiskonfiguration:
hostname ber-dist-sw01
ntp server 10.10.10.10
logging host 10.20.20.20
ip ssh version 2
Nach dem Rollout werden Statusdaten geprüft:
show ip ssh
show ntp associations
show logging
show ip interface brief
So wird kontrolliert, ob die gewünschte Konfiguration tatsächlich wirksam ist.
Compliance und Drift-Erkennung
Compliance-Prüfungen benötigen fast immer beide Datenarten. Es reicht nicht zu wissen, dass SSH konfiguriert ist. Es muss auch geprüft werden, ob andere, unerwünschte Management-Protokolle aktiv sind oder ob das Gerät tatsächlich im erwarteten Zustand arbeitet.
- Konfigurationsmodell definiert den Soll-Zustand.
- Statusmodell zeigt die aktuelle Realität.
- Abweichungen werden als Drift oder Non-Compliance sichtbar.
Damit werden Prüfungen wesentlich aussagekräftiger als reine Konfigurationsvergleiche.
Troubleshooting und Incident Response
Im Störungsfall ist die Trennung ebenfalls hilfreich. Ein Engineer kann gezielt prüfen, ob das Problem auf fehlerhafte Konfiguration oder auf einen unerwarteten Betriebszustand zurückgeht.
- Ist die Route falsch konfiguriert oder nur nicht aktiv?
- Ist das Interface administrativ shutdown oder operativ gestört?
- Ist ein VLAN nicht angelegt oder nur nicht auf dem Trunk aktiv?
- Ist ein BGP-Peer falsch definiert oder nur temporär nicht erreichbar?
Gerade in komplexen Netzen beschleunigt dieses strukturierte Denken die Fehleranalyse deutlich.
Typische Fehler beim Umgang mit beiden Datenarten
Nur die Running-Config betrachten
Ein häufiger Fehler besteht darin, die Running-Config als vollständige Wahrheit zu betrachten. Sie zeigt jedoch nur die aktuelle Konfiguration, nicht deren tatsächliche Wirkung im Betrieb.
- Interface kann korrekt konfiguriert und trotzdem down sein.
- Routing-Protokoll kann vorhanden, aber ohne Nachbarn sein.
- NTP-Server kann eingetragen, aber unerreichbar sein.
Deshalb müssen Statusdaten immer ergänzend betrachtet werden.
Statusdaten ohne Soll-Modell interpretieren
Ebenso problematisch ist es, operative Zustände ohne Kontext zu bewerten. Nicht jeder Down-Status ist ein Fehler, nicht jede fehlende Route problematisch. Erst der Vergleich mit einem klaren Konfigurations- oder Zielmodell macht Statusdaten belastbar interpretierbar.
Konfiguration und Zustand nicht sauber trennen
In schlecht strukturierten Automatisierungsansätzen werden beide Datenarten oft vermischt. Das erschwert sowohl Templates als auch Validierung und Fehlersuche. Sauber getrennte Modelle sind deshalb deutlich wartbarer.
Best Practices für Modelle von Konfiguration und Statusdaten
- Konfigurationsdaten immer als Soll-Zustand und Statusdaten immer als Ist-Zustand betrachten.
- Beide Datenarten strukturiert und getrennt modellieren.
- Nach Changes nie nur die Konfiguration, sondern auch den Betriebszustand validieren.
- Interfaces, Routing, VLANs und Management-Funktionen sowohl in Konfiguration als auch im Status prüfen.
- Für Compliance und Drift-Erkennung immer Soll-Ist-Vergleiche aufbauen.
- CLI-Ausgaben gezielt in strukturierte Statusdaten überführen.
- Konfigurations- und Statusmodelle in Automatisierung, Monitoring und Troubleshooting gemeinsam nutzen.
- Mit einfachen Objekten wie Interfaces, NTP oder SSH beginnen und Modelle schrittweise erweitern.
- Source of Truth, Templates und Prüfprozesse auf dieselben Datenstrukturen ausrichten.
- Wo möglich modellgetriebene Schnittstellen wie NETCONF, RESTCONF oder YANG-basierte APIs nutzen.
Damit werden Modelle für Konfiguration und Statusdaten zu einem zentralen Werkzeug moderner Netzbetriebsprozesse: Sie verbinden die beabsichtigte Konfiguration mit der tatsächlichen Gerätewirklichkeit und schaffen die Grundlage für kontrollierte Automatisierung, belastbare Validierung und ein deutlich präziseres Verständnis des Netzwerkzustands.
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.
