Hace muchos años conocí GNS3, un emulador que permitía ejecutar imágenes de sistemas operativos originales de equipos Cisco, lo cual me pareció la locura en su momento, además que alguna vez llegué a conectar un enrutador real con mi PC y establecer una sesión OSPF: Wow! Jajaja. De eso han pasado 10 años ya y al día de hoy me sorprende mucho más ver cómo ha evolucionado ese territorio: Cisco trazó una estrategia de virtualización y su primer paso fue una línea de IOS nueva que se ejecuta sobre Linux, no emulables en el clásico hipervisor Dynamips. Ahora GNS3 no sólo puede emular el clásico IOS de antaño, también las nuevas versiones XE, XR, equipos de otras marcas como Juniper, Alcatel-Lucent e imágenes casi arbitrarias de sistemas basados en Linux. Con la misma base tecnológica, pero en otra filosofía, apareció hace pocos años un proyecto llamado UNetLab que ahora se ha transformado en EVE-NG o Emulated Virtual Environment, un poderoso contrincante para GNS3. A continuación una breve introducción a esta plataforma de emulación. Disfrútenlo.

Introducción

Para quien no sepa qué es GNS3, le recomiendo que lea una entrada anterior, muy vieja, pero que explica brevemente lo que es GNS3. Lo nuevo desde esa época es que GNS3 dejó de ser simplemente una forma de montar laboratorios virtuales para certificaciones de Cisco (CCNA/CCNP) ahora sirve para muchas marcas y, en la dinámica del software libre, se ha ido enriqueciendo con aportes de la comunidad de usuarios hasta hacerlo un poderoso emulador de casi cualquier plataforma. Al interior de GNS3 existen un par de motores de virtualización (o hipervisores) que son el corazón del mismo: Dynamips y Qemu. Éstos se encargan de recibir las instrucciones del sistema operativo a emular y traducirlas al procesador físico, de tal manera que el sistema hospedado (un IOS u otro sistema operativo) no se da cuenta que está corriendo sobre otro hardware y se ejecuta fiel a la realidad porque es un sistema operativo real y completo. Para ilustrar más claramente lo que hace Dynamis/Qemu, me referiré a un software que es más probable que ya hayamos utilizado que también nos da una idea de lo que es GNS/Eve-ng. El software en cuestión es VMWare, la aplicación más popular en temas de virtualización que existe hoy en día. Éste hace lo mismo, sólo que emula principalmente sistemas operativos de usuario o servidores. VMWare se usa principalmente en entornos de granjas de servidores sobre muchas y poderosas máquinas reales distribuyendo el hardware entre las máquinas virtuales que se estén ejecutando, usualmente servidores empresariales típicos: active directory, almacenamiento centralizado, impresión, servidor web, SAP, BPMs, etc.. El tema de la virtualización se ha vuelto muy complejo, ya tendremos tiempo para escribir/discutir más al respecto. Qué tiene que ver esta introducción con Eve-ng?, ya veremos en la siguiente sección, pero recuerden: Qemu y Dynamips son el corazón de ambas plataformas 🙂

Diferencias y similitudes de EVE-NG con GNS3

Para continuar con lo que veníamos, la introducción anterior nos refiere a elementos de GNS3, por qué?, porque son los mismos elementos estructurales de EVE. Éste también se basa en Qemu y Dynamips para emular otros sistemas operativos, en particular los de equipos de infraestructura de red. En realidad eso es lo único que veo similar, de resto ambos son muy distintos.
En cuanto a las diferencias, mientras GNS3 está diseñado para ser una aplicación visual fácil de administrar, amigable con el usuario, Eve-ng parece diseñado para entornos empresariales más grandes y con mayores prestaciones. Una crítica común en GNS3 es que traga recursos de máquina (RAM/CPU), otros ingenieros dicen que sólo se quejan quienes no saben sintonizar el sistema, pero lo cierto es que una vez crece el número de dispositivos interconectados en una topología los recursos de una máquina ordinaria, tipo PC o portátil se quedan cortos por muy sintonizado que esté el sistema. A su favor diría, que para estudiar para una certificación con menos de 10 dispositivos (cualquier CCNA o incluso un CCNP R&S) es una buena opción y se puede ejecutar en un buen portátil. La principal ventaja de GNS3 es que corre en un entorno visual como Windows (cualquiera de sus sabores).
Eve-NG es un linux, un Ubuntu sintonizado con los paquetes necesarios para ejecutar la emulación de las redes y el paquete mismo que contiene los scripts que generan una interfaz web hacia Qemu y Dynamips, en otras palabras, una vez instalado nos conectamos con el navegador y éste es la interfaz de usuario. GNS3 es stand-alone, es decir, diseñado para ser ejecutado directamente como una aplicación más de Windows/Linux. La imagen de Eve-ng viene para instalar como máquina virtual sobre VMWare (imagen .OVA) o sobre un servidor físico (.ISO). En GNS3, la propia interfaz permite agregar las imágenes de dispositivos que quiero ejecutar, en Eve la interfaz es puramente cliente, es decir, sólo permite crear topologías con las imágenes que se hayan instalado. Para hacer otra cosa que no sea crear topologías y configurar equipos de red me toca ingresar al Linux, como a cualquier servidor, y usar las herramientas de éste (ftp/ssh por ejemplo) para efectuar cambios. Eve-NG propone procedimientos de cómo y dónde almacenar las diferentes imágenes de SO en el sistema de archivos (Linux), éstos mismos procedimientos explican qué es necesario para que la interfaz web muestre cada tipo de sistema que se haya subido para poder adicionarlo a una topología.

