Panorámica de la automatización en redes fijas

Durante los últimos años he aprendido que cuando se trabaja con redes que tienen miles de dispositivos es prácticamente imposible hacer las cosas manualmente (incluso con unos pocos cientos). Hay muchas tecnologías que se combinan para ayudarnos con esos trabajos y en ésta entrada deseo hacer una panorámica desde mi experiencia de lo que he visto y usado, un poco trazando lo que va a ser una serie de escritos al respecto. Recuerden: es la perspectiva del ingeniero, para los administrativos la automatización significa que la implementación se pueda hacer desde los requerimientos mismos. Eso es SDN (Software-defined Networks) y es un tema mucho más complejo. Por lo pronto disfruten ésta lectura.

Para facilitar la lectura, he dividido todo el texto en las siguientes secciones. Siéntase libre de leer por partes y revisitar cuantas veces sea necesario 🙂

• Introducción
• Gestión y operación semi-automática
• Obtener información… masivamente
• Automatizar la generación de scripts de configuración
• Testbed: prueba de concepto y despliegue
• Conclusión

Introducción

Este blog tiene por objetivo educar un poco a quienes apenas ingresan al mundo de las redes, así que voy a empezar con la definición de algunos términos y conceptos básicos importantes en el ciclo de vida de los servicios de infraestructura de comunicaciones. Si ud. tiene experiencia en un operador móvil o en un ISP/carrier omita esta sección y pase a la siguiente ya que ud. debe tener clarísimo los términos diseño, implementación, deployment y operación 🙂

Cualquier estudiante de ingeniería tiene una idea del ciclo de vida de un servicio tecnológico:

1. Análisis estratégico
2. Planeación
3. Diseño
4. Implementación
5. Despliegue
6. Operación

Alguna literatura incluye la mejora continua, que es útil como una etapa más del ciclo de vida desde el punto de vista administrativo. En breve, la primera fase de cualquier servicio es ver la necesidad y priorizar la inversión del dinero, esto lo hacen las directivas. Durante la fase de planeación, en la cual se baja el nivel de decisión, se eligen project managers o PMs para que sean un sólo punto de contacto y coordinen a todos los recursos humanos y financieros necesarios para la ejecución del proyecto. El diseño es una 1a etapa de ingeniería y se combina con planeación, incluso podríamos decir que la planeación sale del diseño mismo dado que, en principio, en el diseño se establecen las metas funcionales o los criterios de éxito. Una parte de ésta fase se refiere a elementos prácticos de la tecnología como direccionamiento IP, capacidades a desplegar/contratar, interacción con terceros, elementos de soporte y priorización de mercados u orden geográfico del despliegue. La implementación es la concreción de las tecnologías, la realización de los planes, ya todo está definido y se lidia con la puesta en operación de cada elemento coordinando todo lo que sea necesario. Al despliegue o deployment, como se acostumbra llamarlo en éste campo tan esnobista, nos referimos cuando ya se están instalando las tecnologías en su sitio e integrándolas a la red, es la ingeniería de campo y generalmente la hacen varios grupos de técnicos. Finalmente, después de que ya la tecnología está entregada comienza la operación, usualmente ésta comienza cuando un elemento es visible en una herramienta de monitoreo o gestión y ya es posible ver alarmas en caso de que ocurran fallas. Para ésto, al final del despliegue, se deben hacer pruebas de entrega que garanticen que el dispositivo opera perfectamente y cumple los objetivos o requisitos técnicos del diseño.

A partir de ésta brevísima introducción, vamos a definir otros términos más concretos, por ejemplo, comunicaciones fijas en contraposición a las c. móviles. Actualmente, dos de las más importantes industrias del sector comunicaciones son los operadores móviles y los carriers o proveedores de servicio de Internet (ISP por sus siglas en inglés). Carriers se les llama a operadores que son como ISPs de los ISPs, es decir, transportan datos entre ellos, ofreciendo redes a nivel nacional, pero principalmente accesos internacionales. Tal vez en otra entrega describa mejor la relación entre ISP y Carriers, pero por lo pronto quedemonos con la definición anterior. Gran parte de la tecnología de comunicaciones es de elementos fíjos, como routers y switches, a esta parte de la tecnología se le llama comunicaciones fijas o datacom (data communications).

