IMPLEMENTACIÓN DE UN OPENFLOW CONTROLLER PARA EL MANEJO DE OPENFLOW SWITCHES CARLOS ALBERTO CONTRERAS PARDO

Transcripción

1 IMPLEMENTACIÓN DE UN OPENFLOW CONTROLLER PARA EL MANEJO DE OPENFLOW SWITCHES CARLOS ALBERTO CONTRERAS PARDO PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGNIERÍA ELECTRÓNICA BOGOTÁ 2014

2 IMPLEMENTACIÓN DE UN OPENFLOW CONTROLLER PARA EL MANEJO DE OPENFLOW SWITCHES CARLOS ALBERTO CONTRERAS PARDO TRABAJO DE GRADO DIRECTOR: GUSTAVO ADOLFO RAMÍREZ ESPINOSA PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA BOGOTÁ

3 3 A MIS PADRES QUE SIEMPRE ESTUVIERON APOYÁNDOME EN TODO EL PROCESO, A MI AMOR ETERNO QUE TAMBIÉN ME ACOMPAÑO Y A DIOS POR DARME ESTA GRAN OPORTUNIDAD.

4 AGRADECIMIENTOS Gracias a la mi segundo hogar la Pontificia Universidad Javeriana por brindar todo el apoyo académico para el desarrollo de una etapa tan importante, agradezco a cada uno de los profesores que guiaron mi camino para llegar a la cima. De igual forma agradezco a mis faros de toda la vida, mis padres, que con esfuerzo y valentía hicieron todo lo posible por hacer de este sueño una realidad. 4

5 CONTENIDO 1. INTRODUCCIÓN MARCO TEÓRICO REDES SDN OPENFLOW TABLAS DE FLUJO (Flow-Table) VERSION TABLAS DE FLUJO (Flow-Table) VERSION CONTROLADORES SDN POX BEACON FLOODLIGHT SDN VAN CONTROLLER COMUNICACIÓN DEL PROTOCOLO OPENFLOW VERSIÓN 1.0 Y ESPECIFICACIONES DESARROLLOS SIMULADORES MININET CBENCH BENCHMARK TOOL TOPOLOGIA DE RED CREADA EN EL LABORATORIO TOPOLOGIA DE RED BUS TOPOLOGÍA DE RED ANILLO ANALISIS DE RESULTADOS TOPOLOGIA BUS PING DE HOST 1 A HOST 2 (VIRTUAL) PING DE HOST 1 A HOST 3 (VIRTUAL) PING DE HOST 1 A HOST 2 (REAL) PING DE HOST 1 A HOST 3 (REAL) TOPOLOGÍA DE RED ANILLO PING HOST 1 A HOST 2 (VIRTUAL) PING HOST 2 A HOST 3 (VIRTUAL) PING HOST 3 A HOST 1 (VIRTUAL)

6 PIN HOST 1 A HOST 2 (REAL) PING HOST 2 A HOST 3 (REAL) PING HOST 3 A HOST 1 (REAL) FLUJOS OBTENIDOS CON MININET CONCLUSIONES Error! Marcador no definido. 7. BIBLIOGRAFÍA ANEXOS

7 TABLA DE FIGURAS Figura 1. Arquitectura de red SDN...13 Figura 2. Esquema de funcionamiento del protocolo OpenFlow para OpenFlow Switch...14 Figura 3. Componentes de una tabla de flujo de un switch...15 Figura 4. Campos de información encontrados en Header Fields...16 Figura 5. Conteos que realiza el campo Counter y el número de bits usado...17 Figura 6. Paquetes de entrada comparados contra las tablas de flujo en el pipeline...18 Figura 7. Proceso del paquete por tabla de flujo...18 Figura 8. Componentes principales de un flujo de entrada in una tabla de flujo...18 Figura 9. Cabeceras de paquetes OpenFlow...19 Figura 10. Proceso de comparación entre el flujo de entrada y las tablas de flujo...19 Figura 11. Conteos realizados por el protocolo versión Figura 12. Control distribuido...23 Figura 13. Control centralizado...23 Figura 14. Topología de red implementada en la comprobación del controlador...28 Figura 15. Topología dada por floodlight...29 Figura 16. Ancho de banda entre los terminales...30 Figura 17. Topología dada por Beacon...30 Figura 18. Ancho de banda entre los terminales con controlador Beacon...31 Figura 19. Reconocimiento de switch por POX...31 Figura 20. Ancho de banda dado por POX...32 Figura 21. Detección de switch por SDN VAN HP...32 Figura 22. Ancho de banda dado por SDN VAN HP...33 Figura 23. Intercambio de mensajes entre el switch y el controlado...33 Figura 24. Topología lineal en MIninet dada por floodlight...34 Figura 25. Dispositivos Vistos por beacon en topología bus...35 Figura 26. Conexión switch virtuales en topología bus Mininet...35 Figura 27. Topología Anillo Mininet, floodlight...36 Figura 28. Switch vistos por Beacon en Topología anillo en Mininet...37 Figura 29. Switch en topología anillo identificados por el controlador...38 Figura 30. Topología en anillo dada por Mininet, controlador SDN VAN H...38 Figura 31. Características del equipo donde se encuentran los controladores...40 Figura 32. Topología tipo bus implementada en el laboratorio...41 Figura 33. Pantalla Principal de Floodlight...42 Figura 34. Topología de red dada por el controlador...43 Figura 35. Reconocimiento de switch en controlador Beacon...43 Figura 36. Reconocimiento de switches por controlador POX...44 Figura 37. Reconocimiento de los switches por el controlador SDN VAN HP...44 Figura 38. Topología dada por el controlador SDN VAN...45 Figura 39. Topología de red Anillo usada en el laboratorio...45 Figura 40. Topología de red anillo dada por controlador Floodlight...46 Figura 41. Conexión entre sí de los switch

8 Figura 42. Reconocimiento de los switch en la topología anillo por parte del controlador POX...47 Figura 43. Topología en anillo dada por el controlador SDN VAN HP

9 TABLA DE GRÁFICAS Gráfica 1. RTT Max H1- H Gráfica 2. RTT Min H1 - H Gráfica 3. RTT Min Topología H1 H Gráfica 4. RTT Min Topología H1 H Gráfica 5. RTT Max H1-H2, real...49 Gráfica 6. RTT Min H1 - H2, real Gráfica 7. RTT Max H1-H3, real Gráfica 8. RTT Min H1-H3, real Gráfica 9. Tiempo de RTT Max y Min...50 Gráfica 10. Tiempos RTT Max y Min...51 Gráfica 11. Tiempos RTT Max y Min...51 Gráfica 12. RTT Min Host 1 a Host 2, real Gráfica 13. RTT Max Host 1 a Host, real Gráfica 14. RTT Max Host 2 a Host 3, real...52 Gráfica 15. RTT Min Host 2 a Host 3, real Gráfica 16. RTT Max Host 3 a Host 1, real Gráfica 17. RTT Min Host 3 a Host 1, real Gráfica 18. Manejo de Flujos con 10 M de Host...53 Gráfica 19. Manejo de Flujos con 1 M de Host...54 Gráfica 20. Manejo de Flujos con 100 K Host

