Site icon bintorosoft.com

11.4 Konfigurationen mit NETCONF lesen und ändern

bintorosoft@gmail.com

NETCONF ermöglicht es, Netzwerkgeräte strukturiert auszulesen und gezielt zu konfigurieren, ohne sich ausschließlich auf manuelle CLI-Sitzungen oder textbasiertes Parsing zu verlassen. Für moderne Netzwerkautomatisierung ist das ein entscheidender Fortschritt. Statt Router, Switches oder Firewalls nur über frei formulierte Befehle zu steuern, werden Konfigurations- und teilweise Zustandsdaten über standardisierte RPC-Operationen und modellierte Datenstrukturen verarbeitet. Gerade beim Lesen und Ändern von Konfigurationen zeigt NETCONF seine Stärken besonders deutlich: Daten lassen sich gezielt anfragen, Änderungen kontrolliert vorbereiten, validieren und anschließend übernehmen. Für Network Engineers bedeutet das mehr Struktur, bessere Wiederholbarkeit und eine robustere Grundlage für automatisierte Betriebsprozesse.

Was NETCONF beim Lesen und Ändern von Konfigurationen anders macht

Weg von freiem Text, hin zu strukturierten Daten

In klassischen Netzwerkumgebungen erfolgt der Zugriff auf Konfigurationen meist über die CLI. Ein Administrator liest Konfigurationen mit Show-Befehlen aus und schreibt neue Einstellungen per Konfigurationsmodus auf das Gerät. Dieses Verfahren ist praxisnah, aber stark textorientiert. NETCONF verfolgt einen anderen Ansatz: Es arbeitet mit strukturierten Daten und standardisierten Operationen.

Ein klassischer CLI-Ablauf zum Lesen und Ändern könnte so aussehen:

show running-config

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

Mit NETCONF werden dieselben Aufgaben nicht primär als freie Befehlsfolge verstanden, sondern als definierte Operationen auf modellierten Datenobjekten.

Konfigurationen als Daten statt als Textblöcke

NETCONF ist besonders stark, wenn Geräte YANG-basierte Datenmodelle unterstützen. Ein Interface, ein NTP-Server oder ein Routing-Prozess wird dann nicht nur als Text in der Running-Config betrachtet, sondern als Objekt mit klaren Feldern, Hierarchien und Datentypen. Das macht sowohl das Lesen als auch das Ändern deutlich präziser.

Die Grundbausteine von NETCONF beim Konfigurationszugriff

Client, Server und RPC-Operationen

NETCONF arbeitet nach dem Client-Server-Prinzip. Ein Client, zum Beispiel ein Automatisierungsskript, eine Orchestrierungsplattform oder ein Management-Tool, verbindet sich mit dem Netzwerkgerät. Dieses Gerät arbeitet als NETCONF-Server und verarbeitet die angeforderten Operationen.

Beim Lesen und Ändern von Konfigurationen sind folgende Elemente zentral:

Typische NETCONF-Operationen in diesem Zusammenhang sind:

Transport typischerweise über SSH

NETCONF wird in der Praxis meist über SSH transportiert. Für Network Engineers ist das hilfreich, weil SSH als sicheres Managementprotokoll bereits etabliert ist. Bevor NETCONF genutzt werden kann, muss die Funktion auf dem Gerät häufig aktiviert werden.

Auf Cisco-Plattformen erfolgt das oft mit:

conf t
netconf-yang
end

Prüfbefehle können je nach Plattform unter anderem so aussehen:

show running-config | include netconf
show netconf-yang sessions

Diese CLI-Kommandos dienen nicht dem eigentlichen NETCONF-Zugriff, sondern der Vorbereitung und Kontrolle der Verfügbarkeit.

Konfigurationsdaten mit NETCONF lesen

Was beim Lesen von Konfigurationen passiert

Beim Auslesen von Konfigurationen fordert der Client gezielt einen Konfigurationsdatenspeicher oder bestimmte modellierte Datenbereiche an. Im Gegensatz zur CLI muss nicht zwingend die gesamte Konfiguration als Textblock gelesen werden. Vielmehr können relevante Bereiche strukturiert abgefragt werden.

