Konfigurieren von NETCONF/YANG für Cisco IOS XE 16.X-Plattformen
Inhalt
Einleitung
In diesem Dokument wird die Konfiguration von NETCONF/YANG auf Cisco IOS® XE 16.x-basierten Plattformen beschrieben.
Voraussetzungen
Anforderungen
NETCONF/YANG wird von der Cisco IOS® XE 16.3.1-Software unterstützt.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
In diesem Beispiel wird ein eigenständiger WS-C3850-12X48U-Switch mit Cisco IOS XE 16.3.3 als NETCONF-Server verwendet. Dies ist das konfigurierte Gerät, von dem Daten (Ausgabe des Befehls anzeigen) über NETCONF/YANG erfasst werden.
Als NETCONF Client wird ein Laptop (Apple MacBook Pro mit macOS Sierra 10.12.2 und Google Chrome Browser) verwendet. Es fungiert als zentralisierte Verwaltungsplattform und verwendet die Anwendung Yang Explorer. Es ist das Gerät, das die mit YANG formatierten Anforderungen erstellt, die über NETCONF RPC (Remote Procedure Call)-Nachrichten an Catalyst 3850 gesendet werden, um Daten vom Catalyst 3850 zu konfigurieren und zu sammeln.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Das Beispiel in diesem Dokument konzentriert sich auf Labortests mit dem Catalyst 3850. Die bereitgestellten Informationen gelten jedoch auch für andere Cisco IOS XE 16.x-Plattformen wie die Router der Cisco Serie ASR 1000.
Datenmodelle - programmgesteuerte und standardbasierte Konfiguration und Überwachung
Datenmodelle bieten eine alternative und zentralisierte Möglichkeit zur Konfiguration von Cisco Geräten (anstelle der Verwendung von Cisco Command Line Interface (CLI) oder Simple Network Management Protocol (SNMP)) und zur Erfassung von Betriebsdaten (Show-Befehlen) von Cisco Geräten. Da die Datenmodelle auf demselben Verfahren basieren und auch zur Konfiguration oder Erfassung von Daten von Geräten anderer Anbieter verwendet werden können, sind sie ideal für Kunden, die mehrere Anbieter unterstützen. Eine zentralisierte Managementplattform (z. B. ein Laptop) kann zur Konfiguration oder Erfassung von Daten von mehreren Cisco Geräten verwendet werden. Die Datenmodellarchitektur ermöglicht die Automatisierung dieser Verfahren mithilfe von Python-Scripting (zwei weitere wichtige Vorteile).
Another Next Generation (YANG) Data Modeling Language (RFC 6020)
YANG ist eine standardbasierte Datenmodellierungssprache, die verwendet wird, um Gerätekonfigurationsanforderungen oder Anforderungen für Betriebsdaten (Show-Command-Daten) zu erstellen. Es hat ein strukturiertes Format ähnlich einem Computerprogramm, das von Menschen lesbar ist. Es stehen mehrere Anwendungen zur Verfügung, die auf einer zentralisierten Managementplattform (z. B. einem Laptop) ausgeführt werden können, um diese Anforderungen für Konfiguration und Betriebsdaten zu erstellen.
Es gibt sowohl standardmäßige (gemeinsame) YANG-Datenmodelle, die für alle Anbieter gelten (z. B. kann eine Anforderung zur Deaktivierung oder Deaktivierung einer Ethernet-Schnittstelle für Cisco Geräte und Geräte von Drittanbietern identisch sein), als auch geräteeigene (herstellerspezifische) Datenmodelle, die die Konfiguration oder Erfassung von Betriebsdaten vereinfachen, die mit proprietären Herstellerfunktionen verknüpft sind.
Network Configuration (NETCONF) Protocol (RFC 6241)
NETCONF ist ein standardbasiertes und XML-codiertes Protokoll (Extensible Markup Language), das den Transport zur Übermittlung der YANG-formatierten Konfigurations- oder Betriebsdatenanforderung von einer Anwendung, die auf einer zentralisierten Verwaltungsplattform (z. B. einem Laptop) ausgeführt wird, an das Cisco-Gerät bereitstellt, das ein Benutzer konfigurieren möchte, oder von dem er operative Daten (Show-Command-Daten) anfordern möchte. Sie stellt transaktionsbasierte Services bereit, z. B. den Abbruch der gesamten Konfigurationsanforderung, wenn ein Teil der Konfigurationsanforderung fehlschlägt. NETCONF verwendet einen einfachen Remote Procedure Call (RPF)-basierten Mechanismus, um die Kommunikation zwischen einem Client (Skript oder Anwendung der zentralisierten Verwaltungsplattform) und einem Server (Cisco Switch oder Router) zu erleichtern. Dabei wird Secure Shell (SSH) als Transportebene für alle Netzwerkgeräte verwendet. Zu den NETCONF-Vorgängen gehören u. a. get, get-config, edit-config und rpc.
Konfigurieren
1. Grundlegende Konfiguration eines Catalyst 3850 mit Cisco XE 16.3.3-Software zur Unterstützung von NETCONF/YANG-Datenmodellierung
3850-1# show running-config
netconf-yang -------------------------------------> Enable NETCONF/YANG globally. It may take up to 90 seconds to initialize
username cisco1 privilege 15 password 0 cisco1 ---> Username/password used for NETCONF-SSH access
aaa new-model
aaa authorization exec default local -------------> Required for NETCONF-SSH connectivity and edit-config operations
2. Zusätzliche (optionale) Konfiguration, um die NETCONF/YANG-Syslog- und SNMP-Ereignisüberwachung zu ermöglichen
Diese SNMP-Serverkonfigurationen müssen vorhanden sein, damit die Generierung von NETCONF-Benachrichtigungen (RFC 5277 - Tools 5277) für Syslog-Meldungen und für konfigurierte SNMP-Traps ermöglicht wird, um auch NETCONF-Benachrichtigungen zu generieren.
Hinweis: Diese sind zwar mindestens erforderlich, es können jedoch auch weitere SNMP-server-Aktivierungseinträge vorhanden sein. Ein Client (zentrale Verwaltungsplattform) registriert sich, um den NETCONF-Benachrichtigungs-Stream von einem Server (Catalyst 3850) zu empfangen und ein bestimmtes Abonnement-RPC zu senden (siehe Abschnitt 3 der Konfiguration der zentralen Verwaltungsplattform (Laptop)).
3850-1# show running-config
snmp-server community <string> RW ------------------------------> SNMP gateway in DMI requires community public prior to 16.5.1. A configurable community is supported on 16.5.1 and later.
netconf-yang cisco-ia snmp-community-string <string> -----------> Configure the same community string to enable SNMP MIB access for both NETCONF and RESTCONF.
snmp-server trap link ietf -------------------------------------> enable traps for IETF link up/down
snmp-server enable traps snmp authentication linkdown linkup ---> enable traps for link up/down
snmp-server enable traps syslog --------------------------------> enable traps for Syslog so notifications can be generated
snmp-server manager --------------------------------------------> enable snmp-server
Bei Syslog muss diese Konfiguration vorhanden sein, damit die Data Model Interface (DMI) auf dem Catalyst 3850 NETCONF-Benachrichtigungen generieren kann, die in RFC 5277 definiert sind, wenn Syslog-Meldungen von Cisco auf dem Catalyst 3850 generiert werden.
logging history debugging -------> required for the generation of any NETCONF notification messages for Syslog
logging snmp-trap emergencies ---> configure 1 or more of the following to control which levels of Syslog messages are returned as notifications
logging snmp-trap alerts
logging snmp-trap critical
logging snmp-trap errors
logging snmp-trap warnings
logging snmp-trap notifications
logging snmp-trap informational
logging snmp-trap debugging
Bei SNMP-Traps ist diese Konfiguration erforderlich, um NETCONF-Benachrichtigungen zu generieren. In der Cisco XE 16.3.1-Software können maximal 10 SNMP-Traps konfiguriert werden, um NETCONF-Benachrichtigungen zu generieren. Diese Einschränkung kann jedoch in einer zukünftigen Version aufgehoben werden. Die Benachrichtigungsgenerierung für SNMP-Traps ist standardmäßig aktiviert. Um die Erstellung von SNMP-Trap-Benachrichtigungen zu deaktivieren, verwenden Sie diese CLI, kein "netconf-yang cisco-ia snmp-trap-control global-forwarding".
netconf-yang cisco-ia snmp-trap-control trap-list 10.3.6.1.6.3.1.1.5.3 --------> LinkDown trap
netconf-yang cisco-ia snmp-trap-control trap-list 10.3.6.1.6.3.1.1.5.4 --------> LinkUp trap
netconf-yang cisco-ia snmp-trap-control trap-list 10.3.6.1.4.1.9.9.41.2.0.1 ---> Syslog generated notification trap
3. Konfiguration der Netzwerkverbindung des in diesem Beispiel verwendeten Catalyst 3850
Die Catalyst 3850-Managementschnittstelle GigabitEthernet0/0 wird in diesem Beispiel für die Verbindung mit dem Netzwerk und der zentralisierten Managementplattform (ein Laptop ist möglich) verwendet. DHCP (Dynamic Host Configuration Protocol) wurde verwendet, um dieser Schnittstelle die IP-Adresse 172.16.167.175 zuzuweisen. Auf dem Catalyst 3850 können alternative Konfigurationen verwendet werden, solange der Laptop mit dem Catalyst 3850 im Netzwerk kommunizieren kann.
3850-1# show running-config
vrf definition Mgmt-vrf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
interface GigabitEthernet0/0
vrf forwarding Mgmt-vrf
ip address dhcp
negotiation auto
ip route vrf Mgmt-vrf 0.0.0.0 0.0.0.0 172.16.167.161
3850-1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
Vlan1 10.1.1.1 YES NVRAM up up
Vlan10 10.10.10.1 YES NVRAM up up
Vlan20 10.20.20.1 YES NVRAM up up
GigabitEthernet0/0 172.16.167.175 YES DHCP up up
Fo1/1/1 unassigned YES unset down down
Fo1/1/2 unassigned YES unset down down
GigabitEthernet1/0/1 unassigned YES manual up up
GigabitEthernet1/0/2 unassigned YES unset up up
GigabitEthernet1/0/3 unassigned YES unset down down
GigabitEthernet1/0/4 unassigned YES unset down down
GigabitEthernet1/0/5 unassigned YES unset down down
Prüfen Sie NETCONF/YANG auf dem Catalyst 3850.
1. Über die Befehlszeilenschnittstelle (CLI) des Catalyst 3850 kann dieser Befehl verwendet werden, um sicherzustellen, dass die zur Unterstützung der Datenmodellschnittstelle (DMI) auf dem Catalyst 3850 erforderlichen Softwareprozesse ausgeführt werden, sobald netconf-yang konfiguriert ist.
3850-1# show platform software yang-management process
confd : Running
nesd : Running
syncfd : Running
ncsshd : Running
dmiauthd : Running
vtyserverutild : Running
opdatamgrd : Running
ngnix : Running
Die nächsten Schritte werden über die zentralisierte Managementplattform ausgeführt. In diesem Beispiel wird ein Laptop (Apple MacBook Pro mit MacOS Sierra 10.12.2) verwendet, der über Netzwerkzugriff auf den Catalyst 3850 verfügt. Die Befehle werden von einer Terminaleingabeaufforderung auf dem Laptop ausgegeben. Derzeit ist keine spezielle Anwendung auf dem Laptop geladen.
2. Stellen Sie sicher, dass die zentrale Verwaltungsplattform (Laptop) den Catalyst 3850 (172.16.167.175) im Netzwerk erreichen kann.
USER1-M-902T:~ USER1$ ping 172.16.167.175
PING 172.16.167.175 (172.16.167.175): 56 data bytes
64 bytes from 172.16.167.175: icmp_seq=0 ttl=247 time=3.912 ms
64 bytes from 172.16.167.175: icmp_seq=1 ttl=247 time=6.917 ms
64 bytes from 172.16.167.175: icmp_seq=2 ttl=247 time=4.063 ms
64 bytes from 172.16.167.175: icmp_seq=3 ttl=247 time=4.371 ms
^C
3. Überprüfen Sie die SSH-Verbindung zum Catalyst 3850 (in diesem Beispiel 172.16.167.175) über die zentrale Verwaltungsplattform (Laptop) mit dem Benutzernamen und dem Kennwort (cisco1/cisco1) aus dieser Catalyst 3850-Konfiguration. Die Antwort kann eine lange Liste von NETCONF-Funktionen aus dem Catalyst 3850 gefolgt von einer Begrüßung sein. TCP-Port 830 = netconf-ssh.
USER1-M-902T:~ USER1$ ssh -s cisco1@172.16.167.175 -p 830 netconf
cisco1@172.16.167.175’s password: cisco1
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability
--snip--
</capabilities>
<session-id>2870</session-id></ hello>]]>]]>
Use < ^C > to exit
Konfigurieren der zentralen Managementplattform (Laptop)
1. Installieren Sie die Yang Explorer-Anwendung auf einem Laptop
In diesem Beispiel wird die Anwendung Yang Explorer auf einem Laptop (Apple MacBook Pro mit MacOS Sierra 10.12.2, Google Chrome-Browser) als zentrale Verwaltungsplattform verwendet. Yang Explorer erlaubt dem Benutzer Folgendes:
・ YANG-Datenmodelle über die Benutzeroberfläche oder Kommandozeile hochladen/kompilieren
・ Erstellen von NETCONF RPCs (Remote Procedure Calls)
・ Ausführen von RPC auf einem echten NETCONF-Server (Catalyst 3850)
・ Erstellte RPCs zur späteren Verwendung in Sammlungen speichern
・ Datenmodellbäume durchsuchen und YANG-Eigenschaften überprüfen
2. Verwenden Sie die Yang Explorer Anwendung
Starten Sie die Yang Explorer-Anwendung - führen Sie von einer Terminal-Eingabeaufforderung auf dem Laptop den Befehl ./start.sh und aus dem Yang-Explorer-Verzeichnis aus.
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ ./start.sh &
Starting YangExplorer server ..
Use http://localhost:8088/static/YangExplorer.html
Performing system checks...
System check identified no issues (0 silenced).
January 19, 2017 - 23:12:20
Django version 1.8.3, using settings 'server.settings'
Starting development server at http://localhost:8088/
Quit the server with CONTROL-C.
Starten Sie die Yang Explorer GUI - Starten Sie die Yang Explorer-Anwendungs-GUI und melden Sie sich als Gast/Gast in der oberen rechten Ecke des Anwendungs-GUI-Hauptmenüs an (siehe Screenshot).
Funktionen vom Catalyst 3850 abrufen. Geben Sie die Details zum Catalyst 3850 ein (IP-Adresse, Benutzername/Kennwort, TCP-Port 830 für ssh-netconf), und klicken Sie auf Capabilities (Funktionen), um die Liste der Betriebsfunktionen von YANG aus der Catalyst 3850-Software abzurufen.
Yang-Datenmodelle laden - Verschiedene YANG-Datenmodelle können unter Modelle verwalten abonniert werden. Nach dem Abonnieren werden sie im Explorer-Feld links angezeigt. Diese YANG-Modelle ermöglichen es dem Yang Explorer, mit YANG formatierte NETCONF Remote Procedure Calls (RPC)-Nachrichten zu erstellen (die an den Catalyst 3850 gesendet werden, um diesen zu konfigurieren oder Daten von ihm abzurufen), ohne dass YANG-Fachkenntnisse erforderlich sind. Beispiele dafür, wie dies möglich ist, finden Sie im nächsten Abschnitt Grundlegende Betriebsabläufe von NETCONF/YANG
Beispiele:
3. NETCONF-Benachrichtigungen abonnieren (optional)
Ein Client (zentrale Verwaltungsplattform) registriert sich, um NETCONF-Benachrichtigungs-Streams von einem Server (Catalyst 3850) zu empfangen, indem er diese mit YANG formatierte NETCONF-RPC-Nachricht sendet. Der Catalyst 3850 sendet NETCONF-Benachrichtigungen asynchron an jeden Client, der sich anmeldet. Bevor Sie diese Aufgabe abschließen, stellen Sie sicher, dass auf dem Catalyst 3850 die richtige Konfiguration vorhanden ist, um NETCONF-Benachrichtigungen (siehe Abschnitt 2) zur Konfiguration von NETCONF/YANG auf dem Catalyst 3850 zu unterstützen. Der NETCONF-Server (Catalyst 3850) beginnt, die Ereignisbenachrichtigungen an den NETCONF-Client (zentrale Managementplattform) zu senden, sobald die Ereignisse innerhalb des Systems auftreten. Diese Ereignisbenachrichtigungen können weiterhin gesendet werden, bis die NETCONF-Sitzung beendet wird oder das Abonnement aus einem anderen Grund beendet wird. Weitere Informationen zu den Abonnementoptionen finden Sie in RFC 5277 (Tools 5277).
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>snmpevents</stream>
</create-subscription>
</rpc>
Um dies zu tun, müssen Sie schneiden und fügen Sie diese in die Yang Explorer-Anwendung GUI als ein Custom RPC.
Als Nächstes wird Run ausgewählt, um die benutzerdefinierte RPC-Nachricht über NETCONF an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit einer OK-Nachricht, die den Benutzer über den erfolgreichen Vorgang informiert.
Grundlegende Betriebsbeispiele für NETCONF/YANG
Nachdem der Catalyst 3850 und die zentrale Managementplattform konfiguriert wurden und mit der Kommunikation begonnen haben, wollen wir uns einige grundlegende Betriebsbeispiele ansehen.
Die Beispiele können zeigen, dass die mit YANG formatierten NETCONF RPC-Nachrichten, die über NETCONF von der Yang Explorer-Anwendung der zentralen Managementplattform (Laptop) an den Catalyst 3850 gesendet werden, durch den konfd-Softwareprozess auf dem Catalyst 3850 in die standardmäßige Cisco IOS CLI konvertiert werden. Darüber hinaus werden die Cisco IOS CLI-Daten (Befehlsdaten anzeigen) durch den konfd-Softwareprozess auf dem Catalyst 3850 in YANG-formatierte Daten konvertiert, bevor sie als NETCONF RPC-Nachricht an die Yang Explorer-Anwendung der zentralen Managementplattform (Laptop) gesendet werden. Das bedeutet, dass die reguläre CLI weiterhin auf dem Catalyst 3850 verwendet werden kann, um den Switch zu konfigurieren und show-Befehlsdaten zu sammeln. Dies kann auch mit NETCONF/YANG erfolgen.
1. Beispiel für den Datenabruf
Anfordern einer Liste von Schnittstellennamen beim Catalyst 3850
Der gewünschte Vorgang kann im linken Explorer-Bereich der Yang Explorer-Anwendungs-GUI ausgewählt werden. In diesem Fall müssen die Schnittstellennamen-Daten von Catalyst 3850 abgerufen werden. Daher wird Oper (für den Betrieb) ausgewählt, gefolgt von get-config im Dropdown-Menü "Schnittstellenname". Als Nächstes wird RPC ausgewählt, um den YANG-formatierten (menschenlesbaren) NETCONF RPC zu generieren, der an den Catalyst 3850 über NETCONF gesendet werden muss, um diese Daten vom Catalyst 3850 abzurufen.
Nachdem die mit YANG formatierte NETCONF-RPC-Nachricht generiert wurde, wird Run ausgewählt, um sie an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit einer YANG-formatierten (für Menschen lesbaren) Liste der Schnittstellennamen des Catalyst 3850 (GigabitEthernet1/1/1, GigabitEthernet1/1/2 usw.).
2. Konfigurationsbeispiel
Fahren Sie eine Ethernet-Schnittstelle des Catalyst 3850 herunter.
Der gewünschte Vorgang wird auf der linken Seite des Explorer-Abschnitts der Yang Explorer-Anwendungs-GUI ausgewählt. In diesem Fall muss auf dem Catalyst 3850 eine Schnittstelle konfiguriert werden (eine Schnittstelle muss heruntergefahren werden). Daher wird Config (für die Konfiguration) ausgewählt, gefolgt von den erforderlichen Betriebsparametern in den Dropdown-Menüs für die Schnittstelle. Als Nächstes wird RPC ausgewählt, um den YANG-formatierten (menschenlesbaren) NETCONF RPC zu generieren, der zum Ausführen der Konfigurationsaufgabe an Catalyst 3850 über NETCONF gesendet werden muss.
Nachdem die mit YANG formatierte NETCONF-RPC-Nachricht generiert wurde, wird Run ausgewählt, um sie an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit einer YANG-formatierten (für Menschen lesbaren) Nachricht, die besagt, dass der Konfigurationsvorgang erfolgreich war (ok).
Um zu bestätigen, dass die Änderung stattgefunden hat, kann die Konfiguration überprüft werden. Mit einem Get-Config-Vorgang (Oper) kann angegeben werden, dass der Catalyst 3850 zurückantwortet, dass die GigabitEthernet 1/0/16-Konfiguration der Schnittstelle aktiviert wurde = false. Dies bedeutet, dass die Schnittstelle jetzt heruntergefahren wurde.
Nachdem die mit YANG formatierte NETCONF-RPC-Nachricht generiert wurde, wird Run ausgewählt, um sie an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit einer YANG-formatierten Meldung, die besagt, dass die GigabitEthernet 1/0/16-Konfiguration der Schnittstelle jetzt aktiviert wurde = false. Dies bedeutet, dass die Schnittstelle heruntergefahren wurde.
Anzeige der Schnittstellenkonfiguration vor und nach der vorherigen NETCONF/YANG-Konfigurationsänderung über die Catalyst 3850-CLI
Zum Zeitpunkt der vorherigen Konfigurationsänderung in Yang Explorer wird diese über die CLI des Catalyst 3850 ausgegeben. Die Schnittstelle GigabitEthernet 1/0/16 befand sich im standardmäßigen Zustand "no shutdown", bis die RPC-Meldung von NETCONF empfangen wurde, wie in der Protokollmeldung auf dem Catalyst 3850 zu sehen. Nachdem die NETCONF-RPC-Nachricht empfangen wurde, die die mit YANG formatierte Anforderung zum Beenden der Schnittstelle enthält, ist der Vorgang abgeschlossen, die Schnittstelle wird heruntergefahren, und die aktuelle Konfiguration wird entsprechend geändert. Dies zeigt auch, wie der konfd-Softwareprozess auf dem Catalyst 3850 die empfangene, mit YANG formatierte NETCONF-RPC-Nachricht in eine Cisco IOS CLI konvertiert. Das bedeutet, dass Benutzer die Konfiguration weiterhin über die reguläre Cisco IOS CLI ändern und show-Befehle ausführen können. NETCONF/YANG kann das Gleiche tun.
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 39 bytes
!
interface GigabitEthernet1/0/16
end
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
!
*Jan 5 17:05:55.345: %DMI-5-CONFIG_I:Switch 1 R0/0: nesd: Configured from NETCONF/RESTCONF by cisco1, transaction-id 31332
*Jan 5 17:05:57.335: %LINK-5-CHANGED: Interface GigabitEthernet1/0/16, changed state to administratively down
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/16
shutdown -------------------------> the interface is shutdown now
end
3850-1#
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
!
Speichern der Konfiguration auf einem Catalyst 3850
Die aktuelle Konfiguration kann in der Startup-Konfiguration auf dem Catalyst 3850 gespeichert werden, indem diese mit YANG formatierte NETCONF RPC-Nachricht über NETCONF an den Catalyst 3850 gesendet wird.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:save-config xmlns:cisco-ia="cisco/yang/cisco-ia"
</rpc>
Dies geschieht, wenn Sie dies ausschneiden und in die Yang Explorer-Anwendung als Custom RPC einfügen.
Run wird ausgewählt, um die benutzerdefinierte RPC-Nachricht über NETCONF an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit einer erfolgreichen Nachricht.
Anzeige der gespeicherten Startkonfiguration in der Catalyst 3850 CLI nach dem Speichern der vorherigen NETCONF/YANG-Konfiguration
Die Startkonfiguration entspricht jetzt der aktuellen Konfiguration:
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/16
shutdown
end
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
shutdown
!
Konfigurieren des Catalyst 3850 über die CLI
Wie bereits erwähnt, kann die reguläre Catalyst 3850 CLI weiterhin zum Konfigurieren des Switches und zum Erfassen der Show-Befehlsdaten verwendet werden, zusätzlich zur Verwendung von NETCONF/YANG, um dasselbe zu tun. Wenn der Switch nicht mit NETCONF/YANG, sondern mit der Catalyst 3850 CLI konfiguriert wird, wird die neue Ausführungskonfiguration mithilfe des Software-Prozesses syncfd mit der Datenmodellschnittstelle (DMI) auf dem Catalyst 3850 synchronisiert.
3850-1# show running-config interface gigabitEthernet 1/0/16
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/16
shutdown
end
3850-1# config t
Enter configuration commands, one per line. End with CNTL/Z.
3850-1(config)# interface gigabitEthernet 1/0/16
3850-1(config-if)#no shutdown
3850-1(config-if)# exit
3850-1(config)# exit
3850-1#
*Jan 24 16:39:09.968: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/16, changed state to down
*Jan 24 16:39:13.479: %SYS-5-CONFIG_I: Configured from console by console
*Jan 24 16:39:15.208: %DMI-5-SYNC_START:Switch 1 R0/0: syncfd: External change to running configuration detected. The running configuration can be synchronized to the DMI data store.
*Jan 24 16:39:43.290: %DMI-5-SYNC_COMPLETE:Switch 1 R0/0: syncfd: The running configuration has been synchronized to the DMI data store.
3850-1#
Wenn die Yang Explorer-Anwendung das nächste Mal nach der CLI-Änderung eine Kopie der Schnittstellenkonfiguration anfordert, wird die Änderung ordnungsgemäß in der YANG-Ausgabe wiedergegeben.
Run wird ausgewählt, um die RPC-Get-Config-Nachricht für GigabitEthernet1/0/16 über NETCONF an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit der GigabitEthernet1/0/16-Schnittstellenkonfiguration, die "enabled" = true anzeigt.
3. Überprüfen Sie, welche SNMP MIB-Betriebsdaten über GET Request Operations verfügbar sind.
Die SNMP MIB-Daten, die mit NETCONF GET-Vorgängen zurückgegeben werden können, können vom Benutzer nicht konfiguriert werden. Alle unterstützten SNMP MIBs, die in von YANG-Datenmodellen definierte strukturierte Daten konvertiert werden, sind Teil der Cisco XE-Software auf dem Catalyst 3850. Um festzustellen, welche MIB-Daten in GET-Anforderungen verfügbar sind, gibt es drei Optionen. Alle unterstützten MIBs können smiv2 in die Funktionsantwort aufnehmen.
Option 1: Die Schaltfläche Funktionen kann in der Benutzeroberfläche der Yang Explorer-Anwendung ausgewählt werden. Der Catalyst 3850 antwortet mit der Funktionsliste, die die Einträge smiv2 MIB enthält.
Option 2: Diese mit YANG formatierte NETCONF-RPC-Nachricht kann über NETCONF an den Catalyst 3850 gesendet werden, um die Funktionsliste abzurufen, die verfügbare smiv2-MIB-Modelle enthält.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<get>
<filter type="subtree">
<ncm:netconf-state xmlns:ncm="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<ncm:capabilities/>
</ncm:netconf-state>
</filter>
</get>
</rpc>
Dies geschieht, wenn Sie ausschneiden und einfügen in die Yang Explorer-Anwendung als ein Custom RPC.
Run wird ausgewählt, um die benutzerdefinierte RPC-Nachricht über NETCONF an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit einer Funktionsliste, die die unterstützten smiv2-MIBs enthält.
Option 3. Eine Liste der verfügbaren MIB-Modelle kann in den NETCONF-Funktionen und der Hello-Nachricht angezeigt werden, die der Catalyst 3850 als Antwort auf eine SSH-Verbindung von der zentralen Managementplattform (Laptop) zurückgibt.
USER1-M-902T:~ USER1$ ssh -s cisco1@172.16.167.175 -p 830 netconf
cisco1@172.16.167.175’s password: cisco1
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability
--snip--
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONFIG-MAN-MIB?module=CISCO-CONFIG-MAN-MIB&revision=2007-04-27</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONTEXT-MAPPING-MIB?module=CISCO-CONTEXT-MAPPING-MIB&revision=2008-11-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DATA-COLLECTION-MIB?module=CISCO-DATA-COLLECTION-MIB&revision=2002-10-30</capability>
--snip--
</capabilities>
<session-id>2870</session-id></ hello >]]>]]>
Use < ^C > to exit
Zusätzliche YANG-Datenmodelle laden
Dieser Link enthält zusätzliche YANG-Datenmodelldateien. Diese Dateien ermöglichen die Ausführung zusätzlicher Operationen über NETCONF/YANG, die sich auf andere Catalyst 3850-Funktionen beziehen, wie z. B. die Konfiguration von IPv4-Unicast-Routing, QoS usw.
Die gängigen (Internet Engineering Task Force (IETF)) Standardmodelle, die für alle Anbieter gelten, können über standard, ietf, rfc gefunden werden. Es werden die standardbasierten YANG-Datenmodelle aus RFC-Veröffentlichungen des IETF-Standardisierungsgremiums bereitgestellt.
GitHub Yang Modelle Baum Master Standard
Sie finden die nativen Cisco Modelle (geräte- und anbieterspezifisch), indem Sie vendor, cisco, xe, 1632 auswählen. Damit stehen die proprietären YANG-Datenmodelle für die Cisco IOS XE Software-Version 16.3.2 für den Catalyst 3850 zur Verfügung.
GitHub Yang Models Yang Tree Master Vendor
Diese Dateien können auf die zentrale Verwaltungsplattform (Laptop) heruntergeladen und dann wiederum in die Yang Explorer-Anwendung geladen werden. Es gibt zwei Möglichkeiten, dies zu tun. Das erste ist, die verschiedenen YANG-Datenmodelldateien einzeln zu laden, das zweite ist ein Massenladen aller Dateien.
1. Laden Sie die verschiedenen YANG-Datenmodelldateien einzeln
In diesem Beispiel wurde cisco-ethernet.yang bereits von github auf die zentrale Managementplattform (Laptop) heruntergeladen. Hier sind die Schritte, um die Datei in die Yang Explorer-Anwendung GUI laden und dann Abonnieren zu, sodass es in den Explorer-Abschnitt des Tools geladen wird.
2. Massenladen aller YANG-Datenmodelldateien auf einmal
Dieses Verfahren wird auch in Abschnitt 5.2.2 hier erwähnt: github.
Über eine Terminal-Eingabeaufforderung auf der zentralisierten Verwaltungsplattform (Laptop - Apple MacBook Pro mit macOS Sierra 10.12.2):
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ cd server
USER1-M-902T:server USER1$ python manage.py bulkupload --user guest --git https://github.com/YangModels/yang.git --dir vendor/cisco/xe/1632
Git upload ..
Cloning into '/Users/USER1/yang-explorer/server/data/session/tmpk7V4O6'...
remote: Counting objects: 5610, done.
remote: Total 5610 (delta 0), reused 0 (delta 0), pack-reused 5610
Receiving objects: 100% (5610/5610), 11.80 MiB | 2.34 MiB/s, done.
Resolving deltas: 100% (3159/3159), done.
Checking out files: 100% (3529/3529), done.
Cleaning up /Users/USER1/yang-explorer/server/data/session/tmpk7V4O6
Compiling : user: guest, file: /Users/USER1/yang-explorer/server/data/session/tmpHTAEP3/cisco-acl-oper.yang
DEBUG:root:Compiling session dependency ...
//anaconda/bin/pyang
DEBUG:root:Rebuilding dependencies for user guest
--snip--
Alle Yang-Datenmodelle werden jetzt in der Benutzeroberfläche der Yang Explorer-Anwendung angezeigt. Die Dateien, die den gewünschten Funktionen zugeordnet sind, können ausgewählt werden, wenn Sie auf Abonnieren klicken, das sie dann dem Explorer-Abschnitt des Tools hinzufügt.
Andere Aufgaben können jetzt ausgeführt werden, z. B. das Erstellen des RPC NETCONF/YANG, der zum Speichern der Konfiguration auf dem Catalyst 3850 erforderlich ist. Dies geschieht, wenn Sie die RPC-Save-Conf im Explorer-Abschnitt auf der linken Seite der Yang Explorer-Anwendung auswählen. Anschließend wird RPC ausgewählt, um den YANG-formatierten NETCONF RPC zu generieren, der über NETCONF an Catalyst 3850 gesendet werden kann, um die Konfiguration auf dem Catalyst 3850 zu speichern.
Run wird ausgewählt, um die benutzerdefinierte RPC-Nachricht über NETCONF an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit einer erfolgreichen Nachricht.
Bemerkenswerte YANG-Datenmodelle
cisco-ia.yang Datenmodell
Hier sehen Sie einige RPC-Beispiele für das Datenmodell cisco-ia.yang. Sie sind bemerkenswert, da sie Vorgänge wie das Speichern der Catalyst 3850-Konfiguration, das Synchronisieren der Catalyst 3850-Ausführungskonfiguration mit dem lokalen DMI-Datenspeicher und das Zurücksetzen der DMI-Schnittstelle auf dem Catalyst 3850 umfassen.
Der erste Schritt besteht darin, das cisco-ia.yang-Datenmodell zu abonnieren, sodass es im Explorer-Abschnitt links von der YANG Explorer-Anwendungs-GUI angezeigt wird.
Sobald das cisco-ia-Datenmodell im Explorer-Abschnitt links von der grafischen Benutzeroberfläche des YANG Explorer erweitert wurde, werden die verschiedenen Betriebsoptionen angezeigt. Um beispielsweise eine der verfügbaren Datenmodelloptionen cisco-ia.yang zu verwenden, wird der Vorgang save-config ausgewählt, und der zugehörige RPC wird generiert, wenn Sie die RPC-Schaltfläche auswählen.
Als Nächstes wird Run ausgewählt, um die RPC-Nachricht über NETCONF an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit einer Meldung, dass der Vorgang erfolgreich war.
Alle verschiedenen Datenmodelloperationen für cisco-ia.yang werden hier beschrieben:
sync-from - Dieser RPC veranlasst die NETCONF-Schnittstelle auf dem Catalyst 3850, die Darstellung des NETCONF-Datenspeichers des Geräts, auf dem die Konfiguration ausgeführt wird, mit der auf dem Gerät ausgeführten Konfiguration zu synchronisieren. Beide Varianten werden auf dem Catalyst 3850 selbst verwendet.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:sync-from xmlns:cisco-ia
</rpc>
Das Standardverhalten dieses RPCs besteht darin, eine Synchronisierung ohne Standardwerte durchzuführen, wodurch die Ausgabe des an das Gerät gesendeten Befehls show running-config mit dem NETCONF-Datenspeicher synchronisiert wird. Wenn sync-defaults vorhanden ist, liest die NETCONF-Schnittstelle auch die vom Funktionscode bereitgestellten Standardkonfigurationsinformationen. In den meisten Fällen wird diese Option nicht verwendet. In der Regel wird dies nur verwendet, wenn der Benutzer der NETCONF-Schnittstelle die Befehle NETCONF replace verwenden möchte, um vollständige Abschnitte der Gerätekonfiguration zu ersetzen.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:sync-from xmlns:cisco-ia/>
<cisco-ia:sync-defaults/>
</cisco-ia:sync-from>
</rpc>
save-config - Dieser RPC führt den Befehl write memory (copy running-config startup-config) aus, um das aktuell ausgeführte Gerät in der Startup-Konfiguration des Geräts zu speichern.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:save-config xmlns:cisco-ia
</rpc>
checkpoint - Dieser RPC veranlasst die NETCONF-Schnittstelle, die aktuelle Konfiguration mithilfe der integrierten Konfigurationsarchivierungsfunktion von Cisco IOSd in einem nicht flüchtigen Speicher zu speichern.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:checkpoint xmlns:cisco-ia
</rpc>
rollback - Dieser RPC veranlasst die NETCONF-Schnittstelle, ein Rollback der aktuellen Konfiguration des Geräts auf eine aktuelle Konfiguration durchzuführen, die mit dem Prüfpunkt "RPC" oder einer anderen gültigen, auf dem Gerät gespeicherten aktuellen Konfiguration gespeichert wurde.
target-url string (name of the saved checkpoint file)
verbose? Boolean (show detail during rollback process)
nolock? Boolean (lock configuration)
revert-on-error? Empty (if error occurs during rollback, leave running unchanged)
revert-timer? int16 (time in seconds before revets to the original configuration)
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:rollback xmlns:cisco-ia=
<cisco-ia:target-url>saved-config</cisco-ia:target-url>
<cisco-ia:verbose>true</cisco-ia:verbose>
<cisco-ia:nolock>true</cisco-ia:nolock>
<cisco-ia:revert-on-error></cisco-ia:revert-on-error>
<cisco-ia:revert-timer>10</cisco-ia:revert-timer>
</cisco-ia:rollback>
</rpc>
revert - Dieser RPC veranlasst die NETCONF-Schnittstelle, den Revert-Timer vom Rollback-RPC zu ändern. Dadurch wird der Rollback abgebrochen, und der Rollback wird sofort ausgelöst, oder die Parameter für den Rollback mit Zeitmessung werden zurückgesetzt.
now? empty
timer? int16
idle? int16
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:revert xmlns:cisco-ia
<cisco-ia:now/>
<cisco-ia:timer>10</cisco-ia:timer>
<cisco-ia:idle>60</cisco-ia:idle>
</cisco-ia:revert>
</rpc>
reset - Die NETCONF-Schnittstelle kann mit diesem RPC neu gestartet werden. Wenn reinitialize den Wert true hat, löscht die NETCONF-Schnittstelle alle Zustandsinformationen, die im beschreibbaren Datenspeicher vorhanden sind. Bei "false" (Standard) werden die Statusinformationen des NETCONF Konfigurationsdatenspeichers beibehalten.
<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
<cisco-ia:reset xmlns:cisco-ia
<cisco-ia:reinitialize>true</cisco-ia:reinitialize>
</cisco-ia:reset>
</rpc>
<nc:rpc-error xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:error-type>application</nc:error-type>
<nc:error-tag>operation-failed</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-path xmlns:cisco-ia
<nc:error-message lang="en" xmlns="https://www.w3.org/XML/1998/namespace">Reset not supported</nc:error-message>
<nc:error-info>
<nc:bad-element>reset</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
nd.yang-Datenmodell
NED-Datenmodelle (Network Elements Driver) wie nd.yang bieten die höchste Leistung in Bezug auf die Gerätekonfiguration von Cisco (Catalyst 3850). Hier sind einige Screenshots, die dies demonstrieren.
Der erste Schritt besteht darin, das Datenmodell "nd.yang" zu abonnieren, sodass es im Explorer-Abschnitt links von der grafischen Benutzeroberfläche des YANG Explorers angezeigt wird.
Wenn Sie sich durch die verfügbaren Optionen im Explorer-Abschnitt auf der linken Seite der YANG Explorer-Anwendung blättern, zeigt die GUI eine lange Liste konfigurierbarer Catalyst 3850-Funktionen im Datenmodell "end.yang".
Als Beispiel zeigen diese Screencaps, wie die OSPF-Routing-Konfiguration des Catalyst 3850 angezeigt wird, nachdem die Liste der verfügbaren Konfigurationsoptionen für das Ned.Yang-Datenmodell im Explorer-Abschnitt auf der linken Seite der YANG Explorer-Anwendungs-GUI nach unten gescrollt wurde. Die OSPF-Unteroption befindet sich innerhalb der Routeroption. Der zugehörige RPC für die Get-Konfiguration wird generiert, wenn Sie die RPC-Schaltfläche auswählen.
Als Nächstes wird Run ausgewählt, um die RPC-Nachricht über NETCONF an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit seiner OSPF-Routing-Konfiguration.
Im Folgenden wird eine Erweiterung der OSPF-Routing-Konfiguration dargestellt, die vom Catalyst 3850 als Antwort auf den RPC-Vorgang get-config zurückgegeben wird.
<rpc-reply message-id="urn:uuid:0e2c04cf-9119-4e6a-8c05-238ee7f25208" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<native xmlns>
<router>
<ospf>
<id>100</id>
<redistribute>
<connected>
<redist-options>
<subnets/>
</redist-options>
</connected>
</redistribute>
<network>
<ip>10.10.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
<network>
<ip>10.20.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
<network>
<ip>10.100.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
</ospf>
</router>
</native>
</data>
</rpc-reply>
Die OSPF-Routing-Konfiguration im YANG-Format, die von Catalyst 3850 über NETCONF abgerufen wurde, ist für Menschen lesbar und stimmt mit der Konfiguration der Catalyst 3850 über die CLI der Catalyst 3850 überein.
3850-1# show running-config | section ospf
router ospf 100
redistribute connected subnets
network 10.10.0.0 0.0.255.255 area 0
network 10.20.0.0 0.0.255.255 area 0
network 10.100.0.0 0.0.255.255 area 0
3850-1#
Auf Wunsch kann das Datenmodell "nd.yang" auch zum Ändern der OSPF-Routing-Konfiguration verwendet werden. In diesem Beispiel werden der vorhandenen OSPF-Routing-Konfiguration auf dem Catalyst 3850 neue Netzwerkparameter hinzugefügt, indem zunächst die gewünschten Parameter in den Explorer-Abschnitt der Yang Explorer-Anwendungs-GUI links eingegeben werden (die OSPF-Router-ID 100 wurde ebenfalls eingegeben, wird aber aufgrund des Explorer-Scrollens nicht angezeigt) und dann der zugehörige YANG-formatierte RPC generiert wird, und die RPC-Tastegedrückt wird.
Als Nächstes wird Run ausgewählt, um die RPC-Nachricht über NETCONF an Catalyst 3850 zu senden. Der Catalyst 3850 antwortet mit einer OK-Nachricht, um den Benutzer über den erfolgreichen Vorgang zu informieren.
Dieser NETCONF/YANG-RPC-Vorgang zum Ändern der OSPF-Routing-Konfiguration über das Datenmodell "end.yang" spiegelt sich in der Catalyst 3850-Konfiguration wider, die über die CLI des Catalyst 3850 erfolgt. Eine Syslog-Meldung auf dem Catalyst 3850 gibt an, dass eine Konfigurationsänderung über NETCONF vorgenommen wurde.
3850-1#
*Jan 30 14:13:41.659: %DMI-5-CONFIG_I:Switch 1 R0/0: nesd: Configured from NETCONF/RESTCONF by cisco1, transaction-id 23143
3850-1# show running-config | section ospf
router ospf 100
redistribute connected subnets
network 10.10.0.0 0.0.255.255 area 0
network 10.20.0.0 0.0.255.255 area 0
network 10.30.0.0 0.0.255.255 area 0 ------> new line added to OSPF configuration
network 10.100.0.0 0.0.255.255 area 0
3850-1#
Weitere Informationen zum Speichern der Ausführungskonfiguration auf dem Catalyst 3850 über NETCONF/YANG finden Sie unter dem im vorherigen Abschnitt beschriebenen Vorgang zum Speichern der Konfiguration auf dem Cisco Catalyst 3850.
Python-Scripting
Generieren eines Python-Skripts über die Benutzeroberfläche der Yang Explorer-Anwendung
Die Benutzeroberfläche der Anwendung Yang Explore kann auch verwendet werden, um ein Python-Skript für einen bestimmten NETCONF/YANG-Vorgang zu generieren. Ein wichtiger Vorteil von Python-Scripting ist, dass es die Orchestrierung und Automatisierung von NETCONF/YANG-Vorgängen ermöglicht.
In diesem Beispiel wird ein Speicherkonfigurationsvorgang im Explorer-Fenster auf der linken Seite der Yang Explorer-Anwendungs-GUI auf der zentralisierten Verwaltungsplattform (Laptop) ausgewählt. Als Nächstes wird die Schaltfläche Skript ausgewählt, um das Python-Skript zu generieren. Mit der Schaltfläche Kopieren kann das Skript kopiert werden, sodass es wiederum in eine Datei eingefügt werden kann, die auf der zentralen Verwaltungsplattform (Laptop) mit der Dateierweiterung Python .py gespeichert werden kann. Für dieses Beispiel (nicht dargestellt) wurde diese Datei beispiel.py genannt.
Hier ist eine Erweiterung des Python-Skripts, das generiert und dann kopiert und in eine Datei mit dem Namen example.py auf der zentralisierten Verwaltungsplattform (Laptop) eingefügt wurde.
"""
Netconf python example by yang-explorer (https://github.com/CiscoDevNet/yang-explorer)
Installing python dependencies:
> pip install lxml ncclient
Running script: (save as example.py)
> python example.py -a 172.16.167.174 -u cisco1 -p cisco1 --port 830
"""
import lxml.etree as ET
from argparse import ArgumentParser
from ncclient import manager
from ncclient.operations import RPCError
payload = """ <save-config xmlns
"""
if __name__ == '__main__':
parser = ArgumentParser(description='Usage:')
# script arguments
parser.add_argument('-a', '--host', type=str, required=True,
help="Device IP address or Hostname")
parser.add_argument('-u', '--username', type=str, required=True,
help="Device Username (netconf agent username)")
parser.add_argument('-p', '--password', type=str, required=True,
help="Device Password (netconf agent password)")
parser.add_argument('--port', type=int, default=830,
help="Netconf agent port")
args = parser.parse_args()
# connect to netconf agent
with manager.connect(host=args.host,
port=args.port,
username=args.username,
password=args.password,
timeout=90,
hostkey_verify=False,
device_params={'name': 'csr'}) as m:
# execute netconf operation
try:
response = m.dispatch(ET.fromstring(payload)).xml
data = ET.fromstring(response)
except RPCError as e:
data = e._raw
# beautify output
print(ET.tostring(data, pretty_print=True))
Ausführen eines Python-Skripts von der zentralen Managementplattform (Laptop)
Dies ist die Prüfung der Catalyst 3850 CLI, bevor Sie das Python-Skript example.py ausführen, mit dem die running-config in der startup-config gespeichert werden kann. An diesem Punkt befindet sich der Befehl shutdown in der running-config, jedoch nicht in der Startkonfiguration für die Schnittstelle GigabitEthernet1/0/10.
3850-1# show running-config interface gigabitEthernet 1/0/10
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/10
shutdown
end
3850-1# show startup-config | begin 1/0/10
interface GigabitEthernet1/0/10
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
Von einer regulären Terminal-Eingabeaufforderung auf der zentralen Verwaltungsplattform (Laptop) wird die Python-Datei example.py, die von der Yang Explorer-Anwendungs-GUI generiert wurde, zuerst in das Verzeichnis yang-explore auf dem Laptop kopiert.
USER1-M-902T:~ USER1$ pwd
/Users/USER1
USER1-M-902T:~ USER1$ cp /Users/USER1/Desktop/example.py /Users/USER1/yang-explorer
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ ls -l
total 112
-rw-r--r-- 1 USER1 staff 11358 Jan 4 17:59 LICENSE
-rw-r--r-- 1 USER1 staff 13635 Jan 4 17:59 README.md
drwxr-xr-x 12 USER1 staff 408 Jan 4 17:59 YangExplorer
drwxr-xr-x 7 USER1 staff 238 Jan 4 17:59 default-models
drwxr-xr-x 3 USER1 staff 102 Jan 4 17:59 docs
-rw-r--r-- 1 USER1 staff 72 Jan 4 17:59 env.sh
-rw-r--r--@ 1 USER1 staff 1990 Jan 30 17:50 example.py
-rw-r--r-- 1 USER1 staff 207 Jan 4 17:59 requirements.txt
drwxr-xr-x 11 USER1 staff 374 Jan 5 14:37 server
-rwxr-xr-x 1 USER1 staff 4038 Jan 4 17:59 setup.sh
-rwxr-xr-x 1 USER1 staff 640 Jan 4 17:59 start.sh
drwxr-xr-x 5 USER1 staff 170 Jan 4 18:00 v
USER1-M-902T:yang-explorer USER1$
Anschließend werden diese beiden Befehle von einer regulären Terminalaufforderung auf der zentralen Verwaltungsplattform (Laptop) ausgeführt, die im Kommentarabschnitt am Anfang der Datei beispiel.py bereitgestellt wurden, die von der Benutzeroberfläche der Anwendung Yang Explorer generiert wurde (siehe den vorherigen Abschnitt Generating a Python Script from the Yang Explorer Application GUI (Generieren eines Python-Skripts aus der Benutzeroberfläche der Anwendung Yang Explorer).
USER1-M-902T:yang-explorer USER1$ pip install lxml ncclient
Collecting lxml
Downloading lxml-3.7.2.tar.gz (3.8MB)
100% |████████████████████████████████| 3.8MB 328kB/s
Collecting ncclient
Downloading ncclient-0.5.3.tar.gz (63kB)
100% |████████████████████████████████| 71kB 3.5MB/s
Requirement already satisfied: setuptools>0.6 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages (from ncclient)
Collecting paramiko>=1.15.0 (from ncclient)
Downloading paramiko-2.1.1-py2.py3-none-any.whl (172kB)
100% |████████████████████████████████| 174kB 3.1MB/s
Collecting six (from ncclient)
Using cached six-1.10.0-py2.py3-none-any.whl
Collecting cryptography>=1.1 (from paramiko>=1.15.0->ncclient)
Using cached cryptography-1.7.2-cp27-cp27m-macosx_10_6_intel.whl
Collecting pyasn1>=0.1.7 (from paramiko>=1.15.0->ncclient)
Using cached pyasn1-0.1.9-py2.py3-none-any.whl
Collecting cffi>=1.4.1 (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached cffi-1.9.1-cp27-cp27m-macosx_10_10_intel.whl
Collecting enum34 (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached enum34-1.1.6-py2-none-any.whl
Collecting ipaddress (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached ipaddress-1.0.18-py2-none-any.whl
Collecting idna>=2.0 (from cryptography>=1.1->paramiko>=1.15.0->ncclient)
Using cached idna-2.2-py2.py3-none-any.whl
Collecting pycparser (from cffi>=1.4.1->cryptography>=1.1->paramiko>=1.15.0->ncclient)
Downloading pycparser-2.17.tar.gz (231kB)
100% |████████████████████████████████| 235kB 2.6MB/s
Installing collected packages: lxml, six, pycparser, cffi, pyasn1, enum34, ipaddress, idna, cryptography, paramiko, ncclient
Running setup.py install for lxml ... -
done
Running setup.py install for pycparser ... done
Running setup.py install for ncclient ... done
Successfully installed cffi-1.9.1 cryptography-1.7.2 enum34-1.1.6 idna-2.2 ipaddress-1.0.18 lxml-3.7.2 ncclient-0.5.3 paramiko-2.1.1 pyasn1-0.1.9 pycparser-2.17 six-1.10.0
USER1-M-902T:yang-explorer USER1$
Mit dem zweiten Befehl wird das Python-Skript example.py für den Catalyst 3850 mit der IP-Adresse 172.16.167.174 und dem Benutzernamen/Kennwort cisco1/cisco1 über den TCP-Port 830 (netconf-ssh) ausgeführt. Der Catalyst 3850 sendet eine RPC-Antwort an die zentrale Verwaltungsplattform (Laptop), in der bestätigt wird, dass der Speichervorgang erfolgreich war.
USER1-M-902T:yang-explorer USER1$ python example.py -a 172.16.167.174 -u cisco1 -p cisco1 --port 830
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:31e0fdee-b72f-4695-9e03-91ec771b37f5"><result xmlns>Save running-config successful
</result>
</rpc-reply>
USER1-M-902T:yang-explorer USER1
Hier sehen Sie die Prüfung der Catalyst 3850 CLI nach dem Ausführen des Python-Skripts example.py, das die running-config in der Startkonfiguration gespeichert hat. Der Befehl shutdown ist nun aufgrund des erfolgreichen Vorgangs save-config NETCONF/YANG sowohl in der running-config als auch in der startup-config für die Schnittstelle GigabitEthernet1/0/10 vorhanden.
3850-1# show running-config interface gigabitEthernet 1/0/10
Building configuration...
Current configuration : 49 bytes
!
interface GigabitEthernet1/0/10
shutdown
end
3850-1# show startup-config | begin 1/0/10
interface GigabitEthernet1/0/10
shutdown
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
Fehlerbehebung
In diesem Abschnitt finden Sie Informationen zur Behebung von Fehlern in Ihrer Konfiguration.
NETCONF-Fehlermeldungen
Das NETCONF-Protokoll definiert eine Reihe von Vorgängen und Nachrichten, die zwischen dem NETCONF-Client (zentralisierte Managementplattform (Laptop)) und der NETCONF-Implementierung auf dem Servergerät (Catalyst 3850) ausgetauscht werden. Zu den häufig verwendeten NETCONF-Vorgängen gehören:
<get>, <get-config>, <edit-config> und <rpc>
Das Format und andere Einschränkungen des NETCONF-Nachrichteninhalts werden durch YANG-Datenmodelle definiert. Die Interaktion zwischen NETCONF-Client und -Server erfolgt über das Senden von RPCs.
Wenn ein Fehler im Format der NETCONF-Nachricht vorliegt oder der Inhalt der Nachricht nicht mit den Definitionen in den vom Gerät implementierten YANG-Datenmodellen übereinstimmt, kann der NETCONF-Server auf dem Gerät einen RPC-Fehler zurückgeben.
<error-type>application</error-type>
Diese RPC-Fehler zeigen nicht an, dass die NETCONF-Schnittstelle nicht funktioniert. Diese Fehler zeigen an, dass der Client versucht, einen Vorgang auszuführen, der von den auf dem Servergerät implementierten YANG-Datenmodellen nicht unterstützt wird. Benutzer müssen die YANG-Datenmodelle, die auf dem Servergerät implementiert sind, überprüfen, um die Ursachen für diese Fehler zu identifizieren und zu beheben.
RPC-Fehlerbeispiel
In diesem Beispiel wird ein falscher Schnittstellentyp ianaift:fastEtherFX verwendet, um die mit YANG formatierte <edit-config> NETCONF RPC-Nachricht zu generieren, die über NETCONF an den Catalyst 3850 gesendet werden soll.
Wenn Run ausgewählt ist, um die RPC-Nachricht an den Catalyst 3850 zu senden, antwortet der Catalyst 3850 mit einer Fehlermeldung.
Hier sehen Sie den Fehler, der vom Catalyst 3850 zurückgegeben wurde. Beachten Sie, dass es das Fehlertag "operation-failed" und weitere Details zu dem Fehler enthält: "Unsupported - value must be ethernetCsmacd or softwareLoopback"</nc:error-message>".
<nc:rpc-error xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:error-type>application</nc:error-type>
<nc:error-tag>operation-failed</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-path xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">/rpc/edit-config/config/if:interfaces/if:interface[if:name='GigabitEthernet1/0/16']/if:type</nc:error-path>
<nc:error-message lang="en" xmlns="https://www.w3.org/XML/1998/namespace">/interfaces/interface[name='GigabitEthernet1/0/16']/type: "Unsupported - value must be ethernetCsmacd or softwareLoopback"</nc:error-message>
<nc:error-info>
<nc:bad-element>type</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
Als Nächstes beheben wir den Fehler und geben den korrekten Schnittstellentyp an ianaift:ethernetCsmacd in Die RPC-Nachricht, die an den Catalyst 3850 gesendet wurde, sodass der Catalyst 3850 mit einer OK-Nachricht anstatt mit einem Fehler antwortet.
Dieses Mal antwortet der Catalyst 3850 nach der Auswahl von Run (Ausführen) zum Senden der RPC-Nachricht an den Catalyst 3850 mit einer OK-Nachricht, um anzuzeigen, dass der Vorgang erfolgreich war.
Sobald Run ausgewählt ist, um die RPC-Nachricht an den Catalyst 3850 zu senden, antwortet der Catalyst 3850 mit der Schnittstellenkonfiguration im YANG-Format, die anzeigt, dass der Schnittstellentyp ianaift:ethernetCsmacd ist.
Weitere RPC-Fehlertypbeispiele
1. "In Verwendung" (konfigurationsgesperrt) RPC-Fehlerantwort
Dies ist eine NETCONF-Fehlerantwort auf eine <edit-config>-Anforderung. Das <error-tag> gibt "in Gebrauch" an. Die Antwort zeigt an, dass das Servergerät (Catalyst 3850) NETCONF, das den Datenspeicher ausführt, derzeit gesperrt ist und der Vorgang NETCONF <edit-config> zu diesem Zeitpunkt nicht ausgeführt werden konnte. Dies weist nicht auf einen Fehler in der Implementierung der NETCONF-Schnittstelle hin. Wenn ein NETCONF-Client während der Verwendung des Datenspeichers versucht, in den NETCONF-ausgeführten Datenspeicher zu schreiben, erhält der Client diese RPC-Antwort. Der NETCONF-Client kann die Meldung NETCONF edit-config wiederholen. Diese Antwort kann empfangen werden, wenn das Gerät eine geräteinterne Synchronisierung durchführt, um den im NETCONF ausgeführten Datenspeicher mit der IOSd-Konfiguration des Geräts zu synchronisieren.
NETCONF Antwort vom Server (Catalyst 3850) zum Client (zentrale Managementplattform (Laptop)).
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
<rpc-error>
<error-type>application</error-type>
<error-tag>in-use</error-tag>
<error-severity>error</error-severity>
<error-app-tag>config-locked</error-app-tag>
<error-info>
<session-id>0</session-id>
</error-info>
</rpc-error>
</rpc-reply>
2. "Data missing" (Daten fehlen) RPC Error Reply Message (RPC-Fehlerantwort)
In diesem Beispiel wurde ein <edit-config>-RPC für eine nicht konfigurierte Loopback-Schnittstelle an Catalyst 3850 gesendet. Es wurde ein Fehler zurückgegeben, da Sie keine Schnittstelle konfigurieren können, die auf dem Catalyst 3850 nicht vorhanden ist.
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
<rpc-error>
<error-type>application</error-type>
<error-tag>data-missing</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">/rpc/edit-config/config/if:interfaces/if:interface[if:name='Loopback1111']/if:type</error-path>
<error-message xml:lang="en">/interfaces/interface[name='Loopback1111']/type is not configured</error-message>
<error-info>
<bad-element>type</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
3. RPC-Fehlerantwort "Missing Data Model"
Wird ein Datenmodell angefordert, das auf dem Catalyst 3850 nicht vorhanden ist, oder wird ein Leaf angefordert, der nicht in einem Datenmodell implementiert ist, antwortet der Server (Catalyst 3850) mit einer leeren Datenantwort. Dies ist ein erwartungsgemäßes Verhalten.
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
4. "Ungültiger Wert" RPC-Fehlerantwort
In einigen Fällen kann eine NETCONF-Nachricht Inhalte enthalten, die basierend auf den YANG-Datenmodellen gültig sind. Das Gerät (Catalyst 3850) kann jedoch nicht implementieren, was angefordert wird. Wenn die NETCONF-Schnittstelle auf dem Catalyst 3850 Konfigurationen an IOSd sendet, die IOSd nicht erfolgreich anwenden kann, wird eine bestimmte RPC-Fehlerantwort an den NETCONF-Client zurückgegeben.
In diesem Beispiel wird ein ungültiger gepufferter Protokollierungswert von "bogus" in der RPC-Nachricht an Catalyst 3850 gesendet. Das Fehlertag in der Antwort von Catalyst 3850 gibt einen ungültigen Wert an. Die Fehlermeldung zeigt an, dass der Catalyst 3850 IOS Parser den Schweregrad der gepufferten Protokollierung nicht auf "bogus" konfigurieren konnte, da dies kein gültiger Wert ist.
<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="6">
<rpc-error>
<error-type>application</error-type>
<error-tag>invalid-value</error-tag>
<error-severity>error</error-severity>
<error-message xml:lang="en">inconsistent value: Device refused command "logging buffered bogus" at column 20 </error-message>
</rpc-error>
</rpc-reply>
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
3.0 |
21-Dec-2023 |
Aktualisierte Branding-Anforderungen, Rechtschreibung und Formatierung. |
2.0 |
01-Dec-2022 |
PII entfernt.
Alternativer Text hinzugefügt.
Korrigierte RPC-Informationen zurücksetzen.
Aktualisierter Titel, Einführung, maschinelle Übersetzung, Gerunds, Stilvorgaben und Formatierung. |
1.0 |
17-Sep-2021 |
Erstveröffentlichung |
Feedback