Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Modelos de datos: configuración y supervisión basadas en estándares y programáticas

Otro lenguaje de modelado de datos de última generación (YANG) (RFC 6020)

Protocolo de configuración de red (NETCONF) (RFC 6241)

Configurar

1. Configuración básica de un Catalyst 3850 que ejecuta el software Cisco XE 16.3.3 para soportar el modelado de datos NETCONF/YANG

2. Configuración adicional (opcional) para permitir el registro del sistema NETCONF/YANG y el control de eventos SNMP

3. Configuración de conectividad de red del Catalyst 3850 utilizada en este ejemplo

Verifique NETCONF/YANG en el Catalyst 3850

Configuración de la plataforma de gestión centralizada (portátil)

1. Instalar la aplicación Yang Explorer en un ordenador portátil

2. Utilice la aplicación Yang Explorer

3. Suscripción a notificaciones de NETCONF (opcional)

Ejemplos operativos básicos de NETCONF/YANG

1. Ejemplo de recuperación de datos

Solicitud de una lista de nombres de interfaz de Catalyst 3850

2. Ejemplo de configuración

Cierre una interfaz Ethernet en el Catalyst 3850

Catalyst 3850 CLI Muestra la Configuración de la Interfaz antes y después del Cambio de Configuración de NETCONF/YANG Anterior

Guarde la configuración en un Catalyst 3850

Visualización de la configuración de inicio guardada en Catalyst 3850 CLI después de la operación de guardado de la configuración anterior de NETCONF/YANG

Configure el Catalyst 3850 desde la CLI

3. Verifique qué datos operativos de MIB SNMP están disponibles a través de las operaciones de solicitud GET

Cargar modelos de datos YANG adicionales

1. Cargue los diversos archivos del modelo de datos YANG individualmente

2. Carga masiva de todos los archivos del modelo de datos YANG a la vez

Modelos de datos YANG notables

Modelo de datos de cisco-ia.yang

Modelo de datos ned.yang

Scripting Python

Generar un script Python desde la GUI de la aplicación Yang Explorer

Ejecutar un script Python desde la plataforma de gestión centralizada (portátil)

Troubleshoot

Mensajes de error de NETCONF

Ejemplo de error RPC

Otros ejemplos de tipo de error RPC

Introducción

Este documento describe cómo configurar NETCONF/YANG en plataformas basadas en Cisco IOS XE 16.x.

Prerequisites

Requirements

El software Cisco IOS XE 16.3.1 admite NETCONF/YANG.

Nota: No se requiere experiencia previa con scripts NETCONF, YANG o Python para utilizar este documento.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

En este ejemplo, se utiliza un switch WS-C3850-12X48U independiente que ejecuta Cisco IOS-XE 16.3.3 como servidor NETCONF. Este es el dispositivo que se configura y desde el cual se recopilan datos (salida del comando show) a través de NETCONF/YANG.

Un ordenador portátil (Apple MacBook Pro con macOS Sierra 10.12.2 y el navegador Google Chrome) se utiliza como cliente NETCONF. Actúa como la plataforma de gestión centralizada y utiliza la aplicación Yang Explorer. Es el dispositivo que crea las solicitudes con formato YANG que se envían al Catalyst 3850 a través de los mensajes NETCONF RPC (Remote Procedure Call) para configurar y recopilar datos del Catalyst 3850.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

El ejemplo que se presenta en este documento se centra en las pruebas de laboratorio con Catalyst 3850; sin embargo, la información proporcionada también se aplica a otras plataformas Cisco IOS XE 16.x, como los routers Cisco ASR 1000 Series.

Modelos de datos: configuración y supervisión basadas en estándares y programáticas

Los modelos de datos proporcionan una forma alternativa y centralizada de configurar los dispositivos de Cisco (en lugar de utilizar la interfaz de línea de comandos (CLI) de Cisco o el protocolo simple de administración de red (SNMP)) y recopilar datos operativos (comandos show) de los dispositivos de Cisco. Dado que los modelos de datos se basan en estándares, se puede utilizar el mismo procedimiento para configurar o recopilar datos de dispositivos que no son de Cisco, lo que los hace ideales para clientes que ofrecen soporte a varios proveedores. Se puede utilizar una plataforma de gestión centralizada (por ejemplo, un portátil) para configurar o recopilar datos de varios dispositivos Cisco. La arquitectura del modelo de datos permite automatizar estos procedimientos mediante scripts Python (dos ventajas clave adicionales).

Otro lenguaje de modelado de datos de última generación (YANG) (RFC 6020)

YANG es un lenguaje de modelado de datos basado en estándares que se utiliza para crear solicitudes de configuración de dispositivos o solicitudes de datos operativos (comando show). Tiene un formato estructurado similar a un programa de computadora que es legible por las personas. Hay varias aplicaciones disponibles que se pueden ejecutar en una plataforma de gestión centralizada (por ejemplo, un portátil) para crear estas solicitudes de datos operativos y de configuración.

Existen modelos de datos YANG estándar (comunes) que se aplican a todos los proveedores (por ejemplo, una solicitud para deshabilitar o apagar una interfaz Ethernet puede ser idéntica tanto para dispositivos de Cisco como de otros proveedores), así como modelos de datos de dispositivos (nativos o específicos del proveedor) que facilitan la configuración o la recopilación de datos operativos asociados con funciones de proveedores patentadas.

Protocolo de configuración de red (NETCONF) (RFC 6241)