Die wichtigste Operation dafür ist in der Regel get-config. Sie liest Konfigurationsdaten aus einem angegebenen Datastore, etwa aus der laufenden Konfiguration.

Ein stark vereinfachtes NETCONF-Beispiel zum Lesen der Running Configuration:

<rpc>
  <get-config>
    <source>
      <running/>
    </source>
  </get-config>
</rpc>

Das Gerät antwortet mit einer strukturierten Rückgabe, in der die angeforderten Daten enthalten sind.

Gezieltes Lesen statt kompletter Vollausgabe

Ein großer Vorteil von NETCONF ist, dass nicht immer die gesamte Konfiguration benötigt wird. Oft ist es viel sinnvoller, nur bestimmte Bereiche zu lesen, etwa Interface-Daten, NTP-Parameter oder AAA-Einstellungen. Das reduziert Datenmenge und Auswertungsaufwand.

Im klassischen CLI-Modell wird dafür oft mit Filtern gearbeitet, zum Beispiel:

show running-config | include ntp
show running-config | section interface GigabitEthernet0/1
show running-config | section line vty

Mit NETCONF erfolgt dieselbe Logik strukturierter und näher an den eigentlichen Datenmodellen.

Welche Konfigurationsdaten sich typischerweise lesen lassen

Globale System- und Managementparameter

Ein häufiger Praxisfall ist das Lesen globaler Einstellungen, etwa für Hostname, NTP, Syslog, DNS oder AAA. Diese Werte sind besonders wichtig für Inventarisierung, Compliance und Baseline-Prüfungen.

Beispielhafte klassische CLI-Referenzen:

show running-config | include hostname
show running-config | include ntp
show running-config | include logging
show running-config | section aaa

Mit NETCONF können dieselben Inhalte als modellierte Datenobjekte gelesen werden.

Interface- und IP-Konfigurationen

Auch Interface-Daten sind ein typischer Anwendungsfall. Statt komplette Interface-Blöcke als Text zu parsen, kann ein Automatisierungssystem gezielt die Eigenschaften eines Ports abrufen.

Ein klassischer Interface-Block in der CLI könnte so aussehen:

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

Über NETCONF wird dieselbe Information strukturiert als Datenobjekt bereitgestellt.

Routing- und Service-Konfigurationen

Darüber hinaus lassen sich auch Routingdaten und andere Service-Parameter lesen, sofern Modell und Plattform das unterstützen. Dazu gehören etwa OSPF-, BGP-, ACL- oder VLAN-Konfigurationen.

Konfigurationsdaten mit NETCONF ändern

Änderungen über edit-config

Die zentrale Operation für Konfigurationsänderungen ist edit-config. Damit können strukturierte Konfigurationsdaten an das Gerät gesendet werden. Anders als bei einer losen CLI-Sequenz wird nicht einfach eine Folge von Textkommandos übertragen, sondern ein definierter Konfigurationsbereich mit seinen gewünschten Werten.

Ein stark vereinfachtes Beispiel könnte logisch so aussehen:

<rpc>
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      ...
    </config>
  </edit-config>
</rpc>

Welche Daten innerhalb des config-Abschnitts stehen, hängt vom jeweiligen YANG-Modell und vom gewünschten Änderungsumfang ab.

Änderungen gezielt und objektbezogen ausführen

Ein großer Vorteil von NETCONF liegt darin, dass Änderungen nicht zwingend als vollständiger Textblock eines ganzen Konfigurationsbereichs erfolgen müssen. Vielmehr können bestimmte Daten gezielt adressiert werden. Das reduziert das Risiko unbeabsichtigter Nebeneffekte.

In der klassischen CLI würde dieselbe Änderung oft direkt und kontextabhängig eingegeben:

conf t
interface GigabitEthernet0/1
 description Uplink-to-Core
end

Mit NETCONF ist diese Änderung präziser als strukturierte Datenoperation formulierbar.

Wichtige Konzepte beim Ändern von Konfigurationen

Running, Candidate und Startup unterscheiden

Beim Arbeiten mit NETCONF ist es wichtig, unterschiedliche Konfigurationsdatastores zu verstehen. Nicht jedes Gerät unterstützt alle Varianten, aber die Begriffe sind zentral für kontrollierte Änderungen.

