11.7 Typische Anwendungsfälle für NETCONF und RESTCONF

NETCONF und RESTCONF gehören zu den wichtigsten Protokollen für moderne Netzwerkautomatisierung, weil sie strukturierte, modellgetriebene Zugriffe auf Router, Switches, Firewalls und andere Netzwerkgeräte ermöglichen. Statt ausschließlich mit CLI-Befehlen, SSH-Sessions und textbasierten Show-Ausgaben zu arbeiten, können Konfigurations- und Statusdaten über standardisierte Schnittstellen gelesen und geändert werden. Der praktische Nutzen dieser Protokolle zeigt sich besonders dann, wenn typische Betriebsaufgaben wiederholbar, skalierbar und kontrolliert ausgeführt werden sollen. Genau deshalb ist es für Network Engineers wichtig, nicht nur die Theorie hinter NETCONF und RESTCONF zu kennen, sondern vor allem typische Anwendungsfälle im realen Netzwerkbetrieb zu verstehen.

Warum typische Anwendungsfälle so wichtig sind

Protokolle werden erst im Betrieb greifbar

Viele Engineers lernen NETCONF und RESTCONF zunächst über technische Begriffe wie YANG, RPC, Datastores, Ressourcen oder HTTP-Methoden kennen. Diese Grundlagen sind wichtig, aber der eigentliche Mehrwert wird oft erst in praktischen Szenarien sichtbar. Ein Protokoll ist nur dann wirklich relevant, wenn es alltägliche Betriebsaufgaben einfacher, sicherer oder besser automatisierbar macht.

• Wie lese ich Konfigurationen ohne CLI-Parsing aus?
• Wie ändere ich Standardparameter auf vielen Geräten kontrolliert?
• Wie prüfe ich Soll- und Ist-Zustände strukturierter?
• Wie integriere ich Netzwerkgeräte in moderne Automatisierungsprozesse?

Genau diese Fragen beantworten typische Anwendungsfälle viel besser als eine rein theoretische Beschreibung.

NETCONF und RESTCONF sind keine Selbstzwecke

Weder NETCONF noch RESTCONF werden eingeführt, nur weil sie moderne Protokolle sind. Sie lösen konkrete Probleme: mangelnde Struktur in CLI-Ausgaben, fehleranfälliges Parsing, schwer skalierbare Änderungen und unpräzise Integrationen in Automatisierungsplattformen. Typische Use Cases machen sichtbar, in welchen Situationen der Einsatz besonders sinnvoll ist.

Anwendungsfall: Geräteinformationen und Basisdaten auslesen

Inventarisierung von Hostname, Plattform und Management-Daten

Ein sehr häufiger Einstieg in NETCONF und RESTCONF ist das strukturierte Auslesen grundlegender Geräteinformationen. Bevor Änderungen automatisiert werden, ist es sinnvoll, vorhandene Daten zuverlässig und maschinenlesbar zu erfassen. Dazu gehören beispielsweise Hostname, Modell, Softwarestand, Management-IP oder bestimmte globale Basisparameter.

• Hostname und Domain-Name
• Management-IP und Management-Interface
• Plattform und Betriebssystemversion
• Rollen- oder Standortbezug
• Systemweite Management-Parameter

In klassischen Umgebungen würden diese Informationen oft über CLI-Kommandos gesammelt:

show running-config | include hostname
show version
show ip interface brief

Mit NETCONF oder RESTCONF lassen sich dieselben Daten strukturierter erfassen, ohne Textblöcke aufwendig parsen zu müssen. Das ist besonders nützlich für Inventarsysteme, CMDBs, Netzwerkdokumentation und erste Read-Only-Automatisierung.

Warum dieser Use Case ideal für den Einstieg ist

Das strukturierte Auslesen von Basisdaten ist technisch relativ risikoarm, bringt aber sofort praktischen Mehrwert. Teams lernen dabei:

• wie Geräte strukturierte Daten bereitstellen,
• wie Modelle und Pfade aufgebaut sind,
• wie sich Antworten maschinell weiterverarbeiten lassen,
• wie stark sich APIs von klassischen CLI-Abfragen unterscheiden.

Gerade für den Einstieg ist das oft sinnvoller als sofort produktive Konfigurationsänderungen zu automatisieren.