10 1. INTRODUCCIÓN Las topologías actuales de red están configuradas de tal forma que se minimiza el riesgo de indisponibilidad y se asegura una conexión estable para el usuario [1], el entorno que posibilita dicho enlace presenta una alta complejidad en sus arquitecturas debido a un incremento en el uso de internet por parte de dispositivos tales como tabletas, Smartphones, TV Smart y gadgets [2]. Otro problema importante que se destaca, es la alta demanda de servicios en la nube además el uso de servidores Big Data 1 y la convergencia de servicios (datos, voz, video, telefonía) [3], acaparando así un alto flujo de datos, por consiguiente toda la red se ve congestionada y saturada haciendo que estas topologías de red sean obsoletas. La gestión de estas topologías, siendo la red altamente tecnológica, presenta una baja automatización de sus procesos como por ejemplo, para la inserción de políticas de calidad de servicio es necesario la configuración manual por parte de un operario incrementando así el riesgo de fallas por error humano. Para atacar el problema de la configuración y administración surgen las redes SDN (Software Defined Networking o red definida por software), las redes SDN presentan como fundamento principal la separación de los planos de control y el plano de datos, esto con el fin de delegar el plano de control del dispositivo de red a un software externo y únicamente quedándose con el plano de datos. Para entender esta separación de las capas se describe brevemente cual es la función de cada una, el plano de control es el encargado de tomar las decisiones sobre el camino que deben tomar los paquetes, mientras que el plano de datos es el encargado de reenvío de los datos tan rápido como sea posible. Un componente principal de las redes SDN es el controlador, el software al que se le otorgara la inteligencia de la red, el controlador es el encargado de administrar la red de manera centralizada mediante el protocolo de comunicación OpenFlow 2, este sistema además tiene la habilidad de moldear el tráfico a través de la red sin la necesidad de tocar elementos individuales, es decir no requiera la conexión directa entre el controlador y un switch. Al insertar el controlador en las redes SDN éste tiene la habilidad de manipular las reglas dentro del switch cuando sea necesario, dando prioridad o no a los distintos paquetes, con esto posee un gran control sobre la red establecida y por ende beneficios como gestión, total control y optimización con la priorización y tratamiento de paquetes, en consecuencia se obtienen switch con mayor agilidad para el envío de información ya que la inteligencia no estará soportada sobre él si no que será delegada al controlador. Este trabajo de grado tuvo como finalidad la evaluación e implementación de un controlador (OpenFlow Controller) para la administración de las topologías de red SDN. En el mercado existen varios controladores desarrollados para el manejo de este tipo de redes los cuales tienen característica de código abierto, lenguajes de programación variados y capacidad de manejo de versión del protocolo OpenFlow 1.0 y 1.3, con base en las características que se profundizarán a lo largo del trabajo de grado sobre los controladores, se determinó cuáles son los controladores adecuados para el manejo de la topología de red implementada y posteriormente se exponen los resultados del desempeño tanto en el entorno virtual como en el real. En primera instancia se determinaron parámetros esenciales con el fin de establecer un punto de referencia e iniciar con la proceso, se postuló la evaluación en tres aspectos importantes como son la calidad de la documentación, el interfaz de usuario y los niveles de compatibilidad en cuanto a las versiones del protocolo OpenFlow. En la calidad de la documentación se enfocó en la información encontrada y disponible acerca de, los requerimientos del sistema y sus limitaciones, la instalación del controlador, solución de posibles errores y 1 Big Data [25] : El concepto de Big Data aplica para toda aquella información que no puede ser procesada o analizada utilizando procesos o herramientas tradicionales. Sin embargo, Big Data no se refiere a alguna cantidad en específico, ya que es usualmente utilizado cuando se habla en términos de petabytes y exabytes de datos. 2 Protocolo OpenFlow: Es un protocolo de comunicación abierto que permite a un servidor de software determinar el camino de reenvío de paquetes que deberá seguir a través de la red. 10

11 fallos y posteriormente su forma de uso. Para la apreciación de estos parámetros acerca del controlador se observaron videos, tutoriales, blogs de internet referenciados al proceso, además se indagaron foros puesto que al ser software OpenSource 3 debían poseer este tipo de soluciones; este proceso se realizó con el fin de tener un criterio autónomo y determinar con base en la experiencia cual controlador posee la suficiente documentación para pensar en la inclusión de él en una topología de red SDN. En cuanto al interfaz de usuario se evaluó en conjunto con los niveles de compatibilidad del controlador para la versiones 1.0 y 1.3, el proceso que se desarrolló fue la implementación de topologías de red tanto real como virtual utilizando las dos versiones disponibles para así poder determinar la adaptabilidad que tiene el controlador y su correcto funcionamiento, de igual forma se observaron las características de funcionalidad como lo es la visualización de la topología y las estadísticas en tiempo real del flujo a través de los puertos del switch. Para la documentación necesaria acerca del montaje y el uso del controlador, se destinó una parte del trabajo de grado para enfatizar en este ítem, allí se exponen parámetros óptimos y suficientes para la implementación del controlador y la forma en que debe usarse para la administración de la red, de igual forma se documentó la configuración que debe realizarse a los switch HP para el protocolo OpenFlow y las redes SDN. Para concluir con la evaluación e implementación del controlador OpenFlow, se dispuso de dos topologías de red reales, bus y anillo, donde se incluye el controlador para la administración, de esta manera se determinó el comportamiento de los flujos a través de la red, por consiguiente se implementó un servicio de red sobre el controlador. 3 Open Source: Open Source o Código Abierto es un término que se aplica al Software distribuido bajo una licencia que le permita al usuario el acceso al código fuente del Software y además le facilite el estudio y la modificación con toda libertad sin restricciones en el uso, por otro lado permite redistribuirlo siempre y cuando sea de acuerdo con los términos de la licencia bajo la cual el Software original fue adquirido. 11

