Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Modelli di dati - Configurazione e monitoraggio programmatici e basati su standard

Another Next Generation (YANG) Data Modeling Language (RFC 6020)

Protocollo Network Configuration (NETCONF) (RFC 6241)

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

2. Configurazione aggiuntiva (opzionale) per consentire il monitoraggio degli eventi NETCONF/YANG Syslog e SNMP

3. Configurazione della connettività di rete di Catalyst 3850 utilizzata nell'esempio

Verifica di NETCONF/YANG su Catalyst 3850

Configurazione della piattaforma di gestione centralizzata (notebook)

1. Installare l'applicazione Yang Explorer su un notebook

2. Utilizzare l'applicazione Yang Explorer

3. Iscrizione alle notifiche NETCONF (facoltativo)

Esempi operativi di base per NETCONF/YANG

1. Esempio di recupero dei dati

Richiesta di un elenco di nomi di interfaccia da Catalyst 3850

2. Esempio di configurazione

Arresto di un'interfaccia Ethernet su Catalyst 3850

Visualizzazione della configurazione dell'interfaccia dalla CLI di Catalyst 3850 sia prima che dopo la precedente modifica della configurazione NETCONF/YANG

Salvataggio della configurazione su un Catalyst 3850

Display Catalyst 3850 CLI della configurazione di avvio salvata dopo la precedente operazione di salvataggio della configurazione NETCONF/YANG

Configurazione di Catalyst 3850 dalla CLI

3. Verificare quali dati operativi MIB SNMP sono disponibili tramite le operazioni GET Request

Carica modelli di dati YANG aggiuntivi

1. Caricare i vari file del modello di dati YANG singolarmente

2. Caricamento di massa di tutti i file del modello di dati YANG contemporaneamente

Modelli di dati YANG di rilievo

Modello di dati cisco-ia.yang

modello dati end.yang

Script Python

Genera uno script Python dall'interfaccia utente di Yang Explorer

Esecuzione di uno script Python dalla piattaforma di gestione centralizzata (laptop)

Risoluzione dei problemi

Messaggi di errore NETCONF

Esempio di errore RPC

Altri esempi di tipi di errore RPC

Introduzione

Questo documento descrive come configurare NETCONF/YANG su piattaforme Cisco IOS XE 16.x.

Prerequisiti

Requisiti

NETCONF/YANG è supportato dal software Cisco IOS XE 16.3.1.

Nota: per utilizzare questo documento non è necessaria alcuna esperienza precedente con gli script NETCONF, YANG o Python.

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 indipendente WS-C3850-12X48U 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 su standard, la stessa procedura può essere utilizzata per configurare o raccogliere dati da dispositivi non Cisco, il che li rende 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

Nota: questa è la configurazione completa richiesta sullo switch Catalyst 3850 per supportare la modellazione dei dati NETCONF/YANG, ma si presume che "no aaa new-model" sia configurato a livello globale (impostazione predefinita). Se si desidera abilitare il server AAA (autenticazione, autorizzazione e accounting) configurando "aaa new-model" (nuovo modello), è richiesta almeno anche questa configurazione. Inoltre, è possibile espandere questa configurazione per usare il protocollo AAA con una configurazione TACACS+ o RADIUS, ma questa operazione non rientra nell'ambito di questo esempio.

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.

Sebbene queste siano le voci minime richieste, possono essere presenti anche altre voci relative all'abilitazione del server snmp. 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, usare 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.

Suggerimento: se il test SSH non funziona, verificare che tra il laptop e Catalyst 3850 sia presente un firewall che consenta l'uso della porta TCP 830 (riferimento RFC 4742: Strumenti 4742).

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

Nota: l'applicazione YANG Explore è supportata anche sui sistemi Linux.

2. Utilizzare l'applicazione Yang Explorer

Avviare l'applicazione Yang Explorer - dal prompt del terminale sul laptop eseguire il comando ./start.sh & dalla directory yang-explorer.

Nota: lasciare aperta questa sessione terminale altrimenti l'applicazione Esplora risorse può essere chiusa e deve essere riavviata. Può inoltre fungere da registro console dell'attività dell'applicazione.

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 allo screenshot).

Recuperare le funzionalità dallo switch Catalyst 3850 - Immettere i dettagli di Catalyst 3850 (indirizzo IP, nome utente/password, porta TCP 830 per ssh-netconf) e fare clic su Capabilities per recuperare l'elenco delle funzionalità operative di YANG dal software Catalyst 3850.

Suggerimento: anche questo è un buon test per verificare che la comunicazione NETCONF funzioni tra l'applicazione Yang Explorer sulla piattaforma di gestione centralizzata (laptop) e 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.

Nota: la versione corrente di Yang Explorer utilizzata in questo esempio non dispone di un'opzione per esaminare le notifiche NETCONF ricevute. In genere sono memorizzati in un registro notifiche selezionabile nel menu principale dell'applicazione.

Esempi operativi di base per NETCONF/YANG

Ora che Catalyst 3850 e la piattaforma di gestione centralizzata sono configurati e hanno iniziato a comunicare, vediamo 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 aver generato il messaggio RPC NETCONF formattato YANG, l'opzione Run (Esegui) viene selezionata per inviarlo allo switch Catalyst 3850. 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, ecc.).

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, quindi Config (per la configurazione) viene selezionato 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 la configurazione dell'interfaccia Gigabit Ethernet 1/0/16 ha "enabled = false", ossia ora l'interfaccia è stata chiusa.

