Site icon bintorosoft.com

11.6 NETCONF vs. RESTCONF: Unterschiede einfach erklärt

bintorosoft@gmail.com

NETCONF und RESTCONF gehören zu den wichtigsten Protokollen moderner Netzwerkautomatisierung. Beide wurden entwickelt, um Netzwerkgeräte strukturiert, standardisiert und näher an Datenmodellen statt an reinen CLI-Befehlen zu verwalten. Für viele Network Engineers wirken die beiden Begriffe zunächst ähnlich, weil beide häufig im Zusammenhang mit YANG, modellgetriebenen Netzwerken und API-basierter Automatisierung genannt werden. In der Praxis unterscheiden sie sich jedoch deutlich in Kommunikationsstil, Transport, Arbeitsweise und typischen Einsatzszenarien. Wer Netzwerke effizient automatisieren, Konfigurationen sicher ändern und Zustandsdaten strukturiert auslesen will, sollte deshalb verstehen, worin NETCONF und RESTCONF übereinstimmen, wo sie sich unterscheiden und wann welches Protokoll sinnvoller ist.

Warum NETCONF und RESTCONF überhaupt relevant sind

Die Grenzen klassischer CLI-basierter Verwaltung

Über viele Jahre wurden Router, Switches und Firewalls fast ausschließlich über die CLI verwaltet. Dieses Modell ist für Menschen sehr effektiv, stößt aber bei Automatisierung schnell an Grenzen. Freie Textbefehle, wechselnde Ausgabeformate und herstellerspezifische Syntax erschweren konsistente, skalierbare und validierbare Prozesse.

Typische CLI-Arbeit im Alltag sieht beispielsweise so aus:

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

NETCONF und RESTCONF setzen genau an dieser Stelle an. Beide stellen strukturierte Netzwerkdaten bereit und ermöglichen gezieltere, maschinenfreundlichere Interaktion mit Geräten.

Beide Protokolle gehören in modellgetriebete Netzwerke

NETCONF und RESTCONF sind besonders eng mit YANG-Modellen verbunden. YANG beschreibt die Datenstruktur von Interfaces, Routing, VLANs, NTP, AAA oder anderen Netzwerkobjekten. NETCONF und RESTCONF dienen dann dazu, diese modellierten Daten zu lesen und zu ändern. Beide Protokolle sind also Teil desselben Grundgedankens: Netzwerkgeräte sollen nicht nur über freie Befehlsfolgen, sondern über strukturierte Daten und standardisierte Schnittstellen verwaltet werden.

Was NETCONF ist

NETCONF als RPC-basiertes Managementprotokoll

NETCONF steht für Network Configuration Protocol. Es ist ein standardisiertes Protokoll, das Netzwerkgeräte über strukturierte RPC-Operationen verwaltet. RPC steht für Remote Procedure Call. Ein Client ruft also eine klar definierte Funktion auf dem Gerät auf, etwa zum Lesen einer Konfiguration, zum Ändern eines Parameters oder zum Committen einer vorbereiteten Änderung.

Typische NETCONF-Operationen sind:

NETCONF ist also stark operations- und transaktionsorientiert. Genau das macht es besonders interessant für kontrollierte Konfigurationsänderungen.

Transport typischerweise über SSH

NETCONF wird in der Praxis meist über SSH transportiert. Das ist für Network Engineers hilfreich, weil SSH als sicheres Managementprotokoll bereits etabliert ist. Auf Cisco-Geräten muss NETCONF häufig zunächst aktiviert werden.

conf t
netconf-yang
end

Zur Prüfung können je nach Plattform Befehle wie diese verwendet werden:

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

Diese CLI-Befehle sind nicht NETCONF selbst, sondern dienen nur der Aktivierung und Kontrolle des Dienstes.

Was RESTCONF ist

RESTCONF als REST-artige API für Netzwerkdaten

RESTCONF ist ebenfalls ein standardisiertes Protokoll zur Verwaltung von Netzwerkgeräten, verwendet aber einen anderen Kommunikationsstil. Es orientiert sich an REST-Prinzipien und stellt modellierte Netzwerkdaten als Ressourcen über HTTP beziehungsweise HTTPS bereit. Statt RPC-Operationen aufzurufen, greift ein Client auf bestimmte URI-Pfade zu und verwendet HTTP-Methoden wie GET, POST, PUT, PATCH oder DELETE.

RESTCONF ist damit ressourcenorientiert, während NETCONF stärker funktions- beziehungsweise operationsorientiert arbeitet.

Transport typischerweise über HTTPS

RESTCONF nutzt in der Praxis in der Regel HTTPS. Das macht es besonders attraktiv für Umgebungen, die bereits mit Web-APIs, JSON und HTTP-basierten Integrationen arbeiten. Auf Cisco-Plattformen sind dafür oft diese Schritte relevant:

conf t
ip http secure-server
restconf
end

Zur Prüfung kann unter anderem Folgendes verwendet werden:

show running-config | include restconf|ip http

Auch hier gilt: Diese CLI-Kommandos dienen der Vorbereitung, nicht der eigentlichen RESTCONF-Kommunikation.