Wenn ein Gerät einen Candidate-Datastore unterstützt, können Änderungen zunächst dort gesammelt werden. Das verbessert die Sicherheit und Steuerbarkeit des gesamten Change-Prozesses erheblich.

Merge, Replace und Delete sauber verstehen

Beim Ändern von Daten ist wichtig zu wissen, welche Art von Operation durchgeführt wird. In NETCONF können je nach Modell und Implementierung unterschiedliche Änderungsarten genutzt werden.

Gerade für Automatisierung ist diese Präzision ein wichtiger Vorteil gegenüber reinen Textbefehlen, bei denen die tatsächliche Wirkung stärker von Kontext und Syntax abhängt.

Praktisches Beispiel: Einen NTP-Server mit NETCONF ergänzen

Die klassische CLI-Sicht

Ein neuer NTP-Server wird in einer klassischen CLI-Sitzung häufig so eingetragen:

conf t
ntp server 10.10.10.10
ntp server 10.10.10.11
end
write memory

Das funktioniert gut, wenn ein Engineer direkt am Gerät arbeitet. Für Automatisierungssysteme bedeutet es aber, dass Kontext, Reihenfolge und Ergebnis sauber kontrolliert werden müssen.

Die strukturierte NETCONF-Sicht

Mit NETCONF wird derselbe Sachverhalt als strukturierte Konfigurationsänderung beschrieben. Ein Client übergibt dem Gerät modellierte Systemdaten, in denen die NTP-Server enthalten sind. Der Vorteil liegt darin, dass diese Informationen direkt als Datenobjekte verarbeitet werden können.

Zusätzlich kann anschließend strukturiert geprüft werden, ob die Werte korrekt gesetzt wurden. In der CLI geschieht das typischerweise mit:

show running-config | include ntp
show ntp associations

Mit NETCONF sind auch diese Prüfungen näher am Datenmodell möglich.

Praktisches Beispiel: Ein Interface lesen und ändern

Interface-Konfiguration auslesen

Ein sehr praxisnaher Anwendungsfall ist das gezielte Auslesen eines Interfaces. Nehmen wir an, ein Automatisierungssystem soll prüfen, ob auf GigabitEthernet0/1 die richtige Beschreibung und IP-Adresse gesetzt sind.

In der CLI würde man oft Folgendes verwenden:

show running-config interface GigabitEthernet0/1
show ip interface brief

Mit NETCONF kann dieselbe Abfrage über das modellierte Interface-Objekt erfolgen. So erhält das Tool nicht einfach nur einen Textblock, sondern klar benannte Felder wie Name, Beschreibung, Aktivierungsstatus und IPv4-Konfiguration.

Interface-Parameter ändern

Soll anschließend die Beschreibung oder die IP-Adresse angepasst werden, kann dies mit edit-config gezielt erfolgen. Die Änderung wird nicht als lose Befehlsfolge übertragen, sondern als definierter Teil der Interface-Datenstruktur.

Ein klassischer CLI-Change:

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

Mit NETCONF werden genau diese Werte als Interface-Datenobjekt an das Gerät geschickt. Das erhöht die Präzision und macht den Change für Tools besser nachvollziehbar.

Validierung vor produktiven Änderungen

Warum validate so wichtig ist

Ein zentraler Vorteil von NETCONF beim Ändern von Konfigurationen ist die Möglichkeit, Änderungen vor dem Commit zu validieren. In klassischen CLI-Prozessen werden viele Fehler erst sichtbar, wenn Befehle bereits aktiv sind. NETCONF kann hier deutlich kontrollierter arbeiten.

Gerade bei größeren Rollouts oder Änderungen an kritischen Diensten wie Routing, Management-Zugriff oder Security-Policies ist diese Vorabprüfung von großem praktischen Wert.

Candidate-Konfiguration und Commit

Wenn ein Gerät einen Candidate-Datastore unterstützt, lassen sich Änderungen zunächst dort ablegen. Erst nach erfolgreicher Prüfung werden sie mit commit produktiv übernommen. Dieses Prinzip ist für sichere Netzwerkchanges besonders wichtig.