12 2. MARCO TEÓRICO Con base en las topologías actuales de redes de comunicación y la administración por parte de los proveedores de servicio, se tiene al alcance una infinidad de aplicaciones y soluciones que se han vuelto esenciales para la vida cotidiana, por ejemplo, encontramos servicios bancarios tales como transacciones, retiros de dinero, transferencias, también encontramos servicios para aerolíneas, hospitales, información gubernamental. Estas redes han llegado a tal punto de necesidad y dependencia que es indispensable el correcto funcionamiento y la optimización de los procesos para obtener los mayores beneficios posibles, pero cuando un sistema se torna tan esencial e indispensable comienzan a aparecer problemáticas de la misma magnitud. Algunos de los problemas que se observan son el cambio en el patrón del tráfico, es decir, las comunicaciones actuales se basan en el modelo Cliente/Servidor, el cual consiste en una solicitud por parte del cliente a un servidor capaz de procesar y entregar una respuesta a la solicitud [4]; con las nuevas aplicaciones y servicios ofrecidos por múltiples plataformas este modelo ha venido decayendo, ahora las aplicaciones y las solicitudes hechas por un cliente son procesadas por varias bases de datos y servidores, esto hace que se desencadene un flujo de conexiones entre los servidores antes de entregar una respuesta final. Para atacar las problemáticas actuales se instauran estrategias de calidad tales como ACL, seguridad y QoS 4, pero al aplicar estas políticas en redes con altísimas conexiones se torna un problema mayor, el sistema tiende a volverse inmanejable, una alta densidad de terminales y todos con los mismo requerimientos significa una alta demanda de recursos tecnológicos, incrementando así los costos de manejo de la red. 2.1 REDES SDN Para ubicar el contexto de las redes actuales se explica cómo es el proceso de un paquete cuando llega a un switch de red convencional, al ingresar el paquete las reglas de protocolo instauradas en el dispositivo le indican a este a donde transferirlo, el dispositivo simplemente envía el paquete al mismo destino y por la misma trayectoria, en una red definida por software un administrador (controlador) de red puede moldear el tráfico desde una consola centralizada para así indicarle al switch que hacer con el nuevo paquete, teniendo en cuenta parámetros como prioridad, origen, destino, simplemente con una actualización de la tablas de flujo instauradas en los dispositivos se tiene el tratamiento correspondiente para el paquete. Un problema concreto con el cual se lidio y se pensó en una nueva forma de redes fue el crecimiento del ancho de banda, si antes una red tenía cuatro nodos, ahora existe la posibilidad de que llegue a tener 4000, además si esta red requiere de 4000 sistemas de configuración el grado de complejidad y el posible error por tratamiento humano incrementa de una manera exponencial, obligando así a los prestadores de servicios a buscar estrategias para que la programación no se haga nodo a nodo, si no que por el contrario realizarlo de manera centralizada. 4 Estas políticas de calidad son necesarias para tener redes de alto desempeño, se hace una breve descripción a continuación: ACL: Una Lista de Control de Acceso (ACL), es un concepto de seguridad informática usado para fomentar la separación de privilegios dentro de la red, las ACL permiten controlar el flujo de tráfico en equipo de red tales como router y switch. Seguridad: Se necesita tener esta política en la red puesto que se dispone de servicios que exponen datos personales de usuarios como transacciones bancarias de alto valor, se enfoca en la protección de la infraestructura y por ende su contenido QoS: Las políticas de Calidad de servicios (QoS) hace referencia al rendimiento de la red en aspectos como prestación del servicio de comunicación, aprovechamiento eficiente del ancho de banda, rendimiento, retrasos en la trasmisión, latencia, Jitter. 12

13 En respuesta a las nuevas necesidades surge una tecnología que facilita el manejo y la administración sobre las redes de telecomunicaciones, esta tecnología permitirá tener un control absoluto sobre los dispositivos que la componen permitiendo así una visualización exacta sobre cada elemento y sus respectivos enlaces, con base a estas propiedades se podrá manejar el tráfico a través de la red de una manera más eficiente permitiendo dar prioridad a datos detallados y el camino que deben tomar por los dispositivos. Figura 1. Arquitectura de red SDN [5] En esta etapa del surgimiento de las redes SDN y la necesidad de estandarización, empresas pioneras como Verizon, Deutsche Telekom, Google, Microsoft, Facebook y Yahoo [6] se asocian para crear Open Networking Fundation (ONF), una organización instaurada con el fin de reglamentar y determinar los parámetros bajos los cuales las redes SDN funcionan, este reglamentación abarca desde especificaciones técnicas de los switch hasta el desarrollo de nuevas versiones del protocolo OpenFlow. Con la centralización del plano de control se pretende obtener de las redes SDN lo siguiente: Visión total de la red: Con las redes SDN, se tiene la completa visión de la red, se puede localizar la conexión de cada dispositivo (host, Switch, router), se conoce previamente la topología y de esta manera se facilita su administración. Alta disponibilidad: Mediante una centralización del control tráfico se puede tener un manejo optimizado del flujo a través de la red, puesto que es solo un ente que controla la comunicación será este el que determine la mejora trayectoria para que la información llegue a su destino. Optimización hacia fallos: Como se tiene una visualización completa de la red, cuando algún dispositivo o conexión presenta fallos, este inmediatamente es reconocido por el controlador, el control aplica las medidas correspondientes a fallos reorganizando las tablas de flujos de los demás dispositivos, de esta forma toda la red conoce la falla y alterna la vía de comunicación. Actualizaciones sin impacto: Cuando sea necesario la actualización del firmware de los dispositivos de red, al tener la capa de control separada de la de datos, se puede realizar dicha gestión sin alterar el flujo de los datos ni alguna limitación en la capacidad de la misma. 13

14 Administración absoluta por parte propietario: Los propietarios de los sistemas SDN que soporten OpenFlow, poseen la total administración del equipo sin alguna limitación, es decir, no tienen alguna atadura con el fabricante, la administración de la red puede realizarse por cualquier persona con conocimientos suficientes para ello. 2.2 OPENFLOW Fue un proyecto de investigación en la Universidad de Stanford, Nick McKeown junto con un grupo de ingenieros, desarrollaron un protocolo de comunicación al cual denominaron OpenFlow [7], este protocolo les permitía tener acceso, mediante software, a los flujos de datos en los componentes de red (switch, router, AP), los ingenieros encargados del protocolo pudieron tener acceso a las tablas de flujo y también a las reglas encargadas de el reenvío de paquetes en los switch. Con base en esta información se logró analizar y cambiar dicho direccionamiento dando prioridad a información que lo requiera, de esta manera se optimizaría el tráfico y se evoluciona en tanto a las velocidades de procesamiento de paquetes y encolamiento de los dispositivos de red. La forma de uso del protocolo es muy sencilla, los switch poseen tablas de flujos que le indican al dispositivo que acciones realizar cuando llega un paquete, se utilizan aplicaciones remotas para acceder a dichas tablas y modificar las reglas de los componentes de red, en palabras sencillas un administrador de red puede modificar, quitar, añadir y gestionar las reglas. En condiciones normales, sin el protocolo OpenFlow, cuando llega un paquete al switch este evalúa el destino y lo reenvía según la información contenida en su tabla de flujo, todo los paquetes son dirigidos hacia el mismo nodo, encaminados por la misma ruta y tratados de la misma manera, este proceso hace que los operadores de red carezcan de control para agilizar el proceso. Figura 2. Esquema de funcionamiento del protocolo OpenFlow para OpenFlow Switch [8] 14