NETCONF es un protocolo basado en estándar y codificado en lenguaje de marcado extensible (XML) que proporciona el transporte para comunicar la configuración con formato YANG o la solicitud de datos operativos de una aplicación que se ejecuta en una plataforma de administración centralizada (por ejemplo, un portátil) al dispositivo Cisco desde el que un usuario desea configurar o solicitar datos operativos (comando show). Proporciona servicios basados en transacciones, como anular la solicitud de configuración completa cuando falla una parte de dicha solicitud de configuración. NETCONF utiliza un mecanismo basado en una llamada a procedimiento remoto (RPF) simple para facilitar la comunicación entre un cliente (aplicación o script de plataforma de administración centralizada) y un servidor (switch o router de Cisco). Utiliza Secure Shell (SSH) como la capa de transporte a través de los dispositivos de red. Algunas operaciones de NETCONF incluyen get, get-config, edit-config y rpc.

Configurar

1. Configuración básica de un Catalyst 3850 que ejecuta el software Cisco XE 16.3.3 para soportar el modelado de datos 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: Esta es la configuración completa requerida en el Catalyst 3850 para soportar el modelado de datos NETCONF/YANG, pero asume que "no aaa new-model" también está configurado globalmente (el valor predeterminado). Si se desea habilitar AAA (autenticación, autorización y contabilización) configurando "aaa new-model", esta configuración también se requiere como mínimo. También puede expandir esto para utilizar AAA con una configuración TACACS+ o RADIUS, pero esto está más allá del alcance de este ejemplo.

aaa new-model

aaa authorization exec default local -------------> Required for NETCONF-SSH connectivity and edit-config operations

2. Configuración adicional (opcional) para permitir el registro del sistema NETCONF/YANG y el control de eventos SNMP

Estas configuraciones snmp-server deben estar presentes para habilitar la generación de notificaciones NETCONF (RFC 5277 - Tools 5277) para los mensajes de Syslog y para que cualquier trampa SNMP configurada también genere notificaciones NETCONF.

Tenga en cuenta que, si bien estas son las mínimas requeridas, también pueden estar presentes entradas "snmp-server enable" adicionales. Un cliente (plataforma de administración centralizada) se registra para recibir la secuencia de notificación NETCONF de un servidor (Catalyst 3850) y enviar una RPC de suscripción específica (consulte la sección 3 de "Configuración de la plataforma de administración centralizada (portátil)").

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

Para Syslog, esta configuración debe estar presente para que la Interfaz de modelo de datos (DMI) en el Catalyst 3850 tenga la capacidad de generar notificaciones NETCONF definidas en RFC 5277 cuando Cisco genera mensajes de Syslog en el 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

Para trampas SNMP, esta configuración es necesaria para generar notificaciones NETCONF. En el software Cisco XE 16.3.1 se pueden configurar un máximo de 10 trampas SNMP para generar notificaciones NETCONF, pero esta restricción se puede eliminar en una versión futura. La generación de notificaciones para las trampas SNMP está habilitada de forma predeterminada. Para inhabilitar la generación de notificaciones de trampa SNMP, utilice esta 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. Configuración de conectividad de red del Catalyst 3850 utilizada en este ejemplo

En este ejemplo, se utiliza la interfaz de administración GigabitEthernet0/0 de Catalyst 3850 para conectarse a la red y a la plataforma de administración centralizada (se puede utilizar un portátil). El protocolo de configuración dinámica de host (DHCP) se ha utilizado para asignar la dirección IP 172.16.167.175 a esta interfaz. Se pueden utilizar configuraciones alternativas en el Catalyst 3850 siempre y cuando el portátil pueda alcanzar el Catalyst 3850 en la red.

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

Verifique NETCONF/YANG en el Catalyst 3850

1. Desde la interfaz de línea de comandos (CLI) del Catalyst 3850, este comando se puede utilizar para garantizar que los procesos de software necesarios para admitir la interfaz de modelo de datos (DMI) en el Catalyst 3850 se ejecuten una vez que se haya configurado 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

Los siguientes pasos se realizan desde la plataforma de gestión centralizada. En este ejemplo, se utiliza un portátil (Apple MacBook Pro con macOS Sierra 10.12.2) que tiene acceso de red al Catalyst 3850. Los comandos se emiten desde una indicación de terminal en el portátil. En este momento no hay ninguna aplicación especial cargada en el portátil.

2. Asegúrese de que la plataforma de administración centralizada (portátil) puede alcanzar Catalyst 3850 (172.16.167.175) en la red.

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. Verifique la conectividad SSH al Catalyst 3850 (172.16.167.175 en este ejemplo) desde la plataforma de administración centralizada (laptop) con el nombre de usuario y la contraseña (cisco1/cisco1) de esta configuración del Catalyst 3850. La respuesta puede ser una larga lista de capacidades NETCONF del Catalyst 3850 seguida de un mensaje de saludo. Puerto TCP 830 = netconf-ssh.

