Configurazione di NETCONF/YANG per le piattaforme Cisco IOS XE 16.X
Sommario
Introduzione
Questo documento descrive come configurare NETCONF/YANG su piattaforme basate su Cisco IOS® XE 16.x.
Prerequisiti
Requisiti
NETCONF/YANG è supportato dal software Cisco IOS® XE 16.3.1.
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Nell'esempio, viene usato come server NETCONF uno switch WS-C3850-12X48U autonomo con Cisco IOS XE 16.3.3. Si tratta del dispositivo configurato da cui vengono raccolti i dati (output del comando show) tramite NETCONF/YANG.
Come client NETCONF viene usato un laptop (Apple MacBook Pro con macOS Sierra 10.12.2 e Google Chrome browser). Funge da piattaforma di gestione centralizzata e utilizza l'applicazione Yang Explorer. È il dispositivo che crea le richieste formattate YANG inviate allo switch Catalyst 3850 tramite messaggi RPC (Remote Procedure Call) NETCONF per configurare e raccogliere dati dallo switch Catalyst 3850.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
L'esempio riportato in questo documento riguarda i test di laboratorio con Catalyst 3850. Tuttavia, le informazioni fornite sono valide anche per altre piattaforme Cisco IOS XE 16.x, come i router Cisco ASR serie 1000.
Modelli di dati - Configurazione e monitoraggio programmatici e basati su standard
I modelli di dati forniscono un modo alternativo e centralizzato per configurare i dispositivi Cisco (anziché utilizzare l'interfaccia CLI (Command Line Interface) o il protocollo SNMP (Simple Network Management Protocol)) e raccogliere i dati operativi (comandi show) dai dispositivi Cisco. Poiché i modelli di dati sono basati sulla stessa procedura e possono essere utilizzati anche per configurare o raccogliere dati da dispositivi non Cisco, sono ideali per i clienti che supportano più fornitori. Una piattaforma di gestione centralizzata (ad esempio, un laptop) può essere utilizzata per configurare o raccogliere dati da più dispositivi Cisco e l'architettura del modello di dati consente di automatizzare queste procedure tramite script Python (due vantaggi chiave aggiuntivi).
Another Next Generation (YANG) Data Modeling Language (RFC 6020)
YANG è un linguaggio di modellazione dei dati basato su standard utilizzato per creare richieste di configurazione dei dispositivi o richieste di dati operativi (comando show). Ha un formato strutturato simile a un programma per computer leggibile dall'uomo. Sono disponibili diverse applicazioni che possono essere eseguite su una piattaforma di gestione centralizzata (ad esempio, un laptop) per creare queste richieste di dati operativi e di configurazione.
Esistono modelli di dati YANG standard (comuni) validi per tutti i fornitori (ad esempio, una richiesta di disabilitazione o chiusura di un'interfaccia Ethernet può essere identica per entrambi i dispositivi Cisco e non Cisco) e modelli di dati per dispositivi (nativi e specifici del fornitore) che semplificano la configurazione o la raccolta dei dati operativi associati alle funzionalità proprietarie dei fornitori.
Protocollo Network Configuration (NETCONF) (RFC 6241)
NETCONF è un protocollo codificato XML (Extensible Markup Language) basato su standard che fornisce il trasporto per comunicare la richiesta di dati operativi o di configurazione formattati YANG da un'applicazione in esecuzione su una piattaforma di gestione centralizzata (ad esempio, un laptop) al dispositivo Cisco da cui un utente desidera configurare o richiedere dati operativi (comando show). Fornisce servizi basati su transazioni, ad esempio l'interruzione dell'intera richiesta di configurazione quando una parte di essa ha esito negativo. NETCONF utilizza un semplice meccanismo basato su Remote Procedure Call (RPF) per facilitare la comunicazione tra un client (script o applicazione di una piattaforma di gestione centralizzata) e un server (switch o router Cisco). Usando Secure Shell (SSH) come livello di trasporto tra i dispositivi di rete. Alcune operazioni NETCONF includono get, get-config, edit-config e rpc.
Configurazione
1. Configurazione di base di uno switch Catalyst 3850 con software Cisco XE 16.3.3 per supportare la modellazione dei dati NETCONF/YANG
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. Configurazione aggiuntiva (opzionale) per consentire il monitoraggio degli eventi NETCONF/YANG Syslog e SNMP
Queste configurazioni snmp-server devono essere presenti per abilitare la generazione delle notifiche NETCONF (RFC 5277 - Tools 5277) per i messaggi Syslog e per qualsiasi trap SNMP configurata per generare anche le notifiche NETCONF.
Nota: sebbene queste siano le voci minime richieste, possono essere presenti anche altre voci di abilitazione snmp-server. Un client (piattaforma di gestione centralizzata) si registra per ricevere il flusso di notifica NETCONF da un server (Catalyst 3850) e inviare una RPC di sottoscrizione specifica (vedere la sezione 3 di Configurazione della piattaforma di gestione centralizzata (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
Per Syslog, questa configurazione deve essere presente per DMI (Data Model Interface) sullo switch Catalyst 3850 in modo da poter generare notifiche NETCONF definite nella RFC 5277 quando i messaggi Syslog vengono generati da Ciscod sullo switch Catalyst 3850.
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
Per le trap SNMP, questa configurazione è necessaria per generare notifiche NETCONF. Nel software Cisco XE 16.3.1, è possibile configurare un massimo di 10 trap SNMP per generare notifiche NETCONF, ma questa restrizione può essere rimossa in una versione futura. La generazione delle notifiche per le trap SNMP è attivata per impostazione predefinita. Per disabilitare la generazione delle notifiche trap SNMP, utilizzare questa CLI, no 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. Configurazione della connettività di rete di Catalyst 3850 utilizzata nell'esempio
In questo esempio, l'interfaccia di gestione Catalyst 3850 Gigabit Ethernet0/0 viene usata per il collegamento alla rete e alla piattaforma di gestione centralizzata (è possibile usare un laptop). Il protocollo DHCP (Dynamic Host Configuration Protocol) è stato utilizzato per assegnare l'indirizzo IP 172.16.167.175 a questa interfaccia. Configurazioni alternative possono essere utilizzate su Catalyst 3850 a condizione che il notebook possa raggiungere Catalyst 3850 sulla rete.
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
Verifica di NETCONF/YANG su Catalyst 3850
1. Dall'interfaccia della riga di comando (CLI) di Catalyst 3850, questo comando può essere usato per verificare che i processi software richiesti per supportare Data Model Interface (DMI) su Catalyst 3850 siano in esecuzione una volta configurato netconf-yang.
3850-1# show platform software yang-management process
confd : Running
nesd : Running
syncfd : Running
ncsshd : Running
dmiauthd : Running
vtyserverutild : Running
opdatamgrd : Running
ngnix : Running
I passaggi successivi vengono eseguiti dalla piattaforma di gestione centralizzata. Nell'esempio, viene usato un laptop (Apple MacBook Pro con macOS Sierra 10.12.2) con accesso di rete al Catalyst 3850. I comandi vengono emessi da un prompt del terminale sul laptop. A questo punto sul laptop non è caricata alcuna applicazione speciale.
2. Verificare che la piattaforma di gestione centralizzata (laptop) possa raggiungere Catalyst 3850 (172.16.167.175) sulla rete.
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. Verificare la connettività SSH allo switch Catalyst 3850 (172.16.167.175 nell'esempio) dalla piattaforma di gestione centralizzata (laptop) con il nome utente e la password (cisco1/cisco1) in base alla configurazione Catalyst 3850. La risposta può essere un lungo elenco di funzionalità NETCONF disponibili in Catalyst 3850 seguito da un messaggio di benvenuto. Porta TCP 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
Configurazione della piattaforma di gestione centralizzata (notebook)
1. Installare l'applicazione Yang Explorer su un notebook
In questo esempio, l'applicazione Yang Explorer viene utilizzata su un laptop (Apple MacBook Pro con macOS Sierra 10.12.2, browser Google Chrome) per fungere da piattaforma di gestione centralizzata. Esplora risorse consente all'utente di eseguire questa operazione:
· Caricamento/compilazione di modelli di dati YANG dall'interfaccia utente o dalla riga di comando
· Genera RPC NETCONF (chiamate di procedura remota)
· Eseguire RPC su un server NETCONF reale (Catalyst 3850)
· Salvare le RPC create nelle raccolte per un utilizzo successivo
· Esplorare gli alberi dei modelli di dati ed esaminare le proprietà YANG
2. Utilizzare l'applicazione Yang Explorer
Avviare l'applicazione Yang Explorer - da un prompt del terminale sul laptop eseguire il comando ./start.sh e dalla directory yang-explorer.
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.
Avviare la GUI di Yang Explorer - Avviare la GUI dell'applicazione Yang Explorer e accedere alla GUI dell'applicazione Yang Explorer come guest/guest nell'angolo superiore destro del menu principale della GUI dell'applicazione (fare riferimento all'acquisizione dello schermo).
Recupero di funzionalità da Catalyst 3850. Immettere i dettagli di Catalyst 3850 (indirizzo IP, nome utente/password, porta TCP 830 per ssh-netconf) e fare clic su Capabilities (Capacità) per recuperare l'elenco delle capacità operative di YANG dal software Catalyst 3850.
Carica modelli dati Yang: vari modelli dati YANG possono essere sottoscritti in Gestisci modelli. Una volta sottoscritti, vengono visualizzati nella casella Explorer a sinistra. Questi modelli YANG consentono all'applicazione Yang Explorer di creare messaggi RPC (Remote Procedure Call) NETCONF in formato YANG (inviati allo switch Catalyst 3850 per configurarlo o recuperarne i dati) senza dover avere una profonda esperienza YANG. Esempi di come eseguire questa operazione sono illustrati nella prossima sezione Funzionalità NETCONF/YANG
Esempi:
3. Iscrizione alle notifiche NETCONF (facoltativo)
Un client (piattaforma di gestione centralizzata) si registra per ricevere i flussi di notifica NETCONF da un server (Catalyst 3850) inviando questo messaggio RPC NETCONF in formato YANG. Catalyst 3850 invia notifiche NETCONF in modo asincrono a ciascun client che esegue la sottoscrizione. Prima di completare questa attività, verificare che sul Catalyst 3850 sia presente la configurazione corretta per supportare le notifiche NETCONF (vedere la sezione 2) di configurazione di NETCONF/YANG sul Catalyst 3850. Il server NETCONF (Catalyst 3850) inizia a inviare le notifiche degli eventi al client NETCONF (Piattaforma di gestione centralizzata) man mano che gli eventi si verificano nel sistema. Queste notifiche di eventi possono continuare a essere inviate fino al termine della sessione NETCONF o della sottoscrizione per altri motivi. Per ulteriori dettagli sulle opzioni di abbonamento a Tools 5277, vedere la RFC 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>
A tale scopo, è necessario tagliare e incollare il file nella GUI dell'applicazione Yang Explorer come RPC personalizzata.
Successivamente, per inviare il messaggio RPC personalizzato a Catalyst 3850 tramite NETCONF, viene selezionato Esegui. Lo switch Catalyst 3850 risponde con un messaggio ok per comunicare all'utente che l'operazione è riuscita.
Esempi operativi di base per NETCONF/YANG
Ora che Catalyst 3850 e la piattaforma di gestione centralizzata sono configurati e hanno iniziato a comunicare, possiamo esaminare alcuni esempi operativi di base.
Gli esempi possono dimostrare che i messaggi RPC NETCONF formattati YANG inviati tramite NETCONF dall'applicazione Yang Explorer della piattaforma di gestione centralizzata (laptop) allo switch Catalyst 3850 vengono convertiti nella CLI standard di Cisco IOS dal processo software confd sullo switch Catalyst 3850. Inoltre, i dati CLI di Cisco IOS (dati del comando show) vengono convertiti in dati formattati YANG dal processo software confd sullo switch Catalyst 3850 prima di essere inviati come messaggio RPC NETCONF all'applicazione Centralized Management Platform (Laptop) Yang Explorer. Ciò significa che è ancora possibile usare la CLI standard sullo switch Catalyst 3850 per configurare lo switch e raccogliere i dati del comando show, oltre a usare NETCONF/YANG per eseguire la stessa operazione.
1. Esempio di recupero dei dati
Richiesta di un elenco di nomi di interfaccia da Catalyst 3850
L'operazione desiderata può essere selezionata dalla sezione Esplora a sinistra dell'interfaccia utente dell'applicazione Esplora Yang. In questo caso, i dati del nome dell'interfaccia devono essere recuperati da Catalyst 3850, quindi viene selezionato Oper (per l'operazione) seguito da get-config nell'elenco a discesa del nome dell'interfaccia. L'opzione RPC viene selezionata successivamente per generare la RPC NETCONF formattata YANG (leggibile dall'uomo) che deve essere inviata allo switch Catalyst 3850 tramite NETCONF per recuperare questi dati dallo switch Catalyst 3850.
Dopo la generazione del messaggio RPC NETCONF formattato YANG, l'opzione Run (Esegui) viene selezionata per l'invio al Catalyst 3850. Lo switch Catalyst 3850 risponde con un elenco formattato YANG (leggibile dall'uomo) dei nomi delle interfacce Catalyst 3850 (Gigabit Ethernet1/1/1, Gigabit Ethernet1/1/2 e così via).
2. Esempio di configurazione
Arresto di un'interfaccia Ethernet su Catalyst 3850
L'operazione desiderata è selezionata dal lato sinistro della sezione Explorer dell'interfaccia utente dell'applicazione Yang Explorer. In questo caso, per configurare un'interfaccia (chiusura di un'interfaccia) è necessario su Catalyst 3850. Di conseguenza, è selezionato Config (per la configurazione), seguito dai parametri operativi richiesti nei menu a discesa dell'interfaccia. L'opzione RPC viene selezionata successivamente per generare la RPC NETCONF formattata YANG (leggibile dall'uomo) che deve essere inviata al Catalyst 3850 tramite NETCONF per eseguire l'attività di configurazione.
Dopo la generazione del messaggio RPC NETCONF formattato YANG, l'opzione Run (Esegui) viene selezionata per l'invio al Catalyst 3850. Lo switch Catalyst 3850 risponde con un messaggio formattato YANG (leggibile dall'uomo) in cui si dichiara che l'operazione di configurazione è stata completata (ok).
Per verificare che la modifica sia stata apportata, è possibile controllare la configurazione. È possibile usare un'operazione get-config (Oper) quando lo switch Catalyst 3850 risponde che l'interfaccia Gigabit Ethernet 1/0/16 ha abilitato la configurazione = false ora, ossia l'interfaccia è stata chiusa.
Dopo la generazione del messaggio RPC NETCONF formattato YANG, Esegui viene selezionato per inviarlo a Catalyst 3850. Lo switch Catalyst 3850 risponde con un messaggio in formato YANG in cui si afferma che la configurazione dell'interfaccia Gigabit Ethernet 1/0/16 è stata abilitata = false, ossia l'interfaccia è stata chiusa.
Visualizzazione della configurazione dell'interfaccia dalla CLI di Catalyst 3850 sia prima che dopo la precedente modifica della configurazione NETCONF/YANG
Al momento della precedente operazione di modifica della configurazione di Yang Explorer, questo output viene generato dalla CLI di Catalyst 3850. L'interfaccia Gigabit Ethernet 1/0/16 è in stato no shutdown predefinito finché non viene ricevuto il messaggio RPC NETCONF, come mostrato nel messaggio di registro su Catalyst 3850. Dopo aver ricevuto il messaggio RPC NETCONF contenente la richiesta formattata YANG di chiudere l'interfaccia, l'operazione viene completata, l'interfaccia viene chiusa e la configurazione corrente viene modificata di conseguenza. Questo comando mostra anche come il processo del software confd sullo switch Catalyst 3850 converte il messaggio RPC NETCONF formattato YANG ricevuto nella CLI standard di Cisco IOS. Ciò significa che un utente può ancora utilizzare la CLI standard di Cisco IOS per modificare la configurazione ed eseguire i comandi show, oltre a usare NETCONF/YANG per eseguire la stessa operazione.
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
!
Salvataggio della configurazione su un Catalyst 3850
La configurazione corrente può essere salvata nella configurazione di avvio sullo switch Catalyst 3850 inviando questo messaggio RPC NETCONF formattato YANG allo switch Catalyst 3850 tramite NETCONF.
<?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>
Questa operazione viene eseguita quando si taglia e incolla il file nell'applicazione Yang Explorer come RPC personalizzata.
Per inviare il messaggio RPC personalizzato allo switch Catalyst 3850 tramite NETCONF, l'opzione Esegui è selezionata. Catalyst 3850 risponde con un messaggio di errore.
Display Catalyst 3850 CLI della configurazione di avvio salvata dopo la precedente operazione di salvataggio della configurazione NETCONF/YANG
La configurazione di avvio ora corrisponde alla configurazione in esecuzione:
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
!
Configurazione di Catalyst 3850 dalla CLI
Come accennato in precedenza, è possibile usare la CLI standard di Catalyst 3850 per configurare lo switch e raccogliere i dati del comando show, oltre a usare NETCONF/YANG per eseguire la stessa operazione. Quando si usa la CLI di Catalyst 3850 al posto di NETCONF/YANG per configurare lo switch, la nuova configurazione in esecuzione viene sincronizzata con l'interfaccia del modello di dati (DMI) sullo switch Catalyst 3850 tramite il processo software syncfd.
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#
La volta successiva che l'applicazione Yang Explorer richiede una copia della configurazione dell'interfaccia dopo la modifica della CLI, la modifica viene riflessa correttamente nell'output YANG.
L'opzione Run (Esegui) è selezionata per inviare il messaggio RPC get-config per Gigabit Ethernet1/0/16 allo switch Catalyst 3850 tramite NETCONF. Lo switch Catalyst 3850 risponde con la configurazione dell'interfaccia Gigabit Ethernet 1/0/16 che mostra abilitata = true.
3. Verificare quali dati operativi MIB SNMP sono disponibili tramite le operazioni GET Request
I dati MIB SNMP che possono essere restituiti con le operazioni GET di NETCONF non sono configurabili dall'utente. Tutti i MIB SNMP supportati che vengono convertiti in dati strutturati definiti dai modelli di dati YANG fanno parte del software Cisco XE su Catalyst 3850. Per individuare i dati MIB disponibili nelle richieste GET, sono previste tre opzioni. Tutti i MIB supportati possono includere smiv2 nella capacità di risposta.
Opzione 1. Il pulsante Capabilities può essere selezionato nell'interfaccia utente di Yang Explorer. Catalyst 3850 risponde con il proprio elenco di funzionalità che contiene le voci MIB smiv2.
Opzione 2. Questo messaggio RPC NETCONF formattato YANG può essere inviato al Catalyst 3850 tramite NETCONF per recuperare l'elenco delle funzionalità che include i modelli MIB smiv2 disponibili.
<?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>
Questa operazione viene eseguita quando si taglia e incolla nell'applicazione Yang Explorer come RPC personalizzata.
Per inviare il messaggio RPC personalizzato allo switch Catalyst 3850 tramite NETCONF, l'opzione Esegui è selezionata. Catalyst 3850 risponde con un elenco di funzionalità che include i MIB smiv2 supportati.
Opzione 3. È possibile visualizzare un elenco dei modelli MIB disponibili nelle funzionalità NETCONF e nel messaggio Hello restituito dal Catalyst 3850 in risposta a una connessione SSH dalla piattaforma di gestione centralizzata (laptop).
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
Carica modelli di dati YANG aggiuntivi
Questo collegamento contiene ulteriori file del modello di dati YANG. Questi file consentono di eseguire operazioni aggiuntive tramite NETCONF/YANG che si riferiscono ad altre funzionalità di Catalyst 3850, come la configurazione del routing unicast IPv4, la funzionalità QoS, ecc.
Per individuare i modelli standard (comuni, Internet Engineering Task Force (IETF)) validi per tutti i fornitori, scegliere standard, ietf, rfc. Questo fornisce i modelli di dati YANG basati su standard presi da pubblicazioni RFC da parte dell'organismo di standard IETF.
GitHub Yang Models Tree Master Standard
Per individuare i modelli Cisco nativi (specifici del dispositivo o del fornitore), selezionare vendor, cisco, xe, 1632. Vengono forniti i modelli di dati YANG proprietari per il software Cisco IOS XE versione 16.3.2 per Catalyst 3850.
GitHub Yang Models Yang Tree Principale Fornitore
Questi file possono essere scaricati sulla piattaforma di gestione centralizzata (laptop) e quindi caricati nell'applicazione Yang Explorer. Ci sono due modi per farlo. Il primo consiste nel caricare i vari file del modello di dati YANG singolarmente, il secondo consiste nel caricare in massa tutti i file.
1. Caricare i vari file del modello di dati YANG singolarmente
Nell'esempio, cisco-ethernet.yang è già stato scaricato da github sulla piattaforma di gestione centralizzata (laptop). Di seguito sono riportati i passaggi per caricare il file nella GUI dell'applicazione Yang Explorer e quindi sottoscriverlo in modo che venga caricato nella sezione Explorer dello strumento.
2. Caricamento di massa di tutti i file del modello di dati YANG contemporaneamente
Questa procedura è menzionata anche nella sezione 5.2.2 qui: github.
Dal prompt di un terminale sulla piattaforma di gestione centralizzata (notebook - Apple MacBook Pro con 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--
Tutti i modelli di dati Yang sono ora visualizzati nella GUI dell'applicazione Yang Explorer. I file associati alle caratteristiche di interesse possono essere selezionati facendo clic su Subscribe, che li aggiunge alla sezione Esplora risorse dello strumento.
È ora possibile completare altre attività, ad esempio generare la RPC NETCONF/YANG necessaria per salvare la configurazione sullo switch Catalyst 3850. A tale scopo, selezionare la RPC save-conf nella sezione Explorer sul lato sinistro dell'applicazione Yang Explorer. Quindi, RPC viene selezionato per generare la porta NETCONF in formato YANG che può essere inviata allo switch Catalyst 3850 tramite NETCONF per salvare la configurazione sullo switch Catalyst 3850.
Esegui è selezionato per inviare il messaggio RPC personalizzato a Catalyst 3850 tramite NETCONF. Catalyst 3850 risponde con un messaggio di errore.
Modelli di dati YANG di rilievo
Modello di dati cisco-ia.yang
Di seguito sono riportati alcuni esempi di RPC per il modello di dati cisco-ia.yang. Si tratta di operazioni notevoli, come il salvataggio della configurazione Catalyst 3850, la sincronizzazione della configurazione corrente di Catalyst 3850 con l'archivio dati DMI (Data Model Interface) locale e il reset dell'interfaccia DMI su Catalyst 3850.
Il primo passaggio consiste nella sottoscrizione al modello di dati cisco-ia.yang in modo che venga visualizzato nella sezione Explorer a sinistra dell'interfaccia utente dell'applicazione YANG Explorer.
Una volta espanso il modello di dati cisco-ia nella sezione Explorer a sinistra dell'interfaccia utente dell'applicazione YANG Explorer, vengono visualizzate le varie opzioni operative. Ad esempio, per utilizzare una delle opzioni disponibili del modello di dati cisco-ia.yang, l'operazione save-config viene selezionata e la RPC associata viene generata quando si seleziona il pulsante RPC.
Successivamente, per inviare il messaggio RPC allo switch Catalyst 3850 tramite NETCONF, viene selezionato Esegui. Lo switch Catalyst 3850 risponde con un messaggio di conferma dell'esito positivo dell'operazione.
Di seguito sono descritte tutte le varie operazioni del modello di dati cisco-ia.yang:
sync-from - Questa RPC fa in modo che l'interfaccia NETCONF sullo switch Catalyst 3850 sincronizzi la rappresentazione dell'archivio dati NETCONF del dispositivo che esegue la configurazione con la configurazione in esecuzione sul dispositivo. Entrambi i modelli sono disponibili nello stesso Catalyst 3850.
<?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>
Per impostazione predefinita, questa RPC esegue una sincronizzazione senza impostazioni predefinite che sincronizza l'output di un comando show running-config inviato al dispositivo con l'archivio dati NETCONF. Se sono presenti valori predefiniti di sincronizzazione, l'interfaccia NETCONF legge anche le informazioni di configurazione predefinite fornite dal codice della funzionalità. Nella maggior parte dei casi questa opzione non viene utilizzata. In genere, questa opzione viene utilizzata solo se l'utente dell'interfaccia NETCONF desidera utilizzare i comandi NETCONF replace per sostituire sezioni complete della configurazione del dispositivo.
<?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 - Questa RPC esegue un comando write memory (copy running-config startup-config) per salvare il dispositivo che esegue la configurazione nella configurazione di avvio del dispositivo.
<?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 - Questa RPC determina il salvataggio della configurazione corrente da parte dell'interfaccia NETCONF in un archivio non volatile tramite la funzionalità di archiviazione della configurazione incorporata di Cisco IOSd.
<?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 - Questa RPC determina il rollback da parte dell'interfaccia NETCONF della configurazione in esecuzione del dispositivo a una configurazione in esecuzione salvata con la RPC del checkpoint o con qualsiasi altra configurazione in esecuzione valida salvata sul dispositivo.
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 - Questa RPC determina la modifica da parte dell'interfaccia NETCONF del revert-timer della RPC di rollback. In questo modo il rollback programmato viene annullato e viene attivato immediatamente oppure vengono reimpostati i parametri per il rollback programmato.
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 - L'interfaccia NETCONF può essere riavviata con questa RPC. Se reinitialize è true, l'interfaccia NETCONF cancella tutte le informazioni sullo stato presenti nell'archivio dati scrivibile in esecuzione. Se è false (impostazione predefinita), le informazioni sullo stato del datastore di configurazione NETCONF vengono mantenute.
<?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>
modello dati end.yang
I modelli di dati NED (Network Elements Driver), ad esempio ned.yang, offrono la massima potenza in termini di configurazione del dispositivo Cisco (Catalyst 3850). Ecco alcune immagini che lo dimostrano.
Il primo passaggio consiste nella sottoscrizione al modello di dati end.yang in modo che venga visualizzato nella sezione Explorer a sinistra dell'interfaccia utente dell'applicazione YANG Explorer.
Scorrendo le opzioni disponibili nella sezione Explorer sul lato sinistro dell'applicazione YANG Explorer, la GUI mostra un lungo elenco di funzionalità configurabili di Catalyst 3850 nel modello di dati end.yang.
Ad esempio, queste schermate mostrano come visualizzare la configurazione di routing OSPF dello switch Catalyst 3850 dopo aver prima scorruto l'elenco delle opzioni di configurazione disponibili per il modello di dati end.yang nella sezione Explorer sul lato sinistro dell'interfaccia utente dell'applicazione YANG Explorer. L'opzione secondaria ospf si trova all'interno dell'opzione router. La RPC get-config associata viene generata quando si seleziona il pulsante RPC.
Successivamente, per inviare il messaggio RPC allo switch Catalyst 3850 tramite NETCONF, viene selezionato Esegui. Catalyst 3850 risponde con la configurazione di routing OSPF.
Di seguito è riportata un'espansione della configurazione di routing OSPF restituita dallo switch Catalyst 3850 in risposta all'operazione RPC get-config.
<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>
La configurazione di routing OSPF formattata YANG recuperata da Catalyst 3850 tramite NETCONF è leggibile dall'uomo e corrisponde a quanto mostrato nella configurazione Catalyst 3850 tramite la CLI di Catalyst 3850.
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#
Se lo si desidera, è possibile utilizzare il modello di dati end.yang anche per modificare la configurazione di routing OSPF. In questo esempio, i nuovi parametri di rete vengono aggiunti alla configurazione di routing OSPF esistente sullo switch Catalyst 3850 immettendo prima i parametri desiderati nella sezione Explorer della GUI dell'applicazione Yang Explorer a sinistra (è stato immesso anche l'ID router OSPF 100, ma non è visibile a causa dello scorrimento della schermata di Explorer), quindi generando l'RPC in formato YANG associato e facendo clic sul pulsante RPC.
Successivamente, per inviare il messaggio RPC allo switch Catalyst 3850 tramite NETCONF, viene selezionato Esegui. Lo switch Catalyst 3850 risponde con un messaggio ok per comunicare all'utente che l'operazione è riuscita.
Questa operazione RPC NETCONF/YANG per modificare la configurazione del routing OSPF tramite il modello di dati end.yang è riflessa nella configurazione Catalyst 3850 come mostrato nella CLI di Catalyst 3850. Inoltre, sullo switch Catalyst 3850 è presente un messaggio syslog che indica che è stata apportata una modifica alla configurazione tramite NETCONF.
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#
Per i dettagli su come salvare la configurazione di esecuzione sulla configurazione di avvio del Catalyst 3850 con NETCONF/YANG, consultare l'operazione di salvataggio della configurazione menzionata nella sezione precedente del modello di dati cisco-ia.yang.
Script Python
Genera uno script Python dall'interfaccia utente di Yang Explorer
L'interfaccia utente dell'applicazione Yang Explore può essere utilizzata anche per generare uno script Python per una determinata operazione NETCONF/YANG. Uno dei principali vantaggi dello scripting Python è che consente l'orchestrazione e l'automazione delle operazioni NETCONF/YANG.
In questo esempio, viene selezionata un'operazione di salvataggio della configurazione nella finestra Explorer sul lato sinistro dell'interfaccia utente dell'applicazione Yang Explorer sulla piattaforma di gestione centralizzata (laptop). Quindi, il pulsante Script viene selezionato per generare lo script Python. È quindi possibile selezionare il pulsante Copy (Copia) per copiare lo script in modo che possa a sua volta essere incollato in un file che può essere salvato sulla piattaforma di gestione centralizzata (laptop) con estensione .py di Python. Per questo esempio, (non visualizzato) il nome del file è example.py.
Ecco un'espansione dello script Python che è stato generato e poi copiato e incollato in un file chiamato example.py sulla piattaforma di gestione centralizzata (laptop).
"""
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))
Esecuzione di uno script Python dalla piattaforma di gestione centralizzata (laptop)
Di seguito viene riportato un controllo Catalyst 3850 CLI prima di eseguire lo script Python example.py che può salvare il file running-config nella configurazione di avvio. A questo punto, il comando shutdown è nella configurazione in esecuzione ma non nella configurazione di avvio per l'interfaccia Gigabit Ethernet1/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
!
Da un normale prompt terminale sulla piattaforma di gestione centralizzata (laptop), il file example.py di Python generato dall'interfaccia utente dell'applicazione Yang Explorer viene prima copiato nella directory yang-explore sul laptop.
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$
Successivamente, da un normale prompt del terminale sulla piattaforma di gestione centralizzata (laptop), vengono eseguiti questi due comandi forniti nella sezione dei commenti all'inizio del file example.py generato dall'interfaccia utente dell'applicazione Yang Explorer (fare riferimento alla sezione precedente, Generazione di uno script Python dall'interfaccia utente dell'applicazione 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$
Il secondo comando esegue lo script Python example.py sullo switch Catalyst 3850 all'indirizzo IP 172.16.167.174 con nome utente/password cisco1/cisco1 tramite la porta TCP 830 (netconf-ssh). Lo switch Catalyst 3850 invia una risposta RPC alla piattaforma di gestione centralizzata (laptop) in cui viene confermata la riuscita dell'operazione di salvataggio della configurazione.
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
Di seguito viene riportato il controllo Catalyst 3850 CLI dopo aver eseguito lo script Python example.py che ha salvato la configurazione in esecuzione nella configurazione di avvio. Il comando shutdown è ora presente sia nella configurazione di esecuzione che nella configurazione di avvio dell'interfaccia Gigabit Ethernet 1/0/10 a causa del corretto funzionamento del comando save-config NETCONF/YANG.
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
!
Risoluzione dei problemi
In questa sezione vengono fornite informazioni utili per risolvere i problemi di configurazione.
Messaggi di errore NETCONF
Il protocollo NETCONF definisce una serie di operazioni e messaggi scambiati tra il client NETCONF (piattaforma di gestione centralizzata, laptop) e l'implementazione NETCONF sul dispositivo server (Catalyst 3850). Le operazioni NETCONF più comuni includono:
<get>, <get-config>, <edit-config> e <rpc>
Il formato e gli altri vincoli sul contenuto del messaggio NETCONF sono definiti dai modelli dati YANG. Il client e il server NETCONF interagiscono inviando RPC.
Se si verifica un errore nel formato del messaggio NETCONF o se il contenuto del messaggio non corrisponde alle definizioni nei modelli di dati YANG implementati dal dispositivo, il server NETCONF sul dispositivo può restituire un errore RPC.
<error-type>application</error-type>
Questi errori RPC non indicano che l'interfaccia NETCONF non funziona. Tali errori indicano che il client sta tentando di eseguire un'operazione non supportata dai modelli di dati YANG implementati sul dispositivo server. Gli utenti devono esaminare i modelli di dati YANG implementati sul dispositivo server per identificare e risolvere le cause di questi errori.
Esempio di errore RPC
Nell'esempio, viene usato un tipo di interfaccia errato ianaift:fastEtherFX per generare il messaggio RPC NETCONF <edit-config> in formato YANG da inviare tramite NETCONF allo switch Catalyst 3850.
Dopo aver selezionato Esegui per inviare il messaggio RPC allo switch Catalyst 3850, lo switch Catalyst 3850 risponde con un messaggio di errore.
Di seguito viene riportato l'errore restituito da Catalyst 3850. Si noti che contiene un tag di errore "operazione non riuscita" e ulteriori dettagli relativi all'errore indicano "Non supportato - il valore deve essere ethernetCsmacd o 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-info>
<nc:bad-element>type</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
Risolvere quindi l'errore e specificare il tipo di interfaccia corretto ianaift:ethernetCsmacd nel messaggio RPC inviato allo switch Catalyst 3850 in modo che lo switch Catalyst 3850 risponda con un messaggio ok anziché con un errore.
Questa volta, dopo aver selezionato Esegui per inviare il messaggio RPC allo switch Catalyst 3850, lo switch Catalyst 3850 risponde con un messaggio ok per indicare che l'operazione è stata completata.
Dopo aver selezionato Esegui per inviare il messaggio RPC allo switch Catalyst 3850, lo switch Catalyst 3850 risponde con la configurazione dell'interfaccia formattata YANG che indica che il tipo di interfaccia è ift:ethernetCsmacd.
Altri esempi di tipi di errore RPC
1. Messaggio di risposta di errore RPC "In uso" (bloccato da configurazione)
Risposta di errore NETCONF a una richiesta <edit-config>. Il tag <error-tag> indica "in uso". La risposta indica che il dispositivo server (Catalyst 3850) NETCONF che esegue l'archivio dati è attualmente bloccato e che non è possibile eseguire l'operazione NETCONF <edit-config> in questo momento. Ciò non indica un errore nell'implementazione dell'interfaccia NETCONF. Se un client NETCONF tenta di scrivere nell'archivio dati in esecuzione di NETCONF mentre l'archivio dati è in uso, il client riceve questa risposta RPC. Il client NETCONF può ritentare l'esecuzione del messaggio di modifica configurazione NETCONF. Questa risposta può essere ricevuta quando il dispositivo esegue un'operazione interna di sincronizzazione dal dispositivo per sincronizzare l'archivio dati in esecuzione di NETCONF con la configurazione IOSd del dispositivo.
Risposta di NETCONF dal server (Catalyst 3850) al client (piattaforma di gestione centralizzata (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. Messaggio di risposta di errore RPC "Dati mancanti"
Nell'esempio, è stata inviata una RPC <edit-config> allo switch Catalyst 3850 per un'interfaccia di loopback non configurata. È stato restituito un errore perché non è possibile configurare un'interfaccia che non esiste su Catalyst 3850.
<?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. Messaggio di risposta di errore RPC "Modello di dati mancante"
Se viene effettuata una richiesta per un modello di dati che non esiste in Catalyst 3850 o una richiesta per una foglia che non è implementata in un modello di dati, il server (Catalyst 3850) risponde con una risposta dati vuota. Si tratta di un comportamento normale.
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
4. Messaggio di risposta di errore RPC "Invalid-value"
In alcuni casi un messaggio NETCONF può contenere contenuto valido in base ai modelli di dati YANG, tuttavia il dispositivo (Catalyst 3850) non è in grado di implementare le funzionalità richieste. Quando l'interfaccia NETCONF sullo switch Catalyst 3850 invia a IOSd configurazioni che non possono essere applicate correttamente da IOSd, il client NETCONF riceve una risposta di errore RPC specifica.
In questo esempio, un valore booleano del buffer di registrazione non valido viene inviato nel messaggio RPC a Catalyst 3850. Il tag di errore nella risposta da Catalyst 3850 indica un valore non valido. Il messaggio di errore indica che il parser Catalyst 3850 IOS non è stato in grado di configurare il livello di gravità nel buffer di registrazione su false perché questo valore non è valido.
<?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>
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
3.0 |
21-Dec-2023 |
Aggiornamento dei requisiti di personalizzazione, ortografia e formattazione. |
2.0 |
01-Dec-2022 |
PII rimossa.
Testo alternativo aggiunto.
Informazioni RPC di ripristino corrette.
Aggiornamento di titolo, introduzione, traduzione automatica, argomenti, requisiti di stile e formattazione. |
1.0 |
17-Sep-2021 |
Versione iniziale |
Feedback