15 Cuando se tiene instalado el protocolo OpenFlow se puede determinar prioridad y enrutamiento de los paquetes en los switch, haciendo de esta una red más flexible y optimizada para ciertos propósitos, por ejemplo, se puede determinar prioridad a un video o una comunicación en streaming de esta manera se evita la interrupción del servicio. Por otro lado, y una de las ventajas del protocolo, es la determinación de normas para gestionar el tráfico, por ejemplo, cuando en una red tiene algún indicio de un terminal sospechoso de virus, puede establecerse una norma para el tráfico a partir del origen y destino del paquete y proceder a bloquear todos los flujos en la red que se dirijan o salgan de él. El protocolo OpenFlow tiene dos funciones principales, la primera consiste en poder definir el flujo de paquetes, la segunda función facilita el camino que deben tomar los paquetes a través de la red, estas configuraciones pueden hacerse gracias al protocolo, con la ventaja de hacer en tiempo real sin la necesidad de interrupción en el servicio. Basándose en estas características, el protocolo plantea mejoramientos notables en cuanto al ancho de banda usado, la latencia presente en el sistema y la disminución de saltos para el consumo energético [7]. Esta tecnología consta de tres componentes principales: Switch de dos tipos, OpenFlow-only y OpenFlow Hibridos. Controlador OpenFlow. Protocolo de comunicación para redes SDN capaz de establecer conexión de manera segura a los Switch, OpenFlow. 2.3 TABLAS DE FLUJO (Flow-Table) VERSION 1.0 [8] Los Switch OpenFlow constan de tablas de flujo para el desempeño de sus funciones, las tablas de flujo ejecutan las funciones de reenvió y redireccionamiento, además poseen un canal seguro para la comunicación con el controlador, esta conexión se realiza ya que el controlador es el encargado de gestionar el dispositivo de red y lo hace con el protocolo OpenFlow. Las tablas de flujo contienen tres campos principales, el primer campo llamado Header Fields contiene un conjunto de entradas que son cabeceras del paquete las cuales poseen información con direcciones IP de origen y de destino, información sobre Vlan (ID y Priority), puerto de ingreso, protocolos de comunicación (TCP/UDP), cada campo del Header Fields se explicará a continuación, un segundo campo Counters contiene información de conteo, este conteo se realiza por tabla, por flujo, por puerto y por cola, el tercer campo Actions es donde se encuentra la información de qué hacer con el paquete de entrada, es decir, que acción de reenvío debe ejecutar y por cual puerto, con los campos anteriores se evalúa la información de paquete y con base en ello el switch toma una acción. Todos los paquetes son procesados por el switch y comparados contra la tabla de flujo presentes en ellos, cuando un paquete ingresa se toma la acción definida por la tabla, las acciones pueden ser hacer el reenvío del paquete o sacar el paquete por un puerto especifico, de la misma forma cuando ingresa un nuevo paquete el controlador este es el encargado de actualizar las tablas de los switch para que conozcan e identifiquen el nuevo paquete, de esta forma los dispositivos sabrán qué hacer con él. Header Fields Counter Actions Figura 3. Componentes de una tabla de flujo de un switch 15

16 Header Fields El protocolo OpenFlow toma los flujos de entrada (flows-entry) para detectar los paquetes, cada entrada contiene información específica con valores detallados como se ilustran en la figura 4. Ingress Port Ether Source Ether Dst Ether type VLAN id VLAN priority IP source IP dst IP Procol Figura 4. Campos de información encontrados en Header Fields IP ToS bits TCP/ UDP Src port TCP/ UDP Dst Port Counters Es el campo encargado de actualizar la información, el proceso lo hace por tabla, por flujo, por puerto, además realiza un conteo detallado sobre paquetes recibidos y enviados. En la figura 5, se encuentra los conteos que realiza el campo por cada aspecto mencionado. Counter Bits Per table Active Entries 32 Packets Lookups 64 Packets Matches 64 Per Flow Received Packets 64 Received Bytes 64 Duration (seconds) 32 Duration (nanoseconds) 32 Per Port Received Packets 64 Transmitted Packets 64 Received Bytes 64 Transmitted Packets 64 Receive Drops 64 Transmit Packets 64 Receive Errors 64 Transmit Errors 64 Receive Frame Alignment Errors 64 Receive Overrum Errors 64 Receive CRC Errors 64 Collisions 64 Per Queue 16

17 Transmit Packets 64 Transmit Bytes 64 Transmit Overrun Errors 64 Figura 5. Conteos que realiza el campo Counter y el número de bits usado Actions También conocido como Instructions, con los valores de este campo el Switch sabe qué hacer con el flujo de entrada, entre las acciones se encuentra principalmente el reenvío pero esta acción posee varias naturalidades que pueden ser: 1. All: Reenvío por todos los puertos. 2. Controller: Encapsula y reenvía el paquete de un flujo al controlador, se usa normalmente para el primer paquete de un flujo nuevo, esto con el fin de que el controlador determine si se agrega o no el flujo a las tablas de flujo. 3. Table: Realiza la operación según su tabla (para paquetes de salida únicamente). 4. In_port: Reenvia el paquete por el puerto de entrada TABLAS DE FLUJO (Flow-Table) VERSION 1.3 Para la descripción de las tablas de flujo en la versión 1.3 de OpenFlow, el proceso en el cual los flujos entrantes hacen Matching 5 con las tablas es diferentes en comparación con la versión 1.0, cuando un paquete llega al switch es comparado con una tabla de flujo única y se ejecuta la acción correspondiente a la tabla, mientras que en el protocolo en su versión 1.3 el paquete realiza el proceso de Matching por todas las tablas esto es con el fin de incrementar la precesión en la acción a tomar, al pasar por las diferentes tablas de flujo se le conoce como Pipeline Processing [9] [10]. Pipeline Processing es un proceso en el cual los flujo de entrada pasan por múltiples tablas de flujo contenidas en los switch, de esta manera se precisa las acciones que deben tomar los paquetes en la red, en la Figura 3. se describe el funcionamiento del Pipeling Processing cuando ingresa un paquete al switch y su proceso a través de las tablas de flujo, mientras que en la Figura 6. se observa el proceso que sigue el paquete en cada tabla de flujo comenzando desde la tabla 0. 5 Matching: En SDN es el proceso por el cual los flujos de entrada con comparados con las tablas de flujo de los switches. 17

18 Figura 6. Paquetes de entrada comparados contra las tablas de flujo en el pipeline Figura 7. Proceso del paquete por tabla de flujo En la figura 7. se aprecia el orden que tiene la tabla de flujo para procesar el paquete y se describe a continuación: 1. El paquete es comparado con la primera tabla de flujo, el orden se define desde la tabla de flujo 0 hasta la N. 2. Se aplican las instrucciones para el paquete las cuales varían desde la salida por un puerto específico hasta la sucesión del paquete a otra tabla. 3. Envío de los datos y la acción hacia la siguiente tabla. Las tablas de flujo de la versión 1.3 del protocolo OpenFlow presenta ciertas adiciones en los flujos entrantes en comparación con la versión 1.0, en esta versión se agregan los campos Priority, Timeouts y Cookie, en la figura 8 se observan los componentes de los flujos entrantes y posteriormente se explicará el funcionamiento de cada uno. Match Fields Priority Counters Instructions Timeouts Cookie Figura 8. Componentes principales de un flujo de entrada in una tabla de flujo 18

19 Match Fieds: Son los encabezados del paquete, al igual que el protocolo OpenFlow en la versión 1.0 presenta los mismos encabezados. Ingress Port Ether Source Ether Dst Ether type VLAN id VLAN priority IP source IP dst Figura 9. Cabeceras de paquetes OpenFlow IP Procol IP ToS bits TCP/ UDP Src port TCP/ UDP Dst Port Priority: Este campo se utiliza para indicarle al sistema, a que tabla de flujo debe enviarse específicamente después de ingresar en la tabla 0. En la figura 10. se observa la comparación del paquete con las tablas de flujo y que acciones ejecuta. Figura 10. Proceso de comparación entre el flujo de entrada y las tablas de flujo Cuando un flujo de entrada no realizar el proceso de comparación con una tabla del switch se le conoce como Table-miss, este suceso se presenta principalmente cuando hay el ingreso de nuevos flujos, aquí el switch envía la solicitud al controlador para saber qué hacer con el paquete, el controlador responde con indicaciones para el nuevo flujo, el switch actualiza sus tablas de flujo y posteriormente ejecuta la acción dada por el controlador. Counters: Este campo es destinado para la información estadística de los flujos de entrada, en la figura 11 se muestra una lista de conteos que realiza el sistema 19

