Continuando con nuestra serie de emulación de redes, vamos a finalizarla hablando de las imágenes y la puesta a punto de nuestro servidor. En ésta ocasión vamos a subir imágenes y dejarlas funcionando para su uso posterior, por ejemplo para hacer prácticas de CCNA/CCNP o crear escenarios piloto en algún carrier u operador . Disfrútenlo.
Todas las entradas de la serie: [Introducción a Eve-NG] [Instalación] [Puesta a punto]
Introducción
Si es la 1ra vez que lees mi blog, te recomiendo empezar bien: ésta es la 3a publicación en una serie sobre Eve-NG, así que te recomiendo leer las anteriores antes de continuar. Para contextualizar, Eve-NG es un emulador de redes de gran escalabilidad que actualmente se está usando en entornos educativos y productivos en todo el mundo. Yo personalmente lo he usado en un entorno de producción en el cual los ingenieros prueban sus configuraciones antes de ponerlas en MOPs (method of procedure) y hacer cambios en la red real. Adicionalmente, en mi organización, también se hacen pruebas de automatización y muchos de mis compañeros han hecho sus prácticas de certificación con el servidor que he puesto a punto. Una de las características que más me gustan de éste poderoso emulador, es la posibilidad de emular plataformas que no son fáciles de emular en otras plataformas, por ejemplo, enrutadores Nokia/ALU, lo que ha resultado supremamente útil en mi organización ya que los routers más importantes son de ésta marca y su configuración no es muy conocida. Si quieres saber qué imágenes soporta Eve-NG, ve la lista oficial, que usualmente se va actualizando en la medida que alguien de la comunidad o los creadores encuentran la forma de agregar una imagen nueva.
Familias de imágenes
Si fue curioso e ingresó a la lista oficial de imágenes soportadas, sabrá que son muchas y muy variadas. La pregunta clave ahora es: ponerlas en eve es igual para todas? La respuesta es NO, para nada! Jajaja
Eve tiene tres formas de emular imágenes: mediante KVM/qemu (el método más poderoso), Dynamips (el antiguo motor de GNS3) y IOL. Brevemente, KVM significa Kernel-based Virtualization y significa que qemu publica las capacidades de virtualización mediante el kernel haciendo una virtualización muy simple y por ende casi que ofreciendo el hardware al sistema operativo ejecutado. Ésto tiene sus ventajas y sus desventajas, como ventaja es que es muy versátil en el tipo de máquina que percibe el sistema emulado, se puede controlar muy específicamente, mediante parámetros de línea de comandos qué se le ofrece a la máquina invitada. La gran desventaja es que como es línea de comandos, lanzar una máquina puede ser un comando extremadamente largo y hay que saber un poco de sistemas operativos para saber cómo dirigir los diferentes periféricos de la guest a la host, por ejemplo, cómo redirigir la consola o si va a ser gráfica, etc. Aunque Eve-NG hace casi todo por nosotros, cada imagen tiene algunos parámetros que hay que modificar para que funcionen bien, la interfaz web incluso nos permite sintonizarlos directamente cuando creamos una instancia. Quemu es la verdadera magia de Eve-NG así como de la actual versión de GNS3. Del lado de Dynamips no hay mucho que decir, Dynamips es muy conocido por GNS3 y ya sabemos que lo único que se puede sintonizar es el idle-pc que es un nro con el cual se calcula la cantidad de CPU que se le da a una imagen.
IOL merece una mención especial, éstas imágenes son privadas de Cisco y se supone que estaban restringidas para sus propios laboratorios. Yo me he topado un par de veces con cosas como éstas del lado de Cisco, por ejemplo unos poderosos generadores de tráfico que pude usar en un laboratorio de CCNP pero que nunca más los volví a usar. La virtud de las imágenes IOL son su bajo impacto en la CPU y memoria. En mi experiencia, en mi organización ejecutamos topologías muy grandes usando imágenes de IOS XE y de IOS XR, las cuales por encima de 10 routers ya casi han topado la capacidad del server (24 CPUs), de otro lado, una vez instaladas las imágenes IOL he visto topologías con 100 routers y el servidor todavía respira.
Las imágenes IOL vienen en dos sabores: L2 y L3, con las primeras se simulan switches y con las segundas routers. No he experimentado suficiente con ellas para saber qué tan completas son en términos de tecnologías que soportan, sin embargo, he leído muchos foros en las que las usan para estudiar hasta nivel CCNP, en incluso en ciertos laboratorios de CCIE en un rol limitado.
Por último y muy importante: las imágenes no son de libre distribución. Este es el principal problema de usar emuladores, en teoría, sólo mediante licencias especiales se pueden subir y usar éstas imágenes. De otro lado, conseguir las imágenes no es difícil ya que son muchos los sitios en los cuales se han colgado todo tipo de imágenes para la descarga.
¿Cómo subir las imágenes?
Ya he mencionado, que Eve-NG no incluye ninguna imagen de Sistema Operativo, por lo tanto, una vez inastalada la VM como he ilustrado anteriormente, se deben subir las imágenes que queremos ejecutar. También sabemos que Eve-ng es una VM que corre independientemente del host es decir nuestra compu real, por lo tanto, para comunicarlas es necesario establecer comunicaciones como se haría entre dos PCs cualquiera. En éste sentido hay muchas alternativas, yo usualmente instalo un servidor ftp en el host (compu real) y uso wget desde eve para «descargar» las imágenes desde nuestra compu al server, que en términos de virtualización lo llamaremos guest. Todo lo anterior opera de igual manera si el servidor es un servidor real (comunmente llamado bare metal) o está virtualizado, sólo tenemos que conocer las IPs de ambas máquinas para poder saber hacia dónde apuntar nuestras URLs o abrir las sesiones. En caso de que quieran usar este método, pueden descargar Filezilla Server en su compu real y usar wget desde eve. El problema de éste escenario es que wget está hecho para trabajar con URLs, por ende un url de imagen podría ser algo como ftp://guestUser:guestPassword@10.10.10.10/images/ios15.5.bin, no parece gran cosa, pero las imágenes usualmente no tienen nombres tan simples y la estructura de carpetas tampoco será sólo images 🙂 entonces el uso de wget se complica.
Otro mecanismo mucho más limpio es usar un cliente de sftp dado que eve ya tiene abierto el puerto de SSH y por medio de éste se puede redirigir ftp por una sesión cifrada. Una aplicación gratuita, fácil de usar y muy común es WinSCP, por lo tanto se debe descargar y pasar las imágenes desde nuestra compu al servidor como se haría en cualquier transferencia de archivos.
Existen otras formas de transferir las imágenes, por ejemplo, podemos compartir una carpeta entre el host y el guest y luego montarlas en el servidor como si fuera una usb que conectáramos. También esta conectar una USB que contenga las imágenes al guest y copiar de allí. En los casos anteriores hay que conocer un poco de la interacción de Linux y VMWare, dónde y cómo montar sistemas de archivos, etc. por lo que tampoco es un método tan limpio como pareciera en principio. En conclusión, la opción de ftp porque es más limpia, fácil de usar, genérica y funciona bien cuando el servidor está en una ubicación diferente. En mi caso particular, el servidor por estar en producción, estaba bajo ciertas restricciones de seguridad y la única manera de transferir archivos fue con éste método.
Subir una imagen de IOS clásico
Ya tendremos tiempo de discutir sobre los tipos de imágenes, por lo pronto, para laboratorios de CCNA se puede usar la imagen de C7200 para router y C3660 con una tarjeta de switching para emular los switches y su configuración. En realidad, hay muchos sitios en Internet o learning partners que han creado laboratorios para sus cursos usando exclusivamente imágenes IOL. En ésta ocasión, sólo voy a ilustrar cómo subir una imagen de C7200.
En la siguiente página hay varios enlaces para descarga de imágenes ProtechGurus, recuerden: no todas las imágenes funcionan tan fácil como las dynamips y no se puede garantizar que el enlace esté activo permanentemente. Descargue las imágenes que desee y tengalas en una carpeta antes de seguir las siguientes instrucciones.
Estos son los pasos necesarios para subir imágenes de IOS clásico:
- Tener una imagen Eve-NG instalada y operativa (apunte la IP que tiene el server). Si no lo ha hecho lea mi publicación Qué es eve-ng II: instalación paso a paso
- Descargar e instalar WinSCP
- Descargar imágenes de IOS que se quieran usar
- Subir las imágenes a la carpeta correcta de eve-ng
- Crear topologías y estudiar 🙂
De los pasos descritos, sólo uno requiere explicación: subirlos a la carpeta correcta. La mecánica de subir imágenes a Eve consiste en saber en qué carpeta subir las imágenes, cómo nombrar la carpeta (en caso de tener que crearla), cómo nombrar la imagen, luego hay que saber los parámetros adicionales que se necesitan para que la imagen funcione correctamente. Afortunadamente, las imágenes Dynamips son tremendamente fáciles de instalar porque sólo requiere subirlas y en caso de imágenes con extensión .bin, descomprimirlas. Si prefiere la fuente original, lea las instrucciones oficiales.
Como lo mencioné inicialmente, existen tres formas de emular imágenes en Eve-NG: Quemu, Dynamips y IOL, éstas a su vez son carpetas dentro del server. Para subir imágenes Dynamips se guardan en la carpeta /opt/unetlab/addons/dynamips.
Una vez que se subieron las imágenes, dado que en éste caso son .bin, es necesario descomprimirlas para su uso en las topologías (el comando en la galería que sigue). Ya que se descomprimieron se ejecuta una utilidad que todavía no comprendo muy bien qué hace pero en todos los ejemplos se utiliza, así que la usamos (yo a veces la he omitido y todo funciona). La ilustración de todos los pasos anteriores está en la galería de imágenes que les dejo a continuación:
Un ejemplo de la mecánica de Eve-NG y sus imágenes, es que por defecto, el servidor no reconoce la imagen de C3660 y, a pesar de que todo se hizo correctamente no se ve disponible. Usé un truco muy sucio que a veces funciona, que es renombrar la imagen, en éste caso cambié de 3660 por 3725, pero lamentablemente la imagen no corrió (creo que el 3725 es un switch y no un router, tal vez sea eso). Algunas veces el truco funciona, sin embargo, cada dispositivo corresponde con una plantilla que define el hardware y parámetros que ofrece quemu a la imagen, por lo tanto las probabilidades de que funcione son bajas.
Finalmente, abrimos la interfaz web de Eve, creamos un lab nuevo y creamos una topología usando nuestro nuevo router. Voalá! Tenemos un lab en el que emulamos routers C7200 con imagen 15.2 y en la cual podemos hacer capturas de tráfico entre muchas otras cosas.
Conclusiones y siguientes pasos
Sobre Eve-NG hay mucho qué decir, hemos subido las imágenes más sencillas, la familia de qemu es mucho más grande y cada marca una tiene sus particularidades, por ejemplo la carpeta dentro de addons/qemu tiene que tener un nombre específico para que se vea disponible en la interfaz web, adicionalmente cada imagen tiene parámetros como memoria, cpu o incluso parámetros de qemu que hay que pasarle para que funcione bien, por ejemplo, qué hardware debe reconocer el dispositivo. Dónde se guardan las instancias de nuestras topologías, cómo sintonizar las imágenes permanentemente, cómo crear una plantilla para un dispositivo no soportado, versión Professional, etc..
Las siguientes entradas sobre Eve serán sobre topologías útiles para estudio de CCNA y CCNP, y en un futuro cercano pienso ofrecer talleres de instalación presenciales en Ciudad de México: creando prácticas de CCNA en su propia laptop. Pronto les tendré noticias al respecto, por ahora, sigan pendientes para que vean qué más podemos hacer con Eve-NG. Si les gustó el material, por favor comenten y compartan.
Todas las entradas de la serie: [Introducción a Eve-NG] [Instalación] [Puesta a punto]