Eve Cliente Vs Servidor

Eve Cliente Vs Servidor

Por ejemplo, si quiero crear una topología con IOS 12.4 tipo router c7200, subo el archivo a cierto directorio (en la versión actual es /opt/unetlab/addons/dynamips/) y allí le hago un procedimiento para que el sistema “lo vea” (dar permisos de ejecución a la carpeta, a los archivos y darle el nombre que los scripts van a buscar), luego de ésto, la interfaz web me muestra que esa imagen está disponible y puedo crear dispositivos de este tipo y ejecutarlos en la topología objetivo. Cada sistema tiene un procedimiento diferente y toca consultar continuamente el How-to del sitio oficial para saber bien qué hacer en cada caso. Un poco engorroso. Con GNS3 también pasa, no es fácil, pero es más fácil que Eve-NG. Una buena forma de comprender todo ésto sería usando inicialmente GNS3, poniendolo a punto y luego pasar a Eve-NG como una alternativa más poderosa cuando agotamos las posibilidades de GNS3, sin embargo, considero que no se aprovecha la capacidad de Eve-NG si no tenemos una poderosa máquina debajo, preferiblemente un servidor virtualizado.

Ventajas y desventajas sobre GNS3

Como mencionaba anteriormente, la gran desventaja de Eve, frente a GNS3 es que la forma de subir imágenes es un poco engorrosa: cada plataforma tiene un procedimiento diferente, toca “untarse” con mucha consola Linux, algunos comandos son muy largos lo cual dificulta un poco el trabajo y como la plataforma no parece muy madura, a veces hay que entrar al código del sistema para ajustar algún parámetro con la finalidad de que la imagen subida se ejecute bien. La documentación tampoco me parece muy exacta y menos aún extensiva, hay más videos que textos.
De otro lado, la gran ventaja es que se puede ejecutar sobre una máquina virtual y ya está sintonizada para un mejor desempeño. Usualmente, en las empresas existen granjas de servidores con capacidades enormes y nuestra máquina no sólo puede ser un pequeño monstruo desde el principio sino que puede crecer fácilmente si vemos la necesidad: sólo agregar más CPUs/memoria/disco a la máquina virtual :). Yo no puedo decir que ésto último no es posible con GNS3, dado que éste cuenta con posibilidades de conectarse a una máquina virtual para obtener su poder de cómputo, pero no he explorado esa alternativa así que no la puedo juzgar.

Qué se puede hacer?

Tanto en GNS3 como en Eve-ng se pueden hacer las mismas cosas: emular redes complejas que corran protocolos de comunicaciones tan sofisticados como sean las imágenes de los dispositivos, es decir, podríamos tener una red de CSR1000, interconectar 10 de ellos entre sí y emular una red con segment routing (el último grito de la moda en San Francisco). Otro ejemplo que me gusta aún más: interconectar 5 CSR1000 con 5 Alcaltel-Lucent 7750 y emular L3VPNs o L2VPNs con mpls (ejemplo más terrenal). De otro lado podríamos simplemente interconectar IOs tradicionales en una topología de menos de 10 dispositivos y preparar laboratorios de CCNA o CCNP con una complejidad razonable.
Otra posibilidad poderosa de estos entornos, es conectar éstos enrutadores virtuales con redes externas reales, es decir por medio de la/s tarjeta/s de red del equipo sobre el cual se ejecutan. En la entrada original que escribí hace tanto, mostraba cómo en GNS3 se podía poner a hablar un enrutador virtual con uno real haciendo un puente (bridge) con la tarjeta de red del portátil, incluso alguna vez lo hice: ospf entre un router real y uno emulado en mi portátil =:0 si eso lo ponemos en perspectiva en Eve-ng, vemos que es mucho más poderoso: podríamos conectarlo a una red real con servidores reales y hacer la autenticación en el AAA real de la empresa, o conectar un firewall e interceptar tráfico desde/hacia los enrutadores reales para simular, por ejemplo, una estrategia de balanceo de carga hacia internet. Estas técnicas son lo que actualmente denominamos VNF (Virtual Network Functions) y es prima hermana de SDN (Software-Defined Networking), que en un futuro abordaré en este blog. En fin, las posibilidades son casi infinitas y la industria lo sabe.

