Cisco Catalyst 9200: NETCONF und RESTCONF

Aus maxTechCorner
(Weitergeleitet von Cisco RESTCONF)

Auf einen Blick

Gilt fürCisco Catalyst 9200/9200L/9200CX mit IOS XE 17.15/17.18 (NETCONF und RESTCONF ab 16.9.2)
BereichNetzwerk-Hardware
Dauerca. 30 Minuten bis zur ersten Abfrage
RechtePrivileged EXEC (enable); Benutzer mit Privilege 15 für den Zugriff
StandOktober 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 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

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> und yang-interfaces aaa authorization method-list <Name>.


Warnungaaa 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 process müssen u. a. confd und ncsshd den Status Running zeigen.
  • candidate-datastore 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 netconf-yang einzuschalten.
  • Ist noch das alte netconf (ohne -yang) aktiv, mit no netconf legacy abschalten.

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 server 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 (ip http secure-trustpoint <Name>).


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 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 restconf bzw. no netconf-yang; den HTTPS-Server danach mit no ip http secure-server 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 IT-Consulting von m.a.x. it.

Siehe auch

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? Kontakt aufnehmen