20 Counter Bits Per Flow Table Reference count (active entries) 32 Requiered Packet Lookups 64 Optional Packet Lookups 64 Optional Per Flow Entry Received Packets 64 Optional Received Bytes 64 Optional Duration (seconds) 32 Requiered Duration (nanoseconds) 32 Optional Per Flow Port Received Packets 64 Requiered Transmitted Packets 64 Requiered Received Bytes 64 Optional Transmitted Bytes 64 Optional Receive Drops 64 Optional Transmit Drops 64 Optional Receive Errors 64 Optional Transmit Errors 64 Optional Receive Frame Alignment Errors 64 Optional Receive Overrun Errors 64 Optional Receive CRC Errors 64 Optional Collisions 64 Optional Duration (seconds) 32 Requiered Duration (nanoseconds) 32 Optional Per Queue Transmit Packets 64 Requiered Transmit Bytes 64 Optional Transmit Overrun Errors 64 Optional Duration (seconds) 32 Requiered Duration (nanoseconds) 32 Optional Per Group Reference Count (flow entries) 32 Optional Packet Count 64 Optional Byte Count 64 Optional Duration (seconds) 32 Requiered Duration (nanoseconds) 32 Optional Per Group Bucket Packet Count 64 Optional Byte Count 64 Optional Per Group Bucket 20

21 Flow Count 32 Optional Input Packet Count 64 Optional Input Byte Count 64 Optional Duration (seconds) 32 Requiered Duration (nanoseconds) 32 Optional Per Meter Band In Band Packet Count 64 Optional In Band Byte Count 64 Optional Figura 11. Conteos realizados por el protocolo versión 1.3 Instructions: Cada flujo de entrada contiene un conjunto de instrucciones las cuales son ejecutadas cuando se compara el paquete con las tablas de flujo, mediante este campo del protocolo se determina el proceso que debe realizarse al paquete bien sea modificación del contenido de instructions o el procesamiento por el pipeline. Timeouts: Este campo es el encargado de determinar el tiempo máximo que tiene el switch para descartar el flujo. Cookie: Este campo habilita al controlador para realizar una categorización del paquete de entrada más eficiente en vez de realizar la clasificación siguiendo todas las tablas de flujo del switch CONTROLADORES SDN El controlador es el núcleo y alma fundamental de las redes, este es capaz de administrar y dirigir toda la topología de red. Algunas de las funciones del controlador son la de centralizar toda la comunicaciones que pasa a través de los dispositivos de red, también tiene una visualización total de la red, el controlador es capaz de determinar cómo los flujos van a comportarse dentro de la red, en resumen los dispositivos que componen la red SDN deben reportarse al controlador cada vez que estos lo ameriten, estos casos suelen ser ingreso de nuevos flujos por la red, el dispositivo de red no tiene definido qué hacer con el paquete y por ende pregunta al controlador que hacer con él, el control da las indicaciones a los dispositivos mediante la actualización de las tablas de flujo que cada elemento posee y de esta forma realizar la acción correspondiente. En la actualidad existen varias soluciones de controladores, entre los cuales se encuentran POX, Beacon, Floodlight, SDN VAN HP, estos controladores presentan varias características y diferencias, donde la más notoria diferencia es el lenguaje de programación con el cual fueron desarrollados, a continuación se presenta una breve descripción de los controladores y sus características POX Es un controlado desarrollado para cubrir las necesidades de redes SDN usando lenguaje de programación de Python, sirve para sistemas operativos como Windows, Mac OS y Linux. Entre las características más relevantes del controlador se tiene: 21

22 Lenguaje de OpenFlow basado en Python Detección de topologías de red y selección de rutas de acceso Interfaz gráfica para el usuario y componentes de visualización Desarrollado para el manejo del protocolo OpenFlow en versión BEACON Es un controlador con lenguaje de programación en Java, soporta operaciones basadas en eventos y threads, características de desarrollo optimas, presenta interfaz de usuario y visualización completa de la red, por otro lado al ser el código basado en Java tiene amplias características para ser modificado, esta disposición de poder manipular el código es una de las principales características de los controladores puesto que son todos OpenSource 6 (código abierto), entre las características más relevantes se encuentran: Actualmente es capaz de manejar 100 switch virtuales y 20 switch reales. Por su lenguaje de programación de java puede ejecutarse en muchas plataformas, desde los servidores Linux hasta teléfonos Android. Interfaz de usuario personalizado Fácil de descargar y correr, al ejecutar Java y Eclipse simplifican el desarrollo y la depuración de sus aplicaciones. Rápido debido a su característica de multiproceso Desarrollado para el manejo del protocolo OpenFlow en versión FLOODLIGHT Controlador capaz de manejar switch tanto reales como virtuales, basado en lenguaje de programación Java, dispone de una serie de funcionalidades y capacidades para el manejo de redes SDN, el controlador está previsto para el manejo de paquetes y la instalación de entradas en las tablas de flujo, desarrollado por David Erickson. Este software presenta las siguientes características de manejo en su entorno: Interfaz UI amigable y fácil de observar parámetros detallados. Fácil instalación y uso del mismo Desarrollado para el manejo del protocolo OpenFlow en versión SDN VAN CONTROLLER Controlador desarrollado por el propio fabricante de dispositivos de red HP, es capaz de manejar switch tanto reales como virtuales, en su versión de prueba puede manejar hasta 50 nodos con una amplia gama de posibilidades de control e interacción con las mismas, en las características del controlador se encuentra: Interfaces abiertas y programables 6 OpenSource: Es la expresión con la que se conoce al software distribuido y desarrollado libremente. Se focaliza más en los beneficios prácticos (acceso al código fuente) que en cuestiones éticas o de libertad que tanto se destacan en el software libre 22

23 Control flexible y centralizado Alta disponibilidad y escalabilidad Posee robustez en su seguridad Puede manejar el protocolo OpenFlow en sus versiones 1.0 y 1.3 En lo anterior se mostraron algunas características que poseen los controladores y también una breve explicación de cómo funcionan dentro de las redes SDN. Para el uso del controlador se presentan dos topologías de red, la primera topología se conoce como control centralizado, Figura 13, el controlador es conectado a un switch determinado y desde allí tiene visualización completa de la red, puede enviar instrucciones a cualquier componente y tiene comunicación sin ningún inconveniente con cualquier elemento, dentro de las ventajas se destaca el uso de un solo software para la administración de la red, simplicidad sin alterar desempeño. Otra localización que se le puede dar al controlador es la conocida como controlador distribuido, Figura 12, en esta topología de red existen varios controladores ubicados a lo largo de los dispositivos de la red, principalmente se usa este tipo de topologías cuando se tiene redes demasiado extensas, es decir cuando un controlador aun con sus ventajas de red SDN queda corto en la administración, cabe resaltar que es una red bastante extensa, oscilando entre las 70 y 140 switch. Figura 13. Control centralizado Figura 12. Control distribuido Cuando se implementa alguna de las topologías para el controlador nombradas anteriormente, es necesario introducir el tipo de enrutamiento que el controlador asignará, existen dos posibilidades entre las cuales se encuentra el enrutamiento de flujo y el enrutamiento de agregación, a continuación se hace una breve descripción de su funcionamiento. Basado en el flujo Cada flujo individual es generado en el controlador Debe haber una coincidencia exacta en las entradas de flujo para el matching de los paquetes Las tablas de flujo contienen una entrada de flujo por tabla Ideal para un control detallado 23