En el caso de los operadores móviles, coexisten dos tecnologías muy diferentes: la telefonía móvil y todos sus elementos, por ejemplo una red de radios llamada RAN (Radio Access Network en inglés) que consiste en radios, antenas y controladoras llamadas de diferentes maneras según la generación (2, 3 o 4G, la RAN de 3G se llama UTRAN y la de 4G se llama eUTRAN), éstos se comunican con su núcleo o core (término inglés más usado), el cual está compuesto por grandes dispositivos que por su importancia siempre tienen muchos mecanismos de redundancia, tanto física como lógica. Éstos elementos de core también tienen nombres diferentes en cada generación: MSC, RNC, HLR/VLR, HSS, MME, P-GW, S-GW, entre otros, son elementos de core móvil, que a su vez lo dividen en PS o CS, que significa Packet/Circuit Switched para diferenciar que uno se comunica mediante IP, generalmente hacia Internet o servicios de datos y el otro comunica con la PSTN o la telefonía tradicional. Todo lo descrito hace parte de las comunicaciones móviles y la infraestructura fija o de datos (routers, switches y elementos de transporte -fibra, radioenlaces, dwdm, etc) son transparentes para ellos. De otro lado, las comunicaciones fijas son nuestro elemento: enrutadores y conmutadores (switches), incluyendo una parte de la que no conocemos mucho pero a la que hay que meterle un poco el diente y que finalmente por una especie de ósmosis (o fricción, no sé) terminamos conociendo, que son los elementos de acceso: fibra óptica con toda su diversidad (conectores, SFPs, longitudes de onda, distancias, potencias, etc), radioenlaces (muchas formas de conectividad inalámbrica fija) y otras tecnologías para las cuales tienen que haber especialistas, como GPON o DWDM. Finalmente, nosotros también tenemos nuestro core, que son los enrutadores más grandes que usualmente estan centralizados y entregan el tráfico al core móvil (tanto PS como CS).

En resumen, tenemos comunicaciones fijas y comunicaciones móviles, en ambos casos tenemos una red de acceso y una red de core con la posibilidad de que hayan elementos de agregación intermedios y para las cuales existen elementos de gestión y monitoreo generalmente separados. Los elementos de transporte, como fibra óptica, microondas u otras tecnologías también se les llama comunmente acceso, aunque el término, como ven, se traslapa un poco con roles en las otras tecnologías (router de acceso o radios 2/3/4G, ambos son de acceso). Como de costumbre en comunicaciones, los términos se usan indistintamente y toca poner atención al contexto para saber si se refieren a elementos IP o a elementos de transporte.

Gestión y operación semiautomática