Anwendungsfall: Standardisierte Basiskonfigurationen prüfen

NTP, Syslog, DNS und Management-Standards auslesen

Ein weiterer sehr typischer Use Case ist das Überprüfen standardisierter Basiskonfigurationen. In nahezu jedem professionellen Netzwerk gibt es globale Vorgaben, die auf allen oder auf vielen Geräten gleich sein sollten. Dazu gehören etwa NTP-Server, Syslog-Ziele, DNS-Einstellungen, SSH-Parameter oder AAA-Grundlagen.

• NTP-Server korrekt gesetzt?
• Syslog-Ziele vollständig vorhanden?
• Nur sichere Management-Protokolle aktiv?
• AAA-Server und Login-Standards konsistent?

CLI-basiert würde man oft so prüfen:

show running-config | include ntp
show running-config | include logging
show running-config | section line vty
show running-config | section aaa

Mit NETCONF und RESTCONF lassen sich diese Daten gezielter auslesen und direkt mit einem definierten Soll-Zustand vergleichen. Das ist ein klassischer Anwendungsfall für Compliance- und Drift-Prüfungen.

Mehrwert für Compliance und Audit

Gerade bei Sicherheits- und Betriebsstandards ist es wichtig, dass Daten nicht nur menschenlesbar, sondern auch maschinell vergleichbar sind. NETCONF und RESTCONF erleichtern diesen Soll-Ist-Abgleich deutlich, weil die Daten modelliert und strukturiert bereitgestellt werden.

• Weniger Parsing-Aufwand
• Mehr Konsistenz in Reports
• Schnellere Erkennung von Abweichungen
• Bessere Grundlage für Remediation-Prozesse

Anwendungsfall: Interface-Konfigurationen lesen und validieren

Ports, Beschreibungen und IP-Adressen erfassen

Interfaces gehören zu den häufigsten und wichtigsten Netzwerkobjekten. Deshalb ist das Auslesen von Interface-Konfigurationen ein sehr praxisnaher Anwendungsfall für NETCONF und RESTCONF. Automatisierungssysteme oder Inventarplattformen können damit gezielt Informationen über Ports, Beschreibungen, IP-Adressen, VLAN-Zuweisungen oder Trunk-Parameter abfragen.

• Welche Interfaces sind vorhanden?
• Welche Beschreibung ist gesetzt?
• Ist der Port Layer 2 oder Layer 3?
• Welche IP-Adresse oder welches VLAN ist konfiguriert?
• Welche Trunk-Parameter gelten?

In der CLI würde das oft über folgende Befehle laufen:

show running-config interface GigabitEthernet0/1
show ip interface brief
show interfaces status
show vlan brief

Der Vorteil modellierter Zugriffe liegt darin, dass das Tool direkt an das gewünschte Interface-Objekt und dessen Felder gelangt, ohne den gesamten Textblock interpretieren zu müssen.

Portstandards und Naming prüfen

Gerade in Campus- oder Data-Center-Umgebungen sind konsistente Interface-Beschreibungen, Access-Port-Standards und Trunk-Definitionen wichtig. RESTCONF und NETCONF eignen sich sehr gut, um solche Standards systematisch auszulesen und gegen ein Rollen- oder Template-Modell zu prüfen.

• Uplink-Ports korrekt beschrieben?
• Access-Ports im richtigen VLAN?
• PortFast oder BPDU Guard wie vorgesehen aktiv?
• Trunks mit erlaubten VLANs konsistent gesetzt?

Anwendungsfall: Standardisierte Änderungen auf mehreren Geräten

NTP-, Syslog- oder DNS-Parameter ändern

Ein sehr klassischer Write-Use-Case ist die Änderung globaler Standardparameter auf mehreren Geräten. Wenn etwa neue NTP-Server, geänderte Syslog-Ziele oder angepasste DNS-Einträge ausgerollt werden müssen, bieten NETCONF und RESTCONF deutliche Vorteile gegenüber manuellen CLI-Änderungen oder reinen SSH-Schleifen.

Ein klassischer CLI-Change könnte so aussehen:

conf t
ntp server 10.10.10.10
ntp server 10.10.10.11
logging host 10.20.20.20
end
write memory

