Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo configurar NETCONF/YANG en las Plataformas basadas 16.x del Cisco IOS XE. El ejemplo se centra en la prueba de laboratorio con el catalizador 3850 sin embargo, la información proporcionada también aplica al otro Cisco IOS XE 16.x las Plataformas tales como los 1000 Series Router de Cisco ASR.
NETCONF/YANG se utiliza a partir del software IOS XE 16.3.1.
Nota: No se requiere ninguna experiencia previa con NETCONF, YANG, o scripting de Python para utilizar este documento.
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
En este ejemplo un Cisco IOS XE corriente 16.3.3 WS-C3850-12X48U del conmutador solo del soporte se utiliza como el servidor NETCONF. Éste es el dispositivo se configura que y qué datos (salida del comando show) se está recogiendo vía de NETCONF/YANG.
Una computadora portátil (MacBook Pro de Apple que funciona con MaOS Sierra 10.12.2 y al navegador de Google Chrome) se utiliza como el cliente NETCONF. Actúa como la plataforma de la administración centralizada utilizando la aplicación del explorador de Yang. Es el dispositivo que crea las peticiones formatadas de YANG que se envían al catalizador 3850 vía los mensajes NETCONF RPC (llamada a procedimiento remoto) para configurar y para recoger los datos del catalizador 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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Los modelos de datos proporcionan a un suplente y a una manera centralizada de configurar los dispositivos de Cisco (en vez de usar la línea interfaz (CLI) o el Simple Network Management Protocol (SNMP)) de comando cisco y para recoger los datos de funcionamiento (comandos show) de los dispositivos de Cisco. Puesto que los modelos de datos son basados los estándares el mismo procedimiento se puede utilizar para configurar o para recoger los datos de los dispositivos de no-Cisco también que les hace el ideal para clientes que apoyen a los proveedores múltiples. Una administración centralizada que la plataforma (por ejemplo una computadora portátil) se puede utilizar para configurar o para recoger los datos de los dispositivos múltiples de Cisco y de la arquitectura del modelo de datos tiene en cuenta automatizar estos procedimientos vía scripting de Python (dos beneficios fundamentales adicionales).
YANG es un lenguaje basado los estándares del modelado de datos usado para crear los pedidos de la configuración del dispositivo o las peticiones los datos operativos (del comando show). Tiene un formato estructurado similar a un programa de computadora que sea legible. Varias aplicaciones están disponibles que puede ser ejecutado en una plataforma de la administración centralizada (por ejemplo una computadora portátil) para crear este las peticiones de la configuración y de los datos de funcionamiento.
Hay ambos modelos de datos (comunes) estándar de YANG que se aplican a todos los vendedores (por ejemplo, una petición de inhabilitar o de cerrar un interfaz de los Ethernetes debe ser idéntica para los dispositivos de Cisco y de no-Cisco) así como a los modelos de datos del dispositivo (natural, específico del vendedor) que faciliten el configurar o el recoger de los datos de funcionamiento asociados a las características propietarias del vendedor.
NETCONF es un protocolo codificado basado y del Lenguaje de marcado extensible estándar (XML) que proporciona al transporte para comunicar la petición formatada YANG de la configuración o de los datos de funcionamiento de una aplicación que se ejecute en una plataforma de la administración centralizada (por ejemplo una computadora portátil) al dispositivo de Cisco del cual un usuario desea configurar o pedir los datos operativos (del comando show). Proporciona los servicios basados transacción tales como aborto de la petición entera de la configuración cuando una porción de esa petición de la configuración falla. NETCONF utiliza un mecanismo basado simple de la llamada a procedimiento remoto (RPF) para facilitar la comunicación entre un cliente (script o aplicación de la plataforma de la administración centralizada) y un servidor (conmutador o router de Cisco). Utiliza el Secure Shell (SSH) como la capa de transporte a través de los dispositivos de red. Las operaciones algún NETCONF incluyen consiguen, los conseguir-config, los corregir-config, y RPC.
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: Ésta es la configuración completa requerida en el catalizador 3850 para utilizar el modelado de datos NETCONF/YANG pero asume que no se configura “ningún aaa de modelo nuevo” global (el valor por defecto) también. Si es deseada para activar AAA (autenticación, autorización, y estadísticas) configurando el “aaa de modelo nuevo” entonces la configuración siguiente también se requiere en un mínimo. Usted puede también ampliar esto para utilizar el AAA con un TACACS+ o una configuración de RADIUS pero ésta está fuera del alcance de este ejemplo.
aaa new-model
aaa authorization exec default local -------------> Required for NETCONF-SSH connectivity and edit-config operations
Estas configuraciones del SNMP-servidor deben ser presente para activar la generación de notificaciones NETCONF (RFC 5277 - https://tools.ietf.org/html/rfc5277) para los mensajes de Syslog y para que cualquier SNMP traps configurado también genere las notificaciones NETCONF.
Observe que mientras que éstos son el mínimo requerido, “las entradas adicionales del permiso del SNMP-servidor” pudieron estar presentes también. Un cliente (plataforma de la administración centralizada) se registra para recibir la secuencia de la notificación NETCONF de un servidor (catalizador 3850) y para enviar una suscripción específica RPC (véase la sección 3 de “configurar la plataforma de la administración centralizada (computadora 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 will be generated
snmp-server manager --------------------------------------------> enable snmp-server
Para el Syslog, esta configuración debe estar presente para el interfaz del modelo de datos (DMI) en el catalizador 3850 tener la capacidad de generar las notificaciones NETCONF definidas en el RFC 5277 cuando los mensajes de Syslog son generados por IOSd en el catalizador 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 el SNMP traps, esta configuración se requiere para generar las notificaciones NETCONF. En el software IOS-XE 16.3.1 un máximo de 10 SNMP traps se puede configurar para generar las notificaciones NETCONF pero esta restricción será quitada en una futura versión. La generación de la notificación para el SNMP traps se activa por abandono. Para inhabilitar la generación de las notificaciones del SNMP trap utilice este CLI “ninguna global-expedición del SNMP-desvío-control de netconf-Yang Cisco-ia”.
netconf-yang cisco-ia snmp-trap-control trap-list 1.3.6.1.6.3.1.1.5.3 --------> LinkDown trap
netconf-yang cisco-ia snmp-trap-control trap-list 1.3.6.1.6.3.1.1.5.4 --------> LinkUp trap
netconf-yang cisco-ia snmp-trap-control trap-list 1.3.6.1.4.1.9.9.41.2.0.1 ---> Syslog generated notification trap
La interfaz de administración GigabitEthernet0/0 del catalizador 3850 se utiliza para conectar con la red y con la plataforma de la administración centralizada (una computadora portátil será utilizada) en este ejemplo. El Protocolo de configuración dinámica de host (DHCP) se ha utilizado para asignar a la dirección IP 172.16.167.175 a este interfaz. Las configuraciones alternativas se pueden utilizar en el catalizador 3850 mientras la computadora portátil pueda alcanzar el catalizador 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 1.1.1.1 YES NVRAM up up
Vlan10 10.10.10.1 YES NVRAM up up
Vlan20 20.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
1. Del comando line interface(cli) del catalizador 3850, este comando se puede utilizar para asegurarse de que los procesos del software requeridos para utilizar el interfaz del modelo de datos (DMI) en el catalizador 3850 una vez ejecutado netconf-Yang están configurados.
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 de la plataforma de la administración centralizada. En este ejemplo, se utiliza una computadora portátil (MacBook Pro de Apple que funciona con MaOS Sierra 10.12.2) que tiene acceso a la red al catalizador 3850. Los comandos se publican de un mensaje de la terminal en la computadora portátil. No hay aplicación especial cargada en la computadora portátil a este punto.
2. Asegúrese de que la plataforma de la administración centralizada (computadora portátil) pueda alcanzar el catalizador 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 de SSH al catalizador 3850 (172.16.167.175 en este ejemplo) de la plataforma de la administración centralizada (computadora portátil) con el nombre de usuario y contraseña (cisco1/cisco1) de la configuración antedicha del catalizador 3850. La respuesta será una lista larga de capacidades NETCONF del catalizador 3850 seguido por un mensaje Hello Messages. Puerto 830 TCP = netconf-SSH.
Consejo: Si esta prueba de SSH no trabaja, asegúrese de que cualquier Firewall entre la computadora portátil y el catalizador 3850 permita el puerto 830 (RFC 4742 TCP de la referencia: https://tools.ietf.org/html/rfc4742).
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
En este ejemplo, la aplicación del explorador de Yang se utiliza en una computadora portátil (MacBook Pro de Apple que funciona con MaOS Sierra 10.12.2, al navegador de Google Chrome) para actuar como la plataforma de la administración centralizada. El explorador de Yang permite que el usuario haga esto:
• Cargue por teletratamiento/compile los modelos de datos de YANG de la interfaz de usuario o de la línea de comando
• Construya NETCONF RPC (las llamadas a procedimiento remoto)
• Ejecute el RPC contra un servidor real NETCONF (catalizador 3850)
• Salve los RPC creados a las colecciones para su uso posterior
• Hojee los árboles del modelo de datos y examine las propiedades de YANG
La transferencia directa de la aplicación del explorador de Yang, las instrucciones puestas, y la guía de usuario se pueden encontrar aquí: https://github.com/CiscoDevNet/yang-explorer.
Nota: YANG explora la aplicación también se utiliza en los sistemas Linux.
Comience la aplicación del explorador de Yang - de un mensaje terminal en la computadora portátil funcione con el comando & de ./start.sh del directorio del Yang-explorador.
Nota: Mantenga a esta sesión terminal abierta de otra manera el explorador de Yang que la aplicación cerrará y que debe ser recomenzada. También 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.
Lance el GUI del explorador de Yang - Lance el GUI de la aplicación del explorador de Yang y pegue este URL en el navegador de Google Chrome en la computadora portátil (refiera al tiro de pantalla): http://localhost:8088/static/YangExplorer.html.
Clave - Clave al GUI de la aplicación del explorador de Yang como el invitado/invitado en la esquina superior derecha del menú principal GUI de la aplicación.
Extraiga las capacidades del catalizador 3850 - ingrese los detalles del catalizador 3850 (IP address, username/la contraseña, el puerto 830 TCP para SSH-netconf) y haga clic las capacidades para extraer la lista de las capacidades operativas de YANG del software del catalizador 3850.
Consejo: Esto es también una buena prueba para confirmar que la comunicación NETCONF trabaja entre la aplicación del explorador de Yang en la plataforma de la administración centralizada (computadora portátil) y el catalizador 3850.
Modelos de datos de Yang de la carga - Los diversos modelos de datos de YANG se pueden suscribir a inferior manejan los modelos. Una vez que están suscritos, aparecen en el cuadro del explorador a la izquierda. Estos modelos de YANG permiten que la aplicación del explorador de Yang cree los mensajes formatados YANG de las llamadas a procedimiento remoto (RPC) NETCONF (que se envían al catalizador 3850 para configurarlo o para extraer los datos de él) sin la necesidad de tener experiencia profundizada de YANG. Los ejemplos de cómo hacer esto se cubren en los ejemplos operativos básicos de la siguiente sección NETCONF/YANG.
Un cliente (plataforma de la administración centralizada) se registra para recibir las secuencias de la notificación NETCONF de un servidor (catalizador 3850) enviando este mensaje formatado YANG NETCONF RPC. El catalizador 3850 envía las notificaciones NETCONF asíncronamente a cada cliente que suscriba. Antes de que usted complete esta tarea, asegúrese de que la configuración correcta exista en el catalizador 3850 utilizar las notificaciones NETCONF (véase la sección 2) de configurar NETCONF/YANG en el catalizador 3850. El servidor NETCONF (catalizador 3850) comienza a enviar las notificaciones de eventos al cliente NETCONF (plataforma de la administración centralizada) como los eventos ocurren dentro del sistema. Estas notificaciones de eventos continuarán siendo enviadas hasta que o se termine la sesión NETCONF o la suscripción termina por una cierta otra razón. Vea el RFC 5277 para más detalles relacionados con las opciones https://tools.ietf.org/html/rfc5277 de la suscripción.
<?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, usted necesita cortar y pegar esto en el GUI de la aplicación del explorador de Yang como aduana RPC
Después, ejecútese se selecciona para enviar el mensaje de la aduana RPC al catalizador 3850 vía NETCONF. Las contestaciones del catalizador 3850 detrás con un mensaje aceptable para dejar al usuario saber que la operación era acertada.
Nota: La versión actual del explorador de Yang usada en este ejemplo no tiene una opción para mirar las notificaciones recibidas NETCONF. Se salvan típicamente en una clave clickable de la notificación el menú principal de la aplicación.
Ahora que el catalizador 3850 y la plataforma de la administración centralizada se configuran y han comenzado a comunicar, deja la mirada en algunos ejemplos operativos básicos.
Los ejemplos demostrarán que YANG formató los mensajes NETCONF RPC enviados vía NETCONF del explorador de Yang de la plataforma de la administración centralizada (computadora portátil) que la aplicación al catalizador 3850 es convertida al Cisco IOS estándar CLI por el proceso del software del confd en el catalizador 3850. También, los datos del Cisco IOS CLI (datos del comando show) son convertidos a los datos formateados de YANG por el proceso del software del confd en el catalizador 3850 antes de que se envíen como mensaje NETCONF RPC a la aplicación del explorador de Yang de la plataforma de la administración centralizada (computadora portátil). Esto significa que el CLI regular se puede todavía utilizar en el catalizador 3850 para configurar el conmutador y para recoger los datos del comando show además del uso NETCONF/YANG de hacer lo mismo.
La operación deseada se puede seleccionar de la sección del explorador del lado izquierdo del GUI de la aplicación del explorador de Yang. En este caso, los datos del nombre del interfaz deben ser extraídos del catalizador 3850 y así que se selecciona la operación (para la operación) siguió por los conseguir-config bajo nombre del interfaz cae abajo. El RPC se selecciona después para generar el NETCONF (legible) formatado YANG RPC que se requiere ser enviado al catalizador 3850 vía NETCONF para extraer estos datos del catalizador 3850.
Después de que se genere el mensaje formatado YANG NETCONF RPC, ejecútese selcted para enviarlo al catalizador 3850. El catalizador 3850 contesta con una lista (legible) formatada YANG de los nombres del interfaz del catalizador 3850 (GigabitEthernet1/1/1, GigabitEthernet1/1/2, etc).
La operación deseada se selecciona del lado izquierdo de la sección del explorador del GUI de la aplicación del explorador de Yang. En este caso, configurar un interfaz (que cierra un interfaz) se requiere en el catalizador 3850 y así que los Config (para la configuración) selcted siguió por los parámetros del funcionamiento requeridos bajo interfaz los menúes de persiana. El RPC se selecciona después para generar el NETCONF (legible) formatado YANG RPC que se requiere ser enviado al catalizador 3850 vía NETCONF para ejecutar la tarea de configuración.
Después de que se genere el mensaje formatado YANG NETCONF RPC, ejecútese se selecciona para enviarlo al catalizador 3850. El catalizador 3850 contesta con un mensaje (legible) formatado YANG que estado que la operación de la configuración era acertada (aceptable).
Para confirmar que ocurrió el cambio la configuración puede ser controlado. Una operación de los conseguir-config (operación) puede ser utilizada donde el catalizador 3850 contesta detrás que el interfaz GigabitEthernet 1/0/16 configuración “ha activado = falso” ahora que significa que el interfaz fue cerrado.
Consejo: En el general cuando no está claro qué formato los valores deben ser en la sección del explorador de la aplicación del explorador de Yang, vaciar la configuración formated YANG del catalizador 3850 como se muestra es una buena manera de determinar cuáles son antes de que una tentativa se haga para modificarlos. El Lado derecho de las pantallas abajo proporciona a algunas descripciones y dependencias para estos valores también en la propiedad y las columnas de valor.
Después de que se genere el mensaje formatado YANG NETCONF RPC, ejecútese se selecciona para enviarlo al catalizador 3850. El catalizador 3850 contesta con un mensaje formateado de YANG que estado que el interfaz GigabitEthernet 1/0/16 configuración ha activado = falso ahora que significa que el interfaz fue cerrado.
A la hora de la operación anterior del cambio de configuración del explorador de Yang, esto se hace salir del CLI del catalizador 3850. El interfaz GigabitEthernet 1/0/16 no era en el valor por defecto ningún estado de cierre normal hasta que el mensaje NETCONF RPC se reciba como se ve en el mensaje de registro en el catalizador 3850. Después de que se reciba el mensaje NETCONF RPC que contiene la petición formatada de YANG a la parada normal el interfaz, se completa la operación, el interfaz es parada normal, y la configuración corriente se modifica para reflejar esto. Esto también demuestra cómo el proceso del software del confd en el catalizador 3850 convierte el mensaje formatado YANG recibido NETCONF RPC en el Cisco IOS estándar CLI. Esto significa que un usuario puede todavía utilizar el Cisco IOS regular CLI para modificar la configuración y para ejecutar los comandos show además de usar 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 no se ha guardado (copiado de la configuración corriente a la configuración de inicio) en el catalizador 3850 todavía.
3850-1# show startup-config | begin 1/0/16
interface GigabitEthernet1/0/16
!
La configuración corriente se puede guardar a la configuración de inicio en el catalizador 3850 enviando este mensaje formatado YANG NETCONF RPC al catalizador 3850 vía 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="http://cisco.com/yang/cisco-ia"/>
</rpc>
Se hace esto cuando usted corta y pegar esto en la aplicación del explorador de Yang como aduana RPC.
Ejecutado se selecciona para enviar el mensaje de la aduana RPC al catalizador 3850 vía NETCONF. El catalizador 3850 contesta detrás con un mensaje acertado.
La configuración de inicio ahora hace juego la configuración corriente:
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
!
Según lo mencionado previamente, el catalizador regular 3850 CLI se puede todavía utilizar para configurar el conmutador y para recoger los datos del comando show además de usar NETCONF/YANG para hacer lo mismo. Cuando el catalizador 3850 CLI se utiliza en vez de NETCONF/YANG para configurar el conmutador el nuevo ejecutar-config se sincroniza con el interfaz del modelo de datos (DMI) en el catalizador 3850 vía el proceso del software del 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 will 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 del explorador de Yang pide una copia de la configuración de la interfaz después de que el cambio CLI, el cambio se refleje correctamente en la salida de YANG.
Ejecutado se selecciona para enviar el mensaje de los conseguir-config RPC para GigabitEthernet1/0/16 al catalizador 3850 vía NETCONF. El catalizador 3850 contesta detrás con la configuración de la interfaz GigabitEthernet1/0/16 que muestra que activado = verdad.
Los datos MIB SNMP que se pueden devolver con NETCONF CONSIGUEN las operaciones no son usuario configurable. Todos utilizaron el MIB SNMP que se convierte en los datos estructurados definidos por los modelos de datos de YANG es parte del software IOS-XE en el catalizador 3850. Para descubrir qué datos MIB están disponibles en las peticiones get allí sea tres opciones expuestas. Todos MIB utilizado incluirán smiv2 en la respuesta de la capacidad.
Opción 1. El botón de las capacidades se puede seleccionar en el GUI de la aplicación del explorador de Yang. El catalizador 3850 contesta detrás con su lista de la capacidad que contenga las entradas de MIB smiv2.
Opción 2. Este mensaje formatado YANG NETCONF RPC se puede enviar al catalizador 3850 vía NETCONF para extraer la lista de las capacidades que incluye los modelos disponibles MIB smiv2.
<?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>
Se hace esto cuando usted corta y pegar en la aplicación del explorador de Yang como aduana RPC.
Ejecutado se selecciona para enviar el mensaje de la aduana RPC al catalizador 3850 vía NETCONF. El catalizador 3850 contesta detrás con una lista de la capacidad que incluya el MIB smiv2 utilizado.
Opción 3. Una lista de modelos disponibles MIB se puede ver en las capacidades y el mensaje Hello Messages NETCONF devueltos por el catalizador 3850 en respuesta a una conexión SSH de la plataforma de la administración centralizada (computadora portátil).
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
Este link contiene los ficheros adicionales del modelo de datos de YANG. Estos ficheros permiten que las operaciones adicionales sean ejecutadas vía NETCONF/YANG tales como el cual se relacione con otras características del catalizador 3850 para configurar el unicast IPv4 que encamina, QoS, el etc.
https://github.com/YangModels/yang
El estándar (campo común, Internet Engineering Task Force (IETF)) los modelos que se aplican a todos los vendedores pueden ser encontrados seleccionando el estándar, IETF, RFC. Esto proporciona a los modelos de datos basados los estándares de YANG tomados de las publicaciones RFC por el cuerpo de estándares IETF.
https://github.com/YangModels/yang/tree/master/standard/ietf/RFC
Los modelos nativos de Cisco (dispositivo, específico del vendedor) pueden ser encontrados seleccionando al vendedor, Cisco, xe, 1632. Esto proporciona a los modelos de datos propietarios de YANG para la versión 16.3.2 del Software Cisco IOS XE para el catalizador 3850.
https://github.com/YangModels/yang/tree/master/vendor/cisco/xe/1632
Estos ficheros se pueden descargar sobre la plataforma de la administración centralizada (computadora portátil) y después a su vez cargar en la aplicación del explorador de Yang. Hay dos maneras de hacer esto. El primer es cargar en los diversos ficheros del modelo de datos de YANG individualmente, los segundos es un cargamento a granel de todos los ficheros.
Consejo: http://rawgit.com/ se pudo requerir para descargar los ficheros de Github. Para descargar los ficheros del github seleccione el botón sin procesar asociado al fichero de YANG. Si un URL se da en vez de una opción de la transferencia directa del fichero, el URL se puede pegar en http://rawgit.com/ que a su vez proporcionen a una producción URL. Pegar esta nueva producción URL en un navegador debe proporcionar a la opción de la transferencia directa del fichero.
En este ejemplo cisco-ethernet.yang se ha descargado ya del github sobre la plataforma de la administración centralizada (computadora portátil). Aquí están los pasos para cargar el fichero en el GUI de la aplicación del explorador de Yang y entonces el Subscribeto él para cargarlo en la sección del explorador de la herramienta.
Consejo: Las funciones de las capacidades NETCONF se pueden utilizar para determinar qué modelos de datos son utilizados por el software del catalizador 3850. Vea la sección 2. de configurar la plataforma de la administración centralizada (computadora portátil).
Este procedimiento también se menciona en la sección 5.2.2 aquí: https://github.com/CiscoDevNet/yang-explorer.
De un mensaje terminal en la plataforma de la administración centralizada (computadora portátil - MacBook Pro de Apple que funciona con MaOS 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 de Yang ahora se consideran en el GUI de la aplicación del explorador de Yang. Los ficheros asociados a las características del interés pueden ser seleccionados cuando usted el tecleo suscribe que entonces las agrega en la sección del explorador de la herramienta.
Consejo: Las funciones de las capacidades NETCONF se pueden utilizar para determinar qué modelos de datos son utilizados por el software del catalizador. Vea la sección 2. de configurar la plataforma de la administración centralizada (computadora portátil).
Otras tareas se pueden ahora completar por ejemplo para generar el NETCONF/YANG RPC requerido para salvar la configuración en el catalizador 3850. Se hace esto cuando usted selecciona la salvaguardia-conf RPC en la sección del explorador en el lado izquierdo de la aplicación del explorador de Yang. Entonces el RPC se selecciona para generar el NETCONF formatado YANG RPC que será enviado al catalizador 3850 vía NETCONF para salvar la configuración en el catalizador 3850.
Ejecutado se selecciona para enviar el mensaje de la aduana RPC al catalizador 3850 vía NETCONF. El catalizador 3850 contesta detrás con un mensaje acertado.
Aquí están algunos ejemplos RPC para el modelo de datos cisco-ia.yang. Son notables puesto que implican las operaciones por ejemplo para salvar la configuración del catalizador 3850, para sincronizar los ejecutar-config del catalizador 3850 al almacén de datos de Interfcae del modelo de datos locales (DMI), y para reajustar el interfaz DMI en el catalizador 3850.
El primer paso es suscribir al modelo de datos cisco-ia.yang de modo que aparezca en la sección del explorador a la izquierda del GUI de la aplicación del explorador de YANG.
Una vez que el modelo de datos de Cisco-ia se amplía en la sección del explorador a la izquierda del GUI de la aplicación del explorador de YANG se consideran las diversas opciones operativas. Como un ejemplo para utilizar una de las opciones disponibles del modelo de datos cisco-ia.yang, se selecciona la operación de los salvaguardia-config y se genera el RPC asociado cuando usted selecciona el RPCBUTTON.
Después, ejecútese se selecciona para enviar el mensaje RPC al catalizador 3850 vía NETCONF. Las contestaciones del catalizador 3850 detrás con un mensaje acertado para dejar al usuario conocer la operación eran acertadas.
Todas las diversas operaciones del modelo de datos cisco-ia.yang se describen aquí:
sincronización-de - Este RPC hace el interfaz NETCONF en el catalizador 3850 sincronizar la representación del datastore NETCONF de la configuración corriente del dispositivo con la configuración corriente en el dispositivo. Ambos existen en el catalizador 3850 sí mismo.
<?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="http://cisco.com/yang/cisco-ia"></cisco-ia:sync-from>
</rpc>
El comportamiento predeterminado de este RPC es realizar los sin-valores por defecto de una sincronización que cause la salida de un comando show running-config enviado al dispositivo que se synced con el datastore NETCONF. Si los sincronización-valores por defecto están presentes, el interfaz NETCONF también lee la información de la configuración del valor por defecto proporcionada por el código de la característica. En la mayoría de los casos esta opción no se utiliza. Esto sería utilizada típicamente solamente si el usuario del interfaz NETCONF quiso utilizar el NETCONF substituye los comandos de substituir las 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="http://cisco.com/yang/cisco-ia">
<cisco-ia:sync-defaults/>
</cisco-ia:sync-from>
</rpc>
salvaguardia-config - Este RPC ejecuta un comando de la memoria de la escritura (lanzamiento-config de los ejecutar-config de la copia) de salvar la configuración corriente del dispositivo actual a la configuración de inicio de 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="http://cisco.com/yang/cisco-ia"/>
</rpc>
punto de verificación - Este RPC hace el interfaz NETCONF salvar la configuración corriente al almacenamiento permanente usando la característica incorporada del archivo de configuración de 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="http://cisco.com/yang/cisco-ia"/>
</rpc>
restauración no actualizada - Este RPC causa a interfaz NETCONF a la restauración no actualizada la ejecutar-configuración del dispositivo a una configuración corriente que fue guardada con el punto de verificación RPC o cualquier otra configuración corriente válida 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 executing the rollback)
<?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="http://cisco.com/yang/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>
invierta - Este RPC hace el interfaz NETCONF invertir para hacer IOSd invertir a la configuración activa previa inmediatamente, después de un retardo, o después de un tiempo de inactividad si no se recibe ningunas otras operaciones de la configuración.
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="http://cisco.com/yang/cisco-ia">
<cisco-ia:now/>
<cisco-ia:timer>10</cisco-ia:timer>
<cisco-ia:idle>60</cisco-ia:idle>
</cisco-ia:revert>
</rpc>
restauración - El interfaz NETCONF se puede recomenzar con este RPC. Si reinicialice es verdad, el interfaz NETCONF borra toda la información del estado que existe en el datastore programable-que se ejecuta. Si es falso (el valor por defecto) se preserva la información del estado del datastore de la configuración 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="http://cisco.com/yang/cisco-ia">
<cisco-ia:reinitialize>true</cisco-ia:reinitialize>
</cisco-ia:reset>
</rpc>
Nota: Algunas versiones de software de las Plataformas de Cisco o del Cisco IOS no pudieron utilizar todas las funciones dadas en este tiempo. Por ejemplo, cuando usted envía la restauración antedicha a un IOS que se ejecuta 16.3.3 del catalizador 3850, el error no utilizado de la “restauración” es vuelto por el catalizador 3850 a la plataforma de la administración centralizada (computadora portátil) como contestación 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="http://cisco.com/yang/cisco-ia">/nc:rpc/cisco-ia:reset</nc:error-path>
<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>
Los modelos de datos del driver de los elementos de red (NED) tales como ned.yang proporcionan a la mayoría de la potencia en términos de configuración del dispositivo de Cisco (catalizador 3850). Aquí están algunas capturas de pantalla que demuestran esto.
El primer paso es suscribir al modelo de datos ned.yang de modo que aparezca en la sección del explorador a la izquierda del GUI de la aplicación del explorador de YANG.
El movimiento en sentido vertical con las opciones disponibles en la sección del explorador en el lado izquierdo de la aplicación del explorador de YANG, GUI muestra una lista larga de características configurables del catalizador 3850 en el modelo de datos ned.yang.
Como un ejemplo, demostrate de estas capturas de pantalla cómo visualizar la configuración de la encaminamiento OSPF del catalizador 3850 después de primer enrollar abajo de la lista de opciones de configuración disponibles del modelo de datos ned.yang en la sección del explorador en el lado izquierdo del GUI de la aplicación del explorador de YANG. La ospfsub-opción está situada dentro del routeroption. Se genera el conseguir-config asociado RPC cuando usted selecciona el RPCBUTTON.
Después, ejecútese se selecciona para enviar el mensaje RPC al catalizador 3850 vía NETCONF. Las contestaciones del catalizador 3850 detrás con él son configuración de la encaminamiento OSPF.
Aquí está una extensión de la configuración de la encaminamiento OSPF vuelta por el catalizador 3850 en respuesta a la operación de los conseguir-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="http://cisco.com/ns/yang/ned/ios">
<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>20.20.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
<network>
<ip>100.100.0.0</ip>
<mask>0.0.255.255</mask>
<area>0</area>
</network>
</ospf>
</router>
</native>
</data>
</rpc-reply>
YANG formated la configuración de la encaminamiento OSPF que fue extraída del catalizador 3850 vía NETCONF es legible y hace juego se ve qué cuando usted mira la configuración del catalizador 3850 vía el catalizador 3850's CLI.
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 20.20.0.0 0.0.255.255 area 0
network 100.100.0.0 0.0.255.255 area 0
3850-1#
Si está deseado, el modelo de datos ned.yang se puede también utilizar para modificar la configuración de la encaminamiento OSPF. En este ejemplo, los nuevos parámetros de red son agregados a la configuración existente de la encaminamiento OSPF en el catalizador 3850 primero ingresando los parámetros deseados en la sección del explorador del GUI de la aplicación del explorador de Yang a la izquierda (nota que la identificación 100 del ranurador OSPF también fue entrada pero no es considerado debido al movimiento en sentido vertical de pantalla del explorador) y en seguida generando el RPC formated YANG asociado y golpean el RPCbutton.
Después, ejecútese se selecciona para enviar el mensaje RPC al catalizador 3850 vía NETCONF. Las contestaciones del catalizador 3850 detrás con un mensaje aceptable para dejar al usuario conocer la operación eran acertadas.
Esta operación NETCONF/YANG RPC para modificar la configuración de la encaminamiento OSPF vía el modelo de datos ned.yang se refleja en la configuración del catalizador 3850 según lo considerado vía el catalizador 3850's CLI. Hay también un mensaje de Syslog en el catalizador 3850 que indica que un cambio de configuración fue realizado vía 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 20.20.0.0 0.0.255.255 area 0
network 30.30.0.0 0.0.255.255 area 0 ------> new line added to OSPF configuration
network 100.100.0.0 0.0.255.255 area 0
3850-1#
Refiera a la operación de los salvaguardia-config mencionada en el modelo de datos de la sección anterior cisco-ia.yang para los detalles en cómo salvar los ejecutar-config a los lanzamiento-config en el catalizador 3850 vía NETCONF/YANG.
Yang explora el GUI de la aplicación se puede también utilizar para generar un script de Python para una operación dada NETCONF/YANG. Un beneficio fundamental de scripting de Python es que permite la orquestación y la automatización de las operaciones NETCONF/YANG.
En este ejemplo, una operación de los salvaguardia-config se selecciona en la ventana del Explorador en el lado izquierdo del GUI de la aplicación del explorador de Yang en la plataforma centralizada del managemnet (computadora portátil). Después, el botón del script se selecciona para generar el script de Python. El botón Copy Button se puede entonces seleccionar para copiar el script para poderlo a su vez pegar en un fichero que se pueda guardar en la plataforma de la administración centralizada (computadora portátil) con una extensión de archivo de Python .py. Por este ejemplo (no mostrado) este fichero se ha nombrado example.py.
Nota: En el ejemplo debajo de usar la “plataforma” pulse otra en el GUI dio lugar a un error al ejecutar el script de Python. Como consecuencia, el tipo de la “plataforma” fue cambiado al csr puesto que lo hace el router CSR de Cisco también funciona con el Software Cisco IOS XE apenas como el catalizador 3850. Hacer esto evitó el error.
Aquí está una extensión del script de Python que fue generada y entonces copia y pegó en un fichero llamado example.py en la plataforma de la administración centralizada (computadora portátil).
Nota: Los comentarios al inicio del fichero “example.py” que fue generado por el GUI de la aplicación del explorador de Yang incluyen los pasos requeridos para ejecutar el script de Python. El “payload” incluye la operación NETCONF/YANG que el script ejecutará. En este ejemplo es una operación de los salvaguardia-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="http://cisco.com/yang/cisco-ia"/>
"""
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))
Aquí está el control del catalizador 3850 CLI antes de que usted ejecute el script example.py de Python que salvará los ejecutar-config a los lanzamiento-config. A este punto el shutdowncommand está en los ejecutar-config pero no en los lanzamiento-config para el 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
!
De un mensaje regular de la terminal en la plataforma de la administración centralizada (computadora portátil), el fichero example.py de Python que fue generado por el GUI de la aplicación del explorador de Yang primero se copia al directorio de la Yang-exploración en la computadora portátil.
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$
Después, de un mensaje regular de la terminal en la plataforma de la administración centralizada (computadora portátil), se ejecutan estos dos comandos que fueron proporcionados en la sección de comentarios al inicio del fichero example.py que fue generado por el GUI de la aplicación del explorador de Yang (refiera a la sección anterior “que genera un script de Python del GUI de la aplicación del explorador de Yang”).
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 2do comando ejecuta el script example.py de Python contra el catalizador 3850 en la dirección IP 172.16.167.174 con el username/la contraseña cisco1/cisco1 vía el puerto 830 (netconf-SSH) TCP. El catalizador 3850 envía una contestación RPC de nuevo a la plataforma de la administración centralizada (computadora portátil) que la operación de los salvaguardia-config era acertada.
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="http://cisco.com/yang/cisco-ia">Save running-config successful
</result>
</rpc-reply>
USER1-M-902T:yang-explorer USER1
Aquí está el control del catalizador 3850 CLI después de que usted ejecute el script example.py de Python que guardó los ejecutar-config a los config de lanzamiento. El shutdowncommand está presente ahora en los ejecutar-config y los lanzamiento-config para el interfaz GigabitEthernet1/0/10 debido a la operación acertada de los salvaguardia-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
!
En esta sección encontrará información que puede utilizar para solucionar problemas de configuración.
El protocolo NETCONF define un conjunto de las operaciones y los mensajes que se intercambian entre el cliente NETCONF (plataforma de la administración centralizada (la computadora portátil)) y la puesta en práctica NETCONF en el dispositivo del servidor (catalizador 3850). Las operaciones de uso general NETCONF incluyen:
<get>, <get-config>, <edit-config>, y <rpc>
El formato y otros apremios en el contenido del mensaje NETCONF son definidos por los modelos de datos de YANG. El cliente y servidor NETCONF interactivo enviando los RPC.
Si hay un error en el formato del mensaje NETCONF o el contenido del mensaje no hace juego las definiciones en los modelos de datos de YANG ejecutados por el dispositivo, el servidor NETCONF en el dispositivo volverá un error RPC.
<error-type>application</error-type>
Estos errores RPC no indican que el interfaz NETCONF no está trabajando, estos errores indican que el cliente está intentando realizar una operación que no sea utilizada por los modelos de datos de YANG ejecutados en el dispositivo del servidor. Los usuarios deben revisar los modelos de datos de YANG ejecutados en el dispositivo del servidor para identificar y para resolver las causas para estos errores.
En este ejemplo un tipo de interfaz incorrecta ianaift: el fastEtherFX se utiliza para generar el mensaje formatado YANG del <edit-config> NETCONF RPC para enviar vía NETCONF al catalizador 3850.
El funcionamiento se selecciona una vez para enviar el mensaje RPC al catalizador 3850, las contestaciones del catalizador 3850 con un mensaje de error.
Aquí está el error que fue vuelto por el catalizador 3850. Note que contiene una etiqueta del error “operación-falló” y el detalle adicional que se refiere al error exponiendo “sin apoyo - el valor debe ser el ethernetCsmacd o el 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="http://www.w3.org/XML/1998/namespace">/interfaces/interface[name='GigabitEthernet1/0/16']/type: "Unsupported - value must be ethernetCsmacd or softwareLoopback"</nc:error-message>
<nc:error-info>
<nc:bad-element>type</nc:bad-element>
</nc:error-info>
</nc:rpc-error>
Después, fijemos el error especificando el ianaift correcto del tipo de interfaz: ethernetCsmacd en el mensaje RPC enviado al catalizador 3850 de modo que el catalizador 3850 conteste con un mensaje aceptable en vez de un error.
Esta vez, se ejecuta una vez se selecciona para enviar el mensaje RPC al catalizador 3850, el catalizador 3850 contesta con un mensaje aceptable para indicar que la operación era acertada.
Consejo: Cuando es insegura qué el formato correcto de los valores del explorador debe ser, la configuración que existe se puede mirar antes de que usted intente realizar un cambio a él es parámetros. Esto se puede hacer con la operación de los conseguir-config (operación) como se muestra.
El funcionamiento se selecciona una vez para enviar el mensaje RPC al catalizador 3850, las contestaciones del catalizador 3850 con la configuración de la interfaz formatada YANG que muestra que el tipo de interfaz es ianaift: ethernetCsmacd.
1. Mensaje (config-bloqueado) “normalmente utilizado” de la contestación del error RPC
Esto es una respuesta de error NETCONF a una petición del <edit-config>. El <error-tag> indica normalmente utilizado”. La respuesta indica que el dispositivo del servidor (catalizador 3850) NETCONF que el datastore corriente está bloqueado actualmente y la operación del <edit-config> NETCONF no se podría realizar en este tiempo. Esto no indica un error en la puesta en práctica del interfaz NETCONF. Si un cliente NETCONF intenta una escritura al datastore corriente NETCONF cuando el datastore es funcionando, el cliente recibe esta respuesta RPC. El cliente NETCONF debe revisar el mensaje de los corregir-config NETCONF. Esta respuesta pudo ser recibida cuando el dispositivo está realizando una operación interna del “sincronización-de-dispositivo” para sincronizar el datastore corriente NETCONF con la configuración de IOSd del dispositivo.
Respuesta NETCONF del servidor (catalizador 3850) al cliente (plataforma de la administración centralizada (computadora 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 “Dato-que falta” de la contestación del error RPC
En este ejemplo un <edit-config> RPC fue enviado al catalizador 3850 para un interfaz del loopback que no fue configurado. Un error fue vuelto puesto que usted no puede configurar un interfaz que no exista en el catalizador 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 que falta de la contestación del error del modelo de datos RPC
Si una petición se hace para un modelo de datos que no exista en el catalizador 3850 o una petición se hace para una hoja que no se ejecute en un modelo de datos, el servidor (catalizador 3850) responde con una respuesta vacía de los datos. Debe ocurrir lo siguiente.
Consejo: Utilice las funciones de las capacidades NETCONF para determinar qué modelos de datos son utilizados por el software del catalizador. Vea la sección 2. de configurar la plataforma de la administración centralizada (computadora portátil).
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
4. mensaje de la contestación del error RPC del “Inválido-valor”
Un mensaje NETCONF pudo contener en algunos casos el contenido que es válido basado en los modelos de datos de YANG, sin embargo, el dispositivo (catalizador 3850) no puede ejecutar se pide qué. Cuando el interfaz NETCONF en el catalizador 3850 envía las configuraciones a IOSd que IOSd no pueda aplicar con éxito, una respuesta de error específica RPC se devuelve al cliente NETCONF.
En este ejemplo, un valor protegido del registro inválido de falso se envía en el mensaje RPC al catalizador 3850. La error-etiqueta en la contestación del catalizador 3850 indica el inválido-valor. El error-mensaje indica que el analizador de sintaxis IOS del catalizador 3850 no podía configurar el nivel de gravedad protegido registro a falso puesto que esto 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-app-tag>http://cisco.com/ns/yang/ned/ios</error-app-tag>
<error-message xml:lang="en">inconsistent value: Device refused command "logging buffered bogus" at column 20 </error-message>
</rpc-error>
</rpc-reply>