Consejo: Si esta prueba SSH no funciona, asegúrese de que cualquier firewall entre el portátil y Catalyst 3850 permita el puerto TCP 830 (consulte RFC 4742: Tools 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

Configuración de la plataforma de gestión centralizada (portátil)

1. Instalar la aplicación Yang Explorer en un ordenador portátil

En este ejemplo, la aplicación Yang Explorer se utiliza en un ordenador portátil (Apple MacBook Pro con macOS Sierra 10.12.2, navegador Google Chrome) para actuar como plataforma de gestión centralizada. Yang Explorer permite al usuario hacer lo siguiente:

· Cargar / Compilar modelos de datos YANG desde la interfaz de usuario o línea de comandos

· Creación de RPC NETCONF (llamadas a procedimiento remoto)

· Ejecutar RPC contra un servidor NETCONF real (Catalyst 3850)

· Guardar las llamadas RPC creadas en las colecciones para su uso posterior

· Examinar árboles de modelos de datos e inspeccionar las propiedades YANG

Nota: La aplicación YANG Explore también es compatible con sistemas Linux.

2. Utilice la aplicación Yang Explorer

Inicie la aplicación Yang Explorer - desde una indicación de terminal en el portátil ejecute el comando ./start.sh & desde el directorio yang-explorer.

Nota: Mantenga esta sesión de terminal abierta de lo contrario la aplicación Yang Explorer puede cerrarse y debe reiniciarse. También puede servir como registro de la consola de la actividad de la aplicación.

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.

Inicie la GUI de Yang Explorer - Inicie la GUI de la aplicación Yang Explorer e inicie sesión en la GUI de la aplicación Yang Explorer como invitado en la esquina superior derecha del menú principal de la GUI de la aplicación (consulte la captura de pantalla).

Recupere capacidades del Catalyst 3850: ingrese los detalles del Catalyst 3850 (dirección IP, nombre de usuario/contraseña, puerto TCP 830 para ssh-netconf) y haga clic en Capacidades para recuperar la lista de capacidades operativas YANG del software Catalyst 3850.

Consejo: Esta es también una buena prueba para confirmar que la comunicación NETCONF funciona entre la aplicación Yang Explorer en la Plataforma de administración centralizada (Laptop) y el Catalyst 3850.

Cargar modelos de datos Yang: se pueden suscribir varios modelos de datos YANG en Administrar modelos. Una vez suscritos, aparecen en el cuadro Explorador de la izquierda. Estos modelos YANG permiten a la aplicación Yang Explorer crear mensajes de llamadas a procedimiento remoto (RPC) NETCONF formateados YANG (que se envían al Catalyst 3850 para configurarlo o recuperar datos de él) sin necesidad de tener una experiencia en YANG en profundidad. En la siguiente sección, Basic NETCONF/YANG Operational, se incluyen ejemplos de cómo hacerlo

Examples:

3. Suscripción a notificaciones de NETCONF (opcional)

Un cliente (plataforma de administración centralizada) se registra para recibir secuencias de notificación NETCONF de un servidor (Catalyst 3850) mediante el envío de este mensaje RPC NETCONF con formato YANG. El Catalyst 3850 envía notificaciones NETCONF de manera asíncrona a cada cliente que se suscribe. Antes de completar esta tarea, asegúrese de que la configuración correcta esté en su lugar en el Catalyst 3850 para soportar las notificaciones NETCONF (consulte la sección 2) de Configuración de NETCONF/YANG en el Catalyst 3850. El servidor NETCONF (Catalyst 3850) comienza a enviar las notificaciones de eventos al cliente NETCONF (plataforma de administración centralizada) a medida que se producen los eventos dentro del sistema. Estas notificaciones de eventos pueden continuar enviándose hasta que la sesión de NETCONF finalice o la suscripción finalice por algún otro motivo. Consulte RFC 5277 para obtener más detalles relacionados con las opciones de suscripción Tools 5277.

<?xml version="1.0" encoding="utf-8"?>

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">

<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">

<stream>snmpevents</stream>

</create-subscription>

</rpc>

Para hacer esto, necesita cortar y pegar esto en la GUI de la aplicación Yang Explorer como RPC personalizado

A continuación, se selecciona Run para enviar el mensaje RPC personalizado al Catalyst 3850 a través de NETCONF. El Catalyst 3850 responde con un mensaje ok para informar al usuario que la operación fue exitosa.

Nota: La versión actual de Yang Explorer utilizada en este ejemplo no tiene una opción para ver las notificaciones NETCONF recibidas. Normalmente se almacenan en un registro de notificaciones en el que se puede hacer clic en el menú principal de la aplicación.

Ejemplos operativos básicos de NETCONF/YANG

Ahora que el Catalyst 3850 y la plataforma de administración centralizada están configurados y han comenzado a comunicarse, veamos algunos ejemplos operativos básicos.

Los ejemplos pueden demostrar que los mensajes RPC NETCONF formateados YANG enviados a través de NETCONF desde la aplicación Yang Explorer de la Plataforma de administración centralizada (laptop) al Catalyst 3850 se convierten a la CLI estándar de Cisco IOS mediante el proceso de software confd en el Catalyst 3850. Además, los datos de Cisco IOS CLI (show command data) se convierten en datos con formato YANG mediante el proceso de software confd en Catalyst 3850 antes de enviarse como mensaje NETCONF RPC a la aplicación Yang Explorer de la plataforma de administración centralizada (laptop). Esto significa que la CLI normal todavía se puede utilizar en el Catalyst 3850 para configurar el switch y recopilar datos del comando show, además de utilizar NETCONF/YANG para hacer lo mismo.

1. Ejemplo de recuperación de datos

Solicitud de una lista de nombres de interfaz de Catalyst 3850

La operación deseada se puede seleccionar en la sección del Explorador del lado izquierdo de la GUI de la aplicación Yang Explorer. En este caso, los datos del nombre de la interfaz deben recuperarse del Catalyst 3850 y por lo tanto se selecciona Oper (para la operación) seguido de get-config en el menú desplegable del nombre de la interfaz. RPC se selecciona a continuación para generar el NETCONF RPC con formato YANG (legible por personas) que se debe enviar al Catalyst 3850 a través de NETCONF para recuperar estos datos del Catalyst 3850.

Después de generar el mensaje RPC NETCONF con formato YANG, se selecciona Run para enviarlo al Catalyst 3850. El Catalyst 3850 responde con una lista en formato YANG (legible por personas) de los nombres de interfaz del Catalyst 3850 (GigabitEthernet1/1/1, GigabitEthernet1/1/2, etc.).

2. Ejemplo de configuración

Cierre una interfaz Ethernet en el Catalyst 3850

La operación deseada se selecciona del lado izquierdo de la sección del Explorador de la GUI de la aplicación Yang Explorer. En este caso, para configurar una interfaz (apagando una interfaz) se requiere en el Catalyst 3850 y así se selecciona Config (para configuración) seguido de los parámetros operativos requeridos en los menús desplegables de la interfaz. RPC se selecciona a continuación para generar el NETCONF RPC con formato YANG (legible por personas) que se debe enviar al Catalyst 3850 a través de NETCONF para ejecutar la tarea de configuración.

Después de generar el mensaje RPC NETCONF con formato YANG, se selecciona Run para enviarlo al Catalyst 3850. El Catalyst 3850 responde con un mensaje con formato YANG (legible por personas) que indica que la operación de configuración fue exitosa (ok).

Para confirmar que el cambio tuvo lugar, se puede verificar la configuración. Se puede utilizar una operación get-config (Oper) donde el Catalyst 3850 responde que la configuración de la interfaz GigabitEthernet 1/0/16 tiene ‘enabled = false’ ahora, lo que significa que la interfaz se cerró.

Sugerencia: En general, cuando no está claro qué formato pueden tener los Valores en la sección Explorador de la aplicación Yang Explorer, el volcado de la configuración YANG Catalyst 3850 formateada como se muestra es una buena manera de determinar cuáles son antes de que se haga un intento de modificarlos. El lado derecho de las pantallas siguientes proporciona algunas descripciones y dependencias para estos valores, así como en las columnas Propiedad y Valor.

Después de generar el mensaje RPC NETCONF con formato YANG, se selecciona Run para enviarlo al Catalyst 3850. El Catalyst 3850 responde con un mensaje con formato YANG que afirma que la configuración de la interfaz GigabitEthernet 1/0/16 ha habilitado = false ahora, lo que significa que la interfaz se cerró.

Catalyst 3850 CLI Muestra la Configuración de la Interfaz antes y después del Cambio de Configuración de NETCONF/YANG Anterior

En el momento de la operación de cambio de configuración anterior del Yang Explorer, esto se produce desde la CLI del Catalyst 3850. La interfaz GigabitEthernet 1/0/16 estaba en el estado predeterminado de no apagado hasta que se recibe el mensaje NETCONF RPC, como se ve en el mensaje de registro en el Catalyst 3850. Una vez recibido el mensaje NETCONF RPC que contiene la solicitud con formato YANG para apagar la interfaz, la operación se completa, la interfaz se apaga y la configuración en ejecución se modifica para reflejar esto. Esto también demuestra cómo el proceso de software confd en Catalyst 3850 convierte el mensaje RPC NETCONF formateado YANG recibido en la CLI estándar de Cisco IOS. Esto significa que un usuario todavía puede utilizar la CLI regular de Cisco IOS para modificar la configuración y ejecutar los comandos show, además de utilizar NETCONF/YANG para hacer lo mismo.

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 configuración aún no se ha guardado (se copió de la configuración en ejecución a la configuración de inicio) en el Catalyst 3850.

3850-1# show startup-config | begin 1/0/16

interface GigabitEthernet1/0/16

!

Guarde la configuración en un Catalyst 3850

La configuración en ejecución se puede guardar en la configuración de inicio en el Catalyst 3850 enviando este mensaje RPC NETCONF con formato YANG al Catalyst 3850 a través de 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>

Esto se hace al cortar y pegar esto en la aplicación Yang Explorer como RPC personalizado.

Run está seleccionado para enviar el mensaje RPC personalizado al Catalyst 3850 a través de NETCONF. El Catalyst 3850 responde con un mensaje exitoso.

Visualización de la configuración de inicio guardada en Catalyst 3850 CLI después de la operación de guardado de la configuración anterior de NETCONF/YANG

La configuración de inicio ahora coincide con la configuración en ejecución:

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

!

Configure el Catalyst 3850 desde la CLI

Como se mencionó anteriormente, el Catalyst 3850 CLI normal se puede seguir utilizando para configurar el switch y recopilar datos del comando show, además de utilizar NETCONF/YANG para hacer lo mismo. Cuando se utiliza la CLI de Catalyst 3850 en lugar de NETCONF/YANG para configurar el switch, la nueva configuración en ejecución se sincroniza con la interfaz del modelo de datos (DMI) en el Catalyst 3850 a través del proceso de 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 próxima vez que la aplicación Yang Explorer solicite una copia de la configuración de la interfaz después del cambio de CLI, el cambio se reflejará correctamente en la salida YANG.

Run se selecciona para enviar el mensaje get-config RPC para GigabitEthernet1/0/16 al Catalyst 3850 a través de NETCONF. El Catalyst 3850 responde con la configuración de la interfaz GigabitEthernet1/0/16 que muestra enabled = true.

3. Verifique qué datos operativos de MIB SNMP están disponibles a través de las operaciones de solicitud GET

El usuario no puede configurar los datos MIB SNMP que se pueden devolver con las operaciones GET de NETCONF. Todos los MIB SNMP admitidos que se convierten en datos estructurados definidos por los modelos de datos YANG forman parte del software Cisco-XE en el Catalyst 3850. Para descubrir qué datos MIB están disponibles en las solicitudes GET, se indican tres opciones. Todos los MIB admitidos pueden incluir smiv2 en la respuesta de la capacidad.

Opción 1. El botón Capacidades se puede seleccionar en la GUI de la aplicación Yang Explorer. El Catalyst 3850 responde con su lista de capacidades que contiene entradas de MIB smiv2.

Opción 2. Este mensaje RPC NETCONF con formato YANG se puede enviar al Catalyst 3850 a través de NETCONF para recuperar la lista de capacidades que incluye los modelos MIB smiv2 disponibles.

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

Esto se realiza al cortar y pegar en la aplicación Yang Explorer como RPC personalizado.

Run está seleccionado para enviar el mensaje RPC personalizado al Catalyst 3850 a través de NETCONF. El Catalyst 3850 responde con una lista de capacidades que incluye los MIBs smiv2 soportados.

Opción 3.  Se puede ver una lista de modelos MIB disponibles en las capacidades NETCONF y el mensaje Hello devuelto por el Catalyst 3850 en respuesta a una conexión SSH desde la Plataforma de administración centralizada (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

Cargar modelos de datos YANG adicionales

Este enlace contiene archivos adicionales del modelo de datos YANG. Estos archivos permiten ejecutar operaciones adicionales a través de NETCONF/YANG relacionadas con otras funciones de Catalyst 3850, como la configuración del routing unidifusión IPv4, QoS, etc.

https://github.com/YangModels/yang

Los modelos estándar (comunes, IETF (del inglés Internet Engineering Task Force, Grupo de trabajo de ingeniería de Internet)) que se aplican a todos los proveedores se pueden encontrar eligiendo estándar, ietf, rfc. Esto proporciona los modelos de datos YANG basados en estándares tomados de las publicaciones RFC por el cuerpo de estándares IETF.

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

Los modelos nativos de Cisco (dispositivo, proveedor específico) se pueden encontrar seleccionando vendor, cisco, xe, 1632. Esto proporciona los modelos de datos YANG patentados para la versión 16.3.2 del software Cisco IOS XE para el Catalyst 3850.

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

Estos archivos se pueden descargar en la plataforma de administración centralizada (portátil) y, a su vez, se cargan en la aplicación Yang Explorer. Existen dos maneras para hacer esto. La primera es cargar en los diversos archivos del modelo de datos YANG individualmente, la segunda es una carga masiva de todos los archivos.

1. Cargue los diversos archivos del modelo de datos YANG individualmente

Consejo: rawgit puede ser requerido para descargar los archivos de Github. Para descargar archivos desde github, seleccione el botón Raw asociado con el archivo YANG. Si se proporciona una URL en lugar de una opción de descarga de archivos, la URL se puede pegar en rawgit, lo que a su vez puede proporcionar una URL de producción. Pegue esta nueva URL de producción en un navegador y podrá proporcionar la opción de descarga de archivos.

En este ejemplo, cisco-ethernet.yang ya se ha descargado de github en la plataforma de gestión centralizada (portátil). Estos son los pasos para cargar el archivo en la GUI de la aplicación Yang Explorer y luego Suscribirse a él para que se cargue en la sección Explorer de la herramienta.

Sugerencia: la funcionalidad de las funciones de NETCONF se puede utilizar para determinar qué modelos de datos admite el software Catalyst 3850. Consulte la sección 2 de Configuración de la plataforma de gestión centralizada (portátil).

2. Carga masiva de todos los archivos del modelo de datos YANG a la vez

Este procedimiento también se menciona en la sección 5.2.2 aquí: github.

Desde una indicación de terminal en la plataforma de administración centralizada (portátil - 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--

Todos los modelos de datos Yang se ven ahora en la GUI de la aplicación Yang Explorer. Los archivos asociados con las características de interés se pueden seleccionar al hacer clic en Subscribe, que luego los agrega a la sección Explorer de la herramienta.

Sugerencia: la funcionalidad de las funciones de NETCONF se puede utilizar para determinar qué modelos de datos son compatibles con el software Catalyst. Consulte la sección 2 de Configuración de la plataforma de gestión centralizada (portátil).

Ahora se pueden completar otras tareas, como generar el RPC NETCONF/YANG necesario para guardar la configuración en el Catalyst 3850. Esto se hace cuando selecciona save-conf RPC en la sección Explorer en el lado izquierdo de la aplicación Yang Explorer. Luego se selecciona RPC para generar el NETCONF RPC con formato YANG que se puede enviar al Catalyst 3850 a través de NETCONF para guardar la configuración en el Catalyst 3850.

Run se selecciona para enviar el mensaje RPC personalizado al Catalyst 3850 a través de NETCONF. El Catalyst 3850 responde con un mensaje exitoso.

Modelos de datos YANG notables

Modelo de datos de cisco-ia.yang

Estos son algunos ejemplos de RPC para el modelo de datos cisco-ia.yang. Son notables ya que involucran operaciones como guardar la configuración del Catalyst 3850, sincronizar el Catalyst 3850 running-config con el almacén de datos de la Interfaz de modelo de datos (DMI) local y restablecer la interfaz DMI en el Catalyst 3850.

El primer paso es Suscribirse al modelo de datos cisco-ia.yang para que aparezca en la sección Explorer a la izquierda de la GUI de la aplicación YANG Explorer.

Una vez que el modelo de datos cisco-ia se expande en la sección Explorer a la izquierda de la GUI de la aplicación YANG Explorer, se ven las diversas opciones operativas. Como ejemplo para utilizar una de las opciones disponibles del modelo de datos cisco-ia.yang, se selecciona la operación save-config y se genera la RPC asociada cuando se selecciona el botón RPC.

A continuación, se selecciona Run para enviar el mensaje RPC al Catalyst 3850 a través de NETCONF. El Catalyst 3850 responde con un mensaje exitoso para que el usuario sepa que la operación fue exitosa.

A continuación se describen todas las operaciones del modelo de datos de cisco-ia.yang:

sync-from - Este RPC hace que la interfaz NETCONF en el Catalyst 3850 sincronice la representación del almacén de datos NETCONF del dispositivo que ejecuta la configuración con la configuración que se ejecuta en el dispositivo. Ambos existen en el propio 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>

El comportamiento predeterminado de este RPC es realizar una sincronización sin valores predeterminados que hace que la salida de un comando show running-config enviado al dispositivo se sincronice con el almacén de datos NETCONF. Si está presente sync-defaults, la interfaz NETCONF también lee la información de configuración predeterminada proporcionada por el código de función. En la mayoría de los casos, esta opción no se utiliza. Normalmente, esto sólo se utilizaría si el usuario de la interfaz NETCONF quisiera utilizar los comandos NETCONF replace para reemplazar secciones completas de la configuración 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: este RPC ejecuta un comando write memory (copy running-config startup-config) para guardar la configuración actual de ejecución del dispositivo en la configuración de inicio 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 - Este RPC hace que la interfaz NETCONF guarde la configuración en ejecución en almacenamiento no volátil usando la función de archivo de configuración integrada de 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 - Este RPC hace que la interfaz NETCONF revierta la configuración en ejecución del dispositivo a una configuración en ejecución que fue guardada con el RPC de punto de control o cualquier otra configuración válida en ejecución guardada en el 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 - Este RPC hace que la interfaz NETCONF cambie el temporizador revert del RPC de rollback, esto cancela el rollback temporizado y activa el rollback inmediatamente o restablece los parámetros para el rollback temporizado.

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: la interfaz NETCONF se puede reiniciar con este RPC. Si reinitialize es true, la interfaz NETCONF borra toda la información de estado que existe en el almacén de datos de ejecución grabable. Si es false (valor predeterminado), se conserva la información de estado del almacén de datos de configuración de NETCONF.

<?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: algunas plataformas de Cisco o versiones de software del IOS de Cisco no pueden soportar toda la funcionalidad dada en este momento. Por ejemplo, cuando envía el restablecimiento anterior a un Catalyst 3850 que ejecuta IOS 16.3.3, el Catalyst 3850 devuelve el error "Restablecimiento no admitido" a la Plataforma de administración centralizada (Laptop) como respuesta 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>

Modelo de datos ned.yang

Los modelos de datos del controlador de elementos de red (NED), como ned.yang, son los que ofrecen más potencia en términos de configuración de dispositivos de Cisco (Catalyst 3850). Estas son algunas capturas de pantalla que lo demuestran.

El primer paso es Suscribirse al modelo de datos end.yang para que aparezca en la sección Explorer a la izquierda de la GUI de la aplicación YANG Explorer.

Desplácese por las opciones disponibles en la sección Explorer en el lado izquierdo de la aplicación YANG Explorer, GUI muestra una larga lista de funciones configurables de Catalyst 3850 en el modelo de datos end.yang.

A modo de ejemplo, estas capturas de pantalla muestran cómo visualizar la configuración de ruteo OSPF del Catalyst 3850 después de desplazarse por primera vez por la lista de opciones de configuración del modelo de datos ned.yang disponibles en la sección Explorer en el lado izquierdo de la GUI de la aplicación YANG Explorer. La subopción ospf se encuentra dentro de la opción router. El RPC get-config asociado se genera cuando se selecciona el botón RPC.

A continuación, se selecciona Run para enviar el mensaje RPC al Catalyst 3850 a través de NETCONF. El Catalyst 3850 responde con su configuración de ruteo OSPF.

Aquí se presenta una expansión de la configuración de ruteo OSPF devuelta por el Catalyst 3850 en respuesta a la operación get-config RPC.

<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 configuración de ruteo OSPF con formato YANG que se recuperó del Catalyst 3850 a través de NETCONF es legible por las personas y coincide con lo que se ve cuando se observa la configuración del Catalyst 3850 a través de la CLI del 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#

Si lo desea, el modelo de datos ned.yang también se puede utilizar para modificar la configuración de ruteo OSPF. En este ejemplo, se agregan nuevos parámetros de red a la configuración de ruteo OSPF existente en el Catalyst 3850 ingresando primero los parámetros deseados en la sección Explorer de la GUI de la aplicación Yang Explorer a la izquierda (observe que el ID de router OSPF 100 también se ingresó pero no se ve debido al desplazamiento de la pantalla del Explorador) y luego generando el RPC con formato YANG asociado y presionando el botón RPC.

A continuación, se selecciona Run para enviar el mensaje RPC al Catalyst 3850 a través de NETCONF. El Catalyst 3850 responde con un mensaje ok para que el usuario sepa que la operación fue exitosa.

Esta operación NETCONF/YANG RPC para modificar la configuración de ruteo OSPF a través del modelo de datos ned.yang se refleja en la configuración de Catalyst 3850 tal como se ve a través de la CLI de Catalyst 3850. También hay un mensaje de syslog en el Catalyst 3850 que indica que se realizó un cambio de configuración a través de 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#

Consulte la operación save-config mencionada en la sección anterior modelo de datos cisco-ia.yang para obtener detalles sobre cómo guardar running-config en startup-config en el Catalyst 3850 a través de NETCONF/YANG.

Scripting Python

Generar un script Python desde la GUI de la aplicación Yang Explorer

La GUI de la aplicación Yang Explore también se puede utilizar para generar un script Python para una operación NETCONF/YANG determinada. Una ventaja clave de las secuencias de comandos de Python es que permiten la orquestación y automatización de las operaciones de NETCONF/YANG.

En este ejemplo, se selecciona una operación save-config en la ventana del Explorador en el lado izquierdo de la GUI de la aplicación Yang Explorer en la plataforma de administración centralizada (laptop). A continuación, se selecciona el botón Script para generar el script Python. El botón Copy se puede seleccionar para copiar el script de modo que a su vez se pueda pegar en un archivo que se pueda guardar en la plataforma de administración centralizada (laptop) con una extensión de archivo Python .py. Para este ejemplo (no se muestra) este archivo se ha denominado example.py.

Nota: En el siguiente ejemplo que utiliza "Platform" escriba other en la GUI resultó en un error al ejecutar el script Python. Como resultado, el tipo "Plataforma" se cambió a csr ya que el router Cisco CSR también ejecuta el software Cisco IOS-XE tal como lo hace el Catalyst 3850. Esto evitó el error.

A continuación se muestra una expansión del script Python que se generó y luego se copió y pegó en un archivo llamado example.py en la plataforma de administración centralizada (laptop).

Nota: Los comentarios al inicio del archivo "example.py" generado por la GUI de la aplicación Yang Explorer incluyen los pasos necesarios para ejecutar el script Python. La "carga útil" incluye la operación NETCONF/YANG que la secuencia de comandos puede ejecutar. En este ejemplo es una operación 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))

Ejecutar un script Python desde la plataforma de gestión centralizada (portátil)

Aquí está la comprobación de la CLI de Catalyst 3850 antes de ejecutar el script de Python example.py que puede guardar running-config en startup-config. En este momento, el comando shutdown está en running-config pero no en startup-config para la interfaz GigabitEthernet1/0/10.

3850-1# show running-config interface gigabitEthernet 1/0/10

Building configuration...

Current configuration : 49 bytes

!

interface GigabitEthernet1/0/10

shutdown

end

3850-1# show startup-config | begin 1/0/10

interface GigabitEthernet1/0/10

!

interface GigabitEthernet1/0/11

!

interface GigabitEthernet1/0/12

!

interface GigabitEthernet1/0/13

!

A partir de un mensaje de terminal regular en la plataforma de administración centralizada (laptop), el archivo de Python example.py generado por la GUI de la aplicación Yang Explorer se copia primero en el directorio yang-explore en el 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$

A continuación, a partir de un mensaje de terminal regular en la plataforma de administración centralizada (laptop), se ejecutan estos dos comandos que se proporcionaron en la sección de comentarios al inicio del archivo example.py generado por la GUI de la aplicación Yang Explorer (consulte la sección anterior "Generación de un script Python desde la GUI de la aplicación 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$

El segundo comando ejecuta el script de Python example.py contra el Catalyst 3850 en la dirección IP 172.16.167.174 con el nombre de usuario/contraseña cisco1/cisco1 a través del puerto TCP 830 (netconf-ssh). El Catalyst 3850 envía una respuesta RPC a la plataforma de administración centralizada (laptop) indicando que la operación de guardar configuración fue exitosa.

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

Aquí está la verificación de la CLI de Catalyst 3850 después de ejecutar el script de Python example.py que guardó running-config en la configuración de inicio. El comando shutdown ahora está presente en running-config y startup-config para la interfaz GigabitEthernet1/0/10 debido a la operación exitosa 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

!

Troubleshoot

En esta sección encontrará información que puede utilizar para solucionar problemas de configuración.

Mensajes de error de NETCONF

El protocolo NETCONF define un conjunto de operaciones y mensajes que se intercambian entre el cliente NETCONF (plataforma de administración centralizada [portátil]) y la implementación NETCONF en el dispositivo del servidor (Catalyst 3850). Las operaciones NETCONF más comunes incluyen:

<get>, <get-config>, <edit-config> y <rpc>

El formato y otras restricciones en el contenido del mensaje NETCONF son definidos por los modelos de datos YANG. El cliente y el servidor NETCONF interactúan enviando RPC.

Si hay un error en el formato del mensaje NETCONF o el contenido del mensaje no coincide con las definiciones en los modelos de datos YANG implementados por el dispositivo, el servidor NETCONF en el dispositivo puede devolver un error RPC.

<error-type>application</error-type>

Estos errores RPC no indican que la interfaz NETCONF no funcione, estos errores indican que el cliente está intentando realizar una operación que no es compatible con los modelos de datos YANG implementados en el dispositivo servidor. Los usuarios deben revisar los modelos de datos YANG implementados en el dispositivo del servidor para identificar y resolver las causas de estos errores.

Ejemplo de error RPC

En este ejemplo, se utiliza un tipo de interfaz incorrecto ianaift:fastEtherFX para generar el mensaje RPC NETCONF con formato YANG <edit-config> para enviar a través de NETCONF al Catalyst 3850.

Una vez que se selecciona Run para enviar el mensaje RPC al Catalyst 3850, el Catalyst 3850 responde con un mensaje de error.

Este es el error devuelto por el Catalyst 3850. Observe que contiene una etiqueta de error "operation-failed" (error de operación fallida) y más detalles sobre el error que indican "Unsupported - value must be ethernetCsmacd or softwareLoopback"</nc:error-message>".

<nc:rpc-error xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">

<nc:error-type>application</nc:error-type>

<nc:error-tag>operation-failed</nc:error-tag>

<nc:error-severity>error</nc:error-severity>

<nc:error-path xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">/rpc/edit-config/config/if:interfaces/if:interface[if:name='GigabitEthernet1/0/16']/if:type</nc:error-path>

<nc:error-message lang="en" xmlns="https://www.w3.org/XML/1998/namespace">/interfaces/interface[name='GigabitEthernet1/0/16']/type: "Unsupported - value must be ethernetCsmacd or softwareLoopback"

<nc:error-info>

<nc:bad-element>type</nc:bad-element>

</nc:error-info>

</nc:rpc-error>

Luego, corrijamos el error y especifiquemos el tipo de interfaz correcto ianaift:ethernetCsmacd en El mensaje RPC enviado al Catalyst 3850 para que el Catalyst 3850 responda con un mensaje ok en lugar de un error.

Esta vez, una vez que se selecciona Run para enviar el mensaje RPC al Catalyst 3850, el Catalyst 3850 responde con un mensaje ok para indicar que la operación fue exitosa.

Sugerencia: si no está seguro de cuál puede ser el formato correcto de los valores del explorador, puede examinar la configuración existente antes de intentar realizar un cambio en sus parámetros. Esto se puede hacer con la operación get-config (Oper) como se muestra.

Una vez que se selecciona Run para enviar el mensaje RPC al Catalyst 3850, el Catalyst 3850 responde con la configuración de interfaz con formato YANG que muestra que el tipo de interfaz es ianaift:ethernetCsmacd.

Otros ejemplos de tipo de error RPC

1. Mensaje de respuesta de error RPC "En uso" (config-locked)

Esta es una respuesta de error de NETCONF a una solicitud <edit-config>. <error-tag> indica "in-use". La respuesta indica que el dispositivo servidor (Catalyst 3850) NETCONF que ejecuta el almacén de datos está bloqueado actualmente y que la operación NETCONF <edit-config> no se pudo realizar en este momento. Esto no indica un error en la implementación de la interfaz NETCONF. Si un cliente NETCONF intenta escribir en el almacén de datos en ejecución de NETCONF cuando el almacén de datos está en uso, el cliente recibe esta respuesta RPC. El cliente NETCONF puede reintentar el mensaje edit-config de NETCONF. Esta respuesta se puede recibir cuando el dispositivo está realizando una operación interna "sync-from-device" para sincronizar el NETCONF que ejecuta el almacén de datos con la configuración IOSd del dispositivo.

Respuesta NETCONF del servidor (Catalyst 3850) al cliente (plataforma de administración centralizada (portátil)).

<?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. Mensaje de respuesta de error RPC "Data-missing"

En este ejemplo, se envió un <edit-config> RPC al Catalyst 3850 para una interfaz de loopback que no se configuró. Se devolvió un error porque no puede configurar una interfaz que no existe en el 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. Falta el mensaje de respuesta de error RPC del modelo de datos

Si se realiza una solicitud para un modelo de datos que no existe en el Catalyst 3850 o una solicitud para una hoja que no está implementada en un modelo de datos, el servidor (Catalyst 3850) responde con una respuesta de datos vacía. Debe ocurrir lo siguiente.

Sugerencia: Utilice la funcionalidad de funciones de NETCONF para determinar qué modelos de datos son compatibles con el software Catalyst. Consulte la sección 2 de Configuración de la plataforma de gestión centralizada (portátil).

<?xml version="1.0" encoding="utf-8"?>

<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>

4. Mensaje de respuesta de error RPC "Invalid-value"

En algunos casos, un mensaje NETCONF puede contener contenido válido según los modelos de datos YANG; sin embargo, el dispositivo (Catalyst 3850) no puede implementar lo que se solicita. Cuando la interfaz NETCONF en el Catalyst 3850 envía configuraciones a IOSd que IOSd no puede aplicar correctamente, se devuelve una respuesta de error RPC específica al cliente NETCONF.

En este ejemplo, se envía un valor de registro almacenado en buffer no válido de falsos en el mensaje RPC al Catalyst 3850. La etiqueta de error en la respuesta del Catalyst 3850 indica un valor no válido. El mensaje de error indica que el Catalyst 3850 IOS Parser no pudo configurar el nivel de severidad de registro almacenado en buffer en falso ya que este no es un valor válido.

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