Mit NETCONF oder RESTCONF wird dieselbe Änderung als strukturierte Datenoperation formuliert. Das erleichtert:

• saubere Soll-Definitionen,
• gezielte Änderungen auf Datenobjekten,
• bessere Idempotenz,
• einfachere Prüfung vor und nach dem Rollout.

Warum dieser Use Case besonders beliebt ist

Globale Basisparameter sind oft gut standardisiert, vergleichsweise risikoarm und auf vielen Geräten identisch relevant. Damit eignen sie sich hervorragend für erste produktive Write-Automatisierung mit NETCONF oder RESTCONF.

• wenig Sonderlogik,
• klare Zielwerte,
• hoher Nutzen bei vielen Geräten,
• gute Nachvollziehbarkeit im Change-Prozess.

Anwendungsfall: Interface-Änderungen kontrolliert umsetzen

Beschreibungen, IPs und Aktivierungsstatus anpassen

Neben globalen Parametern sind Interface-Änderungen ein typischer Use Case. Häufig müssen Beschreibungen angepasst, neue Layer-3-Uplinks eingerichtet oder Ports aktiviert beziehungsweise deaktiviert werden. Über strukturierte Schnittstellen lassen sich solche Änderungen gezielter und weniger fehleranfällig umsetzen als über reine CLI-Befehlsfolgen.

Typische CLI-Änderung:

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 oder RESTCONF werden dieselben Parameter auf dem Interface-Objekt geändert. Das ist besonders wertvoll, wenn Interface-Standards automatisiert aus Rollen, Vorlagen oder einer Source of Truth generiert werden.

Stärkere Kontrolle bei kritischen Ports

Gerade bei Uplinks, WAN-Interfaces oder Serveranschlüssen ist es wichtig, Änderungen kontrolliert und nachvollziehbar umzusetzen. NETCONF ist hier mit Candidate-, Validate- und Commit-Mechanismen oft besonders stark. RESTCONF wiederum kann sehr gut in API-nahe Provisionierungs- und Self-Service-Prozesse eingebunden werden.

Anwendungsfall: VLANs, Routing und Netzwerkdienste bereitstellen

Logische Netzwerkobjekte automatisiert anlegen

Ein weiterer häufiger Use Case ist das Bereitstellen logischer Netzwerkobjekte. Dazu gehören VLANs, Routing-Prozessparameter, statische Routen, VRFs oder andere logisch definierte Services. Wenn ein neues VLAN für einen Standort oder ein neuer Routing-Eintrag für einen Service eingeführt wird, lassen sich diese Änderungen strukturiert und standardisiert über modellgetriebene Protokolle umsetzen.

• VLAN-ID und VLAN-Name anlegen
• Neue Layer-3-Schnittstellen einrichten
• Statische Routen ergänzen
• Routing-Prozessparameter anpassen
• Serviceobjekte konsistent ausrollen

CLI-basiert würde das oft so aussehen:

vlan 30
 name CLIENT_FLOOR3

interface Vlan30
 ip address 192.0.2.1 255.255.255.0
 no shutdown

Mit NETCONF oder RESTCONF lassen sich diese Objekte näher an ihrem Datenmodell verwalten. Das ist besonders hilfreich, wenn dieselben Services auf vielen Standorten einheitlich ausgerollt werden sollen.

Rollen- und standortbasierte Bereitstellung

Wenn Netzwerke nach standardisierten Rollen und Standortmustern aufgebaut sind, eignen sich diese Protokolle sehr gut, um neue Services reproduzierbar zu aktivieren. Ein System kann beispielsweise auf Basis einer Source of Truth oder eines Templates automatisch die passenden VLAN-, Interface- und Routingdaten auf die richtigen Geräte bringen.

Anwendungsfall: Konfigurationsvalidierung vor produktiven Changes

NETCONF besonders stark bei kontrollierten Changes

Ein sehr wichtiger Use Case, insbesondere für NETCONF, ist die Validierung und kontrollierte Übernahme von Konfigurationsänderungen. In klassischen CLI-Workflows werden Befehle häufig sofort aktiv. In NETCONF-basierten Umgebungen können Änderungen je nach Plattform zunächst in einer Candidate-Konfiguration vorbereitet, validiert und erst danach per Commit aktiv geschaltet werden.

