Cisco Catalyst 9200: NETCONF und RESTCONF
Auf einen Blick
| Gilt für | 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.

NETCONF und RESTCONF im Vergleich
| 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 vendor/cisco/xe/; 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
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>
- Ist bereits TACACS+ oder RADIUS eingerichtet, verwenden NETCONF und RESTCONF die vorhandenen Methodenlisten, z. B.
aaa authentication login default group TACACS-GRUPPE local– 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:
yang-interfaces aaa authentication method-list <Name>undyang-interfaces aaa authorization method-list <Name>.
aaa new-model ä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
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
- Bis alle Prozesse laufen, können bis zu 90 Sekunden vergehen. In der Ausgabe von
show platform software yang-management processmüssen u. a. confd und ncsshd den Status Running zeigen. candidate-datastoreist 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 vornetconf-yangeinzuschalten.- Ist noch das alte
netconf(ohne -yang) aktiv, mitno netconf legacyabschalten.
Schritt 3: RESTCONF einschalten
RESTCONF nutzt den HTTPS-Server des Switches. Deshalb gehört die Zugriffsbeschränkung zwingend dazu:
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
no ip http serverlä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 (
ip http secure-trustpoint <Name>).
ip http access-class 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
ssh -p 830 netauto@10.10.0.21 -s netconf
Der Switch antwortet mit einer hello-Nachricht und einer langen Liste von capabilities – den unterstützten YANG-Modellen. Mit Strg+C beenden. Abfrage per Python mit der Bibliothek ncclient:
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)
hostkey_verify=True setzt voraus, dass der SSH-Schlüssel des Switches in known_hosts steht; das einmalige SSH-Login oben trägt ihn ein.
RESTCONF: lesen
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
Antwort: {"Cisco-IOS-XE-native:hostname": "SW-OG-01"}. Weitere nützliche Pfade:
| Pfad unter /restconf/data/ | Inhalt |
|---|---|
Cisco-IOS-XE-native:native |
komplette Konfiguration als JSON |
Cisco-IOS-XE-native:native/vlan |
VLAN-Konfiguration |
ietf-interfaces:interfaces |
Interfaces nach IETF-Modell |
Cisco-IOS-XE-interfaces-oper:interfaces |
Status und Zähler aller Interfaces |
Cisco-IOS-XE-matm-oper:matm-oper-data |
MAC-Adresstabelle |
Bei Interface-Namen wird der Schrägstrich URL-kodiert: GigabitEthernet=1%2F0%2F10.
RESTCONF: ändern
Beschreibung eines Ports setzen (PATCH ändert nur die angegebenen Werte):
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
| 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:
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
Per NETCONF steht dieselbe Operation als RPC save-config im Modell cisco-ia zur Verfügung; alternativ am Ende eines Laufs per CLI write memory.
Kontrolle
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
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:
no restconfbzw.no netconf-yang; den HTTPS-Server danach mitno ip http secure-serverwieder schließen, wenn er sonst nicht gebraucht wird. - Bei der Automatisierung Ihrer Netzwerkverwaltung, von der Toolauswahl bis zum ersten Playbook, unterstützt Sie das 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
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
