El viaje de un ingeniero de red hacia la automatización no es algo nuevo, sino que se ha estado gestando desde prácticamente la aparición de las tecnologías de networking. En algunos entornos se ha llegado a percibir la automatización como una amenaza para el ingeniero de red cuando es todo lo contrario, una ayuda en su día a día.
En estos últimos tiempos el acrónimo SDN (Software Defined Networking) se ha convertido en la palabra mágica que inunda los portfolios de todos los fabricantes de equipamiento de comunicaciones. Uno de los motivos es automatizar las infraestructuras de comunicaciones. Pasar de un paradigma de plano de control distribuido a un plano de control centralizado que orqueste las infraestructuras de comunicaciones.
Una de las motivaciones de la utilización de este tipo de tecnologías es automatizar las operaciones en la red: provisiones en la red, obtención de datos de uso, despliegue de nuevo equipamiento. Tal es así que en algunos entornos se llega a identificar automatización con estas tecnologías, cuando la realidad es que la relación entre ambas no es biyectiva: las tecnologías SDN utilizan automatización, pero la automatización no tiene por qué ir de la mano de SDN.
La RAE define automatizar como “Convertir ciertos movimientos en movimientos automáticos o indeliberados”. Dentro del entorno de las comunicaciones esto se traduce en la identificación de tareas repetitivas y aplicar los mecanismos y herramientas que permitan una ejecución mecánica de las mismas.
Si bien existen y han existido herramientas comerciales para la industrialización y automatización de tareas en redes de comunicaciones, éstas son adecuadas para entornos estables de producción o con poca variabilidad. En proyectos de ingeniería en los que prima la eficiencia en la ejecución de los cambios, bien sea sustitución de equipamiento, bien diseño y despliegue de nuevo equipamiento, bien probar a la recepción del equipamiento que este funciona correctamente, etc… la utilización de las herramientas tradicionales no es ni eficiente ni efectiva.
Habilidades de automatización en los ingenieros de red
Es en este punto cuando se ponen en valor las habilidades del ingeniero de red para conseguir minimizar el tiempo necesario para ejecutar las diferentes tareas.
La adquisición de las habilidades de automatización en los ingenieros de red no nace principalmente como una necesidad del mercado, sino más bien como una inquietud de los propios ingenieros. Esta situación se refleja bien en este gráfico clásico de Internet:
A los ingenieros les motiva realizar tareas diferentes, que supongan un reto. Se puede incluso decir que ese tipo de tareas les divierte. Cuando un ingeniero tiene que realizar tareas repetitivas va a buscar la manera de poder minimizar el tiempo que necesita para ejecutar esas tareas. Y tenemos que reconocer que la automatización supone un reto divertido: conseguir que una tarea tediosa y aburrida se pueda realizar rápidamente y con un click.
Mas sobre la convergencia de la red y la seguridad de SASE 🏅
Para ello utilizará las herramientas a su alcance. Aquí el mayor problema con el que se encuentra el ingeniero de red es el desconocimiento de qué herramientas existen. La creciente interrelación con departamentos de sistemas y de desarrollo, el paradigma DevOps, ha facilitado el descubrimiento de este tipo de herramientas.
Si nos centramos en ejemplos concretos, dentro del mundo de las comunicaciones un caso típico es la creación de plantillas para el despliegue de equipamiento. La forma en que se realiza esta tarea ha ido variando con el tiempo:
- Inicialmente se creaban plantillas con variables que eran sustituidas manualmente o con el famoso “buscar y reemplazar”.
- Después se pasa a utilizar la funcionalidad combinar correspondencia de MS Word. En ocasiones esta aproximación provocaba algunos problemas por la conversión automática de caracteres especiales.
- En algunos casos se programaba en algún lenguaje (VisualBasic, Perl, etc…) esa combinación de correspondencia, lo que permitía dotar de mayor flexibilidad a esta tarea.
Sin embargo, esta aproximación sólo funciona bien cuando todos o casi todos los equipos y configuraciones son iguales o prácticamente iguales. En el momento en el que se introduce variabilidad en esas plantillas no queda más remedio que la intervención manual o programar ad-hoc el script que hace las plantillas.
Para solucionar este problema en particular viene en ayuda del ingeniero de red herramientas de desarrollo web tales como los lenguajes de programación de plantillas. En particular el lenguaje Jinja2, diseñado para realizar plantillas web en entornos python.
Este lenguaje permite diseñar una plantilla que se comporte de manera diferente en función de los datos que se le proporcionen. Añade el concepto de modularidad a las plantillas. Ya no es necesario tener una plantilla monolítica, sino que podemos tener pequeñas plantillas que se apliquen o no en función de los datos con los que queramos construir nuestra configuración.
La curva de aprendizaje de este lenguaje de plantillas para un ingeniero de red es muy baja. Se pueden realizar plantillas muy elaboradas sin adentrarse demasiado en las complejidades de un lenguaje de programación. Aunque Jinja2 es un lenguaje muy potente y que permite hacer virguerías, lo que realmente necesita un ingeniero de red es mucho menos: poder configurar un numero variable de elementos, tales como interfaces de red; poder aplicar o no una configuración en función de uno o varios parámetros, como aplicar configuración de BGP o no a un equipo en función de su rol en la red; etc…
La utilización de jinja2 supone una mejora en cómo se realizan las plantillas, ya que permite su industrialización y automatización.
Sin embargo, la utilización de estas plantillas, al igual que con las plantillas tradicionales, pero en mayor medida, plantea otro problema: la gestión de las versiones de las mismas.
Aprende todo sobre el rfc internet y su usos en la actualidad.
Ahora es fundamental llevar un control de estas versiones: cuál es la última versión, cuáles son las modificaciones respecto a la versión anterior, quién ha realizado las últimas modificaciones, cuál es el motivo detrás de ellas, etc…
La forma tradicional es la utilización de un criterio de nombrado manual de los ficheros de plantilla, pero esta aproximación ha traído siempre malas experiencias: versiones con nombres no consistentes, quién no ha visto plantillas con nombres del tipo “definitiva”, “última” o “final” dentro del mismo directorio. No pocas veces se ha reemplazado un fichero por otro por error, perdiéndose toda o parte de la información. Por no hablar de conflictos cuando dos personas han modificado de forma concurrente la misma plantilla.
Al rescate del ingeniero de red vuelve otra vez el mundo del desarrollo. En este entorno es fundamental el control de versiones y se han utilizado muchas herramientas de este tipo. Desde hace años la herramienta predominante es Git, herramienta desarrollada por el famoso Linus Torvalds para gestionar las versiones del kernel de Linux.
Esta herramienta nos va a solucionar los dos principales problemas:
- Nos permite tener un control de versiones. Ya no es necesario cambiar el nombre de los ficheros, es la propia herramienta la que se encarga de crear versiones y de controlar las diferencias entre las mismas.
- Trabajo en grupo: permite que más de una persona trabaje a la vez con una copia de un fichero y fusiona automáticamente todos los cambios. Sólo en caso de que dos personas hayan tocado las mismas líneas de un fichero se requerirá una intervención manual para solucionar el conflicto.
El siguiente paso en nuestro viaje es cómo obtener los datos necesarios para alimentar nuestra plantilla y generar nuestra configuración.
Un tipo de proyecto habitual en los entornos de comunicación es la sustitución o migración de equipamiento. En ocasiones este equipamiento es del mismo fabricante y en otros no, pero en todos los casos es necesario obtener los datos de los servicios en los equipos actuales para poder migrarlos a los nuevos.
Si hasta el momento se había conseguido evitar la utilización de lenguajes de programación, llegados a este momento se hace difícil no tener que adquirir unas mínimas habilidades. La mayor parte del equipamiento actual ya permite entregar datos en formatos estructurados (xml o json principalmente), pero esto no es tan habitual en equipamiento menos reciente. Esos equipos entregan texto puro y duro, por lo que en muchos casos se hace necesario tener que parsear la configuración: analizar la configuración para obtener los datos necesarios en un formato con el que podamos alimentar nuestra plantilla de configuración.
Dentro de los lenguajes de programación que se pueden utilizar destaca python. Los motivos principales son su sencillez y la cantidad de recursos y ejemplos que se pueden encontrar online. En estos momentos es el lenguaje de facto utilizado en la mayoría de las herramientas de automatización de red. De hecho, un intérprete de este lenguaje se incluye ya en los equipos de los principales fabricantes de red, como pueden ser Cisco, Juniper o Nokia.
En base a todo lo anterior ya seríamos capaces de analizar y procesar información en nuestros PCs de forma automática. Quedaría ver cómo obtener esa información de forma dinámica y también cómo volcar configuración en red de la misma forma.
Tenemos aquí tres grandes grupos de opciones:
- Utilización de herramientas embebidas en gestores de conexiones tales como secureCRT. El gran problema de esta aproximación suele ser doble:
- Muchas veces estas herramientas son propietarias y tienen coste.
- Compartir los scripts exige la utilización del mismo gestor de conexiones por parte de todo el equipo, algo que no se suele dar habitualmente.
- Utilización de herramientas desarrolladas por los fabricantes: los principales actores del sector han desarrollado librerías de python open source que pueden ser utilizadas para realizar este cometido. Ejemplos serían pyATS de Cisco o pyEZ de Juniper.
- Utilización de herramientas agnósticas de fabricante y desarrolladas por la comunidad. Aquí tendríamos a su vez dos vertientes principales:
- Ansible: herramienta de automatización generalista proveniente del mundo DevOps.
- Herramientas orientadas a red como napalm o nornir.
También te puede interesar: SASE: convergencia de la red y la seguridad 👈
De entre todas ellas destaca Ansible por los siguientes motivos:
- No es necesario tener conocimientos de programación para poder utilizarla. El resto de herramientas son librerías de python que se pueden utilizar en nuestros scripts.
- Dispone de una gran cantidad de módulos específicos para cada fabricante, desarrollados en la mayoría de los casos por esos mismos fabricantes.
- Es relativamente fácil crear nuevos módulos, programando, eso sí. Pero una vez programado el módulo cualquiera lo puede utilizar sin tener esos conocimientos de programación.
Ansible permite una gran flexibilidad en la automatización de tareas. Permite por ejemplo:
- Conectarse a un equipo y averiguar contra qué equipos establece sesiones de transporte.
- Conectarse a esos equipos y averiguar cuál es el estado del servicio según los parámetros que determinemos.
- Volcar a disco la información obtenida con el formato que más nos interese.
Este tipo de tareas hasta ahora las hacíamos de forma relativamente manual, tanto la obtención de la información como la propia correlación.
La utilización de ansible como herramienta de automatización nos permite poder replicar una tarea de forma sencilla en cualquier momento dado (por ejemplo: antes y después de realizar una intervención en la red), y además reduce los riesgos de errores que se producen entre la silla y el teclado del ordenador.
La forma en que se “programa” ansible es con los denominados playbooks: ficheros en formato yaml en los que le indicamos qué acciones queremos que realice. Embebido en ansible se utiliza jinja2 como lenguaje de plantillas. Por tanto, estos playbook también se pueden (y deben) gestionar mediante el uso de git.
No hay que olvidarse de destacar también una metaherramienta que sobrevuela a todas las anteriores: GNU Linux. Este sistema operativo permite desde sus comienzos grandes capacidades de automatización, algunas que han dado tan buenos resultados como expect, que permite realizar un diálogo con un dispositivo: yo te envío una información y ante lo que me respondes te envío otra información, y así sucesivamente. Algunas herramientas como ansible sólo funcionan sobre un kernel de Linux. Desde la introducción del Windows Subsystem for Linux (WSL) ansible se puede correr también sobre Windows, por lo que ya no hay excusa para aprender un mínimo de este sistema operativo.
También te puede interesar: Massive MIMO en redes 5G
Finalmente es conveniente recordar que la automatización no es un fin, sino un medio. En nuestro día a día antes de empezar a ejecutar una nueva tarea debemos analizar si merece o no la pena automatizarla.
Ilustración 1 Fuente www.xkcd.com
También tenemos que tener en cuenta que la curva ideal de cuánto tiempo ahorramos con las automatizaciones no siempre se ajusta a la gráfica anterior de “geeks and repetitive tasks”. Si perdemos de vista que la automatización es un medio y no un fin esa curva se puede convertir en la siguiente pesadilla:
Ilustración 2: Fuente www.xkcd.com
Pero la única manera como ingeniero de red de llegar a la eficiencia en la automatización es comenzar el viaje… y empezar a divertirse.
Artículo publicado en la revista “A NOSA REDE” del Colegio Oficial Enxeñeiros de Telecomunicación de Galicia.