Suggerimento: in generale, quando non è chiaro quale formato possono avere i valori nella sezione Explorer dell'applicazione Yang Explorer, eseguire il dump della configurazione di YANG formated Catalyst 3850 come mostrato è un buon modo per determinare quali siano prima di tentare di modificarli. Nella parte destra delle schermate successive vengono fornite alcune descrizioni e dipendenze per questi valori, nonché nelle colonne Proprietà e Valore.

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#

Nota: la configurazione non è stata ancora salvata (copiata dalla configurazione corrente alla configurazione di avvio) su Catalyst 3850.

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 Catalyst 3850 CLI anziché 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) viene selezionata per inviare il messaggio RPC get-config per Gigabit Ethernet 1/0/16 a 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 disponibili 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&amp;revision=2007-04-27</capability>

<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONTEXT-MAPPING-MIB?module=CISCO-CONTEXT-MAPPING-MIB&amp;revision=2008-11-22</capability>

<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DATA-COLLECTION-MIB?module=CISCO-DATA-COLLECTION-MIB&amp;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 file aggiuntivi 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 QoS e così via.

https://github.com/YangModels/yang

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.

https://github.com/YangModels/yang/tree/primary/standard/ietf/RFC

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.

https://github.com/YangModels/yang/tree/primary/vendor/cisco/xe/1632

Questi file possono essere scaricati nella 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

Suggerimento: rawgit può essere richiesto per scaricare i file da Github. Per scaricare i file da github, selezionare il pulsante Raw associato al file YANG. Se viene specificato un URL invece di un'opzione di download del file, l'URL può essere incollato in rawgit che a sua volta può fornire un URL di produzione. Incollare il nuovo URL di produzione in un browser e può fornire l'opzione di download del file.

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.

Suggerimento: la funzionalità NETCONF consente di determinare i modelli di dati supportati dal software Catalyst 3850. Vedere la sezione 2. della Configurazione della piattaforma di gestione centralizzata (laptop).

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.

Suggerimento: la funzionalità delle funzionalità NETCONF può essere utilizzata per determinare i modelli di dati supportati dal software Catalyst. Vedere la sezione 2. della Configurazione della piattaforma di gestione centralizzata (laptop).

È 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 RPC 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. Sono degni di nota in quanto comportano operazioni 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: a causa di questa RPC, l'interfaccia NETCONF sullo switch Catalyst 3850 sincronizza 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 chiamata 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 - A causa di questa RPC, l'interfaccia NETCONF salva la configurazione in esecuzione in un'archiviazione non volatile utilizzando 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 consente all'interfaccia NETCONF di eseguire il rollback 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 si annulla il rollback programmato e si attivano immediatamente i parametri di rollback o di reset 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>

Nota: al momento alcune piattaforme Cisco o versioni del software Cisco IOS non supportano tutte le funzionalità specificate. Ad esempio, quando si invia il ripristino precedente a uno switch Catalyst 3850 con IOS 16.3.3, l'errore "Reset not supported" viene restituito da Catalyst 3850 a Centralized Management Platform (Laptop) come risposta 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="http://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 schermate 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 formata da YANG e recuperata da Catalyst 3850 tramite NETCONF è leggibile dall'uomo e corrisponde a quella rilevata 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 (si noti che è 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 ulteriori informazioni su come salvare il file running-config nella configurazione di avvio su Catalyst 3850 con il comando NETCONF/YANG, fare riferimento all'operazione save-config 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.

Nell'esempio, un'operazione save-config viene selezionata nella finestra Explorer sul lato sinistro dell'interfaccia utente di Yang Explorer sulla piattaforma di gestione centralizzata (laptop). Quindi, il pulsante Script viene selezionato per generare lo script Python. Il pulsante Copia può quindi essere selezionato 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 un'estensione di file Python .py. Per questo esempio (non visualizzato) il nome del file è example.py.

Nota: nell'esempio successivo, se si usa il tipo "Platform" altro nella GUI, si è verificato un errore durante l'esecuzione dello script Python. Di conseguenza, il tipo "Piattaforma" è stato cambiato in csr poiché il router Cisco CSR esegue anche il software Cisco IOS-XE, proprio come il Catalyst 3850. Ciò ha evitato l'errore.

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).

Nota: i commenti all'inizio del file "example.py" generato dall'interfaccia utente dell'applicazione Yang Explorer includono i passi richiesti per eseguire lo script Python. Il "payload" include l'operazione NETCONF/YANG che lo script può eseguire. Nell'esempio, questo valore è un'operazione save-config.

"""

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 che erano forniti nella sezione dei commenti all'inizio del file example.py generato dalla GUI dell'applicazione Yang Explorer (fare riferimento alla sezione precedente "Generazione di uno script Python dalla GUI 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

Le informazioni contenute in questa sezione permettono di risolvere i problemi relativi alla 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>formattato 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 segnalare che l'operazione è stata completata.

Suggerimento: quando non si è certi del formato corretto dei valori di Explorer, è possibile controllare la configurazione esistente prima di tentare di modificarne i parametri. A tale scopo, è possibile eseguire l'operazione get-config (Oper), come mostrato di seguito.

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 <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 del modello di dati mancante

Se viene effettuata una richiesta per un modello di dati che non esiste in Catalyst 3850 o viene effettuata 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.

Suggerimento: utilizzare la funzionalità NETCONF per determinare i modelli di dati supportati dal software Catalyst. Vedere la sezione 2. della Configurazione della piattaforma di gestione centralizzata (laptop).

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