• Änderung vorbereiten
• Konfiguration prüfen
• Fehler vor Aktivierung erkennen
• Änderungen gezielt committen oder verwerfen

Das ist besonders nützlich bei:

• Änderungen an Routing-Parametern
• Anpassungen von Management-Zugängen
• WAN- oder Core-Änderungen
• größeren Batch-Rollouts

Warum dieser Use Case in produktiven Netzen so wertvoll ist

Je kritischer ein Change, desto wichtiger wird die Möglichkeit, ihn vorher zu validieren. Genau hier bietet NETCONF im Vergleich zur klassischen CLI oft den größten operativen Mehrwert. RESTCONF ist ebenfalls für strukturierte Änderungen geeignet, NETCONF spielt seine Stärke aber besonders bei kontrollierten, prozessorientierten Change-Modellen aus.

Anwendungsfall: Compliance-Prüfung und Drift-Erkennung

Soll-Ist-Vergleiche auf strukturierter Datenbasis

Compliance und Drift-Erkennung gehören zu den wichtigsten operativen Anwendungsfällen. Ein System kann mit NETCONF oder RESTCONF Konfigurationsdaten auslesen und mit einem definierten Soll-Zustand vergleichen. Dadurch lassen sich unautorisierte Änderungen, fehlende Standards oder unerwartete Abweichungen deutlich systematischer erkennen.

• Fehlen NTP- oder Syslog-Parameter?
• Ist SSH korrekt gesetzt?
• Sind AAA-Standards konsistent?
• Weichen Interface-Beschreibungen oder VLAN-Zuweisungen ab?

CLI-orientiert würde man dafür oft Kombinationen wie diese verwenden:

show running-config | include ntp
show running-config | include logging
show running-config | section line vty
show access-lists

Mit NETCONF und RESTCONF werden diese Prüfungen robuster, weil Datenfelder gezielter und semantisch sauberer verfügbar sind.

Automatisierte Remediation als nächster Schritt

Ein weiterer typischer Anwendungsfall ist die anschließende Korrektur erkannter Abweichungen. Nach der Prüfung kann ein Remediation-Prozess genau jene Werte ändern, die vom Standard abweichen. Dadurch werden Compliance-Systeme von reinen Reporting-Tools zu aktiven Bestandteilen des Netzwerkbetriebs.

Anwendungsfall: Integration in Portale, Plattformen und Self-Service

RESTCONF besonders stark in API-nahen Integrationen

RESTCONF eignet sich besonders gut, wenn Netzwerkfunktionen in übergeordnete Plattformen, Portale oder Web-Services integriert werden sollen. Da es HTTP, HTTPS und häufig JSON verwendet, passt es sehr gut in moderne API-Landschaften.

Typische Anwendungsfälle sind:

• Self-Service-Portale für VLAN- oder Interface-Provisionierung
• Integration in ITSM- und Ticket-Systeme
• Anbindung an Plattform- oder Cloud-nahe Workflows
• Dashboards und Reporting-Systeme
• API-basierte Netzwerkintegration in DevOps-Prozesse

Gerade Teams mit Entwickler- oder Plattformhintergrund finden RESTCONF oft zugänglicher, weil das Kommunikationsmodell vertraut wirkt.

Netzwerk als API-fähiger Service

In modernen Betriebsmodellen wird das Netzwerk zunehmend als programmierbare Plattform verstanden. RESTCONF hilft dabei, Netzwerkgeräte in dieselben API- und Integrationsmuster einzubetten wie andere Infrastrukturdienste. Das ist ein sehr typischer und strategisch wichtiger Use Case.

Anwendungsfall: Read-Only-Automatisierung für Monitoring und Reporting

Statusdaten strukturiert erfassen

Neben Konfigurationsdaten sind auch bestimmte operative Zustände ein typischer Anwendungsfall. Wenn Geräte entsprechende modellierte State-Daten bereitstellen, können Systeme diese Informationen strukturiert abrufen und in Monitoring- oder Reporting-Prozesse integrieren.

• Interface-Status
• aktive IP- oder Routing-Informationen
• Synchronisationsstatus von NTP
• bestimmte Betriebs- und Fehlerdaten

In CLI-orientierten Umgebungen würden dafür häufig diese Befehle verwendet:

show ip interface brief
show interfaces
show ip route
show ntp associations