24 Agregación Una entrada abarca una gran cantidad de flujo, coincidencias menores en el matching para los flujo de entrada. La tabla de flujo contiene una entrada una entrada por cada categoría de flujos. Ideal para la implementación en un entorno donde exista gran cantidad de flujos Además el controlador presenta dos características en su comportamiento, las cuales pueden denominarse controlador reactivo y controlador proactivo, la forma de uso de estas opciones dependerá principalmente de las necesidades del cliente, para describir estos posibles distribuciones del controlador se explican a continuación algunas de sus funcionalidades: Control Reactivo Uso eficiente de la tabla de flujo, se adapta a las necesidades de la red, cuando no se use una tabla de flujo por un tiempo determinado esta pasa a ser reiniciada y dispuesta para el manejo de nuevos paquetes de entrada. Cada flujo incide en un tiempo determinado para su configuración, tiempo que tarda el controlador en actualizar las tablas de flujo. Si llegase haber una desconexión por parte del controlador, el switch entra en una capacidad limitada, quedándose con las actualización realizadas antes de la caída. Control Proactivo Previa configuración de las tablas de flujo, al saber qué tipo de paquetes y como deben ser tratados el controlador puede dar instrucciones previas para su manejo. No existe pérdida de tiempo en la configuración por parte del controlador, acción previamente realizada. Cuando se presenta una desconexión del controlador el tráfico no se ve interrumpido, pero se resalta que este debe conocerse previamente con exactitud. Teniendo presente las características tanto de desarrollo y configuración de los controladores, y las posibilidades de uso dentro de la red, se escoge un controlador que desempeñe la funcionalidad exigida, además se tienen también en cuenta los siguientes parámetros para su escogencia: 1. Documentación suficiente para el desarrollo y utilización. 2. Los lenguajes de desarrollo de los controladores, este ítem hace referencia si el código con el cual fue construido afecta o no el desempeño del mismo. 3. Facilidad de uso de la aplicación y características adicionales, para tener una total administración de la red una amigable interfaz gráfica y un entorno visual bastante amplio son fundamentales para la elección. 4. Adaptabilidad a los firmwares del equipo por parte del controlador. Este ítem hace referencia a las capacidades de funcionamiento con los protocolos 1.0 y 1.3 que el protocolo OpenFlow. 5. Desempeño como controlador. 24

25 COMUNICACIÓN DEL PROTOCOLO OPENFLOW VERSIÓN 1.0 Y 1.3 El protocolo OpenFlow tiene tres tipos de mensajes denominados controller-to-switch, asynchronous, y symmetric [8], cada uno posee subtipos de mensaje. El controller-to-switch son mensajes iniciados por el controlador, este tipo de mensajes es para verificar el estado del switch y para su configuración; el tipo de mensaje asynchronous, es un tipo de mensaje iniciado por el switch, este es utilizado por el dispositivo para actualizar al control de nuevos eventos de red, cambios de estado del Switch y notificación de errores, los eventos de red pueden ser conexión de nuevos terminales, encuentro de nuevos flujos, y peticiones al controlador, por último se encuentra el tipo de mensaje symmetric, este tipo de mensajes son iniciados tanto por el Switch como por él controlador, se utiliza para la comunicación cuando un Switch se vincula a la red el controlador responde. A continuación se mostrará los submensajes de cada tipo conocidos anteriormente: 1. Controller-to-Switch: Son mensajes iniciados por el controlador, este tipo de mensaje es utilizado para verificar el estado del switch y también para configurarlo, puede o no tener una respuesta del switch. Features: Se usa para el establecimiento de la conexión con el Switch mediante TLS 7, con esta solicitud el controlador desea conocer las características del Switch, este responde al controlado con una seria de capacidades específicas soportadas por este. Configuration: El controlador es capaz de establecer y preguntar los parámetros de configuración de Switch, este a su vez solo responde dicha solicitud a controlador. Modify-State: Son mensajes enviados por el controlador para gestionar el Switch, el propósito principal de este es agregar, quitar o modificar los flujos en la tabla de flujo del Switch y establecer las propiedades del puerto. Read-State: Este mensaje es utilizado por el controlador para recolectar estadísticas del Switch acerca de las tablas de flujo, puertos y flujo de entrada. Send-Packet: Es usado por el controlador para indicarle Switch que saque por un puerto específico determinado paquete. Barrier: Este es un mensaje que tiene tanto petición como respuesta, es usado por el controlador para asegurarse que las dependencias de un mensaje se han cumplido o para recibir notificaciones de operaciones terminadas. Role-Request: Este mensaje es usado por el controlador para establecer el canal OpenFlow o para preguntar al switch por él, usualmente se usa cuando al switch se le conectan varios controladores. 2. Asynchronous: Es un tipo de mensaje utilizado por el switch para notificar al controlador de eventos nuevos de red, cambios de estado y notificación de errores. Los eventos de red involucran los casos de nuevas conexiones por parte de terminales y encuentro de nuevos flujos. 7 TLS: El protocolo TLS (Transport Layer Security) es una evolución de protocolo SSL (Secure Sockets Layer), es un protocolo mediante el cual se establece una conexión segura por medio de un canal cifrado entre el cliente y servidor, en este caso se establece una conexión entre switch (cliente) y Controlador (servidor) basándose en este protocolo, se encuentra en la referencia RFC

26 Packet-in: Es un paquete enviado por el Switch hacia el controlador, lo hace cuando entra un paquete nuevo que al ser comparado con la tabla de flujo no sabe qué hacer con él, el controlador analiza el paquete y responde con un Packet-out. Flow-Removed: Se envía cuando se presenta una inactividad de un flujo, o cuando se vencen los parámetros de TTL 8, este puede ser enviado por el controlador o por el Switch. Port-Status: El Switch es el encargado de enviar este mensaje al controlador y se utiliza para cuando la configuración de un puerto cambia. Error: El Switch notifica al controlador cuando existen problemas con esto mensajes. 3. Symmetric: Este tipo de mensajes son iniciados por el switch y por el controlador, el mensaje es utilizado para la comunicación cuando un switch se vincula a la red, se realiza un intercambio de mensajes donde se determinan parámetros funcionales entre los dispositivos. Hello: Son mensajes intercambiados entre el controlador y el Switch, se utilizan para establecer la conexión entre los dos. Echo: Es un mensaje que posee tanto petición como respuesta y se utiliza para verificar parámetros de la red tales como latencia, ancho de banda y determinar el estado activo del dispositivo. Vendor: Permite dar funcionalidades extra al Switch, este mensaje se usa principalmente para futuras versiones de OpenFlow. 3. ESPECIFICACIONES Las especificaciones alcanzadas por el trabajo se desglosan de la siguiente manera, en primera instancia se evaluó el proceso correspondiente a la calidad de documentación la cual hace referencia a la adquisición e instalación del controlador, forma de uso y limitaciones. En segunda instancia se procede a realizar topologías de red utilizando el software Mininet, por otra parte se usa el software Cbench que permite realizar una serie de evaluaciones de desempeño en cuanto a la capacidad de procesamiento del controlador frente a las peticiones realizadas por un número determinado de switch. Para concluir con las especificaciones realizadas se creó una red real SDN administrada por el controlador, se desarrolló una topología en el laboratorio usando switch del fabricante HP con referencias 3500yl y 3800, estos switches fueron especialmente creados para el manejo de redes SDN y el protocolo OpenFlow. El objetivo de esta implementación era observar el funcionamiento del controlador y poder comprobar las ventajas de esta nueva tecnología. El proceso anteriormente mencionado se describe a profundidad en los siguientes numerales: 1. Para dar un veredicto sobre la calidad de documentación se procede a realizar una exhaustiva búsqueda sobre cada aspecto mencionado anteriormente, se enfoca principalmente en la forma de uso y posibles fallos encontrados a la hora de correr el controlador. 8 TTL: Time to live, es utilizado en el paquete IP de manera que los routers puedan analizarlo y actuar según su contenido. Si un router recibe un paquete con un TTL igual a uno o cero, no lo envía a través de sus puertos, si no que notifica vía ICMP a la dirección IP origen que el destino se encuentra inaccesible o inalcanzable y procede a descartar dicho paquete. 26

