Continuamos profundizando en los detalles técnicos de Cisco NSO y su uso en la automatización de redes. El tema de hoy es NETCONF/YANG, con respuestas a todas las preguntas sobre cuándo, dónde y cómo. Habrá muchas comparaciones con SNMP, especialmente la versión 2c, por lo que una buena comprensión de SNMP, su historia y diseño, tal vez no sea indispensable, pero definitivamente es una buena base para aprovechar al máximo este artículo sobre Cisco NSO y la automatización de redes.
¿Qué es NETCONF/YANG?
NETCONF y YANG son dos tecnologías diferentes pero interconectadas: NETCONF es un protocolo en el que nos centraremos más, y YANG es un lenguaje de modelado que se utiliza para describir los atributos que puede tener un dispositivo de red, como su configuración. A menudo se mencionan juntos en la automatización de redes porque suelen utilizarse en conjunto, pero no es un requisito.
NETCONF
NETCONF es un protocolo basado en XML que utiliza un estilo de comunicación RPC. A diferencia de SNMP, NETCONF es una sesión donde una parte se identifica como servidor y la otra como cliente. Con la función "NETCONF call home", a diferencia de SNMP (ignorando los traps por ahora), el equipo puede conectarse al sistema de gestión en lugar de ser pasivo y solo recibir conexiones. NETCONF necesita saber quién es el servidor y quién es el cliente. Cisco NSO aprovecha esta función en la automatización de redes al gestionar automáticamente el equipo que "llama a casa".
NETCONF call home tiene dos ventajas inmediatas: en lugar de perforar agujeros en los cortafuegos para el tráfico entrante en entornos seguros, la conexión puede salir. Esto hace que el sistema de gestión sea más eficiente, ya que no necesita probar conexiones con nodos inactivos que tal vez no respondan.
Las sesiones en NETCONF, ya sea que se configuren con call home o no, deben cumplir con ciertos requisitos que no están presentes en SNMP. Las sesiones deben ser autenticadas, confidenciales y, por lo tanto, cifradas, y deben garantizar tanto la entrega como el orden de los comandos enviados y las respuestas recibidas. Al igual que en HTTP, se puede enviar el siguiente comando antes de recibir la respuesta del anterior ('pipelining'), pero el receptor debe enviar las respuestas en el orden en que se recibieron los comandos. Esta es una diferencia importante con, por ejemplo, una SNMP-walk, donde los paquetes UDP pueden reordenarse sin infringir el estándar del protocolo.
Además, hay un último aspecto importante que saber sobre NETCONF, y es cómo maneja las funciones del equipo. Una sesión de NETCONF comienza con ambas partes identificándose como servidor (que recibe comandos) o cliente (que envía comandos para ejecutar). Al igual que en BGP, ambas partes anuncian qué funciones adicionales soportan, además de las funciones básicas obligatorias en NETCONF. Si ambas partes soportan una función extra, se puede usar en esa sesión. Esto es importante porque no es raro que haya equipos en el mercado que dicen soportar NETCONF pero solo tienen las funciones básicas, y a veces ni siquiera eso. Así que, aunque aparezca NETCONF en la hoja de especificaciones, siempre hay que investigar un poco más y hacer las preguntas adecuadas sobre qué soporta y qué no, algo crítico para los consultores de Cisco NSO y su trabajo en automatización de redes.
YANG
Yet Another Next Generation (YANG) es un lenguaje de modelado que se utiliza para definir dónde y cómo se manejan los datos en un sistema que utiliza NETCONF. YANG crea una estructura de árbol de datos, similar a cómo funciona SNMP. Un archivo YANG para un equipo cumple el mismo rol que un archivo MIB en SNMP, indicando dónde en el árbol se encuentra una variable de datos específica, cómo interpretarla y qué valores son aceptables o no.
Al igual que los archivos MIB en SNMP, donde la posición y el valor de la variable se convierten a formato ASN.1/SNI, los datos YANG se convierten a una representación XML del modelo cuando se transportan a través de NETCONF. Esta representación se llama a veces YIN. Este proceso es central para cómo Cisco NSO maneja las configuraciones en la automatización de redes, ya que la representación XML es utilizada por los NEDs que mencionamos en un artículo anterior.
Una diferencia importante con SNMP es que un equipo que soporta NETCONF/YANG también debe proporcionar los archivos de modelo YANG directamente desde el equipo para que un cliente NETCONF pueda descargarlos, a diferencia de SNMP, donde los archivos MIB a veces solo están disponibles a través del proveedor y no son públicos.
¿Por qué NETCONF/YANG?
Con lo explicado anteriormente, debería quedar claro que es una mejora con respecto a SNMP, especialmente para equipos que soportan las funciones adicionales de NETCONF, como las configuraciones candidatas y el rollback automático en caso de errores. Para los sistemas que solo soportan las funciones básicas, la gran ventaja es que la configuración puede bloquearse para otras sesiones, lo que no es posible en SNMP, por ejemplo.
Pero, como siempre, no es tan simple. Una de las mayores desventajas es que todavía existe un soporte muy variado para las funciones en los equipos que afirman tener soporte para NETCONF. Aunque esté especificado en la hoja de producto que existe una función, primero debe probarse para ver si realmente funciona en la práctica, especialmente en el contexto de la automatización de redes y Cisco NSO.
También existen tecnologías como RESTCONF, que a veces utiliza YANG pero sobre REST en lugar de NETCONF, creando un protocolo que se sitúa entre SNMP y NETCONF en cuanto a la gestión de datos.
Una última nota sobre NETCONF/YANG es que, al igual que en SNMP, se están haciendo esfuerzos para crear modelos estándar que funcionen en todas partes y con todos los proveedores. En NETCONF/YANG, estos provienen de OpenConfig, pero aunque muchos proveedores reportan soporte para ellos, termina sucediendo lo mismo que con SNMP: necesitarás usar los modelos YANG del proveedor.
Un desvío: Telemetría en streaming y alarmas
Si has leído hasta aquí, ¡primero que nada, buen trabajo! Probablemente te hayas hecho una o dos preguntas sobre las "traps" de SNMP para alarmas, ya que deliberadamente pasé por alto ese punto anteriormente. ¿Y cómo podemos recolectar métricas de los equipos que reemplazan a SNMP? Una función importante en la automatización de redes es cómo NETCONF maneja las alarmas y la telemetría, lo cual es central para Cisco NSO. En cuanto a las "traps" de SNMP, NETCONF tiene una función similar llamada "notificaciones de eventos". A diferencia de SNMP, donde los equipos envían traps a un sistema configurado sin importar si el sistema lo solicitó o incluso si existe, un cliente NETCONF se suscribe a una lista de eventos. Esta lista puede incluir desde algo específico hasta literalmente todos los eventos soportados por el equipo, y el servidor NETCONF envía notificaciones de manera similar a las traps de SNMP.
Lo mismo aplica a los datos de medición. Un cliente NETCONF puede configurar una o varias suscripciones para recibir datos del servidor, por ejemplo, la cantidad de paquetes por segundo que pasan por una interfaz. Los datos pueden enviarse a intervalos regulares, de manera similar a los tiempos de sondeo de SNMP, o se puede especificar que los datos se envíen cuando cambien, lo cual quizás no sea lo ideal para un contador de paquetes en una interfaz. Sin embargo, puede ser útil si queremos conocer la cantidad de prefijos que recibimos en una sesión BGP, algo que debería ser bastante estable si no recibimos la tabla completa sino, por ejemplo, solo una ruta predeterminada y los clientes de nuestro proveedor.
¿Necesitas ayuda para empezar con la automatización de redes y Cisco NSO?
Ya sea que necesites ayuda con el análisis, implementación o soporte a largo plazo, nuestros consultores experimentados en Cisco NSO pueden guiarte en cada paso del proceso. Con el apoyo adecuado, puedes maximizar los beneficios de la automatización de redes, reducir costos y mejorar la eficiencia general de tu red. ¡Contáctanos hoy para saber cómo podemos ayudar a tu empresa a tener éxito con la automatización de redes y Cisco NSO!
Comments