Como ven, la arquitectura de la red depende de qué tecnología estemos hablando: móvil o fija y en las comunicaciones fijas tenemos tecnologías de transporte o acceso y las comunicaciones IP o de datos. La gestión es un punto a parte, muy importante pero el cual lamentablemente rara vez es unificado, es decir, casi siempre los fabricantes venden (o regalan) un elemento de gestión para sus propios equipos y por ende hay tantos como marcas hayan en la red. En teoría éstos equipos siempre hacen muchas cosas interesantes, no sólo informes, usualmente venden la idea de poder hacer operación y hasta despliegue de tecnologías, es decir, configurar gráficamente una comunicación lógica (o enlace) de un punto a otro con todas sus características sintonizadas con la solución sin tocar una consola. Eso nunca se logra porque es muy difícil saber operar varias plataformas, hacerlo mientras se atienden las emergencias que ocurren normalmente en cualquier red y además conociendo a fondo los detalles de una operación que en sí ya combina los conceptos de todas las tecnologías (acceso, transporte, core móvil y core fijo). El monitoreo y parte de la operación se logra, los elementos de gestión con frecuencia facilitan las actualizaciones, guardar copias de configuraciones, monitorizar los elementos y generar alarmas que es lo más importante y útil. De otro lado, cuando se trata de obtener informes muy especializados a veces es muy complejo tanto por el hecho de que quienes operan las herramientas de gestión no tienen buena formación o no tienen el tiempo para hacer lo que se necesita para sintonizar un informe particular. Casi todas las plataformas de gestión cuentan con lenguajes propios para obtener casi cualquier información que necesitemos, pero es muy poco común que exista personal dedicado a ese tipo de operaciones, entre otras cosas porque tampoco son tareas de todos los días. La gestión es un mal necesario, porque permite operar, pero los jefes creen que con ella se puede obtener cualquier cosa sin mayor esfuerzo pero en realidad eso es prácticamente imposible y ahí aparece nuestra necesidad como ingenieros de planeación o de ingeniería de crear nuestros propios mecanismos, precisamente aquellos que me propongo describir en el resto de este artículo (y subsiguientes).

Obtener información… masivamente

Una de las principales necesidades que tenemos con frecuencia es obtener información específica de los dispositivos de manera directa, a veces la información que nos dan los elementos de gestión no está actualizada o no tiene lo que necesitamos… o somos muy desconfiados 🙂 . Para cierta operación puede ser necesario, por ejemplo, verificar la versión de hardware de cierto tipo de tarjetas, la gestión nos ofrece la versión del SO, pero considerando el tiempo que tarda discutir qué se quiere, reunión va reunión viene o se termina el proceso de requerimiento que la burocracia exige, ya pasó una semana… cuando menos. Así que lo mejor es usar algún listado de dispositivos (usualmente sí es confiable), crear un script que se conecte a cada uno de ellos y el cual extraiga justo la información que necesitamos. Lo anterior nos garantiza que la información está actualizada, depurada, organizada como lo necesitamos y lo más importante: lo hicimos rápidamente sin mayor dependencia de otras áreas.

Esta es la forma más común de uso de la automatización y la más segura. Yo he usado scripts en python que toman un listado de IPs y ejecutan comandos sobre cada equipo, luego escriben el resultado en un archivo de Excel y de ahí se puede iniciar el análisis para el objetivo que se tenga en mente. Todo lo anterior se puede ejecutar muy rápidamente y la depuración también se puede realizar en vivo, es decir, si algo no salió bien, se puede revisar el script, corregirlo y correrlo de nuevo en un par de minutos (desde que se encuentre el problema en el script rápidamente). Otra forma de hacerlo es mediante una herramienta muy popular entre los ingenieros de comunicaciones: SecureCRT, éste programa tiene un lenguaje de scripting basado en Visual Basic que interactúa bien con las herramientas de Office, aunque en mi experiencia, es un poco más difícil de manejar que un buen programa de Python, dado que los lenguajes de scripting de las consolas usualmente son interactivas y emulan lo que escribe el usuario, por lo tanto hay que estar pendientes y evitar que, por algún motivo, algo salga mal y se ejecuten mil comandos en un contexto equivocado de tal manera que la información no sirva para nada (me ha pasado)… o peor aún generen un desastre.

Esto es lo que yo he usado y que voy a describir en futuras entradas: programas en python y scripts de la terminal, seguramente de SecureCRT.

Automatizar generación de scripts de configuración