Die wichtigste Gemeinsamkeit: Beide arbeiten mit YANG-Datenmodellen

YANG als gemeinsame Basis

Der größte gemeinsame Nenner von NETCONF und RESTCONF ist die enge Verbindung zu YANG. Beide Protokolle greifen auf modellierte Daten zu, statt rein frei formatierte Textblöcke zu übertragen. Das bedeutet:

Dadurch unterscheiden sich beide Protokolle grundlegend von rein CLI-basierten Verfahren.

Beide reduzieren die Abhängigkeit von Text-Parsing

Ein großer Vorteil beider Protokolle ist, dass sie strukturierte Daten liefern. Statt komplette CLI-Ausgaben wie diese zu parsen:

show running-config
show interfaces
show ip route

können Tools gezielt modellierte Objekte und Felder anfragen. Das reduziert Parsing-Aufwand, erhöht die Stabilität von Automatisierung und verbessert die Qualität von Soll-Ist-Vergleichen.

Der zentrale Unterschied: RPC-orientiert versus ressourcenorientiert

NETCONF arbeitet mit Operationen

NETCONF folgt einem RPC-basierten Modell. Der Client ruft eine definierte Funktion auf dem Gerät auf. Typischerweise denkt man also in Aktionen wie:

Das ist besonders stark für kontrollierte, prozedurale Workflows. Der Fokus liegt stärker auf dem Vorgang selbst als auf der Ressource.

RESTCONF arbeitet mit Ressourcen und HTTP-Methoden

RESTCONF folgt einem ressourcenorientierten Modell. Der Client adressiert einen URI-Pfad, der ein bestimmtes Netzwerkobjekt oder einen Datenbereich repräsentiert, und verwendet eine HTTP-Methode, um mit dieser Ressource zu interagieren.

Das Denken ist hier eher:

Dieser Stil wirkt auf Entwickler und Plattformteams oft vertrauter, weil er sich gut in moderne API-Architekturen einfügt.

Unterschiede beim Transport und Datenformat

NETCONF: meist SSH und XML

NETCONF verwendet typischerweise SSH als Transport und XML zur Darstellung von Operationen und Daten. Das macht es strukturiert und leistungsfähig, wirkt aber für viele Engineers zunächst etwas schwergewichtiger.

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

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

Dieses Format ist sehr formal und gut geeignet für definierte Protokolloperationen.

RESTCONF: meist HTTPS und oft JSON

RESTCONF verwendet typischerweise HTTPS und kann Daten in XML oder JSON liefern. Gerade JSON macht RESTCONF für viele Teams leichter zugänglich, weil es aus modernen APIs bestens bekannt ist.

Ein stark vereinfachtes JSON-ähnliches Beispiel für ein Interface-Objekt:

{
  "name": "GigabitEthernet0/1",
  "description": "Uplink-to-Core",
  "enabled": true
}

Das wirkt für viele Engineers und Entwickler intuitiver als ein XML-lastiger RPC-Dialog.

Unterschiede bei Änderungsprozessen

NETCONF bietet stärkere Transaktionsmechanismen

Einer der größten praktischen Unterschiede liegt im Umgang mit Konfigurationsänderungen. NETCONF ist traditionell stärker auf kontrollierte, transaktionsnahe Workflows ausgelegt. Besonders wichtig sind dabei Konzepte wie:

Wenn ein Gerät Candidate unterstützt, können Änderungen erst vorbereitet, dann geprüft und anschließend gemeinsam übernommen werden. Das ist für größere oder risikoreiche Changes sehr wertvoll.

RESTCONF wirkt oft direkter und API-näher

RESTCONF ist ressourcenorientierter und oft näher an klassischen Web-APIs. Änderungen werden typischerweise per PUT, PATCH oder DELETE gegen definierte Ressourcen ausgeführt. Das kann sehr elegant sein, insbesondere bei API-zentrierten Integrationen. Im direkten Vergleich wirkt NETCONF oft stärker prozessorientiert, RESTCONF stärker objektorientiert.

Für Engineers bedeutet das vereinfacht:

Unterschiede beim mentalen Modell für Engineers

NETCONF denkt in Funktionen und Datastores

Bei NETCONF ist das Denkmodell stark davon geprägt, welche Funktion auf welchem Datastore ausgeführt wird. Typische Fragen sind:

Das passt gut zu klassischen Netzbetriebsteams, die saubere Change-Fenster, Rollback-Logik und kontrollierte Aktivierung schätzen.

RESTCONF denkt in Ressourcen und HTTP-Methoden

Bei RESTCONF ist das Denkmodell näher an Web-APIs. Hier fragt man eher:

Das ist besonders eingängig für Teams, die bereits mit REST-APIs, Plattformengineering oder Web-Integrationen arbeiten.

Vergleich typischer Einsatzszenarien

Wann NETCONF oft im Vorteil ist

NETCONF spielt seine Stärken besonders in kontrollierten Konfigurationsprozessen aus. Dazu gehören Szenarien, in denen saubere Validierung, Candidate-Konfiguration und Commit-Logik wichtig sind.