Das ist deutlich kontrollierter als ein rein zeilenweises Schreiben in die Running-Config.

Typische Einsatzszenarien im Betrieb

Read-Only-Automatisierung und Bestandsaufnahme

Ein sinnvoller Einstieg in NETCONF besteht oft darin, zunächst nur Konfigurationen zu lesen. So lassen sich Inventarisierung, Compliance-Prüfungen und Vorher-Nachher-Vergleiche strukturierter aufbauen.

Diese Phase ist besonders wertvoll, weil Teams NETCONF kennenlernen, ohne direkt produktive Änderungen auszuführen.

Wiederkehrende Standardänderungen

Ein weiterer typischer Use Case sind standardisierte Changes, die auf vielen Geräten konsistent ausgerollt werden sollen.

Gerade solche strukturierten Änderungen profitieren stark von der Datenorientierung und Validierbarkeit von NETCONF.

Compliance, Drift-Erkennung und Remediation

Weil Konfigurationen gezielt gelesen und geändert werden können, eignet sich NETCONF sehr gut für Compliance-Workflows. Ein System kann zunächst den Ist-Zustand lesen, Abweichungen vom Soll-Modell erkennen und anschließend kontrollierte Korrekturmaßnahmen anstoßen.

Vorteile gegenüber klassischer CLI-Arbeit

Weniger Parsing, mehr Struktur

Ein wesentlicher Vorteil beim Lesen und Ändern von Konfigurationen über NETCONF ist die geringere Abhängigkeit von unstrukturierten Textausgaben. Das erleichtert die maschinelle Verarbeitung und reduziert Fehlerquellen.

Mehr Kontrolle über Changes

NETCONF verbessert insbesondere die Kontrollierbarkeit von Änderungen. Validierung, Candidate-Datastore und Commit-Mechanismen schaffen einen strukturierteren Prozess als klassische direkte CLI-Änderungen.

Gezieltere Objektänderungen

Ein weiteres Plus ist, dass Änderungen auf Ebene strukturierter Datenobjekte formuliert werden können. Statt Konfigurationsblöcke als Text zu senden, werden konkrete modellierte Werte verändert. Das ist für wiederholbare und saubere Automatisierung besonders wertvoll.

Grenzen und praktische Herausforderungen

Nicht jede Plattform unterstützt NETCONF gleich gut

Trotz aller Vorteile hängt der praktische Nutzen stark von der Geräteplattform, dem Softwarestand und den unterstützten Datenmodellen ab. Nicht jedes Gerät bietet denselben Umfang an NETCONF-Funktionen oder denselben Reifegrad modellgetriebener Schnittstellen.

CLI bleibt für Troubleshooting wichtig

Auch wenn NETCONF starke Vorteile für strukturierte Änderungen bietet, bleibt die CLI im operativen Alltag relevant. Gerade bei Troubleshooting, Live-Diagnose oder herstellerspezifischen Sonderfällen ist sie weiterhin ein wichtiges Werkzeug.

Typische Prüfbefehle bleiben deshalb unverzichtbar:

show ip interface brief
show ip route
show logging
show ntp associations
show access-lists

In der Praxis entsteht daher oft ein hybrider Ansatz: NETCONF für strukturierte Konfigurationsprozesse, CLI für operative Diagnose und Sonderfälle.

YANG- und Modellverständnis wird wichtiger

Wer mit NETCONF Konfigurationen lesen und ändern will, profitiert stark von einem sauberen Verständnis der zugrunde liegenden Datenmodelle. Ohne dieses Verständnis bleibt NETCONF zwar nutzbar, aber sein größter Vorteil – die strukturierte Datenorientierung – wird nicht vollständig ausgeschöpft.

Best Practices für das Lesen und Ändern von Konfigurationen mit NETCONF

Damit wird NETCONF beim Lesen und Ändern von Konfigurationen zu einem sehr praktischen Werkzeug für moderne Netzwerkteams: Es liefert strukturierte Daten statt freier Textblöcke, erlaubt gezielte Änderungen statt unkontrollierter Befehlsfolgen und schafft eine deutlich bessere Grundlage für sichere, nachvollziehbare und skalierbare Netzwerkautomatisierung.

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