Topología de ejemplo

En mi anterior empleo, en uno de los operadores móviles más grandes de México, monté un Eve-NG para hacer pruebas de concepto de las tecnologías que se estaban desplegando. En particular se realizaron pruebas de concepto de Segment-routing que es la nueva arquitectura de MPLS para carriers, Inter-AS option B/C entre otros. Una tarea común era probar los scripts previamente a la ejecución de las ventanas de mantenimiento con el fin de que no sacaran problemas básicos como sintaxis, si quisieramos ser estrictos podríamos montar una versión miniatura de la topología a afectar y mirar el impacto operativo de nuestros comandos pero ya se imaginarán que eso no es tan fácil y no lo hacíamos con tanta frecuencia. Lo más interesante fue trabajar con imágenes de equipos potentes como ALU VSR integrados con capacidades iguales a los de sus versiones físicas 7750. Yo personalmente aprendí mucho de ésta última plataforma usando Eve-NG. Finalmente y lo más interesante que probé sobre este emulador fue un orquestador de Cisco llamado NSO, que me permitía crear modelos de servicios y desplegarlos en una red emulada como si fuera una red real. Más adelante les escribiré más sobre SDN y sobre éste orquestador de Cisco, pero por lo pronto, les aseguro que Eve-NG fue una herramienta super poderosa en el aprendizaje y despliegue de ésta herramienta.

La siguiente imagen es la topología con la que estudiaba Cisco NSO, si se fijan en los nombres de los dispositivos, había casi todos los tipos de plataformas: ALU, IOS clásico, IOS XE, IOS XR, ASA y Nexus, adicionalmente habían dos servidores Linux: un Lubuntu que me permitía acceder a la web del otro y el otro un Red Hat que ejecutaba NSO y que me permitía desplegar servicios sobre la red emulada.

Topología NSO

Topología NSO

Esta topología fue configurada manualmente y todos los dispositivos se veían entre sí en capa 3, luego mediante NSO yo podía, digamos, crear una VRF y enviarla a los diferentes dispositivos sin importar la marca (previa creación de un mapeo de Yang a CLI usando XML). Para éste tipo de topologías y con de 5 a 10 personas creando topologías similares, usamos un servidor virtualizado de 32 CPUs, 64GB de RAM y un disco duro de 512GB, lo cual no es tan grande como pensaríamos y aún así, logré ver más de 30 dispositivos corriendo simultáneamente (no en una sola topología), llegando al límite en CPU y Memoria. El DD siempre estuvo bien de capacidad a pesar de que yo subí algunas imágenes que nunca se usaron. Hay que tener en cuenta, que las imágenes que ejecutabamos eran principalmente routers virtuales equivalentes a routers carrier-grade ALU7750, ASR9K y NCS5K, así como servidores Linux RHEL7 corriendo NSO. En realidad se exprimió bastante la capacidad que nos dieron.

Resumen y conclusiones



Como ven, Eve-ng es una versión de mayor envergadura que GNS3, sin demeritar el último al cual me falta explorarle todas sus posibilidades. Ambos se basan en los mismos hipervisores: Qemu y Dynamips, GNS3 está hecho para ser una aplicación stand-alone e Eve para ser un sistema operativo completo sintonizado para buen desempeño de la plataforma de emulación. Tanto GNS3 como Eve permiten casi lo mismo, con la diferencia de que el último es más escalable que el primero aunque su desarrollo no está muy maduro, cosa que GNS3 sí tiene. Esperen en un futuras entregas tutoriales de cada plataforma y consideren esta como la introducción de una serie de publicaciones sobre éstas dos poderosas herramientas del mundo del networking y amigas estratégicas en el camino de muchas certificaciones, en particular las de Cisco. Gracias por leer y compartir.

Tags: , , ,

Deja un comentario