Gerade in klassischen Enterprise-Netzen mit hohem Change-Anspruch ist das oft ein starkes Argument für NETCONF.

Wann RESTCONF oft im Vorteil ist

RESTCONF ist besonders attraktiv, wenn Netzwerkgeräte stärker in moderne API-Landschaften integriert werden sollen. Typische Vorteile zeigen sich in Umgebungen mit Web-Services, Plattformen und JSON-basierten Toolchains.

RESTCONF fühlt sich in solchen Szenarien oft natürlicher an als ein XML- und RPC-lastiger Ansatz.

Beide Protokolle im Verhältnis zur CLI

CLI bleibt weiterhin relevant

Weder NETCONF noch RESTCONF machen die CLI überflüssig. Die klassische Kommandozeile bleibt vor allem für Troubleshooting, Live-Diagnose und plattformspezifische Detailanalyse unverzichtbar. Typische Befehle wie diese bleiben im Alltag zentral:

show ip interface brief
show ip route
show logging
show spanning-tree
show access-lists

Der Unterschied liegt darin, dass NETCONF und RESTCONF vor allem für strukturierte Automatisierung, konsistente Konfigurationsverwaltung und Integrationen einen großen Mehrwert bieten.

Die Zukunft ist meist hybrid

In der Praxis setzen viele Teams auf hybride Betriebsmodelle:

Dieses Zusammenspiel ist in realen Netzwerkumgebungen oft sinnvoller als die ausschließliche Konzentration auf nur ein Modell.

Unterschiede bei Einstiegshürde und Tooling

RESTCONF wirkt oft zugänglicher

Viele Engineers empfinden RESTCONF am Anfang als leichter zugänglich, weil HTTPS, HTTP-Methoden und JSON aus vielen anderen IT-Bereichen bekannt sind. Das senkt die mentale Einstiegshürde, besonders wenn bereits Erfahrungen mit Web-APIs bestehen.

NETCONF wirkt technischer, bietet aber oft mehr Kontrolle

NETCONF kann anfangs formaler und komplexer wirken, vor allem wegen XML, RPC-Struktur und Datastore-Konzepten. Dafür bietet es gerade in streng kontrollierten Netzwerkumgebungen oft die tieferen und präziseren Mechanismen für Change-Management und Validierung.

Für viele klassische Netzwerkteams ist das kein Nachteil, sondern ein echter Mehrwert.

Typische Missverständnisse im direkten Vergleich

NETCONF und RESTCONF sind keine Konkurrenten im simplen Sinn

Es ist verkürzt, die Frage nur als „welches Protokoll ist besser?“ zu betrachten. Beide verfolgen ähnliche Ziele, nutzen ähnliche Datenmodelle und adressieren ähnliche Problemfelder, aber mit unterschiedlichem Stil. In vielen Umgebungen können beide nebeneinander sinnvoll sein.

RESTCONF ist nicht einfach „NETCONF in HTTP“

Auch wenn beide Protokolle modellierte Daten nutzen, unterscheiden sie sich konzeptionell deutlich. NETCONF bleibt RPC- und datastore-orientiert, RESTCONF ressourcen- und HTTP-orientiert. Diese Unterschiede prägen Design, Tooling und typische Workflows.

JSON allein macht RESTCONF nicht automatisch besser

JSON wirkt oft angenehmer als XML, aber das allein entscheidet nicht über den praktischen Nutzen. Für kontrollierte, transaktionsnahe Netzwerkchanges kann NETCONF trotz XML die bessere Wahl sein. Umgekehrt ist RESTCONF oft klar im Vorteil, wenn Web-Integration und API-Zugänglichkeit im Vordergrund stehen.

Praktische Einordnung für Network Engineers

Fragen, die bei der Auswahl helfen

Welche Schnittstelle besser passt, hängt stark vom Anwendungsfall ab. Hilfreiche Leitfragen sind:

Diese Fragen führen oft zu einer viel besseren Entscheidung als ein rein theoretischer Protokollvergleich.

Beide zuerst read-only kennenlernen

In der Praxis ist es sinnvoll, sowohl NETCONF als auch RESTCONF zunächst für Read-Only-Aufgaben zu nutzen. So können Teams Erfahrung mit Datenmodellen, Pfaden, Antworten und Plattformverhalten sammeln, bevor produktive Write-Changes automatisiert werden.

Beispielhafte Vorbereitung auf Cisco-Geräten:

conf t
netconf-yang
ip http secure-server
restconf
end

Und zur Kontrolle:

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

Diese Kommandos helfen dabei, die technischen Voraussetzungen für beide Protokolle sauber einzuordnen.

Best Practices für das Verständnis von NETCONF vs. RESTCONF

Damit werden die Unterschiede zwischen NETCONF und RESTCONF deutlich greifbarer: Beide schaffen strukturierte, modellgetriebete Zugriffe auf Netzwerkgeräte, aber NETCONF ist stärker auf definierte Operationen, Datastores und kontrollierte Changes ausgelegt, während RESTCONF ressourcenorientiert, API-nah und besonders gut in moderne Web- und Plattformarchitekturen integrierbar ist.

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