imported>TechCorner-Redaktion: Neuer Artikel: netconf-yang, restconf, YANG-Modelle, ncclient, curl, save-config

2026-10-15T00:00:00Z

Neuer Artikel: netconf-yang, restconf, YANG-Modelle, ncclient, curl, save-config

Neue Seite

{{Steckbrief
| gilt_fuer = Cisco Catalyst 9200/9200L/9200CX mit IOS XE 17.15/17.18 (NETCONF und RESTCONF ab 16.9.2)
| bereich = Netzwerk-Hardware
| dauer = ca. 30 Minuten bis zur ersten Abfrage
| rechte = Privileged EXEC (enable); Benutzer mit Privilege 15 für den Zugriff
| stand = Oktober 2026
}}
'''NETCONF und RESTCONF auf dem Cisco Catalyst 9200''' sind die programmierbaren Schnittstellen von IOS XE: Statt CLI-Ausgaben zu lesen und Befehle per Skript einzutippen, fragen Werkzeuge wie Ansible, Python oder ein Monitoring-System strukturierte Daten ab und ändern die Konfiguration über '''YANG-Datenmodelle'''. NETCONF läuft über SSH und tauscht XML aus, RESTCONF über HTTPS mit JSON oder XML. Dieser Artikel zeigt, wie beide Schnittstellen sicher eingeschaltet, getestet und für erste Abfragen und Änderungen genutzt werden.

[[Datei:Cisco-9200-NETCONF-RESTCONF.png|thumb|center|750px|NETCONF und RESTCONF auf dem Catalyst 9200: Werkzeuge wie Ansible, Python mit ncclient oder curl greifen per NETCONF über SSH Port 830 bzw. per RESTCONF über HTTPS Port 443 auf YANG-Modelle (Cisco-IOS-XE-native, IETF, OpenConfig) zu; Voraussetzungen sind AAA, ein Benutzer mit Privilege 15 und eine Zugriffsbeschränkung auf das Management-Netz.]]

== NETCONF und RESTCONF im Vergleich ==
{| class="wikitable"
! Merkmal !! NETCONF !! RESTCONF !! CLI/SNMP
|-
| Standard || RFC 6241 || RFC 8040 || –
|-
| Transport || SSH, Port 830 || HTTPS, Port 443 || SSH bzw. UDP 161
|-
| Datenformat || XML || JSON oder XML || Text bzw. MIB-Werte
|-
| Datenspeicher || running, optional candidate mit commit || running || running
|-
| Transaktionen || ja, mit Sperre und Commit || nein, jede Anfrage einzeln || nein
|-
| typische Werkzeuge || Ansible (netconf_config), Python ncclient, Cisco NSO || curl, Postman, Python requests, Skripte || Netmiko, SNMP-Monitoring
|}
Faustregel: '''RESTCONF''' für einfache Abfragen und einzelne Änderungen, '''NETCONF''' für Konfigurationen, die als Ganzes gelingen oder gar nicht übernommen werden sollen. Beide Schnittstellen nutzen dieselben YANG-Modelle.

=== YANG-Modelle ===
* '''Cisco-IOS-XE-native''': bildet nahezu die komplette CLI-Konfiguration ab (Hostname, Interfaces, VLANs …).
* '''IETF-Modelle''' (z. B. ietf-interfaces) und '''OpenConfig''': herstellerübergreifend, aber mit kleinerem Funktionsumfang.
* '''Cisco-IOS-XE-*-oper''': Betriebsdaten wie Interface-Zähler, CPU-Last oder MAC-Tabelle.
Die Modelle jeder IOS-XE-Version veröffentlicht Cisco im GitHub-Repository ''YangModels/yang'' unter <code>vendor/cisco/xe/</code>; außerdem liefert der Switch sie per NETCONF selbst aus.

== Voraussetzungen ==
* Switch mit Grundkonfiguration, SSH und Management-Zugang – siehe [[Cisco Catalyst 9200: Erstkonfiguration und Absicherung]].
* Ein eigener Benutzer für die Automatisierung mit '''Privilege 15'''. Benutzer mit niedrigerer Stufe werden von RESTCONF abgewiesen.
* Ein Management-Netz, aus dem allein auf die Schnittstellen zugegriffen werden darf.

== Schritt 1: AAA und Automatisierungsbenutzer ==
<syntaxhighlight lang="text">
SW-OG-01# configure terminal
SW-OG-01(config)# aaa new-model
SW-OG-01(config)# aaa authentication login default local
SW-OG-01(config)# aaa authorization exec default local
SW-OG-01(config)# username netauto privilege 15 algorithm-type scrypt secret <Langes-Passwort>
</syntaxhighlight>
* Ist bereits '''TACACS+''' oder RADIUS eingerichtet, verwenden NETCONF und RESTCONF die vorhandenen Methodenlisten, z. B. <code>aaa authentication login default group TACACS-GRUPPE local</code> – siehe [[Cisco Catalyst 9200: Administratoren mit TACACS+ anmelden]]. Der zentrale Server muss dem Benutzer dann Privilege 15 zuweisen.
* Seit IOS XE 17.9.1 lassen sich für die Schnittstellen eigene Methodenlisten festlegen: <code>yang-interfaces aaa authentication method-list <Name></code> und <code>yang-interfaces aaa authorization method-list <Name></code>.