Otra necesidad usual que he tenido es crear un script sabiendo que van a haber muchos dispositivos con una configuración similar. En éste caso la hoja de cálculo ha sido mi amiga fiel. Para ésto he usado dos estrategias, una es escribir la configuración línea a línea (script de configuración) en una hoja de cálculo que haga referencia a información en otra hoja, de tal manera que cuando tenga que cambiar el script sólo cambio la información base y ya, automáticamente puedo usar lo de la hoja inicial como script de configuración actualizado. Este mecanismo es útil cuando la cantidad de dispositivos no es muy grande y sólo quiero evitar recordar todos los comandos que usé, garantizar de esa manera que la configuración sea uniforme (muy importante a la hora de operar o entregar a operaciones).

Otra forma de usar la hoja de cálculo es, como ya lo he mencionado muchas veces, usandola para listar todos los datos específicos necesarios para ejecutar la configuración necesaria y luego usar un procesador de palabras (Word si se quiere) para generar todos los archivos de configuración. Eso lo usé en una implementación que incluía más de 200 pequeños enrutadores, cada mes entregaban datos de unos 30 equipos nuevos (nombres, direcciones IPs, interfaces a eNodesB, etc) y tocaba generar rápidamente muchos scripts que eran repartidos al personal de campo para que pudieran desplegar la tecnología eficientemente.

Por supuesto que se puede usar también un programa de python para hacer lo mismo, aunque eso no lo he hecho, la única desventaja que le veo es el hecho de que es necesario no sólo conocer un poco el lenguaje sino crear un entorno con las librerías necesarias para poder ejecutarlo luego. Sin embargo, valdría la pena intentarlo 🙂

Testbed: prueba de concepto y despliegue

Aunque hacía mucho tiempo no me acercaba a la programación y a los servidores, me ha causado mucha impresión ver cuánto han avanzado las posibilidades de emulación para casi cualquier equipo en un servidor y probar configuraciones antes de desplegarlas con un buen nivel de confiabilidad. Para ésto he usado GNS3 y actualmente estoy probando EVE-NG. También conocí una plataforma propietaria de Cisco llamada VIRL que también es muy interesante y ellos mismos ofrecen unos laboratorios en nube llamados d-cloud que también tengo por tarea estudiar. Mejor dicho, para hacer configuraciones de prueba o estudiar para alguna certificación hay unas herramientas muy poderosas actualmente. Tiempos aquellos (como 2008) en los que me asombró tanto usar GNS3 y pensé que era lo máximo.

Para aclarar un poco, GNS3, Eve-ng y VIRL son entornos virtualizados a los cuales se les suben imágenes de dispositivos (por ejemplo IOS), éstas imágenes se ejecutan como si fueran una máquina real y se interconectan virtualmente con el fin de crear una topología en la cual se configura casi cualquier cosa. Realmente me parece genial. Para el objetivo de aprender o preparar una certificación es perfecto, para hacer pruebas de concepto antes de un despliegue o una implementación es útil, para prever situaciones o tener un poco la idea de cómo va a ser el despliegue, no confiaría 100% porque las imágenes de equipos grandes suelen tener algún tipo de limitante o funcionamiento no fiel a la realidad.

Conclusión

No sé si sea muy ambiciosa esta breve introducción para las estrategias de automatización que he usado pero espero que haya sido de utilidad para quienes apenas se adentran en éste mundo. En resumen tenemos un ciclo de vida de los servicios que, para nosotros los ingenieros, se compone de planeación, diseño, implementación, despliegue y operación, las otras etapas no nos incumben (tanto). Luego tenemos comunicaciones móviles y fijas como dos grandes partes de las tecnologías de operadores móviles y finalmente las necesidades que me han hecho usar diferentes estrategias de automatización: obtener información masivamente sin involucrar a otras áreas de mi organización, crear configuraciones masivamente y probar tecnologías bien sea para estudiar o para hacer demostraciones de concepto. Gracias por haber leído hasta acá, sigan visitando regularmente, comenten y compartan. Pretendo escribir regularmente por lo menos una entrada al mes y diversificar lo que publico, no sólo lecturas, también video e incluso audios.