Configuración de NETCONF/YANG para plataformas Cisco IOS XE 16.X
Contenido
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.
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 formateadas 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 son estándares basados en el mismo procedimiento y se pueden utilizar para configurar o recopilar datos de dispositivos que no son de Cisco, resultan ideales para clientes que ofrecen compatibilidad con varios proveedores. Se puede utilizar una plataforma de gestión centralizada (por ejemplo, un ordenador 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 desde 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 admitir 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
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.
Nota: 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 puede 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.
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
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 y desde el directorio yang-explorer.
USER1-M-902T:~ USER1$ cd yang-explorer
USER1-M-902T:yang-explorer USER1$ ./start.sh &
Starting YangExplorer server ..
Use http://localhost:8088/static/YangExplorer.html
Performing system checks...
System check identified no issues (0 silenced).
January 19, 2017 - 23:12:20
Django version 1.8.3, using settings 'server.settings'
Starting development server at http://localhost:8088/
Quit the server with CONTROL-C.
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/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 de Catalyst 3850 (dirección IP, nombre de usuario/contraseña, puerto TCP 830 para ssh-netconf) y haga clic en Capabilities para recuperar la lista de capacidades operativas YANG del software 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 ello, debe cortar y pegar esto en la interfaz gráfica de usuario 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.
Ejemplos operativos básicos de NETCONF/YANG
Ahora que el Catalyst 3850 y la plataforma de gestió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 contesta que la configuración de la interfaz GigabitEthernet 1/0/16 ha habilitado = false ahora, lo que significa que la interfaz fue apagada.
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#
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 sincronizado.
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 RPC get-config 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 hace cuando se corta y pega 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 de 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&revision=2007-04-27</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-CONTEXT-MAPPING-MIB?module=CISCO-CONTEXT-MAPPING-MIB&revision=2008-11-22</capability>
<capability>urn:ietf:params:xml:ns:yang:smiv2:CISCO-DATA-COLLECTION-MIB?module=CISCO-DATA-COLLECTION-MIB&revision=2002-10-30</capability>
--snip--
</capabilities>
<session-id>2870</session-id></ hello >]]>]]>
Use < ^C > to exit
Cargar modelos de datos YANG adicionales
Este enlace contiene archivos adicionales del modelo de datos YANG. Estos archivos permiten que se ejecuten operaciones adicionales a través de NETCONF/YANG que se relacionan con otras funciones de Catalyst 3850, como la configuración de routing unidifusión IPv4, QoS, etc.
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.
GitHub Yang Modelos Árbol Maestro Estándar
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.
GitHub Yang Modelos Yang Tree Master Proveedor
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
En este ejemplo, cisco-ethernet.yang ya se ha descargado de github en la plataforma de administración centralizada (laptop). 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.
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.
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 de 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. Por 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 de ejecución del dispositivo actual 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 de reversión del RPC de reversión. Esto cancela la reversión temporizada y activa la reversión inmediatamente o restablece los parámetros para la reversión temporizada.
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>
<nc:rpc-error xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:error-type>application</nc:error-type>
<nc:error-tag>operation-failed</nc:error-tag>
<nc:error-severity>error</nc:error-severity>
<nc:error-path xmlns:cisco-ia
<nc:error-message lang="en" xmlns="https://www.w3.org/XML/1998/namespace">Reset not supported</nc:error-message>
<nc:error-info>
<nc:bad-element>reset</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
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 del 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.
Esta es una expansión de la configuración de ruteo OSPF devuelta por el Catalyst 3850 en respuesta a la operación 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 configuración de ruteo OSPF formateada en 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 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 (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 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 del Explorador Yang 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 .py de Python. Para este ejemplo, (no se muestra) este archivo se ha denominado example.py.
Esta es 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).
"""
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 punto, 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 que fue 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 [laptop]) 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 enviarlo 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.
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)
Ésta 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 de sincronización desde el dispositivo 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 RPC <edit-config> 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. Mensaje de respuesta de error RPC "Missing Data Model"
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.
<?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>
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
3.0 |
21-Dec-2023 |
Actualización de requisitos de marca, ortografía y formato. |
2.0 |
01-Dec-2022 |
PII eliminado.
Texto alternativo agregado.
Información RPC revertida corregida.
Actualizado Título, Introducción, traducción automática, gerundios, requisitos de estilo y formato. |
1.0 |
17-Sep-2021 |
Versión inicial |
Comentarios