{{Warnung|<code>aaa new-model</code> ändert sofort die Anmeldung an Konsole und SSH. Vorher einen lokalen Benutzer mit Privilege 15 anlegen und die Anmeldung in einer zweiten Sitzung testen.}}

== Schritt 2: NETCONF einschalten ==
<syntaxhighlight lang="text">
SW-OG-01(config)# netconf-yang feature candidate-datastore
SW-OG-01(config)# netconf-yang
SW-OG-01(config)# end
SW-OG-01# show platform software yang-management process
</syntaxhighlight>
* Bis alle Prozesse laufen, können bis zu '''90 Sekunden''' vergehen. In der Ausgabe von <code>show platform software yang-management process</code> müssen u. a. ''confd'' und ''ncsshd'' den Status ''Running'' zeigen.
* <code>candidate-datastore</code> ist optional: Änderungen landen zunächst in einem Entwurf und werden erst mit ''commit'' aktiv. Dann ist der running-Datenspeicher über NETCONF '''nicht''' mehr direkt beschreibbar – Skripte müssen dafür ausgelegt sein. Cisco empfiehlt, die Funktion vor <code>netconf-yang</code> einzuschalten.
* Ist noch das alte <code>netconf</code> (ohne ''-yang'') aktiv, mit <code>no netconf legacy</code> abschalten.

== Schritt 3: RESTCONF einschalten ==
RESTCONF nutzt den HTTPS-Server des Switches. Deshalb gehört die Zugriffsbeschränkung zwingend dazu:
<syntaxhighlight lang="text">
SW-OG-01(config)# ip access-list standard MGMT-ZUGRIFF
SW-OG-01(config-std-nacl)# permit 10.10.0.0 0.0.0.255
SW-OG-01(config-std-nacl)# exit
SW-OG-01(config)# no ip http server
SW-OG-01(config)# ip http secure-server
SW-OG-01(config)# ip http authentication aaa
SW-OG-01(config)# ip http access-class ipv4 MGMT-ZUGRIFF
SW-OG-01(config)# restconf
SW-OG-01(config)# end
SW-OG-01# write memory
</syntaxhighlight>
* <code>no ip http server</code> lässt unverschlüsseltes HTTP aus; RESTCONF braucht nur HTTPS.
* Ohne eigenes Zertifikat erzeugt der Switch ein selbstsigniertes. Für den Dauerbetrieb ein Zertifikat der internen PKI einspielen und den HTTPS-Server über einen Trustpoint daran binden (<code>ip http secure-trustpoint <Name></code>).

{{Warnung|Über den HTTPS-Server von IOS XE wurde 2023 die Lücke '''CVE-2023-20198''' massenhaft ausgenutzt. Wer RESTCONF einschaltet, muss den Zugriff per <code>ip http access-class</code> auf das Management-Netz beschränken, den Switch nie aus dem Internet erreichbar machen und die Software aktuell halten. Wird RESTCONF nicht gebraucht, reicht NETCONF über SSH – dann bleibt der HTTPS-Server aus.}}

== Schritt 4: Verbindung testen ==
=== NETCONF ===
<syntaxhighlight lang="bash">
ssh -p 830 netauto@10.10.0.21 -s netconf
</syntaxhighlight>
Der Switch antwortet mit einer ''hello''-Nachricht und einer langen Liste von ''capabilities'' – den unterstützten YANG-Modellen. Mit <code>Strg+C</code> beenden. Abfrage per Python mit der Bibliothek ''ncclient'':
<syntaxhighlight lang="python">
from ncclient import manager

FILTER = '<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native"><hostname/></native>'

with manager.connect(host="10.10.0.21", port=830, username="netauto",
password="<Passwort>", hostkey_verify=True) as m:
print(m.get_config(source="running", filter=("subtree", FILTER)).xml)
</syntaxhighlight>
<code>hostkey_verify=True</code> setzt voraus, dass der SSH-Schlüssel des Switches in ''known_hosts'' steht; das einmalige SSH-Login oben trägt ihn ein.

=== RESTCONF: lesen ===
<syntaxhighlight lang="bash">
curl -u netauto --cacert interne-ca.pem \
-H "Accept: application/yang-data+json" \
https://10.10.0.21/restconf/data/Cisco-IOS-XE-native:native/hostname
</syntaxhighlight>
Antwort: <code>{"Cisco-IOS-XE-native:hostname": "SW-OG-01"}</code>. Weitere nützliche Pfade:
{| class="wikitable"
! Pfad unter /restconf/data/ !! Inhalt
|-
| <code>Cisco-IOS-XE-native:native</code> || komplette Konfiguration als JSON
|-
| <code>Cisco-IOS-XE-native:native/vlan</code> || VLAN-Konfiguration
|-
| <code>ietf-interfaces:interfaces</code> || Interfaces nach IETF-Modell
|-
| <code>Cisco-IOS-XE-interfaces-oper:interfaces</code> || Status und Zähler aller Interfaces
|-
| <code>Cisco-IOS-XE-matm-oper:matm-oper-data</code> || MAC-Adresstabelle
|}
Bei Interface-Namen wird der Schrägstrich URL-kodiert: <code>GigabitEthernet=1%2F0%2F10</code>.

