Repositorio Institucional de Documentos

Repositorio de la Universidad de Zaragoza – Zaguan http://zaguan.unizar.es  Proyecto Fin de Carrera Ingeniería de Telecomunicación Especialidad de Telemática Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos) Autor José Javier Serrano García Director Dr. Julián Fernández Navajas Mayo de 2013 . II III Agradecimientos Desde estas líneas deseo agradecer a la Escuela de Ingeniería y Arquitectura de la Universidad de Zaragoza, y en especial al área de Ingeniería Telemática del Departamento de Ingeniería Electrónica y Comunicaciones, la formación académica a lo largo de estos años y los medios materiales y humanos puestos a mi disposición para la realización del presente proyecto. Deseo particularizar un poco más mi gratitud a José Ignacio Mendieta, por su inestimable ayuda en el laboratorio, y a Julián Fernández Navajas, profesor en varias asignaturas de la carrera y director del proyecto. Muchas gracias Julián, por tus conocimientos, tu fantástica capacidad de síntesis y por tu paciencia. Desde un punto de vista más personal, gracias infinitas a mis cinco imprescindibles, los míos, mi familia. Suena a tópico, pero gracias por todo el apoyo, y por estar ahí arrimando el hombro cuando pintaban bastos …… IV V Resumen del proyecto El objetivo del presente proyecto es abordar el estudio de las prestaciones, posibilidades y márgenes de trabajo que en la actualidad presentan ciertas herramientas destinadas a la emulación de sistemas telemáticos, para su posterior aplicación en entornos profesionales y/o académicos. En concreto, el proyecto se centra en el análisis del entorno software de simulación/emulación constituido por GNS3/Dynamips, con base y apoyo en hardware de red Cisco Systems y sus sistemas operativos, principalmente Cisco IOS, y en menor medida Cisco CatOS. Tras los necesarios capítulos introductorios 1 y 2 de la memoria, el corazón del proyecto y la carga principal de contenidos se desarrolla en los capítulos 3 y 4 (y anexos, elaborados ex profeso para este proyecto y fundamentales en el desarrollo de los análisis). En primer lugar, el desarrollo del proyecto comienza con el proceso necesario de adquisición de habilidades de trabajo en un entorno controlado de laboratorio. Este entorno está constituido por hardware de red Cisco Systems y sus S.O., en concreto el dispositivo de red Cisco Catalyst 5500 Swicth, plataforma hardware modular presente en los laboratorios de telemática del DIEC. Se profundiza, igualmente, en el estudio de los S.O. Cisco IOS y Cisco CatOS, necesarios para configurar los equipos conforme a las arquitecturas de red planteadas en el proyecto, LAN Ethernet/VTP y WAN ppp, tanto en entornos reales como emulados. Estos análisis culminan en la elaboración del anexo 1, anexo que sirve para la configuración actual de los equipos Cisco Catalyst 5500 Swicth del laboratorio de telemática del DIEC. Seguidamente, el proyecto se centra en el análisis del entorno emulador GNS3/Dynamips. Dicho entorno software permite, fundamentalmente, emular arquitecturas basadas en hardware de red Cisco Systems, utilizando el mismo S.O. que el hardware de red real. Así, se hace necesaria la integración de los S.O. en el entorno de emulación, según detalla el anexo 3. Con ello, mediante el análisis de escenarios que emulan arquitecturas de red como LAN Ethernet /VTP y WAN ppp en GNS3/Dynamips, imagen de entornos de red reales, se pretende constatar: su usabilidad, capacidad de diseño y adquisición de habilidades propias del entorno real (para su utilidad en entornos académicos o como herramienta de análisis previo a la actuación en un entorno real de trabajo), rigor y correspondencia funcional en la emulación. Ligado a lo anterior, se busca establecer los requerimientos técnicos, capacidad y rendimiento del hardware emulador bajo sistemas operativos de usuario comunes (Windows fundamentalmente,complementado con el análisis en Linux del anexo 4), la potencial escalabilidad de las arquitecturas emuladas sujeta al consumo de recursos del sistema emulador, la influencia sobre la latencia de red emulada y márgenes fiables de trabajo Paralelamente, se acomete el objetivo fundamental y prioritario del proyecto que es el análisis de la potencial capacidad que tiene el entorno emulador de interoperar con tráfico y equipos de red reales, así como la influencia que puede tener dicha interoperación sobre un parámetro de red crítico y decisivo, como la latencia. El comportamiento de la latencia de red puede considerarse indicativo del comportamiento en tiempo real del entorno emulador. Finalmente, en el capítulo 5 se analizan los resultados obtenidos y se extraen conclusiones sobre los objetivos prioritarios y todo el trabajo desarrollado, planteando así mismo líneas futuras de trabajo y/o investigación relacionadas con este proyecto. VI VII Tabla de contenidos Capítulo 1: Introducción al proyecto. ...............................................1 1.1. Perspectiva actual del ámbito de estudio............................................1 1.2. Fundamentos y herramientas de trabajo. Objetivos del proyecto.......2 1.2.1. Adquisición de habilidades vía entorno software GNS3/Dynamips................ 2 1.2.2. Análisis del hardware de red Cisco Systems y sistemas operativos Cisco IOS y Cisco CatOS. Interoperabilidad de GNS3/Dynamips con entornos de red reales. .2 1.2.3. Extensión y aplicación al ámbito académico................................................... 3 1.2.4. Evaluación de la capacidad y rendimiento del sistema hardware emulador (PC emulador). Influencia sobre la latencia de red en la interoperación entorno real ÅÆ entorno emulado y sobre la potencial escalabilidad de las arquitecturas de red WAN ppp y LAN Ethernet/VTP............................................................................... 3 1.3. Contenido esquemático de la memoria del proyecto. Distribución de los contenidos por capítulos.........................................................................4 Capítulo 2: Consideraciones de diseño y entorno de trabajo............7 2.1. Consideraciones generales del proyecto. ............................................7 2.2. Consideraciones del entorno hardware de red Cisco Systems.............7 2.3. Consideraciones del entorno software emulador GNS3/Dynamips. ..... .............................................................................................................9 2.4. Escenario de trabajo general para el análisis. Contingencias en el diseño y soluciones adoptadas....................................................................11 Capítulo 3:Análisis de arquitecturas de red en GNS3/Dynamips....15 3.1. Análisis de la arquitectura de red WAN ppp. ...................................15 3.1.1. Consideraciones iniciales y descripción para la configuración de la arquitectura de red...................................................................................................15 3.1.2. Captura y análisis de tráfico de red emulado en el enlace serie WAN ppp...17 3.2. Análisis de la arquitectura de red LAN Ethernet / VTP ...................18 3.2.1. Consideraciones iniciales y descripción para la configuración de la arquitectura de red...................................................................................................18 3.2.2. Captura y análisis de tráfico emulado en el enlace troncal (trunk link). ...... 20 VIII Capítulo 4: Análisis del rendimiento y capacidad del sistema emulador. Relación con la latencia de red en la interoperación entorno real Æ entorno emulado....................................................25 4.1. Contexto del análisis. ........................................................................25 4.2. Análisis bajo sistema operativo Windows. .......................................26 4.2.1. Análisis del rendimiento del sistema emulador para la arquitectura de red WAN ppp................................................................................................................. 26 4.2.2. Análisis de la latencia para la arquitectura de red WAN ppp....................... 32 4.2.3. Análisis del rendimiento del sistema emulador para la arquitectura de red LAN Ethernet/VTP..................................................................................................38 4.2.4. Análisis de la latencia para la arquitectura de red LAN Ethernet /VTP.......40 Capítulo 5: Análisis final del proyecto, conclusiones y líneas futuras de trabajo y/o investigación. ...........................................................45 5.1. Conclusiones finales de los análisis de las características, rigor y correspondencia funcional de GNS3/Dynamips. Conclusiones de la interoperabilidad entre entornos de red reales y emulados........................45 5.2. Análisis de la capacidad, rendimiento y latencia de red de GNS3/Dynamips en Windows....................................................................47 5.2.1. Conclusiones a los análisis sobre la capacidad y rendimiento del sistema emulador.................................................................................................................. 47 5.2.2. Conclusiones a los análisis de la latencia de red en la interoperación entorno real ÅÆ entorno emulado......................................................................................48 5.3. Inconvenientes principales asociados al desarrollo del proyecto. Líneas futuras de trabajo y/o investigación................................................53 5.3.1. Inconvenientes principales en el desarrollo del proyecto y soluciones adoptadas................................................................................................................. 53 5.3.2. Líneas futuras de trabajo y/o investigación relacionadas con el proyecto. .. 54 Capítulo 6: Referencias bibliográficas y en línea. ..........................55 Capítulo 7: Anexos .........................................................................57 IX 7.1. Anexo 1: Configuración & gestión de plataformas hardware modulares de red Cisco Catalyst 5500 Switch (y similares)......................57 7.1.1. Introducción.................................................................................................. 57 7.1.2. Modos de operación en arquitecturas Cisco Systems. ..................................58 7.1.3. Conexión y configuración vía módulo supervisor Cisco WS-X5530-E3...... 59 7.1.4. Configuración del módulo Router-Switch Module Cisco WS-X5302........... 63 7.1.5. Configuración de Interfaces E1 en módulos Cisco 8-port Multichannel T1/E1. Uso como conmutador Frame-Relay..........................................................67 7.2. Anexo 2: Configuraciones de red para arquitecturas emuladas en GNS3/Dynamips. Interoperación entorno real ÅÆ entorno emulado......71 7.2.1. Configuración y verificación de la arquitectura de red WAN ppp.............71 7.2.2. Análisis exhaustivo del tráfico de red emulado en el enlace serie WAN ppp. .................................................................................................................................85 7.2.3. Configuración de Listas de Control de acceso (ACL)..................................87 7.2.4. Análisis del tráfico de red en el enlace equipo real 1 ÅÆ nodo virtual emulado 1 para el análisis de la interoperabilidad de los entornos de red............. 92 7.2.5. Configuraciones de red adicionales para el análisis de prestaciones y rendimiento del emulador GNS3/Dynamips en la arquitectura WAN ppp.............. 96 7.2.6. Configuración y verificación de la arquitectura LAN Ethernet/VTP........102 7.2.7. Configuraciones de red adicionales para el análisis de prestaciones y rendimiento del emulador GNS3/Dynamips en la arquitectura LAN/VTP ...........112 7.2.8. Complemento teórico-práctico a las conclusiones del proyecto................114 7.3. Anexo 3: Extracción de sistemas operativos Cisco IOS de hardware de red Cisco Systems y posterior integración en GNS3/Dynamips. Configuración básica de GNS3/Dynamips: parámetros y prestaciones fundamentales...........................................................................................121 7.3.1. Introducción................................................................................................ 121 7.3.2. Extracción del sistema Cisco IOS de dispositivos de red Cisco Systems... 121 7.3.3. Interoperación de dispositivos de red reales y emulados en GNS3/Dynamips. ...............................................................................................................................124 7.3.4. Integración de Cisco IOS en el entorno emulador GNS3/Dynamips.......... 127 7.3.5. Optimización del rendimiento de CPU: parámetro idle PC.......................130 7.3.6. Optimización del rendimiento de la memoria RAM.................................. 131 XVI Figura 7.45. Acceso al menú de configuración de GNS3/Dynamips …………………….. 128 Figura 7.46. Contexto gráfico para la verificación del path o ruta en la ejecución del proceso dynamips.exe y su directorio de trabajo temporal ……………………………. 129 Figura 7.47. Contexto gráfico para la configuración de los recursos optimizadores de la memoria RAM del sistema emulador …………………………………………………. 132 Figura 7.48. Vista detallada del directorio/carpeta creada en /home para la instalación de GNS3/Dynamips en Linux …………………………………………………………….. 133 Figura 7.49. Vista detallada de la instalación de las librerías python-qt4 ………………. 134 Figura 7.50. Contexto gráfico de propiedades del archivo binario de la emulación ….. 135 Figura 7.51. Configuración de los directorios de trabajo para GNS3/Dynamips en Linux …………………………………………………………………………………………. 136 Figura 7.52. Contexto gráfico para la verificación/configuración del path para la emulación …………………………………………………………………………………………. 136 Figura 7.53. Contexto gráfico para la la selección /configuración del interfaz Ethernet (como usuario root) en la interoperación entorno real ÅÆ entorno emulado en sistemas Linux ………………………………………………………………………………….. 137 Figura 7.54 a) Proceso para la configuración/selección del interfaz Ethernet (como usuario root) en la interoperación entorno real ÅÆ entorno emulado en sistemas Linux ….. 138 Figura 7.54b) Vista detallada del intérprete de comandos Linux de la figura 7.49a) …..……………………………………………………………………………………… 138 Figura 7.55. Arquitectura de red LAN Ethernet/VTP para analizar la capacidad y rendimiento de GNS3/Dynamips en Linux (idéntica que en Windows) ………………. 139 Figura 7.56. Topología en GNS3 de la arquitectura WAN ppp para implementar el servicio cliente/servidor FTP con los roles de servidor y cliente FTP particularizados ………... 144 Figura 7.57. Interfaz gráfico de TCPOptimizer 3.0.8 para la configuración del MTU ………………………………………………………………………………………….. 145 Figura 7.58. Topología en GNS3 de la arquitectura LAN/VTP para analizar el comportamiento del escenario de trabajo en servicios cliente/servidor FTP, con los roles particularizados de servidor y cliente FTP……………………………………………… 147 Figura 7.59. Trafico de red capturado en servicios FTP cliente/servidor (conexión equipo real 1 Æ entorno emulado Æ equipo real 2, de la arquitectura LAN/VTP) ……………. 148 XVII Indice de Tablas Capítulo 1 Tabla 1.1. Distribución del contenido de la memoria por capítulos……………………. 5 Capítulo 2 Tabla 2.1. Tabla comparativa de las prestaciones diferenciadas de GNS3 y Dynamips... 10 Capítulo 4 Tabla 4.1. Configuraciones hardware base para el sistema emulador ………………….. 26 Tabla 4.2. Consumo de recursos del sistema emulador para la configuración hardware 1, bajo S.O. Windows XP 32 bits y arquitectura de red WAN ppp ……………………..... 28 Tabla 4.3. Consumo de recursos del sistema emulador para la configuración hardware 2, bajo S.O. Windows XP 32 bits y arquitectura de red WAN ppp ……………………….. 29 Tabla 4.4. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ interfaz SVI en nodo virtual 1, para diferentes longitudes de trama y consumo de recursos del PC emulador 1 en la arquitectura WAN ppp ………………………………………… 34 Tabla 4.5. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ interfaz SVI en nodo virtual 1, para diferentes longitudes de trama y consumo de recursos del PC emulador 2 en la arquitectura WAN ppp ………………………………………… 34 Tabla 4.6). Latencia de red imputable a los procesos de emulación con respecto a la latencia total en el enlace equipo_real l (Ethernet 802.3) Æ interfaz SVI en nodo virtual 1, para la arquitectura WAN ppp, protocolo ICMP,diferentes longitudes de trama y 1 switch-router activo …………………………………………………………………. …. 35 Tabla 4.7. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ red virtual Æ equipo_ real 2, para diferentes longitudes de trama y consumo de recursos del PC emulador 1 en la arquitectura WAN ppp ………………………………………………… 36 XVIII Tabla 4.8. Latencia de red para el protocolo ICMP en la conexión equipo rea1 Æ red virtual Æ equipo real 2, para diferentes longitudes de trama y consumo de recursos del PC emulador 2 en la arquitectura WAN ppp ………………………………………………. 36 Tabla 4.9. Consumo de recursos del sistema emulador para la configuración hardware 1, bajo S.O. Windows XP 32 bits y arquitectura de red LAN/VTP ………………… …. 38 Tabla 4.10. Consumo de recursos del sistema emulador para la configuración hardware 2, bajo S.O. Windows XP 32 bits y arquitectura de red LAN/VTP ………………….. 39 Tabla 4.11. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ interfaz SVI de nodo virtual 1, para diferentes longitudes de trama y consumo de recursos del PC emulador 1 y arquitectura de red LAN/VTP …………………………………… 41 Tabla 4.12. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ interfaz SVI de nodo virtual 1 para diferentes longitudes de trama y consumo de recursos del PC emulador 2 y arquitectura de red LAN/VTP ………………………………….. 41 Tabla 4.13. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ entorno emulado Æ equipo real 2, para diferentes longitudes de trama, consumo de recursos del PC emulador 1 y arquitectura de red LAN/VTP …………………………. 42 Tabla 4.14. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ entorno emulado Æ equipo real 2, para diferentes longitudes de trama, consumo de recursos del PC emulador 2 y arquitectura de red LAN/VTP …………………………….. 43 Capítulo 5 Tabla 5.1. Conclusiones en el análisis de la funcionalidad del emulador a nivel 2 y 3, y de la interoperabilidad entre entornos de red reales y emulados ………………………….. 46 Tabla 5.2. Relación de dependencias de la latencia de red en GNS3/Dynamips ………. 48 Tabla 5.3. Conclusiones principales a los análisis de la latencia en la interoperación … 51 Tabla 5.4. Relación de dependencias de la latencia de red en GNS3/Dynamips ………. 52 Capítulo 7 Tabla 7.1. Tabla resumen de las características y prestaciones principales del protocolo VTP y que se aplican en el diseño particular del escenario de trabajo ………………… 107 XIX Tabla 7.2. Tabla resumen de ventajas e inconvenientes del emulador GNS3/Dynamips extraídas del análisis de los capítulos 3 ÅÆ anexo 2, y del análisis de la interoperabilidad del capítulo 4 …………………………………………………………………………… 115 Tabla 7.3. Consumo de recursos del sistema emulador para la configuración hardware 1, bajo S.O. Linux 32 bits y arquitectura de red LAN/VTP …………………………….. 140 Tabla 7.4. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ interfaz SVI de nodo virtual 1, para diferentes longitudes de trama y consumo de recursos del PC emulador 1, arquitectura de red LAN/VTP y sistemas operativos Linux …….. 141 Tabla 7.5. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ entorno emulado Æ equipo real 2, para diferentes longitudes de trama Ethernet, consumo de recursos del PC emulador 1, arquitectura de red LAN/VTP y sistemas operativos Linux ………………………………………………………………………………………….. 142 Tabla 7.6. Resultados obtenidos en la transferencia FTP servidor Æ cliente de archivo.rar (250KB) para distintas longitudes de trama Ethernet 802.3 en el análisis de la arquitectura de red WAN ppp ……………………………………………………………………….. 146 Tabla 7.7. Resultados obtenidos en la transferencia FTP servidor Æcliente para distintas longitudes de trama Ethernet 802.1q del enlace troncal en la arquitectura LAN /VTP... 147 XX Capítulo 1: Introducción al proyecto. 1 1 Capítulo 1: Introducción al proyecto. 1.1. Perspectiva actual del ámbito de estudio. Debido al grado de competitividad actual y la necesidad de optimizar determinadas variables asociadas al diseño del proceso productivo, como bien pueden ser los costes de producción, es necesario disponer de herramientas de trabajo adecuadas y ajustadas a los niveles de exigencia del mundo profesional/laboral. Desde la perspectiva de las comunicaciones en un entorno corporativo de mayor o menor jerarquía, el diseño y la infraestructura de la red de comunicaciones es un punto clave y ciertamente crítico para el correcto desempeño de cualquier proceso productivo. Siendo así, resulta evidente que cualquier actuación y/o actualización organizativa en la infraestructura de trabajo repercute directamente en la estructura y “rediseño” de la red de comunicaciones y su escalabilidad. Por ello, disponer de herramientas adecuadas que reproduzcan y emulen el comportamiento y funcionalidad de la red de comunicaciones del entorno de trabajo en cuestión, minimizan el impacto directo sobre los procesos de producción y costes asociados. Debe contemplarse que el empleo de cualquier herramienta de diseño y emulación que pretenda reproducir un escenario real de trabajo presenta un margen de fiabilidad que es preciso analizar, acotar y optimizar, desde el rol ejercido por un ingeniero de telecomunicación en todo el proceso anteriormente mencionado de diseño, optimización y/o actualización de la red de comunicaciones de una organización o empresa. Acorde con este objetivo, el abanico de posibilidades tecnológicas que a priori se presenta en la elección de una herramienta de trabajo idónea, se puede antojar denso y farragoso. Por ello, es necesario un riguroso análisis de las condiciones y exigencias de trabajo que se plantean: qué objetivos queremos conseguir y cómo alcanzar óptimamente los mismos. Consecuentemente, y añadido a la imposibilidad de acometer un estudio global por su profundidad, se particulariza el mismo sobre el hardware de red Cisco Systems presente en el laboratorio de Telemática del departamento IEC y las herramientas software proporcionadas por el entorno de emulación de redes GNS3/Dynamips. Así, los planteamientos anteriormente descritos son los que desembocan en la elaboración del presente proyecto que trata de analizar y extraer oportunas conclusiones acerca de la idoneidad, márgenes de aplicación y normas/recomendaciones de uso para las herramientas antes mencionadas y potencialmente empleadas en el diseño, análisis y optimización de la red de comunicaciones que toda organización precisa. Herramientas, claro está, puestas a nuestra disposición en el contexto tecnológico actual. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 2 2 1.2. Fundamentos y herramientas de trabajo. Objetivos del proyecto. Expuestas las necesidades que condicionan la elección de nuestras herramientas de trabajo, se prioriza la necesidad de disponer de un entorno software de diseño y análisis con capacidad de reproducir (rigurosamente) una determinada arquitectura de red. Estas motivaciones conducen a optar por herramientas software que aúnen características de simulación y principalmente de emulación, y con una deseable capacidad para interoperar con tráfico de red y equipos reales. El centro del análisis va a ser el entorno software conformado por el interfaz gráfico/simulador GNS3 y el software, motor de la emulación, Dynamips (integrando además la herramienta software para la captura de tráfico Wireshark). Se pretende analizar y constatar empíricamente las prestaciones, rigor y correspondencia funcional de GNS3/Dynamips con entornos de red reales, así como dimensionar y acotar márgenes fiables de trabajo. Siendo así, se consolidan los siguientes objetivos generales en el análisis del proyecto. 1.2.1. Adquisición de habilidades vía entorno software GNS3/Dynamips. Un objetivo fundamental de una herramienta software de simulación/emulación debe ser el de poder adquirir las habilidades necesarias sobre un escenario real de trabajo que permitan, llegado el momento, acometer óptimamente el trabajo de campo. Por esta razón, el conocimiento del entorno software GNS3/Dynamips, así como del sistema operativo Cisco IOS (y en menor medida Cisco CatOS [3] [16]), motor de los dispositivos de red Cisco Systems reales y emulados implicados en el estudio, es el primer objetivo y punto de partida en el desarrollo del proyecto. 1.2.2. Análisis del hardware de red Cisco Systems y sistemas operativos Cisco IOS y Cisco CatOS. Interoperabilidad de GNS3/Dynamips con entornos de red reales. Para el correcto análisis de nuestros objetivos, y en consonancia con el apartado anterior, se hace necesario un proceso de adquisición de conocimientos y habilidades del entorno hardware Cisco Systems en general, y particularmente del dispositivo de red modular Cisco Catalyst 5500 Swicth presente en el laboratorio de telemática, así como de los sistemas operativos Cisco IOS y Cisco CatOS, a él vinculados. Consecuencia de estos análisis es el anexo 1 de la memoria, que permite aplicar estos conocimientos y habilidades sobre ambos escenarios de trabajo, real y emulado en GNS3/Dynamips. El conocimiento de estos sistemas es prioritario para establecer la configuración del hardware conforme a una determinada arquitectura de red, tanto en el entorno real como en el emulado. Además, se realiza un análisis exhaustivo de la funcionalidad y rendimiento de los Capítulo 1: Introducción al proyecto. 3 3 módulos hardware Cisco WS-X5302 (que implementa funcionalidades de routing y switching a nivel 2 y 3) y Cisco WS-X5530-E3 (módulo supervisor que comporta características fundamentalmente de gestión y administración hardware), ambos módulos integrados en nuestro hardware modular Cisco Catalyst 5500 Switch del laboratorio [15][16]. El análisis de la potencial interoperabilidad de GNS3/Dynamips con hardware y tráfico de red real se plantea como objetivo prioritario del análisis a desarrollar. Para ello, el anexo 3 explica detalladamente la configuración y técnica precisas para configurar la interacción/interoperación de los entornos de red real y emulado. Seguidamente, se analiza dicha interoperación: funcionalidad, límites y correspondencia funcional del tráfico de red emulado respecto del tráfico real. En nuestro caso, los dispositivos de red emulados pretendemos que sean “imagen” de los dispositivos de red Cisco Systems disponibles (o similares) en el laboratorio de telemática. Por lo tanto, el desarrollo del proyecto analiza la emulación en cuanto a la funcionalidad y prestaciones de dichos equipos reales participantes en dos diferentes arquitecturas de red, WAN ppp y LAN Ethernet/VTP. Para proceder a la emulación de dispositivos de red Cisco Systems en GNS3/Dynamips es necesario extraer de los dispositivos de red reales su sistema operativo Cisco IOS e integrarlo posteriormente en el emulador, según se explica en el anexo 3. 1.2.3. Extensión y aplicación al ámbito académico. Hay que destacar dentro de los objetivos de estudio previamente planteados, la posible idoneidad y aplicación del entorno software GNS3/Dynamips al ámbito académico, añadido al ámbito profesional/laboral. Recordemos que GNS3/Dynamips es un entorno software que en principio presenta las mismas características y connotaciones que el entorno real emulado, extrayendo su rendimiento del mismo sistema operativo.Así, mediante el planteamiento y estudio de escenarios que emulan diferentes arquitecturas de red, el posterior desarrollo teórico y práctico de las configuraciones y parámetros de diseño de las mismas, unido al análisis del rendimiento del sistema emulador y del tráfico de red, se pretenden extraer conclusiones sobre la usabilidad y limitaciones del entorno de emulación, no sólo dentro de un marco de trabajo profesional, sino también para el ámbito académico. 1.2.4. Evaluación de la capacidad y rendimiento del sistema hardware emulador (PC emulador). Influencia sobre la latencia de red en la interoperación entorno real ÅÆ entorno emulado y sobre la potencial escalabilidad de las arquitecturas de red WAN ppp y LAN Ethernet/VTP. La línea argumental al respecto gira en torno a los equipos hardware (2 tipos de configuraciones PC diferentes) y sistemas operativos (Windows fundamentalmente y Linux) responsables de ejecutar los procesos de emulación y, llegado el momento, de la Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 4 4 interoperación entre los entornos de red real y emulado. Se pretende así evaluar la capacidad y rendimiento del sistema emulador (principalmente, la carga del procesador y la memoria RAM consumida) y las limitaciones de diseño y escalabilidad para poder ejecutar correctamente los procesos asociados a la emulación. Además, se busca establecer dependencias y relaciones entre el rendimiento asociado a configuraciones concretas del sistema emulador (PC de características hardware determinadas, con S.O Windows o Linux) para las arquitecturas de red propuestas, y su posible incidencia sobre la latencia de red a la hora de interoperar dispositivos reales y emulados. 1.3. Contenido esquemático de la memoria del proyecto. Distribución de los contenidos por capítulos. Establecida la carga teórica del análisis desarrollado, su reflejo en la presente memoria se concreta esquemáticamente en la tabla 1.1 de la página siguiente. Capítulo 1: Introducción al proyecto. 5 5 Contenidosȱȱ delȱproyectoȱContenidoȱteórico/prácticoȱdelȱcapítuloȱ ȱ Capítuloȱ1ȱxIntroducción al proyecto y objetivos del mismo. ȱ Capítuloȱ2ȱ xIntroducción teórica a los entornos controlados hardware y software del laboratorio. xEscenario de trabajo para el análisis, problemas y soluciones. Capítuloȱ3ȱ xConfiguración y análisis en el entorno emulado de las arquitecturas de red WAN ppp y LAN Ethernet/VTP relacionadas con el escenario de trabajo del capítulo 2. Primeras aproximaciones a la interoperación entorno real ÅÆ entorno emulado. xSe apoya en los anexos 1 y 2, y en menor medida en el anexo 3. Capítuloȱ4ȱ xCapacidad del emulador, análisis del rendimiento y prestaciones para dos configuraciones hardware distintas del sistema emulador (PC con distintos procesadores y memoria RAM) y S.O Windows. Influencia del consumo de recursos del sistema sobre la potencial escalabilidad de la arquitectura y sobre la latencia de red. xAnálisis intensivo de la interoperabilidad del entorno emulador GNS3/Dynamips con equipos y tráfico de red reales. xAnálisis de resultados particulares del capítulo. xSe apoya fundamentalmente en los anexos 2 y 3. Capítuloȱ5ȱxAnálisis y conclusiones a los objetivos prioritarios del proyecto. Inconvenientes y líneas de trabajo y/o investigación futuras. Capítuloȱ6ȱxReferencias bibliográficas y en línea de apoyo en el proyecto. Capítuloȱ7:ȱ ȱ Anexosȱ xElaborados ex profeso para el desarrollo del proyecto. Los anexos 1, 2 y 3 se consideran fundamentales para el correcto desarrollo y análisis del proyecto. Los anexos 4 y 5 se elaboran como complemento a los análisis prioritarios realizados. Anexoȱ1ȱ xConfiguración & gestión de dispositivos de red hardware modulares Cisco Catalyst 5500 Switch (y similares). ( La elaboración de este anexo 1 ha servido para configurar los equipos Cisco Catalayst 5500 Switch utilizados en el laboratorio de telemática 2.03). Anexoȱ2ȱxConfiguraciones de red en arquitecturas emuladas en GNS3/Dynamips.Interoperación entorno real ÅÆ entorno emulado. Anexoȱ3ȱ xExtracción del sistema operativo Cisco IOS de hardware de red Cisco Systems. Integración de Cisco IOS en el entorno software de emulación GNS3/Dynamips. Configuración básica de GNS3/Dynamips, parámetros y prestaciones fundamentales. Anexoȱ4ȱxAnálisis de prestaciones y rendimiento del sistema emulador en entornos de trabajo Linux (distribución Ubuntu 12.04). Anexoȱ5ȱ xImplementación de un servicio telemático cliente /servidor FTP vía interoperación entorno real (Ethernet 802.3) ÅÆ entorno emulado en arquitecturas de red emuladas. Tabla 1.1. Distribución del contenido de la memoria por capítulos. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 12 12 Figura 2.3. Esquema de contingencias y soluciones adoptadas para implementar las arquitecturas de red del proyecto en GNS3/Dynamips en base al dispositivo Cisco Catalyst 5500 Switch del laboratorio. Capítulo 2 : Consideraciones de diseño y entorno de trabajo 13 13 La figura 2.4 muestra el dispositivo/nodo de red general emulado EtherSwitch router disponible en GNS3/Dynamips, que será la base del diseño de las arquitecturas de red emuladas. Sobre éste se integran (conforme a las indicaciones/soluciones adoptadas a las contingencias planteadas en la figura 2.3 anterior) el sistema Cisco IOS de la plataforma Cisco 3600/3700 series [9] y los módulos de interfaces virtuales-hardware necesarios para conformar un dispositivo de red emulado idéntico o similar, tanto hardware como software, al dispositivo de red modular Cisco Catalyst 5500 Switch del laboratorio. Figura 2.4. Nodo EtherSwitch router general disponible en el entorno de emulación GNS3/Dynamips. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 14 14 Capítulo 3: Análisis de arquitecturas de red en GNS3/Dynamips 15 15 Capítulo 3: Análisis de arquitecturas de red en GNS3/Dynamips. 3.1. Análisis de la arquitectura de red WAN ppp. 3.1.1. Consideraciones iniciales y descripción para la configuración de la arquitectura de red. Conforme al escenario común de trabajo descrito en el apartado 2.4, se procede al planteamiento y diseño de la arquitectura de red en el entorno gráfico de simulación GNS3, arquitectura que realiza la interconexión (a nivel de red) de las VLAN configuradas en las bancadas 1-2 y 3-4 del laboratorio de telemática 2.03 (localmente, en cada router-switch) según la figura 3.1. Figura 3.1. Topología/simulación gráfica en GNS3 de la arquitectura de red WAN ppp. Inicialmente, para configurar gráficamente sobre GNS3 la topología de la figura 3.1 anterior, el anexo 2 (apartado 7.2.1) muestra en profundidad la manera de proceder. Seguidamente, para los análisis de este capítulo 3, cuyo cometido principal es verificar la usabilidad, funcionalidad y rigor del entorno emulador sólo consideramos activos y configuramos los nodos adscritos a la subred 155.210.157.248 / 30 (enlace WAN ppp de 1,544 MB, esto es, el enlace serie WAN ppp que conectaría las bancadas 1-2 y3-4 del laboratorio 2.03). Esta es considerada nuestra arquitectura de red principal. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 16 16 Se consideran los siguientes aspectos de diseño sobre el escenario de la figura 3.1: xPara que se produzca intercambio de la información de routing entre los dispositivos de red EtherSwitch router, con el objetivo de informarse mutuamente de sus respectivas “informaciones de red”, y con esto configurar cada uno sus tablas de enrutamiento, se activará posteriormente el protocolo RIP v2 en los interfaces pertinentes [8] (en sistemas basados en Cisco IOS, los protocolos de enrutamiento están desactivados por defecto; se configuran y activan a nivel de interfaz, sobre los interfaces adecuados según los propósitos del diseño). xLos equipos reales, integrados en el escenario mediante enlaces FastEthernet se adscriben administrativamente y localmente a VLAN2, con direcciones IP y máscaras asignadas según el diseño particular de la figura 3.1. Los equipos QEMU son terminales/host virtuales Linux y se consideran a efectos de diseño adscritos localmente a VLAN3, en el espacio de direcciones de red indicado. xSegún esta arquitectura de red, la interconexión de los equipos EtherSwitch router que emulan los dipositivos Cisco Catalyst 5500 Switch y que en el entorno real conectarían las bancadas 1-2 y 3-4 del laboratorio 2.03, se realiza mediante un enlace WAN serie point-to-point de 1,544 MB, adscrito administrativamente a la subred 155.210.157.248 / 30, subred de la red mayor 155.210.0.0 / 16. Los dispositivos de red emulados EtherSwitch router (descritos en el apartado 2.4) son hardware de red con capacidad para operar en los niveles 2 y 3 del modelo de referencia OSI (router-switch multilayer): añadidas a las características de routing, además de implementar conmutación a nivel 2 entre equipos adscritos a una misma VLAN en un nodo local EtherSwitch router, nos permiten realizar InterVLAN routing (conmutación a nivel 3) entre VLAN diferentes (en un mismo nodo local) mediante la configuración de interfaces virtuales SVI (sin necesidad de utilizar para ello un router externo y un enlace troncal configurado con el protocolo 802.1q óISL). Para habilitar las funcionalidades a nivel 3 en los router-switch multilayer (sino, el dispositivo sólo funcionaría a nivel 2) no debemos olvidar durante el proceso de configuración, y desde el modo de configuración global (los modos de configuración del hardware de red Cisco Systems se detallan en el anexo 1), ejecutar el comando Cisco IOS : switch_router1(config)# ip routing A tal efecto, para establecer las configuraciones de red vía consola de los dispositivos emulados mediante comandos Cisco IOS, y tomando como base los análisis reflejados en el anexo 1, el anexo 2 detalla más profundamente cómo proceder (apartado 7.2.1). Capítulo 3: Análisis de arquitecturas de red en GNS3/Dynamips 17 17 3.1.2. Captura y análisis de tráfico de red emulado en el enlace serie WAN ppp. Una vez implementada la configuración de red para el escenario de trabajo actual, configuración detallada en el anexo 2 (apartado 7.2.1), y para ahondar en el análisis de la funcionalidad y la correspondencia funcional de GNS3/Dynamips con entornos de red reales, se realiza una captura del tráfico existente para su análisis mediante la herramienta software Wireshark [14]. Así, un análisis del tráfico en la conexión serie WAN ppp principal configurada entre los nodos EtherSwitch router 1 y 2 (subred 155.210.157.248/30 de la figura 3.1) constata la existencia de tráfico de red relacionado con los protocolos en funcionamiento y activos en el escenario de trabajo emulado (figura 3.2). Se verifica, por lo tanto, que la actualización de las tablas de enrutamiento en los nodos emulados se ha producido a través de información (tráfico de red emulado) que circula por el entramado de la red virtual. Figura 3.2. Tráfico de red en el enlace serie WAN ppp del entorno emulado. El tráfico capturado en el enlace serie WAN ppp pone de manifiesto la comunicación existente entre los nodos EtherSwitch router en el entorno emulado. En primer lugar, se constata la existencia de tráfico de red relacionado con RIP v2, por ejemplo, en las tramas capturadas 19, 24 y 35: los nodos EtherSwitch router envían información de sus tablas de enrutamiento con dirección de destino multicast 224.0.0.9.En segundo lugar, se aprecia tráfico relacionado con el protocolo point-to-point configurado en el enlace serie WAN ppp, tráfico éste que permite el mantenimiento de la conexión serie. También se aprecia tráfico relacionado con el protocolo CDP. CDP (Cisco Discovery Protocol) es un protocolo de nivel 2 propietario de Cisco Systems, configurado por defecto en sus dispositivos, que permite el intercambio de información entre los mismos. Dicho protocolo puede ser desactivado a voluntad del administrador del sistema. Al respecto, un análisis más exhaustivo del tráfico de red capturado (de la información contenida en las tramas anteriores) se acomete en el anexo 2 (apartado 7.2.2). Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 18 18 3.2. Análisis de la arquitectura de red LAN Ethernet / VTP 3.2.1. Consideraciones iniciales y descripción para la configuración de la arquitectura de red. Se procede a diseñar y configurar el escenario común de trabajo del apartado 2.4 según la arquitectura de red actual, consistente en una infraestructura LAN Ethernet/VTP conmutada sobre las dos ubicaciones físicas (bancada 1-2 y bancada 3-4), segmentada en dos VLAN, VLAN2 y VLAN3 (además de una VLAN nativa), como recoge esquemáticamente la figura 3.3. Figura 3.3. Topología/simulación gráfica en GNS3 de la arquitectura LAN Ethernet/VTP. Se consideran los siguientes aspectos de diseño y configuración sobre el escenario general de la figura 3.3, escenario en el que inicialmente sólo consideramos activos para este capítulo los nodos emulados R1 y R2 (las consideraciones sobre los nodos Auxiliar 1 y 2 se hacen en el capítulo 4): xEntorno de red LAN Ethernet, conmutado a nivel 2 y 3 (gracias a las prestaciones disponibles en dispositivos switch multilayer como el Cisco Catalyst 5500 Switch del laboratorio que permiten implementar InterVLAN routing)[3]. Los dipositivos de red emulados EtherSwitch router 1 (R1) y EtherSwitch router 2 (R2) representan y emulan los dispositivos de red Cisco Catalyst 5500 Switch del laboratorio. Capítulo 3: Análisis de arquitecturas de red en GNS3/Dynamips 19 19 xEn cuanto al interfaz gráfico/simulación de la topología en GNS3: a nivel 1, interconexión de los nodos EtherSwitch router 1 y 2 por medio de un enlace FastEthernet, sustituyendo el enlace serie point-to-point de la arquitectura WAN ppp anterior. xLas bancadas 1-2 y 3-4 del laboratorio 2.03 se interconectan por medio de un enlace FastEthernet que actúa como enlace troncal (trunk link) por el que circulan, mediante el protocolo 802.1q, VLAN2, VLAN3 y VLAN nativa. Sobre esta circunstancia se profundiza más en el anexo 2 (apartado 7.2.6). xSobre este escenario de trabajo no se configura ningún protocolo a nivel 3, como sí se hacía en la arquitectura de red WAN ppp (recordemos, RIP V2): estamos en un escenario LAN Ethernet conmutado. Solo se considera conmutación a nivel 2 y 3. xSobre el escenario general de la figura 3.3, primeramente se configuran los nodos EtherSwitch router 1 y 2 que constituyen la infraestructura principal de esta arquitectura de red,apoyándonos en el apartado 7.2.6 del anexo 2. Recordemos que el cometido principal en este capítulo es verificar la usabilidad, funcionalidad y rigor del entorno emulador. Sobre el resto de la arquitectura nos ocupamos en el capítulo siguiente (nodos Auxiliar 1 y 2). Añadido a esto, se configura para nuestra arquitectura de red el protocolo VTP (VLAN Trunk Protocol), protocolo creado por Cisco Systems para resolver los problemas operativos en entornos conmutados/segmentados VLAN [10]. En nuestra arquitectura de red (figura 3.3), procedemos a configurar los dispositivos de red emulados EtherSwtich router 1 y 2 con los siguientes “roles” VTP, “roles” que se explican brevemente en la tabla 3.1 de la página siguiente: xNodo EtherSwitch router 1 Æ Servidor VTP xNodo EtherSwitch router 2 Æ Cliente VTP Esta asignación de “roles” implica que tomamos el nodo 1 como “cerebro” de la configuración VLAN, sobre el que creamos las mismas y efectuamos todas las modificaciones administrativas futuras. Esta información, gracias a VTP, se transferirá al resto de switch participantes del escenario conmutado. En base a estas consideraciones, procedemos con la configuración y verificación del escenario de trabajo en el entorno emulado de GNS3/Dynamips, según el anexo 2 de la memoria. Complementando las disposiciones anteriores, podemos contrastar un análisis más profundo de las características y prestaciones telemáticas del protocolo VTP en el apartado 7.2.6 del anexo 2. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 20 20 3.2.2. Captura y análisis de tráfico emulado en el enlace troncal (trunk link). Para realizar un análisis intensivo del entorno software emulador y contrastar su funcionalidad, rigor y correspondencia funcional con entornos de red reales análogos, se realiza una captura del tráfico de red emulado en el enlace troncal de la arquitectura (trunk link) configurado con el protocolo 802.1q. Con ello se pretende constatar si por dicho enlace emulado circulan tagged frames 802.1q, identificadas según la VLAN a la que corresponden (corroborando así el rigor y la correspondencia funcional del emulador). Figura 3.4. Captura de tráfico emulado en enlace troncal (protocolo 802.1q ) Figura 3.5. Detalle de trama Ethernet 802.1q capturada en el enlace troncal. Las figuras 3.4 y 3.5 anteriores nos muestran ciertas características del tráfico capturado y de una trama Ethernet 802.1q, respectivamente. Sobre el tráfico capturado, se observan en principio 5 protocolos diferentes en operación en el entorno virtual: STP, DHCP, ARP, CDP e ICMP (comando ping). Sin entrar en grandes consideraciones por no ser objetivo del análisis, se apunta teóricamente que STP (Spanning Tree Protocol) se usa fundamentalmente en redes conmutadas para crear una topología lógica sin loops a partir de una topología física con loops (topología redundante).Las topologías de red redundantes se diseñan para garantizar que las redes continúen funcionando en presencia de puntos únicos de falla, aumentando la confiabilidad del diseño [1] [11]. Capítulo 3: Análisis de arquitecturas de red en GNS3/Dynamips 21 21 Los enlaces, puertos y switch que noforman parte de la topología activa sin loops no envían tramas de datos. El protocolo Spanning Tree es una herramienta que permite a un administrador de red disponer de una topología redundante, sin que exista el riesgo de que se produzcan problemas provocados por los loops de conmutación. STP se ejecuta por defecto en dispositivos Cisco Systems (switch y switch multilayer en nuestro caso). Como no se corresponde con el diseño de nuestro supuesto práctico, podría ser desactivado en nuestro escenario de trabajo, mediante el comando Cisco IOS siguiente, ejecutado desde el modo de configuración global Æ de interfaz VLAN (ver anexo 1) : switch_router1(config)#interface [vlan/id] switch_router1(config–if)# no spanning-tree vlan [vlan/id] , esto es, STP debe desactivarse a nivel de interfaz VLAN (para todas las VLAN del diseño), no a nivel de interfaz físico Ethernet, y debe hacerse en todos los switch participantes del diseño conmutado, para que no haya errores y no se generen loops de conmutación. Así mismo, un análisis inicial de la trama emulada Ethernet 802.1q de la figura 3.5, nos muestra el identificador VLAN ID (tagged frame, VLAN ID = 2),consecuencia de ejecutar en 192.168.2.3/24 (equipo_real 2 en nodo EtherSwitch router 2 ,VLAN2): ping 192.168.2.2 (equipo_real 1 en EtherSwitch router 1 , VLAN2). Profundizando un poco más para analizar la rigurosidad funcional del emulador, y del consiguiente tráfico de red virtual, consideramos la estructura teórica de una trama Ethernet 802.1 q, descrita en la figura 3.6. Figura 3.6. Estructura de trama Ethernet 802.1q. Imagen extraída de “Cisco Networking Academy program, CCNP: Building Multilayer Switching Networks v.5.0” [10]. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 28 28 Configuración hardware 1 Carga de CPU (offmode)1 MemoriaRAM en uso en MB (offmode) Carga media de CPU (pseudoactivo) 2 Memoria RAM en uso en MB (pseudoactivo) 1 switch-router activo 1% max. 318 1-2 % 780 Æ 540 2 switch-router activos 1% max. 318 4 % Æ 2-3 % 940 Æ 720 2 switch-router activos + 1 QEMU 1% max. 318 16 % Æ 14 % 950Æ 750 2 switch-router activos + 2 QEMU 1% max. 318 17 % Æ 15 % 960Æ 760 2 switch-router activos + 1 auxiliar ( sin QEMU) 1% max. 318 6 % Æ 4-5 % 970Æ 760 2 switch-router activos + 2 auxiliar ( sin QEMU) 1% max. 318 11% Æ 9-10 % 980 Æ 790 Tabla 4.2. Consumo de recursos del sistema emulador para la configuración hardware 1, bajo S.O. Windows XP 32 bits y arquitectura de red WAN ppp. En la tabla 4.2 anterior, tabla 4.3 y siguientes, las expresiones XX Æ XX deben interpretarse como un descenso en el consumo de recursos en el PC emulador. A continuación se analiza detalladamente esta circunstancia. Antes, se destaca que para el análisis de la configuración hardware 2, equipo_real 1 y equipo_real 2 son sendos equipos reales externos (equipos portátiles), integrados en el escenario emulado de trabajo vía interfaces de red Ethernet específicos en el PC emulador, y siguiendo las instrucciones y requerimientos descritos en el anexo 3. En base a esta configuración hardware, la tabla 4.3 siguiente muestra los resultados obtenidos en el análisis de la capacidad y rendimiento del sistema emulador. 1 Estado inicial en el que ningún nodo y/o terminal QEMU está en funcionamiento. 2 Estado en el que el tráfico de red presente es el relacionado con el mantenimiento y actualización de los protocolos configurados en el escenario de trabajo ( información dinámica de nivel 2 y 3 Æ escaso tráfico) Capítulo 4: Análisis del rendimiento y capacidad del sistema emulador. Relación con la latencia de red en la interoperación entorno real ÅÆ entorno emulado 29 29 Configuración hardware 2 Carga del procesador (off mode) MemoriaRAM en uso en MB (off mode) Carga media del procesador (pseudoactivo) Memoria RAM en uso en MB (pseudoactivo) 1 switch-router activo 1% max 330 1-2% 770 Æ 512 2 switch-router activos 1% max 330 3 % Æ 2 % 940Æ 710 2 switch-router activos + 1 QEMU 1% max 330 15 % Æ 12% 970Æ 770 2 switch-router activos + 2 QEMU 1% max 330 16 % Æ 14 % 980 Æ 780 2 switch-router activos + 1 auxiliar ( sin QEMU) 1% max 330 5 % Æ 4 % 980Æ 760 2 switch-router activos + 2 auxiliar ( sin QEMU) 1% max 330 9% Æ 8 % 990Æ 800 Tabla 4.3. Consumo de recursos del sistema emulador para la configuración hardware 2, bajo S.O. Windows XP 32 bits y arquitectura de red WAN ppp. Se constata empíricamente que los valores de carga de CPU y consumo de memoria RAM son muy fluctuantes en todos los experimentos realizados, ponderándose la media de los mismos. El descenso en el consumo de recursos anterior se asocia principalmente al uso de los recursos optimizadores de memoria RAM disponibles en el entorno emulador, y detallados más intensamente en el apartado 7.3.6 del anexo 3. Se contrasta empíricamente que estos recursos son manifiestamente ejecutados por el sistema transcurridos varios minutos desde la puesta en funcionamiento de la arquitectura emulada, y la optimización máxima se consigue en topologías en las que los dispositivos emulados se corresponden con un único modelo, es decir, sólo se está emulando un sistema o imagen Cisco IOS, a pesar de existir varios nodos iguales en la arquitectura de red. La carga completa y funcionalmente estable del sistema Cisco IOS en el PC emulador, considerando además que se ha configurado previamente un correcto y decisivo valor del parámetro idle PC (parámetro de configuración inicial del emulador y recurso optimizador prioritario de CPU detallado en el apartado 7.3.5 del anexo 3), se consigue transcurridos pocos minutos, y se refleja secundariamente en un ligero descenso de la carga de CPU (ojo, éste es un descenso de la carga de CPU pequeño y “secundario”, no tiene que ver con el asociado al anterior parámetro idle PC). Establecer posibles dependencias entre los descensos en el consumo de memoria RAM y CPU desembocaría en un análisis hardware a más bajo nivel que escapa a los propósitos del proyecto. Por ello, enunciamos de un modo general la característica de estabilidad del sistema alcanzada tras varios minutos de Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 30 30 actividad (se comprueba empíricamente que este tiempo es de 5-10 minutos máximo) y haciendo uso de los recursos optimizadores aportados por GNS3/Dynamips descritos en el anexo 3. Sobre los consumos de recursos asociados a los terminales QEMU se especifican y detallan ciertas connotaciones secundarias en el apartado 7.2.5 del anexo 2. A la hora de ejecutar los procesos asociados con la emulación, GNS3/Dynamips consume como mínimo, y en principio (sin el uso de los recursos optimizadores de memoria descritos en el anexo 3), la misma cantidad de memoria RAM real que consumirían el conjunto de todos los dispositivos reales que se emulan en el escenario de trabajo. Consecuentemente, el consumo de memoria RAM es ciertamente crítico a la hora de ejecutar la emulación. Sin el uso de los recursos optimizadores de memoria, la escalabilidad de la topología asociada a una determinada arquitectura sería muy limitada. Estas vicisitudes se han comprobado empíricamente en el desarrollo del proyecto, resultando inviable la emulación en caso de no optar por la optimización de memoria RAM en el supuesto de la configuración hardware 1 (1 GB de RAM), ya que en nuestro caso los dispositivos de red emulados EtherSwitch router emulan/disponen de 128 Mb de RAM “virtual” cada uno). Activada la función de optimización ghost ios [13] descrita en el apartado 7.3.6 del anexo 3, la cantidad de memoria RAM ahorrada no es un proceso exacto ni matemáticamente accesible al cálculo debido a la complejidad en la administración de la memoria RAM por parte de los sistemas operativos. Simplemente, se procede a mostrar empíricamente el consumo de memoria RAM en las tablas 4.2 y 4.3. Con la facilidad ghostios activa, el consumo de memoria RAM deja de ser una circunstancia crítica a la hora de abordar la emulación para el escenario que nos ocupa, en el que todos los dispositivos emulados ejecutan el mismo sistema Cisco IOS. La única recomendación práctica al respecto es simple: que nuestro sistema emulador disponga de la mayor cantidad de memoria RAM posible (mínimo recomendable 2 GB). Derivado de todo lo anterior, la escalabilidad de los escenarios emulados de trabajo (en principio, y como aproximación, se interpreta este parámetro como el número de nodos que el sistema es capaz de incorporar adecuadamente al diseño y emular en una arquitectura) se ve limitada principalmente por el consumo de CPU por parte del sistema emulador. El consumo de CPU que reflejan las tablas 4.2 y 4.3, mostrado en las figuras 4.2 y 4.3, constata una evolución según el número de nodos activos que aproximamos a una progresión geométrica con el objetivo de establecer una cota superior de escalabilidad suficientemente fiable, y así establecer un margen adecuado de trabajo para nuestro escenario telemático. Igualmente, se aprecia cómo este consumo depende clara y directamente del procesador que monta nuestro sistema emulador. Así, en el caso de la configuración hardware 1, en base a los resultados de la tabla 4.2 y para una situación estable del escenario de trabajo caracterizada por el descenso en el consumo de recursos, podríamos emular arquitecturas con hasta 7 nodos de red activos conforme al margen de trabajo. Esta cota superior conduce a un consumo de CPU entre el 70-90 %. Capítulo 4: Análisis del rendimiento y capacidad del sistema emulador. Relación con la latencia de red en la interoperación entorno real ÅÆ entorno emulado 31 31 La cota superior del margen escalable de trabajo lo establecemos considerando escenarios en los que implementamos una interoperación entre entornos de red real y emulado, escenarios en los que subyace un cierto interés teórico-práctico en analizar el comportamiento del tráfico de red. En caso de implementar escenarios emulados con objetivos telemáticos más básicos, como por ejemplo el estudio del comportamiento de protocolos de comunicaciones a nivel 2 o nivel 3, la escalabilidad del escenario de trabajo puede ser ligeramente mayor, pudiendo llegar al límite del 100 % de carga de CPU durante un cierto periodo de tiempo (esto se contrasta empíricamente). Esta situación conduce a un comportamiento del sistema emulador inadecuado y limitado, pero funcionalmente capaz de acometer los procesos de emulación para propósitos telemáticos básicos de estudio a nivel 2 y 3 (estando el número de nodos a emular, evidentemente, dentro de unos límites). Para la configuración hardware 2, y según los resultados mostrados en la tabla 4.3, el consumo de CPU desciende ligeramente con respecto al caso anterior, evidenciando una dependencia con el hardware del PC emulador. Esto nos permitiría, y en caso estrictamente necesario y límite, llegar a una cota superior de escalabilidad de hasta 8 nodos emulados en nuestra arquitectura, eso sí, con un incremento en el consumo de CPU con respecto a la configuración hardware 1 anterior. Al respecto, improvisar una fórmula matemática general que relacione el número de nodos activos con el consumo de CPU resulta inviable debido a la dependencia directa que existe con el hardware del sistema emulador. En el análisis de estos resultados es preciso tomar en consideración el hecho de que los PC’s que ejecutan la emulación se corresponden con equipos de gama media-baja en el contexto tecnológico actual. Figura 4.2. Consumo de CPU en el sistema emulador (PC) en función del número de nodos emulados activos para la arquitectura WAN ppp y configuración hardware 1. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 32 32 Figura 4.3. Consumo de CPU en el sistema emulador (PC) en función del número de nodos emulados activos para la arquitectura WAN ppp y configuración hardware 2. 4.2.2. Análisis de la latencia para la arquitectura de red WAN ppp. Seguidamente, se analiza en la interoperación entorno real ÅÆ entorno emulado de GNS3/Dynamips el efecto sobre la latencia del tráfico de red en transmisiones sin control de errores. Los experimentos a realizar son dos: xLatencia para diferentes longitudes de trama Ethernet, en transmisiones sin control de errores (protocolo ICMP) para la conexión: equipo real 1 ÅÆ interfaz SVI de nodo virtual emulado 1. xLatencia para diferentes longitudes de trama Ethernet, en transmisiones sin control de errores (protocolo ICMP), para la conexión extremo a extremo: equipo real 1 ÅÆ entorno emulado (vía SVI de nodo virtual emulado 1) ÅÆ equipo real 2. Los análisis efectuados son evaluados para las diferentes cargas de CPU y consumos de memoria RAM para las configuraciones hardware de las tablas 4.2 y 4.3, tablas obtenidas anteriormente y de modo empírico en el análisis de la capacidad y rendimiento del sistema emulador. Los resultados obtenidos en los análisis siguientes se relacionan con instantes de tiempo de consumo máximo de recursos del sistema emulador, según reflejan las anteriores tablas 4.2 y 4.3. Esto es, suponen una cota superior de los resultados. Capítulo 4: Análisis del rendimiento y capacidad del sistema emulador. Relación con la latencia de red en la interoperación entorno real ÅÆ entorno emulado 33 33 Latencia en transmisiones sin control de errores (protocolo ICMP) para la conexión equipo real 1 (Ethernet 802.3) ÅÆ interfaz SVI de nodo virtual emulado 1. Atendiendo al escenario de la figura 3.1 y haciendo uso del protocolo ICMP, protocolo que no realiza control de errores y solo informa de los mismos, desde equipo_ real 1 (192.168.2.2) implementamos solicitudes de eco con destino el interfaz virtual SVI de VLAN2 en el nodo virtual/emulado EtherSwitch router 1 (192.168.2.1): ping 192.168.2.1 –n cuenta –l longitud ,donde –ncuenta es el número de solicitudes de eco enviadas (en nuestro caso serán 200 ) y -l longitud es el tamaño en bytes del campo datos del datagrama ICMP a tal efecto (sin considerar el tamaño de la cabecera). Se realizan 20 repeticiones del experimento, ponderándose la media de los mismos. Las longitudes de trama Ethernet 802.3 consideradas para este análisis serán la longitud de trama mínima (64 bytes, que se corresponde con un valor de MTU mínimo de 46 bytes), la longitud de trama 1514 bytes (que corresponde a un valor de MTU máximo de 1500 bytes) y dos longitudes intermedias, 512 bytes y 1024 bytes. Los ǻ entre las longitudes de trama consideradas son aproximadamente los mismos. Interpretando teóricamente la estructura de la trama Ethernet 802.3 y los campos/cabeceras que conforman el datagrama IP/ICMP, se calcula el valor del parámetro –l longitud , en la ejecución del comando ping anterior: Longitud ( datagrama IP/ICMP ) = ( longitud de trama Ethernet – 14 bytes de cabecera Ethernet) – (20 bytes de cabecera IP) - ( 8 bytes de cabecera ICMP ) La longitud de trama máxima empleada en el experimento, 1514 bytes, es la que nos permite utilizar el máximo valor de MTU (1500 bytes) sin que haya fragmentación de la información (Fragmented IP protocol) . En las tablas 4.4 y 4.5 de la página siguiente, que recogen los resultados obtenidos para este experimento (valor del Round Trip Time promedio) se interpretan los switch-router activos (valor nominal de las columnas) por el consumo directo de recursos que implican en el PC emulador, consumos reflejados en las tablas 4.2 y 4.3 anteriores. En el desarrollo de este experimento no se ha producido ningún TIMEOUT, esto es, la pérdida de ningún datagrama ICMP. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 34 34 RTT promedio (configuración hardware 1) 1 switchrouter activo 2 switchrouter activos 3 switchrouter activos 4 switchrouter activos Longitud Trama 64 bytes 31 ms 40 ms 46 ms 61 ms Longitud Trama 512 bytes 33 ms 40 ms 47 ms 62 ms Longitud Trama 1024 bytes 35 ms 42 ms 49 ms 66 ms Longitud Trama 1514 bytes 38 ms 43 ms 52 ms 67 ms Tabla 4.4. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ interfaz SVI en nodo virtual 1, para diferentes longitudes de trama y consumo de recursos del PC emulador 1 en la arquitectura WAN ppp. RTT promedio (configuración hardware 2) 1 switchrouter activo 2 switchrouter activos 3 switchrouter activos 4 switchrouter activos Longitud Trama 64 bytes 30 ms 40 ms 45 ms 59 ms Longitud Trama 512 bytes 33 ms 40 ms 47ms 61 ms Longitud Trama 1024 bytes 34 ms 41 ms 48 ms 65 ms Longitud Trama 1514 bytes 37 ms 42 ms 50 ms 66 ms Tabla 4.5. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ interfaz SVI en nodo virtual 1, para diferentes longitudes de trama y consumo de recursos del PC emulador 2 en la arquitectura WAN ppp. Los resultados de las tablas anteriores muestran unos valores muy elevados de latencia en la interoperación entorno real (Ethernet 802.3) ÅÆ entorno emulado (interfaz SVI de nodo virtual emulado 1) para esta arquitectura de red (conmutación a nivel 3), en comparación con la latencia de red real obtenida para este mismo experimento en el laboratorio (RTT máximo = 1ms). En base a los resultados anteriores cabe preguntarse qué valor o ratio de la latencia en la interoperación es imputable al interfaz físico Ethernet empleado en la interoperación y qué valor o ratio en el total de la misma es imputable al proceso de emulación en sí. El valor imputable al proceso de emulación en la interoperación podemos analizarlo capturando el tráfico de red en el enlace de la interoperación en cuestión, mediante Wireshark, captura en la que profundizan las figuras 7.20 a) y 7.20 f) del anexo 2, y calculando la diferencia de tiempo entre Request y Reply de cada petición de eco, Capítulo 4: Análisis del rendimiento y capacidad del sistema emulador. Relación con la latencia de red en la interoperación entorno real ÅÆ entorno emulado 35 35 ponderando la media en base a todas las peticiones.El trabajo para ponderar la media de las (200*20) repeticiones para todos los supuestos prácticos sería ingente y desproporcionado, por eso se ha realizado sólo en base a 100 peticiones de eco de un solo experimento (el experimento relacionado con un solo swich-router activo para la configuración hardware 1). Así, éste es un valor aproximado al buscado (reflejado en la tabla 4.6), pero indicativo e ilustrativo general de la incidencia/comportamiento que es objeto del análisis. ǻ Request – Reply interoperación real ÅÆ emulado ( Valor/ratio de latencia imputable al proceso de emulación ) 1switch- router activo (EtherSwitch router 1) Longitud Trama 64 bytes 30 ms (97 % de la latencia en la interoperación ) Longitud Trama 512 bytes 31 ms (94 % de la latencia en la interoperación) Longitud Trama 1024 bytes 32 ms (91 % de la latencia en la interoperación) Longitud Trama 1514 bytes 35 ms (94 % de la latencia en la interoperación) Tabla 4.6). Latencia de red imputable a los procesos de emulación con respecto a la latencia total en el enlace equipo_real l (Ethernet 802.3) Æ interfaz SVI en nodo virtual 1, para la arquitectura WAN ppp, protocolo ICMP,diferentes longitudes de trama y 1 switch-router activo. La tabla 4.6 anterior constata empíricamente en el valor de la latencia en la interoperación entorno real ÅÆ entorno emulado (interfaz SVI de nodo virtual emulado 1) un mayor peso específico del proceso de emulación que del interfaz Ethernet a través del que se realiza la interoperación . Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 36 36 Latencia en transmisiones sin control de errores (protocolo ICMP) en la conexión extremo a extremo equipo real 1 ÅÆ entorno emulado ÅÆ equipo real 2. Se realiza un experimento formalmente similar al anterior para evaluar la latencia de la arquitectura de red extremo a extremo, esto es, equipo_real 1 (192.168.2.2) ÅÆ entorno virtual ÅÆ equipo_real 2 (192.168.4.2). Según la configuración de red establecida para el escenario de trabajo de la figura 3.1, el formato del comando ICMP a ejecutar en este caso sería: ping 192.168.4.2 –n cuenta –l longitud RTT promedio (configuración hardware 1) 1 switchrouter activo 2 switchrouter activos 3 switchrouter activos 4 switchrouter activos Longitud Trama 64 bytes - 56 ms 57 ms 62 ms Longitud Trama 512 bytes - 57 ms 59 ms 63 ms Longitud Trama 1024 bytes - 90 ms 91 ms 92 ms Longitud Trama 1514 bytes - 119 ms 121 ms 124 ms Tabla 4.7. Latencia de red para el protocolo ICMP en la conexión equipo_rea1 l Æ red virtual Æ equipo_ real 2, para diferentes longitudes de trama y consumo de recursos del PC emulador 1 en la arquitectura WAN ppp. RTT promedio (configuración hardware 2) 1 switchrouter activo 2 switchrouter activos 3 switchrouter activos 4 switchrouter activos Longitud Trama 64 bytes - 55 ms 56 ms 60 ms Longitud Trama 512 bytes - 56 ms 58 ms 62 ms Longitud Trama 1024 bytes - 89 ms 90 ms 91 ms Longitud Trama 1514 bytes - 118 ms 119 ms 122 ms Tabla 4.8. Latencia de red para el protocolo ICMP en la conexión equipo rea1 Æ red virtual Æ equipo real 2, para diferentes longitudes de trama y consumo de recursos del PC emulador 2 en la arquitectura WAN ppp. Capítulo 4: Análisis del rendimiento y capacidad del sistema emulador. Relación con la latencia de red en la interoperación entorno real ÅÆ entorno emulado 37 37 Al igual que anteriormente, se han realizado 20 repeticiones del experimento, ponderándose la media de los mismos. Los resultados mostrados en las tablas 4.7 y 4.8 anteriores constatan empíricamente un valor igualmente elevado para la latencia en este experimento y para la arquitectura de red actual, comparado con un valor teórico máximo esperable máximo de 2- 3 ms en este caso concreto. Los valores de la latencia en todos los experimentos realizados son bastante fluctuantes, pudiendo ser atribuibles, principalmente, a las fluctuaciones existentes en el consumo de recursos del PC emulador previamente constatadas. En el desarrollo de este experimento no se ha producido ningún TIMEOUT, esto es, la pérdida de ningún datagrama ICMP. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 44 44 Capítulo 5: Análisis final del proyecto, conclusiones y líneas futuras de trabajo y/o investigación. 45 45 Capítulo 5: Análisis final del proyecto, conclusiones y líneas futuras de trabajo y/o investigación. Partiendo de los análisis expuestos en los capítulos 3 y 4, apoyados en los anexos elaborados a raíz del estudio de los entornos de trabajo controlados hardware y software sobre los que se articula el proyecto, se exponen las conclusiones prioritarias del mismo. Finalmente, se proponen determinadas líneas de trabajo y/o investigación futuras para profundizar en el conocimiento de las prestaciones telemáticas potencialmente ofrecidas por el entorno GNS3/Dynamips, prestaciones que por profusas y diversas escapan al contenido de este proyecto. La necesidad de conformar una base teórica y práctica sólida sobre la que se sustenten posibles trabajos y análisis futuros es el condicionante principal para que este proyecto se haya concretado intensamente en los contenidos expuestos. 5.1. Conclusiones finales de los análisis de las características, rigor y correspondencia funcional de GNS3/Dynamips. Conclusiones de la interoperabilidad entre entornos de red reales y emulados. Figura 5.1. Secuenciación del análisis de las características, rigor y correspondencia funcional de GNS3/Dynamips. La tabla 5.1 de la página siguiente expone resumidamente las primeras conclusiones y consecuencias extraídas en el análisis de la interoperabilidad y funcionalidad del entorno emulador GNS3/Dynamips, hasta nivel 3 según el modelo de referencia OSI. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 46 46 ȱ Conclusionesȱȱdeȱlaȱ funcionalidadȱeȱ interoperabilidadȱdeȱ GNS3/Dynamipsȱȱ Característicasȱ/ȱPrestacionesȱȱ ȱ ÆÆȱ ȱ Consecuenciasȱ prácticas/beneficiosȱparaȱ elȱdiseño.ȱ Conclusiónȱ1ȱ ȱ -Interoperación factible y funcional entre dispositivos de diferentes marcas y modelos. Estricta funcionalidad del entorno emulador a nivel 2 y 3. ( interoperamos tráfico de red Ethernet enviado/recibido por dispositivos de red reales y emulados, a través del interfaz Ethernet empleado para implementar la interoperación). - Versatilidad de diseño a nivel 2 y 3. - Adecuado uso de GNS3/Dynamips en ámbitos profesionales y académicos a nivel 2 y 3. ȱ Conclusiónȱ2ȱ ȱ - Permite segmentar arquitecturas/topologías de trabajo en una “parte real” y una “parte emulada”, según nuestros intereses de diseño y objetivos. - Versatilidad de diseño. - Aporta un extra al inconveniente de disponer recursos hardware limitados en un entorno de trabajo. Conclusiónȱ3ȱ ȱ - Facilidad para implementar las configuraciones emuladas de red en base a comandos Cisco IOS (anexo 2). El interfaz gráfico de GNS3 para el diseño de las topologías resulta cómodo, intuitivo y fácilmente asimilable. - Adecuada usabilidad de GNS3/Dynamips. Conclusiónȱ4ȱ ȱ - Permite fácil y cómodamente generar, y posteriormente capturar y analizar, tráfico de red (mediante la herramienta software Wireshark). - Adecuado uso del emulador en ámbitos profesionales y académicos para analizar el tráfico de red asociado a las arquitecturas. Tabla 5.1. Conclusiones en el análisis de la funcionalidad del emulador a nivel 2 y 3 , y de la interoperabilidad entre entornos de red reales y emulados. Capítulo 5: Análisis final del proyecto, conclusiones y líneas futuras de trabajo y/o investigación. 47 47 Para profundizar más en las conclusiones de la tabla anterior se remite al apartado 7.2.8 y a la tabla 7.2 del anexo 2. Igualmente, para ahondar más intensamente en las conclusiones sobre la interoperabilidad, objetivo prioritario del proyecto, en el apartado 7.2.4 del mismo anexo 2 se realiza un análisis más exhaustivo mediante Wireshark del tráfico de red en el enlace equipo real 1 Å Ænodo virtual 1. Además, el anexo 5 se elabora como complemento teórico-práctico intensivo a los análisis de la interoperabilidad de los capítulos 3 y 4. 5.2. Análisis de la capacidad, rendimiento y latencia de red de GNS3/Dynamips en Windows. 5.2.1. Conclusiones a los análisis sobre la capacidad y rendimiento del sistema emulador. Contrastado empíricamente que la interoperación no afecta significativamente al consumo de recursos del sistema, se conforman en el capítulo 4 los análisis para el estudio de la dependencia inversa: cómo afecta a la latencia de red (y en cierta manera al comportamiento en tiempo real) el consumo de recursos en el sistema emulador, dependiente este consumo de la mayor o menor complejidad la topología (principalmente, el número de nodos emulados activos). Estos análisis particulares tienen su reflejo en el mismo capítulo 4. A continuación, se muestra en la tabla 5.3 un resumen de las dependencias halladas en estos análisis. Las consideraciones oportunas sobre el rendimiento y capacidad del sistema emulador en sistemas operativos Linux (distribución Ubuntu 12.04) se muestran, complementando los análisis del proyecto en Windows, en el anexo 4 de la memoria. A grandes rasgos, en los apartados 7.4.2 y 7.4.3 de este anexo 4 se constata un ligero descenso en el consumo de recursos del sistema emulador en entornos de trabajo Linux, así como un ligero descenso del valor de la latencia de red (asociado indefectiblemente al descenso en el consumo de recursos). Conclusiones finales - Tabla de dependencias sobre el consumo de recursos del entorno emulador Se improvisa en la tabla 5.1 siguiente una breve relación de dependencias que resume esquemáticamente las conclusiones sobre el consumo de recursos de los análisis del capítulo 4. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 48 48 Dependenciasȱenȱelȱ consumoȱdeȱrecursosȱ delȱsistemaȱemuladorȱ ȱ Configuraciónȱ hardwareȱdelȱ PCȱemuladorȱ ȱ ȱ Tecnologíaȱdeȱlaȱ arquitecturaȱdeȱ redȱȱ ȱ ȱNºȱdeȱnodosȱ emuladosȱ activosȱȱ (topologíaȱdeȱlaȱ arquitectura)ȱ ȱ ConsumoȱdeȱCPUȱ ȱ ALTA BAJA MUY ALTA ȱ Consumoȱdeȱmemoriaȱ RAMȱ MEDIA BAJA MUY ALTA Tabla 5.2. Relación de dependencias en el consumo de recursos del sistema emulador. La diferencia existente en la dependencia respecto de la configuración hardware para los consumos de CPU y memoria RAM (ALTA y MEDIA respectivamente) se supedita al hecho de que al activar en GNS3/Dynamips el recurso optimizador de memoria ghost ios el consumo de memoria RAM deja de ser crítico en la emulación (para el escenario de trabajo que nos ocupa caracterizado por emular un único y común sistema Cisco IOS en todos los dispositivos emulados). 5.2.2. Conclusiones a los análisis de la latencia de red en la interoperación entorno real ÅÆ entorno emulado. Indefectiblemente asociadas al objetivo principal del proyecto (análisis de la interoperabilidad), se establecen las conclusiones a los experimentos de los apartados 4.2.2 y 4.2.4 en el análisis de la latencia. Los resultados para los dos experimentos considerados son concluyentes en tanto que nos proporcionan información sobre la latencia mínima a considerar, según el tamaño de trama, en la prestación de servicios telemáticos más complejos en las arquitecturas de red emuladas, por el hecho de no implementar control de errores en la transmisión (el protocolo ICMP solo informa de ellos). Esto excluye la circunstancia de que esta latencia de red emulada sea más o menos correcta. Para el primero de los experimentos propuestos en ambas arquitecturas, las tablas 4.4 y 4.5 obtenidas en el apartado 4.2.2, y las tablas 4.11 y 4.12 del apartado 4.2.4 revelan un valor de la latencia de red para todas las longitudes de trama Ethernet muy elevado con respecto al valor que se obtiene en un entorno real análogo. Este valor no sería asumible en la práctica sobre un escenario real similar (se recuerda que estamos implementando en este caso conmutación a nivel 3). Capítulo 5: Análisis final del proyecto, conclusiones y líneas futuras de trabajo y/o investigación. 49 49 Aunque estrictamente no es el caso, esta elevada latencia sugiere el hecho de que el potencial valor de la latencia media en una supuesta conexión extremo–extremo en topologías emuladas más complejas (mayor número de nodos intermedios o hops en la trayectoria), sobre todo para el caso de la arquitectura WAN ppp, incumpliese la recomendación ITU-T G.114 al respecto (valor máximo < 150 ms) [18][19] a la hora de implementar servicios telemáticos avanzados, como VoIP o vídeo multimedia. Estos valores de latencia se obtienen en situaciones de consumo máximo y mínimo de recursos. Llegado el caso, a la hora de extrapolar estos resultados de un escenario de red emulado en GNS3/Dynamips sobre un análogo escenario real, podríamos considerar como una cota superior amplia y fiable para la latencia de red real el valor de latencia mínimo obtenido en cada experimento emulado concreto (para cada longitud de trama y consumo de recursos). Sobre esto se profundiza más en el apartado 7.2.8 del anexo 2. En segundo lugar, se aprecia un comportamiento del emulador con respecto a la longitud de trama acorde al comportamiento teórico en el escenario real, esto es, mayor valor de latencia de red para longitudes de trama mayores (correspondencia funcional). Figura 5.2. Comportamiento del emulador para la latencia de red respecto al consumo de recursos y la longitud de trama para las tablas 4.4 , 4.5,4.11 y 4.12 referentes al primero de los experimentos de la latencia en ambas arquitecturas de red. Del análisis conjunto de estas últimas valoraciones de las tablas 4.4,4.5, 4.11 y 4.12 se observa que la dependencia del comportamiento del emulador para la latencia es más crítica y sensible en el sentido de las columnas y hacia la derecha, que en el de las filas y en sentido descendente: el comportamiento del emulador para la latencia de red en este experimento (y consecuentemente trasladable en cierta manera a su comportamiento en tiempo real) resulta más sensible al consumo de recursos del sistema emulador que al tamaño de trama Ethernet. De un modo gráfico, esto se muestra en la figura 5.2 anterior. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 50 50 De las tablas 4.7 y 4.8 del apartado 4.2.2 (arquitectura WAN ppp) podemos extraer parecidas conclusiones a las antes descritas. Pero en este caso, la comunicación entre los nodos emulados se realiza a nivel de red (nivel 3), a través de un enlace serie WAN ppp de 1,544 Mb. Ello conlleva que en este caso la dependencia de la latencia sea mayor en el sentido descendente de las filas que de las columnas (aumenta la dependencia con respecto a la longitud de trama, debido a la capacidad de 1,544 MB del enlace serie ppp). Aunque los valores de latencia media calculados en este segundo experimento cumplen estrictamente la recomendación ITU-T G.114, límite establecido por ejemplo para prestar servicios VoIP [18], hay que observar este valor con cautela y cierta perspectiva práctica relativa, pues nuestra conexión extremo-extremo se circunscribe a dos nodos de red únicamente (2 hops en la trayectoria del tráfico). Para el segundo de los experimentos en la arquitectura LAN Ethernet/VTP, las tablas 4.13 y 4.14 muestran un descenso contundente en la latencia con respecto al mismo experimento en la arquitectura WAN ppp. En este caso, los resultados son bastante más equiparables a los obtenidos sobre un mismo escenario real, apreciándose igualmente que estos empeoran conforme aumenta el consumo de recursos y el tamaño de la trama. Sobre el escenario emulado LAN Ethernet/VTP conmutado, y para este experimento, estamos implementando conmutación a nivel 2 entre ambos equipos real 1 y 2, equipos adscritos a la misma VLAN, y el emulador presenta un mejor comportamiento en la interoperación. Los valores de latencia media obtenidos, aunque superiores a los obtenidos sobre idénticos escenarios reales (aproximadamente entre 1-2 ms), se circunscriben mejor a la recomendación ITU-T G.114 [19] de una manera absoluta, en el hipotético caso de querer implementar servicios telemáticos avanzados de voz, pues su valor está ampliamente dentro de los márgenes de seguridad establecidos, y de una manera relativa, pues la conexión extremo-extremo implica dos nodos de red tan sólo, en este caso 2 switch (un solo hop en la trayectoria equipo real 1 ÅÆ equipo real 2). Las tablas 5.2 y 5.3 siguientes muestran resumidamente las conclusiones más decisivas e importantes en el análisis de la latenciaen la interoperación. Un análisis más exhaustivo de las mismas puede contrastarse en el apartado 7.2.8 del anexo 2. Capítulo 5: Análisis final del proyecto, conclusiones y líneas futuras de trabajo y/o investigación. 51 51 Conclusiones finales de la latencia – Tabla de dependencias de la latencia Tabla 5.3. Conclusiones principales a los análisis de la latencia en la interoperación . Conclusionesȱaȱ losȱanálisisȱdeȱ laȱlatencia.ȱ ȱ DescripciónȱȱȱÆÆȱ ȱ Consecuenciasȱ ȱ Conclusiónȱ1ȱ ȱ - Los valores calculados de latencia media de red en el entorno emulado son superiores (y en algunos caso muy superiores) a los correspondientes sobre análogos escenarios de red reales. - Circunscribir nuestros análisis a aproximaciones asociadas con márgenes/cotas superiores de latencia fiables de trabajo. ȱ Conclusiónȱ2ȱ - Comportamiento deficiente del emulador en la interoperación de algunas arquitecturas, como las que interoperan tráfico Ethernet con interfaces virtuales SVI (conmutación a nivel 3). - Prudencia a la hora de trasladar el funcionamiento y los resultados en tiempo real de la arquitectura de red emulada y el tráfico con ella relacionado a entornos reales y profesionales de trabajo. Así, el uso de GNS3/Dynamips en este escenario es más adecuado para el ámbito académico que para entornos profesionales. Conclusiónȱ3ȱ ȱ ȱ - En la arquitectura LAN Ethernet/VTP (arquitectura emulada conmutada) el comportamiento de la latencia es relativamente correcto y equiparable, con un cierto margen, a la latencia de red sobre un análogo escenario de red real. - Comportamiento de la latencia en la interoperación trasladable a escenarios reales (adscrito al margen de trabajo de una cota superior fiable ) ȱ Conclusiónȱ4ȱ ȱ - A pesar de lo anterior, la correspondencia funcional del emulador es estricta y acorde con escenarios de red reales análogos a nivel 2 y 3. - En cuanto a la funcionalidad de una arquitectura emulada se constata el uso correcto y adecuado del emulador a nivel 2 y 3. Conclusiónȱ5ȱ ȱ ȱ - Los dos experimentos de la latencia nos permiten fijar una latencia de red mínima emulada en función de la longitud de trama. - Permite fijar una latencia mínima a considerar sobre escenarios emulados de trabajo . Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 52 52 Longitudȱ deȱtramaȱ ȱ Configuraciónȱ hardwareȱ ȱ ȱ Arquitecturaȱdeȱȱ redȱȱÆÆȱ Nºȱdeȱ nodosȱ emuladosȱ activosȱ Dependenciasȱdeȱ laȱlatenciaȱdeȱred enȱ GNS3/Dynamipsȱ (ȱinteroperaciónȱ entornoȱrealȱ ÅÆ ȱ enornoȱemulado)ȱ MEDIA (similar al entorno real) MEDIA-ALTA ALTA (correcta/incorreta elección teórico/práctica de la tecnología a implementar) MUY ALTA (relacionado con el consumo de recursos) Tabla 5.4. Relación de dependencias de la latencia de red en GNS3/Dynamips. Las relaciones anteriores se interpretan gráficamente en la figura 5.3. Sobre esta figura se interpreta el grosor de los trazos que marcan las dependencias como indicativo de una mayor o menor dependencia. En la misma es conveniente señalar que la dependencia del valor de la latencia media de la red indirectamente con respecto a la arquitectura se circunscribe al hecho de que un mal diseño de la arquitectura y su topología asociada (dependencia indirecta vía consumo de recursos); una incorrecta elección de la tecnología para prestar un determinado servicio telemático (dependencia directa) puede implicar unos valores de latencia considerablemente elevados para la prestación del servicio, pudiendo quedar fuera de los márgenes recomendables establecidos por las recomendaciones ITU-T para la latencia extremo a extremo [19]. Figura 5.3. Interpretación gráfica de las dependencias existentes en la latencia de red emulada en la prestación de un determinado servicio telemático. Capítulo 5: Análisis final del proyecto, conclusiones y líneas futuras de trabajo y/o investigación. 53 53 5.3. Inconvenientes principales asociados al desarrollo del proyecto. Líneas futuras de trabajo y/o investigación. 5.3.1. Inconvenientes principales en el desarrollo del proyecto y soluciones adoptadas. El principal inconveniente, tal como se describe en el apartado 2.4, hace referencia a la imposibilidad actual de emular estrictamente dispositivos de la plataforma hardware Catalyst de Cisco Systems en GNS3/Dynamips. Relacionado con esta imposibilidad,la de implementar/emular sistemas Cisco CatOS en el entorno emulado. Es decir, en lo que a dispositivos Cisco Systems se refiere, GNS3/Dynamips solo emula sistemas Cisco IOS, por lo que aunando los dos inconvenientes deben analizarse y seleccionarse un adecuado dispositivo de red/sistema Cisco IOS para emular las características y prestaciones potenciales del hardware de red Cisco Catalyst 5500 Switch del laboratorio, en base al dispositivo multilayer EtherSwitch router de GNS3/Dynamips. Así mismo, debe conformarse en el entorno emulador sobre el dispositivo emulado EtherSwitch router, una arquitectura modular hardware similar a la del dispositivo real, disponiendo para ello de módulos virtuales de interfaces, reflejo de módulos hardware existentes en el mercado (para profundizar sobre esto puede consultarse el anexo 2, apartado 7.2.1). Añadido a los inconveniente anteriores, y aunque no puede catalogarse como una contingencia propiamente dicha, el desarrollo del proyecto ha exigido un profundo estudio y asimilación de contenidos teórico-prácticos relacionados con el dispositivo de red Cisco Catalayst 5500 Switch, de un modo particular, y del hardware de red Cisco Systems en general, además de los sistemas operativos asociados Cisco CatOS y Cisco IOS. Cabe destacar sobre el estudio de este dispositivo de red que al no disponer de información ni reseñas en el laboratorio sobre el mismo, la búsqueda de información, bibliografía adecuada, datasheets y manuales de uso ha sido una tarea ardua, debido a que la información existente en la red es amplia y variada. Acotar la conveniencia de la misma a nuestros propósitos de trabajo fue un proceso laborioso y complejo, por tratarse de hardware de cierta antigüedad sobre el que Cisco Systems no ofrece actualmente soporte. Es igualmente reseñable que el estudio en profundidad de los sistemas Cisco IOS ha sido absolutamente fundamental para configurar las arquitecturas emuladas en GNS3/Dynamips. En menor medida, también ha sido importante la asimilación del sistema operativo Cisco CatOS. El estudio de este último ha sido decisivo para poder trasladar al entorno emulado determinadas configuraciones que en el dispositivo Cisco Catalayst 5500 Switch se implementan indefectiblemente con comandos Cisco CatOS, configuraciones reflejadas en el anexo 1. Al respecto, los análisis anteriores, y la consiguiente elaboración del anexo 1, han servido para configurar los equipos Cisco Catalayst 5500 Switch actualmente utilizados en el laboratorio de telemática del DIEC. Otro inconveniente a destacar en el desarrrollo del proyecto es el que hace referencia a la correcta elección de la versión del entorno software GNS3/Dynamips, ya que se constató experimentalmente que versiones actuales del software presentaban ciertas Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 60 60 Principales comandos Cisco CatOS para administración & gestión en arquitecturas hardware Cisco Catalyst 5500 Switch vía módulo supervisor Cisco WS-X5530-E3. Una vez accedemos, vía consola, al módulo supervisor [5] a través del emulador de Terminal, con la configuración que se detalla en la figura 7.1, se muestra por pantalla el promt para el modo de operación usuario. Desde aquí, mediante el ingreso del comando: xConsole> enable , se accede al modo de operación enable-mode; visualmente,su promt es: x Console>(enable) En caso de estar protegido el acceso por contraseña, se nos solicitará su ingreso. Una vez en el modo de operación enable-mode, con el ingreso del comando: ? , obtendremos un listado de todos las posibles instrucciones susceptibles de ser ejecutadas desde el modo de operación en que nos encontremos, así como todas las opciones existentes para un comando, si ingresamos : ? , al final de un determinado comando (del que desconocemos las opciones completas que presenta para su ejecución). Interesante es destacar que mediante el uso de tabulador, el sistema busca aquella instrucción de posible ejecución que comprenda los caracteres ingresados hasta el momento desde el teclado (al igual que ocurre en otros sistemas operativos conocidos, como Unix/Linux). Figura 7.1. Configuración de HyperTerminal para la conexión al módulo supervisor Cisco WS-X5530-E3. Capítulo 7: Anexos 61 61 Desde el modo de operación enable-mode, podemos acceder a la disposición física y configuración de los módulos hardware presentes en la arquitectura Cisco Catalyst: xConsole>(enable) show modules , o podemos disponer de una información completa del mismo mediante: xConsole>(enable) show version xConsole>(enable) show module 5 , nos ofrece información (en este caso concreto) del módulo hardware nº 5. xConsole>(enable) show config , muestra la configuración actual del sistema. xConsole>(enable) show port [ nºmodulo / nº interfaz] , ofrece información del interfaz nº interfaz ubicado en el módulo nº modulo. xConsole>(enable) set module name [ nºmodulo mi_nombre] , da nombre mi_nombre al módulo nº modulo. xConsole>(enable) set port name [nºmódulo / nºinterfaz mi_nombre] , da nombre mi_nombre al interfaz nºinterfaz , del módulo nº módulo. xConsole>(enable) set port [nºmódulo / nºinterfaz][ enable , disable ] , activa o desactiva el interfaz correspondiente; por defecto, los interfaces se encuentran activos en Cisco CatOS. xConsole>(enable) set port [nºmodulo / nºinterface] duplex , configura el interfaz correspondiente en modo full dúplex. xConsole>(enable) set port speed [velocidad] , establece la capacidad (bps) del interfaz indicado. A través del módulo supervisor podemos acceder a otros módulos presentes en nuestro equipo Cisco Catalyst 5500 Switch, módulos que precisen de configuración y/o gestión, sin tener que conectarnos vía consola a dicho módulo específico (ni tener que desconectarnos, por lo tanto, del módulo supervisor): xConsole>(enable) session [nº modulo] , nos conecta al puerto consola del módulo nº módulo para su gestión y configuración. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 62 62 Tras esto, una vez en el módulo hardware en cuestión, la instrucción: exit , ejecutada desde el modo de operación usuario (Router>exit ), nos devuelve al módulo supervisor desde el que habíamos accedido previamente. Para anular/eliminar una instrucción/comando de configuración previamente ejecutado, se utiliza el mismo formato de comando, pero sustituyendo set Æclear . No es necesario guardar la configuración en funcionamiento para poder disponer de ella después de cada puesta en marcha o reinicio, pues CatOS salva automáticamente la misma tras presionar la tecla “Intro” después de cada instrucción, a diferencia de Cisco IOS, que precisa hacer la copia explícita de la configuración (con el comando: copy run start) Comandos Cisco CatOS para la configuración de escenarios VLAN desde el módulo supervisor Cisco WS-X5530-E3. Desde el modo de operación enablemode del módulo supervisor del Catalyst 5500, ejecutamos las tareas de creación/configuración VLAN y asignación física de interfaces a las mismas, así como tareas de configuración VTP (si procediese): xConsole>(enable) set vlan 100 xConsole>(enable) set vlan 200 , creamos vlan 100 y vlan 200 . xConsole>(enable) set vlan 200 8/13-24 , asigna a vlan 200 los puertos / interfaces 13 al 24, ambos inclusive, pertenecientes al módulo nº 8 . xConsole>(enable) set vlan 100 8/0-12 , asigna a vlan 100 los puertos / interfaces 0 al 12, ambos inclusive, pertenecientes al módulo n º 8 . xConsole>(enable) set vtp mode [ client | server | transparent ] , asigna (en el ámbito de un dominio VTP) el rol del dispositivo . xConsole>(enable) set vtp domain [mi_nombre] , asigna/relaciona el Catalyst 5500 con el dominio VTP mi_nombre (si el switch es servidor o cliente, no en modo trasparente )[2] [10] . Una vez acometidas las tareas de gestión VLAN anteriores, se procede con la configuración a nivel 3, para conferir a nuestro sistema de capacidades de InterVLAN Capítulo 7: Anexos 63 63 routing que presentan los equipos multilayer Cisco Catalyst 5500 Switch (y similares). Este aspecto va a ser fundamental en las configuraciones a implementar en el entorno emulado GNS3/Dynamips. Para ello, la disposición hardware de los equipos utilizados en el laboratorio presenta dos módulos hardware Cisco RSM WS-X5302 (Route–Switch Module), independientes entre sí. Dichos módulos en nuestro caso, adicionalmente ejercen control sobre sendos módulos Cisco 8-port Multichannel T1/E1 PRI, debiendo estar estos físicamente contiguos a su correspondiente módulo RSM “gestor” (así es requerido desde un punto de vista de configuración hardware por la arquitectura Cisco Catalyst 5500 Switch)[4]. De este modo, y bajo un prisma de diseño LAN/WAN, la versatilidad de nuestro dispositivo para ofrecer prestaciones a nivel 2 y 3 según el modelo de referencia OSI sobre escenarios de Internetworking queda de manifiesto. A continuación, nos ocupamos de las prestaciones del módulo RSM para implementar InterVLAN routing (switching a nivel 2 - 3 ), y routing entre dispositivos de nivel 3 . 7.1.4. Configuración del módulo Router-Switch Module Cisco WS-X5302. Gestión & configuración VLAN Tras la creación/configuración de VLAN (y VTP, si procede), y la correspondiente asignación de interfaces a las mismas desde el módulo supervisor, accedemos al módulo Cisco RSM WS-X5302 [4] para acometer las tareas de switching & routing entre VLAN. La gestión de dicho módulo RSM se realiza por medio de comandos Cisco IOS, no CatOS . Desde el módulo supervisor (en modo usuario o enable-mode), ejecutamos: xConsole> session 4 xRouter> , redirigiéndonos el comando anterior al módulo nº4 de nuestro dispositivo. En nuestro caso concreto, los equipos Cisco Catalyst 5500 Switch del laboratorio de telemática, disponen de dos módulos RSM ubicados en respectivas bahías/slots nº 4 y nº 6 (pudiendo acceder a cualquiera de ellos). Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 64 64 ¡Importante! Dichos módulos RSM son independientes, y por lo tanto así sus configuraciones. Como refleja la figura 7.2, el módulo RSM nº 4 controla y opera sobre el módulo Cisco 8-port Multichannel T1/E1 PRI situado en el módulo nº 3 contiguo del Cisco Catalyst, lo mismo que el módulo RSM nº 6 opera sobre el módulo nº5 Cisco 8-port Multichannel T1/E1 PRI . Pero ambos módulos nº 4 y nº 6 pueden operar, indistintamente, sobre los módulos hardware nº 7 y nº 8, que son módulos que disponen de 24 puertos FastEthernet cada uno. Figura 7.2. Dispositivo de red Cisco Catalyst 5500 Switch presente en el laboratorio de Telemática del DIEC. Resulta interesante, y muy recomendable, dar nombre a los módulos RSM para evitar confusiones y facilitar el trabajo futuro: xRouter> enable , accedemos al modo de operación EXEC privilegiado. xRouter# configure terminal , o simplemente: conf t , accedemos al modo de operación global. xRouter(config)# hostname RSM4 Capítulo 7: Anexos 65 65 A partir de aquí, para la configuración de los interfaces virtuales SVI asociados a cada VLAN, interfaces que nos permitirán realizar switching a nivel 3 entre VLAN diferentes (sin necesidad de acceder a un router externo mediante un enlace troncal con protocolo 802.1q /ISL), se accede al modo de configuración global Æ de interfaz VLAN: xRSM4(config)# interface vlan 100 xRSM4(config-if)# ip address 192.168.100.1 255.255.255.0 , asignamos una dirección IP al correspondiente SVI, considerando que vlan 100 tiene la dirección de red IP 192.168.100.0 / 24 xRSM4(config-if)# no shutdown , activamos el interface SVI. xRSM4(config-if)# exit , pasamos al modo de operación global para proceder con vlan 200 xRSM4(config)# interface vlan 200 xRSM4(config-if)# ip address 192.168.200.1 255.255.255.0 xRSM4(config-if)# no shutdown , activamos el interfaz SVI . xRSM4(config-if)# exit , pasamos del modo de operación global Æ de interfaz al modo global. xRSM4(config)# Nótese que por claridad en la gestión y administración futuras se ha asignado al tercer octeto de las direcciones de red IP de las VLAN el número identificador de la VLAN correspondiente. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 66 66 Para habilitar las funciones de enrutamiento/switching (a nivel 3) vía RSM : xRSM4(config)# ip routing Si precisamos habilitar algún protocolo dinámico de enrutamiento para establecer la comunicación con “el mundo exterior” (a nivel 3): xRSM4(config)# router rip , modo de operación global Æ de protocolo. xRSM4(config-router)# version 2 . xRSM4(config-router)#network [dirección IP de la red mayor del interfaz y sin máscara ] , activamos en este caso RIP v2; habilitamos, para enviar y recibir actualizaciones de enrutamiento los interfaces correspondientes, con dirección IP de la red mayor a la que pertenece el interfaz. Por defecto, los interfaces están inactivos en este ámbito de trabajo, de ahí la necesidad de activarlos. Para añadir rutas estáticas de enrutamiento: xRSM4(config-router)# ip route [red destino] [mascara] [próximo salto] [distancia administrativa] , por defecto, de cara a la tramitación de información de routing, las rutas estáticas tienen distancia administrativa = 1. , y si añadimos una ruta por defecto: xRSM4(config-router)# ip route 0.0.0.0 0.0.0.0 [próximo salto] Para salvar toda la configuración de nuestro módulo RSM, y desde el modo de operación EXEC privilegiado: xRSM4# copy run start , modo abreviado de: copy running-config startup-config . Para visualizar nuestra configuración actual: xRSM4# show running-config , , o simplemente, con el comando abreviado: show run . Capítulo 7: Anexos 67 67 7.1.5. Configuración de Interfaces E1 en módulos Cisco 8-port Multichannel T1/E1. Uso como conmutador Frame-Relay. Planteamos de un modo práctico la configuración sobre el módulo hardware nº 3 de nuestra arquitectura Cisco Catalyst 5500 Switch del laboratorio, que es el módulo Cisco 8- port Multichannel T1/E1 PRI [6] gestionado por RSM4 (recordemos, RSM4 gestiona su módulo contiguo nº 3, y RSM6 gestiona su módulo contiguo nº 5). Configuramos los interfaces E1 (estructurados, según estándar G.704 [19] ) que precisemos a través de los siguientes comandos Cisco IOS : xConsole > session 4 xRSM4> enable xRSM4# configuration terminal , o simplemente : conf t . xRSM4 (config)# controller e1 0/0 , accedemos al slot 0 / interfaz 0 (de los 8 interfaces E1 controlados por RSM4) xRSM4(config-controller)# framing no-crc4 xRSM4(config-controller)# channel group 0 timeslot 1 - [ timeslot ] , con ello hemos creado el interfaz serial 0 / 0 : 0 xRSM4(config-controller)#exit xRSM4(config)#interface serial 0/0:0 xRSM4(config-if)#no shutdown xRSM4(config-if)#bandwith [ ancho de banda ] xRSM4(config-if)#no ip address xRSM4(config-if)#encapsulation frame-relay ietf xRSM4(config-if)#no keepalive , desactivamos LMI. xRSM4(config-if)#exit En el supuesto de querer configurar interfaces E1 desestructurados (unframed): Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 68 68 xRSM4# configuration terminal , o simplemente: conf t. xRSM4(config)# controller e1 0/0 , accedemos al slot 0, interfaz 0 (de los 8 interfaces E1 que disponemos) xRSM4 (config-controller)# channel group 0 unframed , con ello hemos creado el interfaz serial 0 /0 : 0 desestructurado (unframed) Una vez creado el interfaz serial, procedemos igual que antes. xCisco Catalyst 5500 Switch : uso como conmutador WAN Frame Relay Con la finalidad de profundizar en el funcionamiento del Cisco Catalyst 5500 Switch como conmutador Frame Relay, se plantea el supuesto práctico básico de interconectar vía Frame Relay dos router del laboratorio 2.03, tal como muestra la figura 7.3. Para ello, en primer lugar deberemos configurar sobre el módulo 8-port Multichannel T1/E1 PRI (módulo nº 3 del switch, por ejemplo), 2 interfaces siguiendo el estándar (G.703 ó G.704) que deseemos, según se ha mostrado en el punto anterior (configuraremos, por ejemplo, los interfaces serial 0/0:0 y serial 0/1:0). Figura 7.3. Escenario de estudio planteado en el laboratorio para el uso del Cisco Catalyst 5500 como conmutador WAN Frame Relay. Capítulo 7: Anexos 69 69 Según este escenario de conmutación Frame Relay: Router1 : Enlace Router 1 Æ interface E1 de equipo Catalyst 5500 (interfaz serial 0/0:0 ) DLCI asignado: 21 Router2 : Enlace Router 2 Æ interface E1 de equipo Catalyst 5500 (interfaz serial 0/1:0 ) DLCI asignado: 22 ¡Importante!. En este escenario, carece de sentido hablar de la configuración de los interfaces E1 del Cisco Catalyst como DTE o DCE. Ambos interfaces presentarán configuración NNI. A continuación, se establecen los PVC (circuitos virtuales), para la conmutación WAN Frame Relay del tráfico, y así intercomunicar los dos router: xRSM4 (config)#frame relay switching , configuramos nuestro módulo RSM4 con capacidad de conmutación Frame Relay. xRSM4 (config)# interface serial 0/0:0 xRSM4 (config-if)#frame-relay intf-type nni xRSM4 (config-if)#frame-relay route 21 interface serial 0/1:0 22 , según esta configuración, el switch conmuta el tráfico que venga por el interfaz serial 0/0:0 con DLCI 21, al interfaz serial 0/1:0 con DLCI 22 . xRSM4 (config-if)#exit Establecemos la configuración “espejo” de la anterior para el interfaz serial 0/1:0: xRSM4 (config)# interface serial 0/1:0 xRSM4 (config-if)#frame-relay intf-type nni xRSM4 (config-if)# frame-relay route 22 interface serial 0/0:0 21 xRSM4 (config-if)#exit xRSM4 (config)# Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 76 76 Figura 7.8 a). Configuración VLAN: configuración y asignación VLAN de interfaces en nodos emulados EtherSwitch router. Con ello, quedan configuradas las facilidades para realizar conmutación a nivel 2 entre equipos pertenecientes a una misma VLAN, y conmutación a nivel 3 entre VLAN diferentes (VLAN2 y VLAN3, en este caso); todo ello, y en este punto del análisis, en el ámbito VLAN de un mismo nodo EtherSwitch Router. En este punto es reseñable, de cara a establecer una comparativa entre los entornos de red real (laboratorio) y emulado, que la misma asignación de interfaces realizada en la figura 7.8 a) anterior se implementaría en el equipo real Cisco Catalyst 5500 Switch por medio de comandos Cisco CatOS [3][7], conforme a las particularidades descritas en el apartado 2.4 y siguiendo el anexo 1, obteniendo funcionalmente el mismo resultado. Configuración VLAN complementaria: configuraciones en modo VLAN Database. Se da la circunstancia de que determinados sistemas Cisco IOS (es realmente muy difícil concretar cuáles por la gran cantidad de sistemas y versiones existentes de dispositivos Cisco Systems en el mercado,pero suelen ser sistemas relativamente antiguos) precisan de una configuración adicional a la hora de implementar correctamente la configuración VLAN. Esto se ejecuta en un submenú o modo de configuración denominado VLAN Database. Los sistemas Cisco IOS antiguos precisaban de dicho modo de configuración para establecer toda la configuración VLAN. En sistemas Cisco IOS actuales, toda la configuración VLAN se establece desde el modo de operación o configuración global. Pero en esta transición entre ambas formas de operar existen sistemas que precisan de una cierta configuración adicional. A grandes rasgos,es una configuración suplementaria para “activar” la configuración VLAN previamente establecida desde el modo de configuración global. Es decir, para que la configuración VLAN se implemente correctamente, debemos acceder a dicho submenú y proceder a la activación. Este es un sencillo proceso, pero presenta el inconveniente funcional de que no se conserva en la memoria del dispositivo y Capítulo 7: Anexos 77 77 se borra cada vez que se apaga o reinicia el dispositivo (no como el resto de las configuraciones en Cisco IOS, si procedemos a guardarlas en memoria). Se han encontrado posibles respuestas en foros de Internet para solucionar este inconveniente y poder conservar en memoria la “activación”, pero ninguna ha resultado ser realmente efectiva. En sistemas Cisco IOS actuales, dicha configuración VLAN Database ya no es precisa y es suficiente con el proceso de configuración VLAN general del punto anterior. El acceso a dicho submenú o modo de configuración VLAN Database también es necesario, si el sistema es relativamente antiguo, para configurar las funcionalidades del protocolo VTP que se ven en el siguiente apartado 7.2.6. Para acceder a dicho submenú VLAN Database y proceder a la “activación” VLAN que completa el proceso de configuración anterior, se accede desde el modo de operación EXEC privilegiado, procediendo como indica a continuación la figura 7.8 b), en base a comandos Cisco IOS. Se observa un “warning” del sistema recomendando usar el modo de configuración global para acometer tareas de configuración VLAN, acorde a las indicaciones antes descritas acerca de la relativa antigüedad del modo de operación VLAN Database, pero se comprueba empíricamente que si no operamos de esta forma los interfaces virtuales SVI no se activan convenientemente. Resumiendo, para cada sistema Cisco IOS deberá comprobarse la necesidad de proceder con dicha activación adicional. Figura 7.8 b). Configuración VLAN: activación de interfaces SVI desde VLAN Database. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 78 78 Verificación de la conectividad VLAN en el emulador GNS3/Dynamips. Configuramos primero equipo_real 1 (integrado éste en el entorno emulado según indica el anexo 3), asignando dirección IP 192.168.2.2 / 24 al inferfaz de red Ethernet de equipo_real 1 (PC portátil real y externo al emulador), según refleja la figura 7.9. Figura 7.9. Configuración de interfaz Ethernet en equipo_real 1. Del mismo modo, se configura QEMU3, asignando la dirección IP 192.168.3.2 / 24 al interfaz Ethernet eth0 del host emulado Linux QEMU3, además de una puerta de enlace predeterminada través de dicho interfaz eth0 : tc@QEMU3:~$ sudo ifconfig eth0 192.168.3.2 tc@QEMU3:~$ sudo route add default gw 192.168.3.1 eth0 Resulta interesante en este punto del estudio ver que en la configuración del interfaz de red de equipo_real 1 (figura 7.9) estamos considerando como default gateway para el mismo el interfaz virtual SVI de VLAN2, previamente configurado en el entorno emulado, procediendo así a la potencial interoperación entre equipos reales y virtualmente emulados. A continuación, mediante el comando Linux traceroute, y desde QEMU3 (192.168.3.2 /24, host virtual Linux adscrito a VLAN3), se comprueba la conectividad VLAN, así como el trayecto seguido por el tráfico de red implicado, según la figura 7.10. Capítulo 7: Anexos 79 79 Figura 7.10. Test de conectividad y trayectoria del tráfico en la conmutación VLAN a nivel 3. , observando como primero ( hop 1 ) se “alcanza” el SVI de VLAN3, y desde allí ( hop 2 ) se conmuta el tráfico a nivel 3 hacia el host de destino con dirección IP 192.168.2.2 /24 (equipo portátil real 1 externo, adscrito a VLAN2). Es destacable que esta misma verificación en la conectividad VLAN permitiría establecer una primera conclusión en el estudio de la hasta ahora potencial capacidad que ofrecía el entorno de emulación GNS3/Dynamips para interoperar tráfico de red real y emulado: la comprobación de la anterior conectividad VLAN, se ha realizado mediante una correcta interoperación entre tráfico/equipos reales y emulados. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 80 80 Configuración VLAN ( VLAN2 y VLAN3 ) en nodo emulado EtherSwitch router 2 De modo similar a la configuración expuesta anteriormente, se procede para configurar VLAN2 y VLAN3 en el nodo EtherSwitch router 2, salvedad hecha con el espacio de direcciones de red asignado, siendo ahora: VLAN2 : 192.168.4.0 / 24 VLAN3 : 192.168.5.0 / 24 Es conveniente clarificar aclarar en este caso que para la arquitectura actual de estudio (WAN ppp), el espacio de direcciones IP a configurar para una misma VLAN administrativa según nuestros intereses de trabajo, pero en entornos locales diferentes, no es el mismo (conexión VLAN a nivel 3). ¿Por qué? La causa reside, como se verá en detalle más adelante, en que si esto no fuese así, al intercambiar los respectivos nodos EtherSwitch router la información de sus tablas de enrutamiento, éstas no se actualizarían convenientemente, pues los router creerían estar actualizando información que ya disponen en su tabla, por tener idéntica dirección IP y máscara. Pero esta información es distinta de la que ya tienen, y se encuentra en un dominio broadcast diferente. Por lo tanto, dicha información es “aprendida” por los router a través del protocolo de enrutamiento dinámico correspondiente (RIP v2, en nuestro estudio) y con distancia administrativa mayor (distancia administrativa de RIP = 120) [8]. El dispositivo entendería que está actualizando una información que ya tiene en su tabla con distancia administrativa menor (la información que dispone de la misma VLAN “directamente conectada” tiene distancia administrativa = 0), por lo que no incorporaría la información nueva en sus tablas, discriminando así la misma sobre equipos y dispositivos adscritos a la misma VLAN administrativa, pero que están en otro dominio broadcast. En el escenario VLAN conmutado que se abordará seguidamente en este anexo, se configurará para las VLAN la misma dirección IP y máscara de red, aunque éstas se encuentren físicamente en nodos de red diferentes. Conexión de los nodos EtherSwitch router vía enlace serie WAN point-to-point Para configurar el enlace serie WAN ppp entre los nodos referidos, se deben asignar direcciones de red IP a los interfaces serie implicados (se configura el interfaz serial 2/0 en ambos nodos, para facilitar el análisis), según el mapa de direcciones de red establecido en el diseño de la figura 3.1. Capítulo 7: Anexos 81 81 Al respecto: xenlace serie WAN ppp ÅÆ subred 155.210.157.248 /30 xdirección IP del interfaz serial 2/0 en el nodo 1Æ155.210.157.249 /30 xdirección IP del interfaz serial 2/0 en el nodo 2: 155.210.157.250 /30. Es necesario recalcar, con objeto de clarificar el mapa de direcciones IP de nuestro escenario de trabajo, que sobre la dirección IP de la red mayor del enlace serie (155.210.0.0/16 ) se ha realizado subnetting [1], con máscara de subred /30 (equivalente a la máscara 255.255.255.252), para un óptimo aprovechamiento de las direcciones IP disponibles en un escenario telemático real. Este diseño sería aplicable, por ejemplo, en un entorno de trabajo que precise implementar numerosas conexiones/subredes independientes, con muy pocos nodos implicados en su infraestructura WAN de interconexión, enlaces serie fundamentalmente: dicho mapa de direcciones sólo permite dos nodos por conexión/subred WAN, en principio [1]. Adicionalmente, sobre cada subred, se procedería a implementar sus respectivos entornos de trabajo LAN/VLAN. Seguidamente, procedemos a activar el protocolo a configurar para el enlace serie, en este caso ppp ( point-to-point protocol ). Todo este proceso, con los comandos Cisco IOS ejecutados, se ilustra de modo explícito a continuación en la figura 7.11. Figura 7.11. Configuración del enlace serie WAN ppp en nodo EtherSwitch router 1. De modo análogo se procedería para configurar el interfaz serial 2/0 en el nodo EtherSwitch router 2. A la hora de configurar cualquier interfaz no debe olvidarse en dispositivos Cisco Systems el comando destinado a “activar” el mismo, pues no basta solo con asignarle una dirección de red para que se muestre activo (en sistemas basados en Cisco IOS, por defecto, los interfaces se encuentran desactivados). Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 82 82 En este punto, se realiza una primera consulta de las tablas de enrutamiento que los nodos emulados EtherSwitch router tienen configuradas hasta el momento, con el ingreso del comando Cisco IOS definido para ello y desde el modo EXEC privilegiado, según la figura 7.12 , y el anexo 1. Figura 7.12. Tabla de enrutamiento (situación inicial) en el nodo EtherSwitch router 1. Según refleja la tabla de enrutamiento anterior, el nodo EtherSwitch router 1 no tiene constancia de los dispositivos conectados al nodo EtherSwitch router 2 (y viceversa). ¿Cuál es el motivo? En este punto de la configuración de red no se ha producido intercambio de información a nivel 3 entre dispositivos porque no se ha configurado para ello un protocolo (dinámico) de enrutamiento en los mismos, o bien como alternativa a esto, el administrador de red no ha procedido a la configuración de rutas estáticas que permitan la comunicación entre los equipos y dispositivos implicados en el escenario de trabajo. Conforme a esto, se procede a configurar un protocolo de enrutamiento dinámico en el entorno emulado. Configuración del protocolo de enrutamiento RIP v2 en el entorno emulado. Se procede a la configuración y activación del protocolo de enrutamiento dinámico RIP v2 en el entorno emulado de trabajo. Para ello, tal como se mencionó anteriormente, en sistemas Cisco IOS los protocolos de enrutamiento deben activarse a nivel de interfaz (modo de configuración global Æ interfaz , anexo 1), estando por defecto desactivados. Capítulo 7: Anexos 83 83 Con esta “activación”, se habilita el envío y recepción de información y actualizaciones de las tablas de enrutamiento en un dispositivo, a través del interfaz activado. Figura 7.13. Configuración del protocolo RIP v2 en el nodo EtherSwitch router emulado. Según describe la figura 7.13 anterior, se activa el protocolo RIP v2 en aquellos interfaces que deseemos presenten implicación completa a nivel 3 en el entorno de red de trabajo (es decir, que envíen actualizaciones de su tabla de enrutamiento y también reciban actualizaciones de las tablas de otros dispositivos implicados en el escenario). Como se observa, en sistemas Cisco IOS, dicha activación se realiza “informando” de la dirección IP de la red mayor a la que pertenece el interfaz a activar. Como RIP v2 es un protocolo classless [8] (a diferencia de RIP que es classfull y no “anuncia” las máscaras de sus tablas), el protocolo se encargará de informar adecuadamente de la mascara de red asociada a las subredes implicadas en la comunicación. Por ello, el uso de RIP v2 es más adecuado que RIP en este escenario de trabajo, ya que hemos realizado subnetting para conectar los nodos EtherSwitch router por medio del enlace serie WAN ppp (recordemos, subred 155.210.157.248 /30), evitando así el riesgo de que la información relativa a subredes (de la red mayor 155.210.0.0 /16 ) no se difunda y actualice correctamente. Al respecto, conviene apuntar que no existe inconveniente en haber usado RIP en el diseño, pero en este caso debería tenerse especial atención en desactivar el comportamiento classfull del protocolo, desde el modo de configuración global Æ protocolo, por medio del comando Cisco IOS : switch_router1(config-router)#ip classless , evitando así los riesgos de pérdida de información anteriormente descritos [8]. Llegados a este punto del análisis, configurado ya todo el entramado de interfaces (FastEthernet,serie y SVI ), VLAN y protocolos implicados en la comunicación, se realiza consulta de las tablas de enrutamiento configuradas (y supuestamente aprendidas y Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 84 84 actualizadas a través del protocolo dinámico RIP v2) en los nodos emulados EtherSwitch router, obteniendo así información relevante de la conectividad y el tráfico de red que debería circular actualmente por el entorno de red emulado (figura 7.14). Así mismo, podemos extraer importantes conclusiones acerca de la comunicación establecida para el intercambio y actualización de la información de routing entre nodos virtuales emulados en GNS3/Dynamips, y analizar así el rigor funcional del emulador. Mediante el ingreso desde el modo de configuración EXEC privilegiado del comando Cisco IOS: switch_router1#show ip route ,se observa en la figura 7.14 la tabla de enrutamiento que una vez activado el protocolo RIP v2 presenta el nodo emulado Etherswitch router 1. En la misma se aprecia como el dispositivo aprende vía RIP la información de red que dispone el nodo 2: es decir, se ha establecido comunicación entre ambos nodos virtuales para proceder al intercambio y actualización de sus tablas de enrutamiento. A tal efecto, por el entramado virtual debería circular tráfico de red relacionado con la actualización y mantenimiento de la información asociada al protocolo RIP v2. Esto lo vemos en el apartado 3.1.2 del capítulo 3 y en el siguiente apartado 7.2.2. Figura 3.2.2.10 Tabla de enrutamiento final para el nodo ETherSwitch router1 Figura 7.14. Tabla de enrutamiento final después de habilitar RIP v2 en el entorno emulado del análisis. Capítulo 7: Anexos 85 85 7.2.2. Análisis exhaustivo del tráfico de red emulado en el enlace serie WAN ppp. Completando el contenido del apartado 3.1.2 del correspondiente capítulo 3, para profundizar en el análisis del tráfico de red emulado se contrasta, por ejemplo, la trama nº 19 de la figura 3.3 (figura que reproducimos nuevamente por claridad de la exposición), trama relacionada con el protocolo de enrutamiento dinámico RIP v2. La figura 7.15 siguiente muestra esta información. Figura 3.3. Tráfico de red en el enlace serie WAN ppp del entorno emulado. Figura 7.15. Trama capturada en el enlace serie WAN ppp con información RIP v2. Se aprecia como la trama capturada contiene información acerca de la tabla de enrutamiento actual del nodo EtherSwitch router 2, y se publica con dirección IP de destino multicast 224.0.0.9,desde el interfaz serial 2/0:dirección IP 155.210.157.250 /30. Esta información permite a dispositivos de red que operan en el nivel 3 del modelo de Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 92 92 7.2.4. Análisis del tráfico de red en el enlace equipo real 1 ÅÆ nodo virtual emulado 1 para el análisis de la interoperabilidad de los entornos de red. Haciendo uso de la herramienta software Wireshark se realiza captura del tráfico de red en el enlace indicado, enlace en el que se efectúa la interoperación de los entornos de red real y emulado. Se pretende verificar en este momento el rigor y la correspondencia funcional del entorno de emulación en cuanto a la estructura de las tramas, y por consiguiente, del tráfico de red implicado en el experimento. Figura 7.21.a) Tráfico de red capturado en el enlace equipo_rea1 l Æ nodo virtual 1, para una longitud de trama Ethernet de 64 bytes (longitud mínima, MTU = 46 bytes) en la arquitectura WAN ppp. Una primera aproximación al tráfico capturado de las figuras 7.21 a) y 7.21 f) nos permite comprobar el rigor y correspondencia funcional del emulador, verificando que realmente circulan por el entorno de red emulado tramas estructuralmente acordes al tráfico real generado con el comando ICMP (ping) desde equipo rea1 1 externo. En segundo lugar, nos permite extraer una conclusión importante y decisiva en el análisis de la interoperación entorno real ÅÆ entorno emulado, objetivo prioritario del proyecto: el interfaz de red Ethernet (del PC emulador) utilizado para integrar entornos de red reales en GNS3/Dynamips presenta un funcionamiento asimilable a un proxy ”transparente” entre ambos entornos. Este interfaz “conmutaría” automáticamente el tráfico de red real hacia el entorno emulado, y viceversa. Analicemos lo que sucede en la figura 7.21 a). Cuando se produce la primera petición de eco (ping) desde el equipo real 1 (192.168.2.2) con destino el interfaz virtual SVI del nodo EtherSwitch router1 (192.168.2.1), al desconocer equipo real 1 la dirección física (MAC) correspondiente a la dirección IP destino, se realiza una petición ARP en el dominio broadcast en que nos encontramos. Esta petición ARP es Capítulo 7: Anexos 93 93 respondida por el interfaz virtual SVI, informando de su dirección física (MAC). Al respecto, esta dirección MAC “virtual” es dinámicamente asignada por el nodo EtherSwich router en el proceso de configuración VLAN y/o cada vez que ponemos en funcionamiento el dispositivo, y todos los interfaces virtuales SVI configurados tienen la misma dirección MAC virtual. Tras responder a la petición broadcast ARP, el equipo real 1 tiene conformadas ya las correspondencias físicas y lógicas con las que asignar las direcciones de origen y destino a nivel 2 correspondientes a las direcciones IP. Y si comprobamos esta tabla ARP vemos que en la misma no hay ninguna entrada que haga referencia al interfaz Ethernet utilizado en la interoperación. Únicamente se hace referencia al interfaz SVI emulado. Del mismo modo, si comprobamos la tabla ARP del nodo EtherSwitch router emulado, vemos que esta sólo hace referencia a la dirección MAC del interfaz Ethernet del equipo real 1. Estas tablas ARP se muestran en las figuras 7.20 b) y7.20 c) siguientes. Así, en todo esto subyace que el interfaz Ethernet empleado para implementar la interoperación funcionalmente puede desglosarse en un interfaz hardware real y un interfaz software emulado, produciéndose una “conmutación” incondicional entre ambos. Dicho de otra manera, su funcionamiento puede asimilarse al de un proxy de obligado e incondicional paso/conmutación entre ambos entornos de red. Esta “conmutación” entorno real ÅÆ entorno emulado influirá decisivamente en la latencia de red en la interoperación entre ambos entornos de trabajo. Figura 7.21.b) Tabla ARP en nodo emulado EtherSwitch router 1. Figura 7.21.c) Tabla ARP en equipo real 1. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 94 94 Un análisis más detallado de una trama de la figura 7.21 a), por ejemplo la trama nº 15, nos muestra cómo para alcanzar 192.168.2.1 (interfaz SVI emulado del nodo 1) desde 192.168.2.2 (equipo real 1) la dirección MAC de destino es la dirección MAC virtual del interfaz SVI. Del mismo modo, la trama nº 16 muestra cómo para alcanzar 192.168.2.2 desde 192.168.2.1 la dirección MAC de destino es la dirección física del interfaz Ethernet de equipo real 1. Esto se ve reflejado en las subfiguras 7.21 d) y 7.21 e) siguientes. Figura 7.21 d) .Trama nº 15: ping 192.168.2.2 ( equipo real 1)Æ 192.168.2.1 ( interfaz SVI) Figura 7.21 e) .Trama nº 16: ping 192.168.2.1(interfaz SVI) Æ 192.168.2.2 (equipo real 1) Para comprobar las direcciones MAC en el nodo EtherSwitch router1 hacemos uso del comando Cisco IOS :show mac , desde el modo de operación EXEC privilegiado de la consola del dispositivo, confirmando el valor mostrado en las figuras anteriores (C4:01:04:30:00:00). También podemos observar las entradas en la tabla ARP mediante el comando: show arp , confirmando la entrada en la tabla que hace referencia al interfaz Ethernet de equipo real 1 (1C:75:08:78:16:1C). En conclusión, el interfaz Ethernet empleado en la interoperación puede considerarse “transparente” a los entornos real y emulado. Eso sí, tendrá una influencia manifiesta en la latencia de red en la interoperación entorno real ÅÆ entorno emulado. Capítulo 7: Anexos 95 95 Figura 7.21 f). Tráfico de red capturado en el enlace equipo_rea1 l Æ nodo virtual 1, para una longitud de trama Ethernet de 1514 bytes ( MTU = 1500 bytes ) en la arquitectura WAN ppp. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 96 96 7.2.5. Configuraciones de red adicionales para el análisis de prestaciones y rendimiento del emulador GNS3/Dynamips en la arquitectura WAN ppp. Para configurar el escenario global de trabajo de la figura 3.1 que nos permite abordar el análisis de la capacidad y rendimiento del sistema emulador del capítulo 4 procedemos como se indica a continuación. Por comodidad y claridad en la exposición, se muestra de nuevo la figura 3.1 en la página siguiente. Siendo así, y de cara a establecer una relación más significativa entre el número de nodos activos participantes en el escenario emulado de trabajo (router-switch multilayer) y el rendimiento/consumo de recursos del sistema emulador, sobre nuestra arquitectura de red principal se añaden 2 enlaces serie ppp que interconectan los nodos EtherSwitch router 1 y EtherSwitch router 2 con sendos nodos emulados EtherSwitch router, que denominamos nodos Auxiliar 1 y 2, sin ningún propósito especial de diseño telemático. El único objetivo es evaluar la repercusión directa sobre el rendimiento del sistema emulador según el número de nodos emulados activos en un escenario (para evaluar la potencial escalabilidad del diseño de la arquitectura). Desde la perspectiva teórica de administración & gestión de redes a nivel 3, estamos interconectando (mediante enlaces serie WAN ppp) nuestra arquitectura de trabajo principal, la subred 155.210.157.248 / 30, con las subredes 155.210.157.240 / 30 y 155.210.157.244 / 30, todas ellas subredes de la red mayor 155.210.0.0 / 16 (esquema general administrativo reflejado en la figura 7.22). Figura 7.22. Esquema administrativo de diseño a nivel 3, según el modelo de referencia OSI, configurado para el análisis de la capacidad y rendimiento del sistema emulador. Capítulo 7: Anexos 97 97 Este “rediseño” ampliado de la arquitectura de red principal, con las correspondientes direcciones IP y máscaras de subred asignadas (recordemos, sin ningún propósito especial telemático de diseño), permite extraer los resultados mostrados en las tablas 4.2 y 4.3 del análisis de la capacidad y rendimiento del sistema emulador del capítulo 4. Figura 3.1. Topología/simulación gráfica en GNS3 de la arquitectura de red WAN ppp ( Nodos/conexiones/subredes incorporados en la arquitectura de red principal WAN ppp para analizar el rendimiento y prestaciones del sistema emulador). Configuramos a continuación los nodos EtherSwitch router Auxiliar 1 y 2. Para configurar las nuevas subredes de este “nuevo” escenario ampliado de trabajo accedemos vía consola en los nodos emulados al entorno de configuración Cisco IOS, asignando las direcciones de red necesarias en los interfaces que interconectan los nodos, según las figuras 7.23 y 7.24 mostradas en la página siguiente. Recordemos que desde la perspectiva teórica de administración & gestión de redes a nivel 3 según el modelo de referencia OSI, estamos interconectando (mediante enlaces serie ppp) nuestro escenario de trabajo principal , la subred 155.210.157.248 / 30, con las subredes 155.210.157.240 / 30 y 155.210.157.244 / 30, todas ellas subredes de la red mayor 155.210.0.0 / 16 (esquema general administrativo reflejado en la figura 7.22). Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 98 98 xNodos EtherSwitch router 1 / auxiliar 1 ( subred 155.210.157.240 / 30 ) Figura 7.23. Comandos Cisco IOS para la configuración de la subred 155.210.157.240 / 30. xNodos EtherSwitch router 2 / auxiliar 2 ( subred 155.210.157.244 / 30 ) Figura 7.24. Comandos Cisco IOS para la configuración de la subred 155.210.157.244 / 30. Capítulo 7: Anexos 99 99 Una vez configurada completamente la arquitectura de red para el análisis global de los propósitos de los capítulos 3 y 4, y para profundizar un poco más sobre nuestros análisis, recuperamos de nuevo, por ejemplo, la tabla 4.2 del capítulo 4. Utilizamos esta tabla para hacer ciertas consideraciones teórico-prácticassobre los host emulados Linux QEMU. Configuración hardware 1 Carga de CPU (offmode)3 MemoriaRAM en uso en MB (offmode) Carga media de CPU (pseudoactivo) 4 Memoria RAM en uso en MB (pseudoactivo) 1switch-router activo 1% max. 318 1-2 % 780 Æ 540 2switch-router activos 1% max. 318 4 % Æ 2-3 % 940 Æ 720 2 switch-router activos + 1 QEMU 1% max. 318 16 % Æ 14 % 950Æ 750 2switch-router activos + 2 QEMU 1% max. 318 17 % Æ15 % 960Æ 760 2switch-router activos + 1 auxiliar ( sin QEMU) 1% max. 318 6 % Æ 4-5 % 970Æ 760 2switch-router activos + 2 auxiliar ( sin QEMU) 1% max. 318 11% Æ 9-10 % 980 Æ 790 Tabla 4.2. Consumo de recursos del sistema emulador para la configuración hardware 1, bajo S.O. Windows XP 32 bits y arquitectura de red WAN ppp. Conclusiones sobre el uso de host emulados Linux QEMU xLos terminales QEMU son host virtuales que emulan sistemas operativos Linux. A la vista de los resultados mostrados en la tabla 4.2, si comparamos paralelamente el consumo de CPU entre las filas nº2 ÅÆ nº3 se aprecia que el uso de dichos terminales eleva significativamente (un 12 % aproximadamente) la carga de CPU. 3 Estado inicial en el que ningún nodo y/o terminal QEMU está en funcionamiento. 4 Estado en el que el tráfico de red presente es el relacionado con el mantenimiento y actualización de los protocolos configurados en el escenario de trabajo ( información dinámica de nivel 2 y 3 Æ escaso tráfico) Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 100 100 xAunque igualmente se constata que el incremento en el consumo de CPU relativo al pasar de 1 QEMU activo a 2 QEMU activos (fila nº3Æ fila nº4) supone únicamente el 1%, el uso de dichos terminales parece no ser recomendable en demasía para los entornos de emulación GNS3/Dynamips, toda vez que cargas elevadas del procesador y consumos elevados de memoria RAM pueden repercutir negativamente en la ejecución en tiempo real de los procesos asociados con la emulación, incidiendo directamente sobre parámetros de red como la latencia. En estudios futuros, y sobre equipos emuladores de una gama tecnológica superior, cabría incluirse el estudio de más terminales QEMU para analizar esa tendencia aparentemente “asintótica” en la evolución del consumo de CPU al aumentar su número. Siendo así, el uso de los mismos se justifica en el análisis realizado en el capítulo 3, paralelamente con el anexo 2, como host para verificar la conectividad VLAN, y así analizar la funcionalidad y rigor del emulador GNS3/Dynamips. Otra justificación de su uso, es mostrar la posibilidad de utilización en diseños emulados. Dado que la interoperación entre el tráfico de red real y emulado no eleva significativamente el consumo de recursos del sistema, y así se comprueba empíricamente, sobre el escenario actual, en el que básicamente el tráfico de red presente en el mismo es el relacionado con la actualización y mantenimiento de los protocolos de nivel 2 y 3 configurados en la arquitectura de red (básicamente point-to-point y RIP v2), parece adecuado el uso de equipos reales externos mejor que los host virtuales QEMU, como host integrantes de la arquitectura y que subsidiariamente nos permitan analizar y verificar las configuraciones de diseño y la conectividad VLAN (y por consiguiente, la funcionalidad y rigor del entorno de emulación), además de la interoperación entorno real ÅÆ entorno emulado. Pero esta deseable disposición de diseño y trabajo puede presentar varios inconvenientes logísticos: primero, en cuanto a la disponibilidad de equipos reales externos (interfaces de red Ethernet externos al emulador); en segundo lugar, en cuanto a que todo equipo real que se desee incorporar al entorno emulado precisa de un interfaz físico libre y específico en el PC emulador para su integración (esto es, un interfaz de red Ethernet). Capítulo 7: Anexos 101 101 Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 108 108 Verificación de la conectividad VLAN y funcionalidades VTP del emulador Una vez realizadas las configuraciones anteriores, procedemos a verificar la conectividad VLAN en el entorno emulado, verificando así la funcionalidad del emulador. Según nuestro diseño, debe existir conectividad completa entre VLAN2 y VLAN3, generándose conmutación a nivel 3 en la comunicación entre ambas VLAN a través del nodo EtherSwitch router 1, que recordemos es un switch multilayer. Primeramente, comprobamos la funcionalidad y características VTP activas en ambos nodos emulados, desde el modo de configuración EXEC privilegiado: Figura 7.30. Estado VTP en el nodo emulado EtherSwitch router 1 (servidor VTP). Figura 7.31. Estado VTP en el nodo emulado EtherSwitch router 2 (cliente VTP). Capítulo 7: Anexos 109 109 Según las anteriores figuras 7.30 y 7.31, los nodos 1 y 2 estarían ejecutando en el entorno emulado los roles previamente asignados en la configuración emulada VTP (servidor y cliente respectivamente). Seguidamente, las figuras 7.32 y 7.33 constatan que se ha producido la transmisión de la información relativa a la configuración VLAN implementada en el servidor, mediante el protocolo VTP. Figura 7.32. Relación de la información transmitida y recibida por el servidor emulado VTP. Figura 7.33. Relación de la información transmitida y recibida por el cliente emulado VTP. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 110 110 A continuación, verificamos la conectividad y el trayecto que sigue el tráfico en la conmutación emulada entre equipos de una misma VLAN (conmutación a nivel 2), y entre VLAN diferentes (conmutación a nivel 3) en el nodo EtherSwitch router 2. Para ello, habremos configurado previamente equipo_real 1, equipo_real 2, QEMU2 y QEMU3, según el mapa de direcciones IP del diseño VLAN mostrado en la figura 7.25. Así, ejecutamos desde equipo_real 2 (192.168.2.3): Figura 7.34. Conectividad y trayectoria en la conmutación VLAN (en switch emulado, nodo 2 ) En la figura 7.34 se observa como desde 192.168.2.3/24, para alcanzar el host 192.168.2.2/24 (equipo_real 2 Æ entorno emuladoÆ equipo_real 1, diferente VLAN en distintos nodos virtuales) se realiza conmutación a nivel 2 (1 hop). Para alcanzar 192.168.3.3/24 (diferente VLAN en distinto nodo emulado), es necesario “alcanzar” primero el SVI configurado para su VLAN, y desde el interfaz virtual SVI alcanzar finalmente el host de destino final 192.168.3.3/24 (2 hops, conmutación a nivel 3). En ambos casos, se ha hecho uso del enlace troncal 802.1q configurado. Hay que destacar que en las verificaciones anteriores, se ha realizado interoperación entre equipos reales y equipos emulados. No se pierde de vista este aspecto, uno de los objetivos analizados en el proyecto. Completando el análisis y verificación de la conectividad VLAN, conviene apuntar que en el nodo EtherSwitch router 1 el enlace troncal no se utilizará en el caso de querer establecer conmutación a nivel 3 entre VLAN2 ÅÆ VLAN3, pues ésta se realiza en el mismo switch multilayer, a través de los interfaces virtuales SVI. Capítulo 7: Anexos 111 111 Finalizando el análisis de la conectividad VLAN en el entorno emulado GNS3/Dynamips, verificamos la misma en el nodo EtherSwitch router 1: Figura 7.35. Conectividad y trayectoria en la conmutación VLAN (en switch multilayer 1 emulado) La figura 7.35 nos muestra cómo para alcanzar 192.168.2.3/24 desde 192.168.2.2/24 (equipo_real 1 Æ entorno emulado Æ equipo_real 2, misma VLAN en distintos nodos virtuales) se está realizando conmutación a nivel 2, utilizando para ello el enlace troncal (1 hop). Para alcanzar 192.168.3.2/24 desde 192.168.2.2/24 (equipo real 1Æhost emulado QEMU, distinta VLAN en el mismo nodo), se realiza conmutación a nivel 3 (2 hops) en el mismo switch multilayer como se indicó antes, sin hacer uso del enlace troncal. Las verificaciones anteriores de la conectividad sobre este escenario segmentado VLAN, configurado en base a comandos Cisco IOS tal como se implementan sobre un escenario de red real similar, confirma la funcionalidad y rigor del emulador, así como la correspondencia funcional entre el entorno emulado y el real. Así mismo, recordemos que las verificaciones han sido realizadas vía interoperación entre ambos entornos de red, real y emulado, confirmándose así la funcionalidad de esta prestación del emulador GNS3/Dynamips, uno de los objetivos del proyecto. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 112 112 7.2.7. Configuraciones de red adicionales para el análisis de prestaciones y rendimiento del emulador GNS3/Dynamips en la arquitectura LAN/VTP Para configurar globalmente el escenario de trabajo de la figura 7.25 que nos permite analizar los propósitos del capítulo 4, procedemos como se indica a continuación. Por comodidad y claridad en la exposición se muestra de nuevo la figura 7.25. Figura 7.25. Topología/simulación gráfica en GNS3 de la arquitectura LAN /VTP. Según esta topología, conectamos los nodos de red EtherSwitch router 1 y 2 de la arquitectura de red LAN Ethernet/VTP principal con sendos nodos EtherSwitch router (R3 y R4 respectivamente) mediante enlaces serie encapsulados HDLC, vía los interfaces serial 0/0 disponibles en cada uno de los nodos emulados. Estos nuevos enlaces serie se adscriben administrativamente a las redes locales 192.168.4.0 / 24 y 192.168.5.0 / 24, sin ningún propósito telemático y no participan del escenario conmutado LAN Ethernet /VTP. La configuración de los interfaces serial 0/0 en cada de los nodos emulados (dirección IP y máscara de red, encapsulamiento HDLC y activación del interfaz) se realiza mediante los comandos Cisco IOS pertinentes, reflejado ello en las figuras 7.36 y 7.37 de la página siguiente. Se realiza encapsulamiento HDLC para mostrar las posibilidades del entorno emulador. Capítulo 7: Anexos 113 113 xNodos EtherSwitch router 1 / R3 ( red 192.168.4.0 / 24) Figura 7.36. Configuración de interfaces serial 0/0 asignados a la red 192.168.4.0 / 24 en los nodos EtherSwitch router 1 y R3 de la arquitectura de red LAN/VTP. xNodos EtherSwitch router 2 / R4 ( red 192.168.5.0 / 24) Figura 7.37. Configuración de interfaces serial 0/0 asignados a la red 192.168.5.0 / 24 en los nodos EtherSwitch router 2 y R4 de la arquitectura de red LAN/VTP. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 114 114 7.2.8. Complemento teórico-práctico a las conclusiones del proyecto. Explicitando más profundamente las conclusiones de la tabla 5.1 del capítulo 5 del proyecto, en cuanto a la funcionalidad, rigor y correspondencia funcional del entorno emulador es destacable que las configuraciones de red se implementan en base a idénticos comandos Cisco IOS que serían ejecutados en análogos entornos reales de trabajo, sin ninguna cortapisa tecnológica y funcional por parte del software emulador. Las configuraciones de red para las arquitecturas WAN ppp y LAN Ethernet/VTP y los diseños propuestos según las figuras 3.1 y3.3 son convenientemente descritas y analizadas en el anexo 2. Una vez implementadas, se verifica su funcionalidad (en este mismo anexo) siendo los resultados acordes con los objetivos de diseño: funcionalmente rigurosos e idénticos a los que se obtendrían sobre entornos reales análogos. Recordemos que este entorno software emulador debe principalmente sus prestaciones y potencia de emulación al empleo en la misma de idénticos sistemas Cisco IOS que integran dispositivos de red reales. Derivado de esto, ha surgido la necesidad de elaborar el anexo 3 sobre la extracción de los sistemas Cisco IOS de dispositivos de red reales y su posterior integración en el entorno software GNS3/Dynamips. A la hora de implementar las configuraciones en GNS3/Dynamips, se presenta al usuario idéntico interfaz gráfico que visualizaría en caso de configurar el dispositivo de red real vía puerto consola y cable de acceso rollover, siendo ésta otra ventaja con respecto a otras plataformas de emulación. Esta característica permite, llegado el momento, una cierta “aclimatación funcional” a un determinado entorno real de trabajo que debamos analizar en el emulador previamente a acometer una actuación telemática sobre él. Tal como se menciona en el capítulo 1, uno de los objetivos a evaluar en el proyecto es el uso potencial del entorno emulador GNS3/Dynamips en entornos profesionales, como herramienta software que permita un análisis previo de un escenario real de trabajo sobre el que se planea acometer una determinada actuación, con el objetivo de minimizar riesgos estructurales y costes asociados al proceso. Por ello, todas las herramientas y prestaciones que permitan reproducir adecuadamente un escenario real de trabajo sobre uno emulado es un aporte sustancialmente beneficioso. Además, GNS3/Dynamips permite implementar topologías/arquitecturas en base a dispositivos de red genéricos (switch Ethernet,switch Frame Relay,switch ATM…), dispositivos no asociados a ningún modelo corporativo concreto, haciendo interesante y recomendable su uso en ámbitos académicos. La tabla 7.2 de la página siguiente nos ofrece a modo de resumen las principales ventajas e inconvenientes que se extraen de los análisis realizados en los capítulos 3 y 4 del proyecto. Capítulo 7: Anexos 115 115 Tablaȱ7.2ȱ Ventajasȱ/ȱinconvenientesȱ delȱentornoȱemuladorȱGNS3/Dynamipsȱ (ȱextraídasȱdelȱanálisisȱdelȱcapítuloȱ3ÅÆȱanexoȱ2ȱ yȱdelȱanálisisȱdeȱinteroperabilidadȱdelȱcapítuloȱ4ȱ)ȱ Ventajasȱ xObjetivo fundamental del proyecto: permite la correcta interoperación funcional a nivel 2 y 3 de tráfico y equipos de red reales y emulados. Estricta correspondencia funcional del tráfico de red implicado en dicha interoperación. xFacilidad de implementación y uso que lo hace recomendable para ámbitos profesionales y académicos. Adecuada usabilidad. xConfiguración de escenarios de trabajo emulado conforme a escenarios reales análogos, con las consiguientes ventajas para el campo profesional en cuanto a la adquisición de habilidades sobre los escenarios reales, minimización de riesgos y costes. Correspondencia funcional entre entornos reales y emulados. xImplementación de topologías en base a dispositivos de red generales no asociados a dispositivos hardware concretos que incrementa las posibilidades y versatilidad del diseño en entornos académicos, así como minimizar consumo de recursos. xPermite segmentar topologías extensas de trabajo en una “parte real” y una “parte emulada”, vía interfaz Ethernet, en el caso de disponer recursos hardware limitados, y si procede en el diseño. Inconvenientes xActualmente no permite emular estrictamente dispositivos de red de la familia Catalyst de Cisco Systems, debiendo hacer uso de ciertos recursos de diseño para conformar dispositivos de red emulados similares. xLos dispositivos de red emulados se circunscriben actualmente a los entornos corporativos Cisco Systems y Juniper. xNo permite emular sistemas operativos Cisco CatOS (ni es previsible que lo haga). xActualmente, sólo se implementa interoperación entorno real ÅÆ entorno emulado a través de interfaz Ethernet. xDeficiente comportamiento de la latencia en la interoperación entorno real ÅÆ entorno emulado para algunas arquitecturas de red, como es el caso de la interoperación tráfico real Ethernet ÅÆ interfaz virtual SVI (conmutación a nivel 3). Tabla 7.2. Tabla resumen de ventajas e inconvenientes del emulador GNS3/Dynamips extraídas del análisis de los capítulos 3ÅÆanexo 2, y del análisis de la interoperabilidad del capítulo 4. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 116 116 Complemento a las conclusiones de los análisis de la interoperación entorno real ÅÆ entorno emulado. Ahondando en las conclusiones del objetivo prioritario del proyecto, se analizan exhaustivamente los resultados de la interoperación entorno real ÅÆ entorno emulado, haciendo referencia a los apartados 3.1.2,3.2.2. En ellos se realiza captura y análisis del tráfico de red emulado sobre escenarios en los que se implementa una interoperación entre entornos de red real y emulado. Siendo así, se aprecia cómo disponemos de idéntica información a la que obtendríamos sobre análogos escenarios reales de red (existe estricta correspondencia funcional). Esta información está relacionada con los protocolos configurados y activos, caso del apartado 3.1.2. En el caso del apartado 3.2.2 ( y 7.2.2 de este anexo 2), el tráfico de red capturado aporta, además, información significativa sobre la interoperación entre los entornos de red real y emulado, información ésta que permite verificar la correspondencia funcional entre ambos entornos. Concretamente, se verifica que la estructura de las tramas del tráfico de red emulado es idéntica a la teórica, y en definitiva, a la del tráfico de red real. Esto constata empírica y definitivamente que el tráfico de red en GNS3/Dynamips, entre dispositivos emulados, y en el caso de escenarios en los que interoperan equipos reales y emulados guarda correspondencia funcional con el tráfico de red real. En el apartado 7.2.4 de este anexo 2, se ha realizado un análisis mediante Wireshark del tráfico de red existente en el enlace equipo real 1 Å Ænodo virtual 1, para distintas longitudes de trama Ethernet. En este enlace se procede a la interoperación entre el entorno real y el emulado.Siendo así, se muestra y analiza el comportamiento telemático de la interoperación al respecto. Los resultados de esta captura muestran cómo existe una absoluta correspondencia funcional entre el tráfico de red real y emulado a “ambos lados” del interfaz Ethernet, conservándose la estructura y longitud de trama. Consecuentemente, no sólo es factible la interoperación entre entornos de red reales y emulados en GNS3/Dynamips, sino que el rigor estructural del tráfico de red en la misma es máximo. Complemento a las conclusiones del proyecto sobre la latencia en la interoperación. 1. Complemento al análisis de resultados de la arquitectura de red WAN ppp. Para el primero de los experimentos propuestos en el análisis de la latencia, las tablas 4.4 y4.5 obtenidas en el apartado 4.2.2 del capítulo 4, revelan un valor de la latencia de red para todas las longitudes de trama Ethernet muy elevado con respecto al valor que se obtiene en un entorno real análogo. Este valor no sería asumible en la práctica en un escenario de red real similar. Recordemos que en este primer ensayo implementábamos peticiones de eco (ping) desde un equipo real externo al emulador (192.168.2.2) con destino el interfaz virtual SVI (192.168.2.1), interfaz configurado en el nodo multilayer Etherswitch router (esto es, conmutación a nivel 3). A la vista de los resultados, y para esta arquitectura de red, el valor de la latencia en la interoperación entorno real ÅÆ entorno Capítulo 7: Anexos 117 117 emulado es considerablemente deficiente debiendo considerarse indefectiblemente en los posibles análisis que pudiésemos efectuar en el emulador sobre la prestación de servicios telemáticos en esta arquitectura. Así, el elevado valor de la latencia en este caso sugiere un mal comportamiento por parte del emulador en la interoperación en el caso de conmutar tráfico de red real Ethernet con destino un interfaz virtual SVI (conmutación a nivel 3). Aunque estrictamente no es el caso, esta elevada latencia sugiere el hecho de que el potencial valor de la latencia media en una supuesta conexión extremo–extremo en topologías emuladas más complejas (mayor número de nodos intermedios o hops en la trayectoria) incumpliese la recomendación ITU-T G.114 al respecto (valor máximo < 150 ms) [19] a la hora de implementar servicios telemáticos, como VoIP o vídeo multimedia. Estos valores de latencia se han obtenido en una situación de consumo máximo de recursos, siendo igualmente deficientes los valores obtenidos en la situación estable de trabajo asociada al consumo mínimo de recursos. A la hora de extraer conclusiones y paralelismos en el estudio de un escenario de red real reproduciendo éste sobre el emulador GNS3/Dynamips, podríamos considerar como una cota superior amplia para la latencia media real el valor de latencia mínimo obtenido en cada experimento emulado concreto (para cada longitud de trama y consumo de recursos). Por ejemplo, en el supuesto práctico de la configuración hardware 1, longitud de trama Ethernet 802.3 de 1514 bytes y 2 switch-router activos, el valor medio de la latencia es de 43 ms (tabla 4.4, muy elevado en este caso). Pero en el cálculo de este valor medio, ponderación de los valores de las 200 peticiones de eco para las 20 repeticiones del experimento, intervienen varios valores, siendo el menor de ellos 2 ms (los valores mínimos, máximos y medios de la latencia son reportados al finalizar la ejecución del comando ping). Empíricamente se comprueba que la latencia media medida sobre el mismo escenario de red real queda siempre por debajo de este valor, y en alguna de las 200 repeticiones del ensayo (1 – 2 iteraciones) lo alcanza. Por lo tanto, podríamos considerar como una cota superior (suficientemente amplia) para la latencia media en el análogo escenario de red real el valor mínimo de la latencia medido en el escenario emulado, valor que depende para cada supuesto práctico. Esto nos permitiría trasladar desde el entorno emulado al escenario de red real, y para cada supuesto práctico, un margen de trabajo considerablemente fiable para la latencia. De los resultados de las tablas 4.4 y 4.5 del capítulo 4, extraídos en condiciones de consumo máximo de recursos, extraemos otras conclusiones decisivas asociadas al objetivo principal del proyecto. La primera de ellas es que el valor de la latencia en la interoperación entorno real ÅÆ entorno emulado es muy dependiente del número de nodos emulados, y por lo tanto, del consumo de recursos en el sistema emulador. Ello nos conduce a la decisiva conclusión de que el comportamiento en tiempo real del emulador puede estar severamente condicionado por la arquitectura de red y su topología asociada (principalmente, el nº de nodos emulados de la arquitectura). Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 124 124 7.3.3. Interoperación de dispositivos de red reales y emulados en GNS3/Dynamips. Una de las prestaciones que confieren al entorno de emulación GNS3/Dynamips un atractivo especial frente a otras plataformas de emulación es la capacidad de interoperar tráfico de red y equipos reales con tráfico de red y equipos emulados. Éste, recordemos, es uno de los objetivos principales de análisis del proyecto. Para proceder a la interoperación telemática: entorno de red real ÅÆ entorno de red emulado, el sistema emulador, generalmente un PC, debe disponer de tantos interfaces Ethernet libres como nodos o dispositivos reales se pretenda integrar, realizándose a través de dichos interfaces la integración/interoperación de ambos entornos (figura 7.40). Figura 7.40. Esquema general para la integración de un equipo real en el entorno de emulación GNS /Dynamips, vía interfaz Ethernet. Al respecto, es necesario concretar lo siguiente: xSi el dispositivo real a integrar es un host (PC), para su integración se utilizará cableado de red Ethernet RJ-45 directo. xAsí mismo, si el dispositivo real a integrar es un switch/router, para su integración se utilizará cableado de red Ethernet RJ-45 cruzado. Añadido a esto, se deben configurar los interfaces Ethernet del PC emulador empleados en la interoperación sin ninguna dirección de red, como si presentasen configuración DHCP. Capítulo 7: Anexos 125 125 Una vez se ha procedido con la “parte física” de la interoperación, desde el entorno de GNS3/Dynamips se procede a la configuración software de la misma. Pero antes de proseguir, hacemos un breve inciso. Para la realización del presente proyecto se ha hecho uso de la versión software 0.7.3 de GNS3 [12]. Si bien existen versiones más actualizadas del mismo, tras una primera toma de contacto y experimentación inicial, presentaron ciertas inestabilidades en su comportamiento por lo que se decidió trabajar con la versión antes mencionada, que tras su análisis presentó un comportamiento más estable. Tras una sencilla y convencional instalación debe procederse con la configuración básica y fundamental del que será nuestro entorno de trabajo emulado (hacemos referencia al entorno Windows, la instalación respectiva en entorno Linux se detalla en el anexo 4). Para ello, al hacer uso por primera vez del software, se ofrece un contexto gráfico para establecer las configuraciones prioritarias del emulador, reflejado en la figura 7.41. Figura 7.41. Contexto gráfico inicial para la configuración de los parámetros básicos y fundamentales de GNS /Dynamips. Este menú inicial de configuración puede obviarse y optar por ejecutar manualmente la configuración de los parámetros y variables fundamentales del emulador. La configuración y descripción de estos parámetros básicos se aborda en apartados posteriores. Además, tal como indica la figura 7.41, el tercero de ellos debe ser configurado posteriormente, como se describe en el apartado 7.5.3 de este anexo 3. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 126 126 Tras este inciso, continuamos con la configuración de la interoperación entorno real ÅÆ entorno emulado. Una vez nos encontramos en el interfaz gráfico principal de GNS3, seleccionamos del menú lateral izquierdo un elemento “cloud”, cuya función es representar (y obviamente integrar) dispositivos reales en el entorno emulado. Seguidamente, haciendo “clic” con el botón derecho del ratón sobre dicho elemento, seleccionamos del menú desplegable la opción Configure , según muestra la figura 7.42. Figura 7.42. Contexto gráfico para la integración de dispositivos reales en GNS3 / Dynamips. Finalmente, y sobre el nuevo contexto gráfico emergente de la figura 7.43 siguiente, Figura 7.43. Contexto gráfico de configuración en la selección del interfaz de integración. Capítulo 7: Anexos 127 127 seleccionamos la pestaña ÆNIO Ethernet ; esta pestaña, a través de un nuevo menú desplegable, nos permite seleccionar de una lista de interfaces disponibles en el PC emulador el interfaz Ethernet que deseemos para integrar el dispositivo de red real (para ello, seleccionaremos el interfaz deseado de la lista y a continuación Æ Add ) Toda la configuración anterior nos permite disponer de un dispositivo de red real (host, switch o router) con capacidad de interoperar con un escenario telemático emulado en GNS3/Dynamips. Finalmente, solo resta la conexión en el interfaz gráfico de GNS3, vía Ethernet, del elemento “cloud” con el dispositivo de red emulado que deseemos. 7.3.4. Integración de Cisco IOS en el entorno emulador GNS3/Dynamips. Tal como se ha comentado anteriormente, una vez extraído el sistema operativo del dispositivo de red, y con la finalidad de proceder a su emulación en un determinado escenario de trabajo en GNS3/Dynamips, debemos proceder a integrarlo/incorporarlo en el entorno software. Para ello, procedemos como se indica a continuación. Primeramente, una vez realizada la instalación de GNS3/Dynamips es prioritario y fundamental configurar el path o ruta indicando los directorios donde se ubicarán nuestros proyectos de trabajo y las imágenes a emular por los dispositivos, esto es, los sistemas Cisco IOS. Este es uno de los parámetros básicos de configuración antes mencionados.La personalización al respecto es libre, pero sirva como ejemplo ilustrativo la opción de trabajo mostrada en la figura 7.44. Figura 7.44. Contexto gráfico para la configuración del path o ruta de los directorios. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 128 128 Seguidamente, se accede al menú de configuración: Edit ÆPreferencesÆGeneral , desde el interfaz gráfico principal de GNS3, como muestra la figura 7.45. Figura 7.45. Acceso al menú de configuración de GNS3/Dynamips. Los sistemas Cisco IOS (recordemos, extraídos de dispositivos de red reales) los copiaremos en el directorio destinado a las imágenes (directorio images, en el caso anterior de la figura 7.44), y los proyectos de trabajo realizados o activos se guardarán en el directorio configurado a tal efecto (directorio projects de la figura 7.44). Finalmente, precisamos asociar dispositivos emulados con imágenes o sistemas Cisco IOS. Para ello, desde el interfaz gráfico principal de GNS3:Edit ÆIOS images and hypervisors , nos dirige a un contexto gráfico de configuración en el que únicamente resta, y según nuestras particularidades de trabajo y emulación, seleccionar las opciones que nos ofrecen los menús desplegables (esto es, los modelos de dispositivos e imágenes asociadas). Recomendación práctica: los sistemas o imágenes Cisco IOS en su formato original, extraídos de los dispositivos de red, presentan formato nombre_imagen.bin. Cada vez que ponemos en funcionamiento en el emulador un dispositivo asociado con una imagen, ésta debe descomprimirse, con el tiempo que ello implica. Podemos agilizar este proceso descomprimiendo nombre_imagen.bin con el software Winrar por ejemplo,en el mismo directorio donde tenemos ubicadas las imágenes Cisco IOS, cambiar el nombre del archivo generado/descomprimido al formato nombre_imagen.image y reasignar esta nueva imagen a nuestro dispositivo, según indicaba el párrafo anterior. Con ello, cada vez que iniciemos el dispositivo emulado ahorraremos el tiempo empleado en la descompresión de la imagen Cisco IOS asociada al mismo. Capítulo 7: Anexos 129 129 Un parámetro de configuración fundamental cuyo funcionamiento es preciso verificar la primera vez que vayamos a hacer uso de GNS3/Dynamips (y configurar adecuadamente si es necesario) es el path o ruta seguida en la ejecución del proceso dinamips.exe (proceso sobre el que recaen fundamentalmente las tareas de emulación) y su directorio de trabajo. Este es uno de los parámetros mostrados con anterioridad en la figura 7.41. Para ello, desde el interfaz gráfico principal de GNS3: Edit ÆPreferencesÆGeneral ÆDynamips, muestra el contexto gráfico sobre el que se realiza esta verificación (figura 7.46). El resultado de la misma es satisfactorio si así se indica (en color verde). En caso contrario (color rojo), deben configurarse correctamente el path y/o el directorio temporal de trabajo. Figura 7.46. Contexto gráfico para la verificación del path o ruta en la ejecución del proceso dynamips.exe y su directorio de trabajo temporal. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 130 130 7.3.5. Optimización del rendimiento de CPU: parámetro idle PC. Una tarea de configuración absolutamente prioritaria y fundamental del entorno de emulación es el cálculo del denominado idle PC. Este es uno de los parámetros de configuración inicial mostrados en la figura 7.41, la primera vez que usamos el software. Pero la configuración de este parámetro es preciso abordarla manualmente llegado el momento de usar un dispositivo emulado concreto. Sin una correcta configuración del mismo, el consumo de CPU puede alcanzar valores entre el 50 % y el 100 % que hacen prácticamente inviable la ejecución de los procesos asociados a la emulación. Esto es debido a que en la emulación de Cisco IOS, el procesador del sistema emulador desconoce cuándo el dispositivo emulado está realmente activo y cuándo está “desocupado”, y por ello está ejecutando continuamente las instrucciones que conforman el entramado de su sistema operativo Cisco IOS. La configuración del parámetro idle PC es por lo tanto, a grandes rasgos, una manera de informar a nuestro procesador cuándo los dispositivos emulados se encuentran realmente activos, y así ejecutar las instrucciones precisas de su sistema operativo cuando corresponda, no de manera continua. En caso de no estar activos, los dispositivos emulados permanecen en un estado de “pseudoreposo” (iddle). En principio, el valor idle PC debe calcularse para cada Cisco IOS concreto [12][13]. Pero la experiencia práctica acumulada a lo largo del desarrollo del proyecto nos recomienda calcularlo para cada Cisco IOS y para cada PC emulador concreto. Es decir, un valor de idle PC calculado para un determinado Cisco IOS en un PC concreto no sería un valor óptimo para el mismo sistema Cisco IOS en distinto PC emulador. El cálculo del parámetro idle PC es relativamente sencillo. Una vez disponemos de un dispositivo emulado en nuestro panel principal de GNS3 e iniciamos este dispositivo (dispositivo asociado a una determinada imagen Cisco IOS según las indicaciones anteriores), el procesador de nuestro PC emulador comenzará a ejecutar, vía proceso dinamips.exe, las instrucciones asociadas al sistema a emular. En este momento, haciendo “clic” con el botón derecho del ratón sobre el icono del dispositivo, del menú desplegable seleccionamos la opción idle PC . Tras unos segundos, se nos mostrará por pantalla una lista desplegable de posibles valores. De estos valores, los realmente válidos, son aquellos que van acompañados por el símbolo (*). Si al calcular el valor idle PC no obtuviésemos un valor con (*) deberíamos repetir el proceso. Recurriendo de nuevo a la experiencia acumulada en el análisis de esta plataforma de emulación, un pequeño consejo práctico para obtener un buen valor de idle PC es proceder al cálculo cuando estamos ejecutando alguna instrucción Cisco IOS desde la consola del dispositivo. Concretando descriptivamente nuestro pequeño consejo práctico: iniciamos el dispositivo y esperamos el tiempo suficiente para que se cargue correctamente Cisco IOS. En este momento, si no hemos calculado previamente idle PC o no disponemos de un valor óptimo del mismo, el valor de carga de CPU puede llegar al 100 %. Por esta circunstancia, nuestro sistema funcionará lentamente, pero sin llegar a bloquearse. Con relativa habilidad, ejecutamos alguna instrucción Cisco IOS, vía consola del dispositivo, y Capítulo 7: Anexos 131 131 seguida e inmediatamente calculamos idle PC. La experiencia práctica nos dice que los valores así calculados son óptimos, o próximos a serlo. Este pequeño apunte práctico sería útil en caso de querer asignar un valor adecuado de idle PC antes de incorporar el dispositivo emulado en la topología de una determinada arquitectura, para así proceder con las configuraciones de red de un modo más “ágil” por parte del sistema emulador. Otra forma de proceder para el cálculo de idle PC podría ser: una vez diseñada la topología y activa una determinada arquitectura con sus dispositivos en funcionamiento, aunque sea con un valor inicial no óptimo de idle PC, calcular en este momento el valor hasta dar con un valor óptimo. Al estar los dispositivos de red activos, esto es, ejecutando instrucciones del sistema operativo asociado, los valores calculados serían óptimos, o próximos a serlo. El inconveniente de esta propuesta es que hasta concretar un valor adecuado el funcionamiento del sistema podría llegar a ser bastante deficiente (con cargas de CPU hasta 100 %), siendo un proceso lento y tedioso. Para un determinado dispositivo de red, imagen Cisco IOS asociada al mismo y sistema emulador, el cálculo del valor óptimo de idle PC es un proceso que sólo es necesario hacer una vez . 7.3.6. Optimización del rendimiento de la memoria RAM. Si la carga de CPU asociado a una plataforma de emulación es crítico, el consumo de memoria RAM no lo es menos. Tal como recogen los resultados del capítulo 4, el consumo de memoria es ciertamente decisivo y crítico en el correcto desempeño de los procesos de emulación. Para abordar esta contingencia, el entorno de emulación GNS3/Dynamips implementa e integra diversas mejoras, por defecto activadas, pero que con un buen dominio del entorno, y según la cantidad de recursos hardware disponibles, pueden desactivarse a voluntad para priorizar unas sobre otras. Al respecto cabe mencionar que en el desarrollo de este proyecto se ha hecho uso de la configuración por defecto, esto es, con las mejoras activadas. El acceso a estos recursos para la optimización del consumo de memoria RAM, reflejado en la figura 7.47 de la página siguiente, se realiza a través de: Edit ÆPreferences ÆDynamips . Estos recursos de optimización [12], a grandes rasgos, operan como se indica: xGhost IOS support: genera una región de memoria compartida de forma que dispositivos que emulen idéntico sistema Cisco IOS accedan a esa única región de memoria común ahondando en un evidente ahorro de consumo de memoria RAM. Habilitada esta función se generan archivos *.ghost en un directorio working con el mismo path que los directorios de trabajo previamente descritos, archivos que corresponden a la región compartida en la memoria. Análisis de la interoperabilidad con entornos reales de arquitecturas de red emuladas con GNS3/Dynamips (para ámbitos profesionales y académicos). 132 132 xEnable sparse memory support: no afecta al consumo de memoria RAM “real”. Este recurso, limita únicamente el uso de memoria virtual consumida por las instancias de los router considerando únicamente el consumo de memoria de aquellos dispositivos que están realmente activos. Este recurso afecta al consumo de memoria virtual [12]. Figura 7.47. Contexto gráfico para la configuración de los recursos optimizadores de la memoria RAM del sistema emulador. Para la correcta ejecución de ambos recursos RAM optimizadores, la configuración de GNS3/Dynamips obliga a activar también la opción Enable mmmap support; en caso contrario, el funcionamiento de los recursos anteriores no será correcto. Si bien el entorno emulador GNS3/Dynamips implementa otra serie de recursos para la optimización de los procesos asociados a la emulación, abordarlas escapa a los objetivos del proyecto y no ha sido necesario su concurso en el planteamiento de los escenarios de trabajo del mismo. Huelga decir que tales recursos pueden ser objeto de posteriores análisis para profundizar en el estudio de las potencialidades de esta plataforma de emulación, y así se postula en el capítulo 5. Capítulo 7: Anexos 133 133 7.4. Anexo 4: Análisis de prestaciones y rendimiento del sistema emulador en entornos de trabajo Linux (Distribución Ubuntu 12.04). Habiéndose concretado todos los análisis del entorno emulador GNS3/Dynamips descritos en la presente memoria bajo el sistema operativo Windows, en concreto Windows XP de 32 bits (se comprueba además que el funcionamiento es vible y similar bajo el sistema operativo Windows 7 de 32 y 64 bits), este anexo se elabora ex profeso para mostrar ciertas tareas de configuración de GNS3/Dynamips manifiestamente diferentes en sistemas operativos Linux, en este caso la distribución Ubuntu 12.04. Además, y sin la profundidad de contenidos con respecto a los análisis efectuados bajo sistema operativo Windows,se analiza la capacidad y rendimiento del sistema emulador para la configuración hardware 1 descrita en el capítulo 4,así como su influencia en la latencia de red en la interoperación entorno real ÅÆ entorno emulado. 7.4.1. Instalación/Configuración de GNS3/Dynamips en sistemas Linux. Las tareas de configuración en sistemas operativos Linux es básicamente la misma que en sistemas Windows, con ciertas particularidades relacionadas con la arquitectura software propia del sistema operativo. En primer lugar, descargaremos los archivos GNS3- 0.7.3-src.tar.gz y Dynamips 0.2.8-RC2-x86.bin for Linux (32-bit) [12]. Vamos a instalar y configurar en el sistema/PC emulador las mismas versiones del software que hemos hecho uso en Windows, aunque existen versiones más actuales. Figura 7.48. Vista detallada del directorio/carpeta creada en /home para la instalación de GNS3/Dynamips en Linux.