27 2. Mediante una correcta instalación de los controladores, se verificó la funcionalidad de los mismos y su operación, esto incluye su despliegue en una topología de red real montada en el laboratorio y una topología de red emulada. Se configuraron las topologías de red tales que fueran las mismas en el entorno real como en el virtual con el fin de tener una comparación en cuanto al desempeño a priori 9 (virtual), y un desempeño a posteriori 10 (real). 3. En la UI (User Interface) de los controladores, se pudo determinar visualmente la topología de red en la cual se encontraba, también se observó el flujo de paquetes en tiempo real haciendo referencia a su puerto, su dirección IP, la prioridad y el número de paquetes tanto recibidos como enviados. 4. Con el analizador de protocolos Wireshark se pudo ver el intercambio de mensajes en los diferentes escenarios que se plantearon y que se profundizarán más adelante, esto con fin de verificar el cumplimiento de la especificaciones del protocolo OpenFlow 1.0 y 1.3 por parte de los controladores. 5. Con el equipo disponible en el laboratorio y en conjunto con HP (Hewlett Packard), se desplegó una red que satisface la topología SDN, en el proceso de la configuración de los equipos se asimilaron las líneas de condigo que debían realizarse para la instauración tanto de controlador como la adición de los terminales al switch. 6. Por culminar en los aspectos alcanzados, se realizó un manual (Tutorial) para la creación de una red SDN y la inclusión del controlador, en la guía se explica detalladamente las línea de código usadas para la configuración de los switches y posibles inconvenientes encontrados, por otra parte se muestra como debe ser la adición del controlador y algunos requerimientos y limitaciones. 4. DESARROLLOS Para iniciar con el proceso se escogieron cuatro controladores de los cuales tres de ellos (POX, Beacon, Floodlight) se eligieron con base a un artículo que realiza una evaluación similar, el artículo se llama Evaluation of OpenFlow Controllers [11], el cuarto controlador se escoge ya que es un controlador desarrollado por los mismo fabricantes de switch Hewlett Packard (HP VAN ). Para la evaluación del controlador en las redes SDN, se tuvo la necesidad de implementar programas específicos para este tipo de redes, estos programas se encargan de probar la eficiencia en cuanto al procesamiento de packet_in y packet_out 11, el encargado de realizar este procedimiento se denomina Cbench [12], más adelante se da una explicación a fondo sobre su forma de uso y operación. Por otro lado se tiene un software especialmente desarrollado para probar variadas topologías de red SDN con diferentes elementos, incluye la posibilidad de adicionar el controlador y ser este el encargado de la administración virtual, este software se denomina Mininet [13], además se desarrolló un código de programación en lenguaje Python (Ver anexo 1) para una topología en semejanza con la red real montada. Para la ejecución de los controladores, después de haber sido instalados siguiendo las indicaciones del Anexo 2, deben ejecutarse los siguientes comandos: 9 A priori: Término de la filosofía idealista que designa un saber obtenido antes e independientemente de la experiencia, inherente desde un principio a la conciencia, a diferencia de a posteriori, o saber obtenido de la experiencia y como resultado de la misma. 10 A posteriori: Término que, a diferencia de a priori, designa el saber obtenido de la experiencia. 11 Packet_in/Packet_out: Son mensajes del protocolo OpenFlow que son usados para la notificaciones del switchal controlador la llegada de un nuevo flujo (packet_in), el controlador se encarga de procesarlo e indicarle al switch que debe hacerse con este flujo (packet_out) 27

28 Floodlight: Se abre un terminal (Crtl+Alt+t), allí se ejecuta el comando $ cd flloodlight y luego $ java jar target/floodlight.jar. De esta manera el controlador iniciara y estará escuchando las peticiones por el puerto Beacon: En la ventana principal de eclipse se debe seguir esta ruta, Debug Debug Preferences OSGI Beacon y click en Debug. POX: Se abre un terminal (Crtl+Alt+t), allí se ejecuta el comando $ cd pox y luego $./pox.py samples.pretty_log forwarding.l2_learning. SDN VAN HP: Este controlador basta con ingresar en el navegador la siguiente dirección y se reemplaza la dirección IP por la del equipo donde se corra SIMULADORES MININET Este software permite la emulación de una topología de red (host, switch, controlador OpenFlow) mediante la ejecución de líneas de comando en un OS 12 Linux, la gran ventaja que posee el simulador es que brinda la conexión de cada elemento de red e incorpora el controlador para la administración de la misma, en una primera impresión el simulador de red Mininet permite la conexión virtual del controlador. El uso de Mininet en esta etapa de evaluación fue una de las más importantes para el proyecto, lo que se obtuvo con él programa fue la comprobación de que el controlador funcionó y que la instalación fue correcta, para ello se generó la topología de la Figura 14, y se vinculó el controlador obteniendo así la visualización por parte de la UI de la red y el reconocimiento del switch RECONOCIMIENTO DE TOPOLOGIA DE MININET POR LOS CONTROLADORES Host 1 Switch Host 2 Controlador Figura 14. Topología de red implementada en la comprobación del controlador 12 OS: Operating System o Sistema Operativo 28

29 Para la ejecución de Mininet y la inclusión del controlador tuvo que escribirse la siguiente línea de código en un terminal: $ sudo mn controller=remote,ip= ip_del_host_del_controlador RECONOCIMIENTO DE TOPOLOGIA POR CONTROLADOR FLOODLIGHT E IPERF Figura 15. Topología dada por floodlight 29

30 Figura 16. Ancho de banda entre los terminales RECONOCIMIENTO DE TOPOLOGIA POR CONTROLADOR BEACON E IPERF Figura 17. Topología dada por Beacon 30

31 Figura 18. Ancho de banda entre los terminales con controlador Beacon RECONOCIMIENTO DE TOPOLOGIA POR CONTROLADOR POX E IPERF Figura 19. Reconocimiento de switch por POX 31