=== RESTCONF: ändern ===
Beschreibung eines Ports setzen (PATCH ändert nur die angegebenen Werte):
<syntaxhighlight lang="bash">
curl -u netauto --cacert interne-ca.pem -X PATCH \
-H "Content-Type: application/yang-data+json" \
-H "Accept: application/yang-data+json" \
-d '{"Cisco-IOS-XE-native:GigabitEthernet": {"name": "1/0/10", "description": "Drucker OG"}}' \
https://10.10.0.21/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=1%2F0%2F10
</syntaxhighlight>
{| class="wikitable"
! HTTP-Methode !! Wirkung
|-
| GET || lesen
|-
| PATCH || zusammenführen: nur angegebene Werte ändern
|-
| PUT || ersetzen bzw. anlegen – vorsichtig verwenden, Unterelemente ohne Angabe werden entfernt
|-
| POST || neues Element anlegen oder Operation (RPC) aufrufen
|-
| DELETE || Element löschen
|}

== Änderungen speichern ==
Änderungen über NETCONF und RESTCONF landen in der '''running-config''' und gehen ohne Speichern beim nächsten Neustart verloren. Speichern per RESTCONF:
<syntaxhighlight lang="bash">
curl -u netauto --cacert interne-ca.pem -X POST \
-H "Accept: application/yang-data+json" \
https://10.10.0.21/restconf/operations/cisco-ia:save-config
</syntaxhighlight>
Per NETCONF steht dieselbe Operation als RPC ''save-config'' im Modell ''cisco-ia'' zur Verfügung; alternativ am Ende eines Laufs per CLI <code>write memory</code>.

== Kontrolle ==
<syntaxhighlight lang="text">
show platform software yang-management process ! confd, ncsshd, nginx usw.
show netconf-yang sessions ! aktive NETCONF-/RESTCONF-Sitzungen
show netconf-yang sessions detail
show netconf-yang datastores ! Sperren auf running/candidate
show netconf-yang statistics
show ip http server status ! HTTPS an, HTTP aus, access-class gesetzt
</syntaxhighlight>

== Hinweise ==
* '''Eigener Benutzer:''' Für Automatisierung immer ein eigenes Konto verwenden, nicht den Administrator. So bleibt im Log nachvollziehbar, welche Änderung ein Skript vorgenommen hat.
* '''Management-VRF:''' Läuft der Zugriff über den Management-Port Gi0/0, sind NETCONF und RESTCONF dort ebenfalls erreichbar; die Zugriffsliste muss das Management-Netz enthalten.
* '''Ansible:''' Die Collection ''cisco.ios'' arbeitet über die CLI und braucht NETCONF nicht. Für YANG-basierte Abläufe gibt es ''ansible.netcommon.netconf_config'' und ''netconf_get''.
* '''Telemetrie:''' Dieselben YANG-Modelle nutzt Model-Driven Telemetry; damit sendet der Switch Messwerte laufend an einen Collector, statt abgefragt zu werden.
* '''Abschalten:''' <code>no restconf</code> bzw. <code>no netconf-yang</code>; den HTTPS-Server danach mit <code>no ip http secure-server</code> wieder schließen, wenn er sonst nicht gebraucht wird.
* Bei der Automatisierung Ihrer Netzwerkverwaltung, von der Toolauswahl bis zum ersten Playbook, unterstützt Sie das [https://www.max-it.de/it-services/it-consulting/ IT-Consulting von m.a.x. it].

== Siehe auch ==
* [[Cisco Catalyst 9200]] – Überblick und alle Artikel der Reihe
* [[Cisco Catalyst 9200: Erstkonfiguration und Absicherung]]
* [[Cisco Catalyst 9200: Administratoren mit TACACS+ anmelden]]
* [[Cisco Catalyst 2960-X: Syslog und SNMP einrichten]] – klassisches Monitoring

== Links und Quellen ==
* [https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1718/b-1718-programmability-cg.html Cisco: Programmability Configuration Guide, Cisco IOS XE 17.18.x]
* [https://www.max-it.de/it-services/it-consulting/ IT-Consulting von m.a.x. it]

{{Uebermax}}
[[Kategorie:Netzwerk-Hardware]]

Cisco Catalyst 9200: NETCONF und RESTCONF - Versionsgeschichte

imported>TechCorner-Redaktion: Neuer Artikel: netconf-yang, restconf, YANG-Modelle, ncclient, curl, save-config