Der Vorteil strukturierter Protokolle ist, dass solche Daten besser in automatisierte Soll-Ist-Prüfungen, Dashboards oder Reports übernommen werden können.

Warum Read-Only-Use-Cases oft zuerst umgesetzt werden

Read-Only-Szenarien sind in der Regel risikoärmer als Write-Automatisierung und liefern trotzdem schnell spürbaren Mehrwert. Viele Teams starten deshalb mit:

• Inventarisierung,
• Bestandsaufnahme,
• Compliance-Prüfungen,
• Reporting und Zustandsanalyse.

Erst danach folgen produktive Änderungsprozesse.

Wann NETCONF typischerweise besser passt

Kontrollierte Änderungen und Change-Prozesse

NETCONF ist besonders stark, wenn der Fokus auf strukturierten, kontrollierten Konfigurationsänderungen liegt. Typische Use Cases sind:

• Änderungen mit Candidate- und Commit-Logik
• Validierung vor produktiver Aktivierung
• größere Batch-Änderungen mit klarer Change-Steuerung
• prozedurale, transaktionsnahe Workflows

In klassischen Enterprise-Netzen mit hohem Anspruch an Change-Qualität und Nachvollziehbarkeit ist das ein sehr überzeugender Einsatzbereich.

Ideal für klassische Netzbetriebsteams mit Change-Fokus

Teams, die gewohnt sind, Änderungen stark zu kontrollieren, profitieren oft besonders von NETCONF. Das Protokoll passt gut zu formalen Wartungsfenstern, Rollback-Strategien und prozessorientiertem Konfigurationsmanagement.

Wann RESTCONF typischerweise besser passt

API-Integration und Web-nahe Workflows

RESTCONF ist besonders geeignet, wenn Netzwerkinformationen oder Änderungen in API-nahe Umgebungen eingebunden werden sollen. Typische Use Cases sind:

• Self-Service-Portale
• JSON-basierte Anwendungen
• Web- und Plattformintegration
• leichte Read-Only-Abfragen durch externe Systeme
• ressourcenorientierte Standardänderungen

Gerade für Teams, die bereits stark mit HTTP, JSON und REST-APIs arbeiten, ist das oft der schnellere und natürlichere Einstieg.

Besonders attraktiv für plattformnahe Automatisierung

Wenn Netzwerkfunktionen Teil größerer Plattformprozesse werden, etwa in hybriden Infrastruktur- oder DevOps-Umgebungen, passt RESTCONF oft sehr gut. Es ist API-nah, leicht integrierbar und für viele Nicht-Netzwerker einfacher zugänglich.

Best Practices für typische NETCONF- und RESTCONF-Anwendungsfälle

• Mit risikoarmen Read-Only-Use-Cases wie Inventarisierung und Compliance starten.
• Globale Standardparameter wie NTP, Syslog oder Management-Zugänge als erste Write-Use-Cases wählen.
• NETCONF bevorzugen, wenn Validierung, Candidate und Commit operativ wichtig sind.
• RESTCONF bevorzugen, wenn HTTP-, JSON- und API-Integration im Vordergrund stehen.
• Interface- und Basisdaten strukturiert auslesen, bevor größere Änderungen automatisiert werden.
• Soll-Zustände in einer Source of Truth oder in Templates definieren und dagegen prüfen.
• Write-Operationen immer mit Vorher-Nachher-Validierung kombinieren.
• CLI-Wissen beibehalten und strukturierte Protokolle als Ergänzung für Automatisierung nutzen.
• Geräteunterstützung und Modellabdeckung vor jedem produktiven Einsatz konkret prüfen.
• Typische Use Cases schrittweise erweitern, statt sofort komplexe End-to-End-Automatisierung zu erzwingen.

So zeigen typische Anwendungsfälle sehr klar, wo NETCONF und RESTCONF ihren praktischen Mehrwert entfalten: beim strukturierten Auslesen von Konfigurationen, bei standardisierten Änderungen, bei Compliance- und Drift-Prüfungen sowie bei der Integration des Netzwerks in moderne API- und Automatisierungsprozesse. Genau dort werden aus theoretischen Protokollen konkrete Werkzeuge für einen kontrollierten, skalierbaren und modernen 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:

• 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.