32 Figura 20. Ancho de banda dado por POX RECONOCIMIENTO DE TOPOLOGIA POR CONTROLADOR SDN VAN HP E IPERF Figura 21. Detección de switch por SDN VAN HP 32

33 Figura 22. Ancho de banda dado por SDN VAN HP INTERCAMBIO DE MENSAJES ENTRE EL SWITCH Y EL CONTROLADOR Figura 23. Intercambio de mensajes entre el switch y el controlado 33

34 Con base a las posibilidades que ofrece Mininet y especialmente en la manipulación de terminales, se procedió a emitir comandos tales como ping, pingall, iperf entre los terminales de la red para observar la comunicación entre ellos y en conjunto con WireShark verificar los mensajes del protocolo OpenFlow. Ping: Se pretende emitir un ping desde un origen hacia un destino con el fin de comprobar la conexión correcta de la red y el alcance, esta prueba permite identificar, mediante el uso de WireShark, que el controlador y lo terminales que intervienen en la ejecución de la acción realizan su proceso de comunicación correcto y que el protocolo OpenFlow realiza el intercambio de tramas correspondientes. Ping all: Esta prueba permite realizar ping desde un terminal hacia todos los de la red, de esta forma se identifica a conexión total en la red y su visualización de todos los terminales. Iperf 13 : Permite ejecutar un servidor iperf en un host y un cliente iperf en otro host, esto con el fin de caracterizar el ancho de banda entre los dos TOPOLOGIA BUS, 3 SWITCHES Y 3 HOST Para lograr esta topología de red en Mininet debe escribirse el siguiente comando: $ sudo mn topo linear,3 controller=remote,ip= Ip_del_host_del_controlador TOPOLOGIA BUS, CONTROLADOR FLOODLIGHT (VIRTUAL) Figura 24. Topología lineal en MIninet dada por floodlight 13 Iperf: Es una herramienta de análisis de uso común que puede crear flujos de datos TCP y UDP y medir el rendimiento de la red. permite al usuario ajustar los distintos parámetros que pueden usarse para probar una red, o alternativamente para optimizar o ajustar la red. Iperf tiene una funcionalidad de cliente y servidor, y puede medir el rendimiento entre los dos extremos, ya sea unidireccionalmente o bidireccionalmente. 34

35 TOPOLOGIA BUS, CONTROLADOR BEACON (VIRTUAL) Figura 25. Dispositivos Vistos por beacon en topología bus TOPOLOGIA BUS, CONTROLADOR POX (VIRTUAL) Figura 26. Conexión switch virtuales en topología bus Mininet 35

36 TOPOLOGIA EN ANILLO, 3 SWITCH Y 3 HOST Como esta topología de red es personalizada, debe ejecutarse de la siguiente forma, teniendo en cuenta que Mininet guardas las topologías personalizadas en una carpeta llamada custom. $ sudo mn custom /home/carlos/mininet/custom/mytopo1.py topo mytopo controller=remote,ip= Ip_del_host_del_controlador TOPOLOGIA EN ANILLO CONTROLADOR FLOODLIGHT Figura 27. Topología Anillo Mininet, floodlight 36

37 TOPOLOGIA EN ANILLO CONTROLADOR BEACON Figura 28. Switch vistos por Beacon en Topología anillo en Mininet 37

38 TOPOLOGIA EN ANILLO CONTROLADOR POX Figura 29. Switch en topología anillo identificados por el controlador TOPOLOGIA EN ANILLO CONTROLADOR SDN VAN HP Figura 30. Topología en anillo dada por Mininet, controlador SDN VAN H 38

39 CBENCH BENCHMARK TOOL Para la evaluación del controlador en cuanto a su aspecto de procesamiento de peticiones nuevas por parte de los switch, se usó un Benchmark tool llamado Cbench, este software permite emular un número determinado de host (terminales) conectados a un número N switch y evaluar los parámetros de troughput del controlador. El funcionamiento de Cbench es el siguiente, el simulador crea N switch y conecta un número determinado de host, luego crea N conexiones hacia el controlador, de esta manera se genera una topología como la vista en la figura 25. Para evaluar el Troughput se determinará la cantidad de transacciones por segundo que el controlador pueda manejar, el sistema puede medir este parámetro de dos maneras diferentes, la primera en bits por segundo (bit/s o bps) y la segunda en paquetes por segundo. Figura 25. Topología generada por Cbench. El número de switch a emular será un parámetro dado por el usuario, de igual forma la cantidad de host conectados a los switch. [18] Para la ejecución de Cbench, una vez descargado (Ver Anexo 3), se escribe en una terminal el siguiente código: - $ cd openflow - $ cd oflops - $ cd cbench - $./cbench -c localhost -p m l 10 -s 16 -M 1000 t Donde s representa el número de switch a emular, y M representa la cantidad de Host por switch. En la evaluación que se realizó a los controladores se usó el siguiente comando, donde se varió el número de Host por switch desde 100 k hasta 10 M, en la sección de análisis de resultados se expone lo obtenido../cbench -c localhost -p m l 10 -s 16 M t./cbench -c localhost -p m l 10 -s 16 M t 39

40 ./cbench -c localhost -p m l 10 -s 16 M t 4.2. TOPOLOGIA DE RED CREADA EN EL LABORATORIO La máquina donde se encuentran los controladores POX, Beacon y Floodlight tiene las características que se observan en la Figura 31. Figura 31. Características del equipo donde se encuentran los controladores 40

41 TOPOLOGIA DE RED BUS La figura 32 representa una de las topologías construidas en el laboratorio, usando el equipo disponible que consta de dos switches HP E3800 y un HP 3500yl, y se incluyen los controladores para la administración de la red. A continuación se muestra como fue el intercambio de mensajes entre los switches y el controlador: Switch 1 Switch 2 Switch 3 Controlador Host 1 Host 2 Host 3 Figura 32. Topología tipo bus implementada en el laboratorio La configuración que tuvo que hacerse a los switch se encuentra en el Anexo 4 y se realizó con ayuda del manual dado por el fabricante HP HP OpenFlow Switches. Para tener en contraste los resultados obtenidos en la simulación con lo obtenido en la red real, se realizó la prueba de conectividad entre el Host 1, a los Host 2 y Host 3, en la sección de análisis de resultados se expone cuáles fueron los datos obtenidos en cuanto el tiempo mínimo, máximo y promedio que tardaba en ir y volver a su destino, y el número de paquetes perdidos en el proceso, esta prueba se realizó ya que los switch están en constante comunicación con el controlador y enviaran la solicitud de qué hacer con el flujo de entrada nuevo, así se pondrá a prueba la velocidad de respuesta del controlador, como se puede observar el controlador solo necesita estar en conexión directa con un switch para tener administración y total visión de la red. 41

42 RECONOCIMIENTO DE LA TOPOLOGÍA POR PARTE DEL CONTROLADOR FLOODLIGHT Figura 33. Pantalla Principal de Floodlight En la figura 33 se observa como el controlador floodlight en su UI reconoce los switch y los host. 42

43 Figura 34. Topología de red dada por el controlador RECONOCIMIENTO DE LA TOPOLOGÍA POR PARTE DEL CONTROLADOR BEACON Figura 35. Reconocimiento de switch en controlador Beacon 43