Diseño e implementación de una aplicación para balanceo de carga para una Red Definida por Software (SDN)

Texto completo

(1)La versión digital de esta tesis está protegida por la Ley de Derechos de Autor del Ecuador.. Los derechos de autor han sido entregados a la “ESCUELA POLITÉCNICA NACIONAL” bajo el libre consentimiento del (los) autor(es).. Al consultar esta tesis deberá acatar con las disposiciones de la Ley y las siguientes condiciones de uso: Cualquier uso que haga de estos documentos o imágenes deben ser sólo para efectos de investigación o estudio académico, y usted no puede ponerlos a disposición de otra persona. Usted deberá reconocer el derecho del autor a ser identificado y citado como el autor de esta tesis. No se podrá obtener ningún beneficio comercial y las obras derivadas tienen que estar bajo los mismos términos de licencia que el trabajo original.. El Libre Acceso a la información, promueve el reconocimiento de la originalidad de las ideas de los demás, respetando las normas de presentación y de citación de autores con el fin de no incurrir en actos ilegítimos de copiar y hacer pasar como propias las creaciones de terceras personas.. Respeto hacia sí mismo y hacia los demás..

(2) ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA. DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN PARA BALANCEO DE CARGA PARA UNA RED DEFINIDA POR SOFTWARE (SDN). PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN ELECTRÓNICA Y REDES DE INFORMACIÓN. MARLON ESTEBAN OLAYA YANDUN [email protected]. DIRECTOR: ING. DAVID MEJÍA, MSC. [email protected]. Quito, noviembre 2015.

(3) I. DECLARACIÓN. Yo MARLON ESTEBAN OLAYA YANDUN, declaro bajo juramento que el trabajo aquí escrito es de mi autoría; que no ha sido previamente presentado para ningún grado o calificación profesional; y que he consultado las referencias bibliogríficas que se incluyen en este documento.. A través de la presente declaración cedo mis derechos de propiedad intelectual, correspondientes a este trabajo, a la Escuela Politécnica Nacional, según lo establecido por la Ley de Propiedad Intelectual, por su reglamento y por la normatividad institucional vigente.. Marlon Esteban Olaya Yandun.

(4) II. CERTIFICACIÓN. Certifico que el presente trabajo fue desarrollado por MARLON ESTEBAN OLAYA YANDUN, bajo mi supervisión.. Ing. David Mejía, MSc. Director del Proyecto.

(5) III. AGRADECIMIENTOS. En primer lugar agradezco a mis padres Yolanda y Benigno, por todo el apoyo que me han dado desde el principio de mi vida, en especial a mi madre que ha estado conmigo en los buenos y malos momentos, siempre animándome y ayudándome a ser mejor ser humano. También debo agradecer a Tatita por todo el amor, cariño, comprensión y apoyo que me ha brindado durante prácticamente toda mi carrera universitaria, sin ella este objetivo posiblemente hubiera tardado más, gracias por el apoyo y la presión bonita. No puedo dejar de agradecer a los padres de Taty, la Sra. Gloria y Don Miguel por abrirme las puertas de su hogar y tratarme como otro de sus hijos durante todos estos años. Agradezco al Ing. Davíd Mejía por su guía y concejo durante el desarrollo de este proyecto. Finalmente agradezco a todos mis amigos que de alguna forma me apoyaron en la realización de este proyecto y que han sido parte de mi vida, entre ellos debo agradecer de sobre manera al Meri por la paciencia y ayuda compartiendo sus conocimientos y al Santos por tantos favores y molestias causadas a lo largo del tiempo que nos conocemos, muchas gracias muchachos..

(6) IV. DEDICATORIA. A aquel que ha estado presente en todo lo que he hecho desde el 2011, mi hijo. Esteban Olaya.

(7) V. ÍNDICE DE CONTENIDOS. DECLARACIÓN. I. CERTIFICACIÓN. II. AGRADECIMIENTOS. III. DEDICATORIA. IV. ÍNDICE DE CONTENIDOS. V. ÍNDICE DE FIGURAS. X. ÍNDICE DE TABLAS. XI. ÍNDICE DE CÓDIGOS. XII. RESUMEN. XIII. PRESENTACIÓN. XIV. 1 FUNDAMENTOS TEÓRICOS. 1. 1.1 REDES DEFINIDAS POR SOFTWARE . . . . . . . . . . . . . . . . .. 1. 1.1.1 OPENFLOW . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.1.1.1 Wire Protocol . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.1.1.2 Of-Config . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 1.1.1.3 Mensajes OpenFlow. . . . . . . . . . . . . . . . . . .. 9. 1.1.1.3.1. Mensajes Controlador-Switch . . . . . . . . .. 9. 1.1.1.3.2. Mensajes Asincrónicos. 1.1.1.3.3. Simétricos . . . . . . . . . . . . . . . . . . . . 10. . . . . . . . . . . . . 10. 1.1.2 CONTROLADOR SDN . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 RYU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.1 FUNCIONAMIENTO . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.2 COMPONENTES . . . . . . . . . . . . . . . . . . . . . . . . . . 13.

(8) VI 1.2.2.1 Ejecutables . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2.2.2 Componentes Base . . . . . . . . . . . . . . . . . . . 14 1.2.2.3 Controlador OpenFlow. . . . . . . . . . . . . . . . . . 14. 1.2.2.4 Codificador/Decodificador OpenFlow. . . . . . . . . . 14. 1.2.2.5 Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . 15 1.2.2.6 Librerías . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2.2.7 Librerías de Terceros. . . . . . . . . . . . . . . . . . . 16. 1.3 SISTEMA DE ENCOLAMIENTO . . . . . . . . . . . . . . . . . . . . . 16 1.3.1 CLIENTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3.2 SERVIDORES WEB . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3.2.1 Tráfico web . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3.3 BALANCEADOR DE CARGA . . . . . . . . . . . . . . . . . . . 19 1.3.3.1 Algoritmos de encolamiento . . . . . . . . . . . . . . . 19 1.3.3.1.1. FiFo . . . . . . . . . . . . . . . . . . . . . . . 20. 1.3.3.1.2. Round Robin . . . . . . . . . . . . . . . . . . 21. 1.3.3.1.3. Deficit Round Robin . . . . . . . . . . . . . . 21. 2 DISEÑO Y DESARROLLO DE LA APLICACIÓN. 26. 2.1 ANÁLISIS DE REQUERIMIENTOS . . . . . . . . . . . . . . . . . . . . 26 2.1.1 AMBIENTE FÍSICO. . . . . . . . . . . . . . . . . . . . . . . . . 26. 2.1.2 USUARIOS Y FACTORES HUMANOS . . . . . . . . . . . . . . 26 2.1.3 FUNCIONALIDAD . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2 CRITERIOS DE ENCOLAMIENTO . . . . . . . . . . . . . . . . . . . . 27 2.2.1 FIFO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28. 2.2.2 ROUND ROBIN. . . . . . . . . . . . . . . . . . . . . . . . . . . 28. 2.2.3 DEFICIT ROUND ROBIN . . . . . . . . . . . . . . . . . . . . . 29 2.3 ETAPAS DE LA APLICACIÓN . . . . . . . . . . . . . . . . . . . . . . . 29 2.3.1 RECEPCIÓN DE PAQUETES . . . . . . . . . . . . . . . . . . . 29 2.3.1.1 Paquetes ARP . . . . . . . . . . . . . . . . . . . . . . 30 2.3.1.2 Paquetes no ARP . . . . . . . . . . . . . . . . . . . . 30 2.3.2 PROCESAMIENTO. . . . . . . . . . . . . . . . . . . . . . . . . 31. 2.3.2.1 Procesamiento FIFO . . . . . . . . . . . . . . . . . . . 32 2.3.2.2 Procesamiento RR . . . . . . . . . . . . . . . . . . . . 33 2.3.2.3 Procesamiento DRR . . . . . . . . . . . . . . . . . . . 33 2.3.3 CREACIÓN DE REGLAS . . . . . . . . . . . . . . . . . . . . . 34 2.4 DESARROLLO DE LA APLICACIÓN . . . . . . . . . . . . . . . . . . . 37 2.4.1 RECEPCIÓN DE PAQUETES. . . . . . . . . . . . . . . . . . . 37.

(9) VII 2.4.2 PROCESAMIENTO. . . . . . . . . . . . . . . . . . . . . . . . . 42. 2.4.2.1 Criterio FIFO . . . . . . . . . . . . . . . . . . . . . . . 43 2.4.2.2 Criterio RR . . . . . . . . . . . . . . . . . . . . . . . . 43 2.4.2.3 Criterio DRR . . . . . . . . . . . . . . . . . . . . . . . 43 2.4.3 CREACIÓN DE REGLAS . . . . . . . . . . . . . . . . . . . . . 48 3 IMPLEMENTACIÓN, PRUEBAS Y ANÁLISIS DE RESULTADOS. 51. 3.1 IMPLEMENTACIÓN DE LA SDN . . . . . . . . . . . . . . . . . . . . . 51 3.1.1 IMPLEMENTACIÓN EN MININET . . . . . . . . . . . . . . . . . 51 3.1.1.1 Proceso de Configuración . . . . . . . . . . . . . . . . 52 3.1.2 IMPLEMENTACIÓN FÍSICA . . . . . . . . . . . . . . . . . . . . 55 3.1.2.1 Switch OpenFlow . . . . . . . . . . . . . . . . . . . . . 57 3.1.2.1.1. VLAN . . . . . . . . . . . . . . . . . . . . . . 58. 3.1.2.1.2. Instancia OpenFlow . . . . . . . . . . . . . . 58. 3.1.2.1.3. Controlador . . . . . . . . . . . . . . . . . . . 60. 3.1.2.2 Servidores . . . . . . . . . . . . . . . . . . . . . . . . 61 3.1.2.3 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.2 PRUEBAS Y ANÁLISIS DE RESULTADOS . . . . . . . . . . . . . . . 64 3.2.1 PRUEBAS EN MININET . . . . . . . . . . . . . . . . . . . . . . 66 3.2.1.1 Criterio FIFO . . . . . . . . . . . . . . . . . . . . . . . 68 3.2.1.2 Criterio RR . . . . . . . . . . . . . . . . . . . . . . . . 69 3.2.2 PRUEBAS EN LA SDN FÍSICA . . . . . . . . . . . . . . . . . . 72 3.2.2.1 Criterio FIFO . . . . . . . . . . . . . . . . . . . . . . . 72 3.2.2.2 Criterio RR . . . . . . . . . . . . . . . . . . . . . . . . 77 3.2.2.3 Criterio DRR . . . . . . . . . . . . . . . . . . . . . . . 79 3.2.3 PRUEBAS GENERALES DE LA APLICACIÓN . . . . . . . . . 79 3.2.3.1 Tiempos de respuesta . . . . . . . . . . . . . . . . . . 81 3.2.3.1.1. Criterio FIFO . . . . . . . . . . . . . . . . . . 81. 3.2.3.1.2. Criterio RR . . . . . . . . . . . . . . . . . . . 82. 3.2.3.1.3. Criterio DRR . . . . . . . . . . . . . . . . . . 82. 4 CONCLUSIONES Y RECOMENDACIONES. 91. 4.1 CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.2 RECOMENDACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 REFERENCIAS BIBLIOGRÁFICAS ANEXOS. 98 101.

(10) VIII ANEXO A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1.

(11) IX. ÍNDICE DE FIGURAS. Figura 1.1 Componentes principales del modelo OpenFlow [25] . . . . . .. 2. Figura 1.2 Entrada (Flow) de una tabla de flujos OpenFlow 1.0.0[26] . . .. 6. Figura 1.3 Cabecera OpenFlow 1.0.0 [25] . . . . . . . . . . . . . . . . . .. 6. Figura 1.4 Acciones OpenFlow 1.0.0 [25] . . . . . . . . . . . . . . . . . . .. 8. Figura 1.5 Relación entre componentes, protocolo Of-Config y protocolo OpenFlow [27] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9. Figura 1.6 Perspectiva cliente web . . . . . . . . . . . . . . . . . . . . . . 18 Figura 1.7 Balanceo de carga manual . . . . . . . . . . . . . . . . . . . . 20 Figura 1.8 FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Figura 1.9 Round Robin con tres servidores. . . . . . . . . . . . . . . . . . 22 Figura 1.10 Deficit Round Robin con tres servidores (Parte 1) . . . . . . . . 24 Figura 1.11 Deficit Round Robin con tres servidores (Parte 2) . . . . . . . . 25 Figura 2.1 Criterio de encolamiento basado en FIFO . . . . . . . . . . . . 28 Figura 2.2 Criterio de encolamiento basado en Round Robin . . . . . . . . 29 Figura 2.3 Criterio de encolamiento basado en Deficit Round Robin . . . . 30 Figura 2.4 Funcionamiento en caso de paquete ARP . . . . . . . . . . . . 31 Figura 2.5 Funcionamiento en caso de paquetes que no son ARP . . . . . 32 Figura 2.6 Funcionamiento de la etapa de procesamiento. . . . . . . . . . 33 Figura 2.7 Procesamiento FIFO . . . . . . . . . . . . . . . . . . . . . . . . 34 Figura 2.8 Procesamiento RR . . . . . . . . . . . . . . . . . . . . . . . . . 35 Figura 2.9 Procesamiento DRR . . . . . . . . . . . . . . . . . . . . . . . . 36 Figura 3.1 SDN implementada con Mininet . . . . . . . . . . . . . . . . . . 52 Figura 3.2 Terminal para cada cada host, switch y controlador . . . . . . . 54 Figura 3.3 Creación de la topología en Mininet . . . . . . . . . . . . . . . . 55 Figura 3.4 Configuración de la versión de OpenFlow en el switch . . . . . 55 Figura 3.5 Pantalla de inicio de VMware vSphere Client . . . . . . . . . . 58 Figura 3.6 Advertencia de seguridad . . . . . . . . . . . . . . . . . . . . . 59 Figura 3.7 Administrador de máquinas virtuales . . . . . . . . . . . . . . . 59 Figura 3.8 Página de inicio servidor web 1 . . . . . . . . . . . . . . . . . . 62.

(12) X Figura 3.9 Página de inicio servidor web 2 . . . . . . . . . . . . . . . . . . 62 Figura 3.10 Página de inicio servidor web 3 . . . . . . . . . . . . . . . . . . 63 Figura 3.11 Archivo de configuración vacío . . . . . . . . . . . . . . . . . . 66 Figura 3.12 Archivo de configuración con información . . . . . . . . . . . . 67 Figura 3.13 Arranque del controlador y la aplicación . . . . . . . . . . . . . 68 Figura 3.14 Valores de configuración en Mininet . . . . . . . . . . . . . . . 69 Figura 3.15 Respuesta al cliente 1 . . . . . . . . . . . . . . . . . . . . . . . 70 Figura 3.16 Flujos instalados en el switch virtual criterio FIFO . . . . . . . . 71 Figura 3.17 Flujos instalados en el switch virtual criterio RR . . . . . . . . . 71 Figura 3.18 Pruebas criterio FIFO . . . . . . . . . . . . . . . . . . . . . . . 73 Figura 3.19 Flujos que descartan paquetes . . . . . . . . . . . . . . . . . . 74 Figura 3.20 Flujos para el tráfico entre cliente-servidor . . . . . . . . . . . . 75 Figura 3.21 Flujos para el tráfico entre servidor-cliente . . . . . . . . . . . . 76 Figura 3.22 Pasos 1 y 2 del procedimiento de pruebas para el criterio DRR. 85. Figura 3.23 Flujos cliente-servidor creados hasta el paso 3 del procedimiento de pruebas DRR . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Figura 3.24 Cambio de tiempos de vida de flujos en el archivo de configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Figura 3.25 Flujos con tiempos de vida modificados . . . . . . . . . . . . . 87 Figura 3.26 Petición web utilizando HTTPS con Chrome . . . . . . . . . . . 88 Figura 3.27 Petición web utilizando HTTPS con Opera . . . . . . . . . . . . 89 Figura 3.28 Pruebas audio y video . . . . . . . . . . . . . . . . . . . . . . . 90.

(13) XI. ÍNDICE DE TABLAS. Tabla 1.1 Contadores OpenFlow 1.0.0 [26] . . . . . . . . . . . . . . . . . .. 7. Tabla 1.2 Ejemplos de controladores y sus respectivos desarrolladores . . 12 Tabla 3.1 Características del PC de pruebas . . . . . . . . . . . . . . . . . 52 Tabla 3.2 Características de las PC clientes 1 y 2 . . . . . . . . . . . . . . 56 Tabla 3.3 Características de las PC clientes 3 y 4 . . . . . . . . . . . . . . 56 Tabla 3.4 Características de la PC de clientes y de la PC de servidores . . 57 Tabla 3.5 Configuración de la instancia OpenFlow. . . . . . . . . . . . . . 60. Tabla 3.6 Configuración del controlador en el switch . . . . . . . . . . . . . 60 Tabla 3.7 Características de los clientes Linux virtuales . . . . . . . . . . . 63 Tabla 3.8 Resultados esperados . . . . . . . . . . . . . . . . . . . . . . . . 78 Tabla 3.9 Resultados fallidos obtenidos . . . . . . . . . . . . . . . . . . . . 78 Tabla 3.10 Tiempos de respuesta para FIFO (primeras pruebas) . . . . . . 81 Tabla 3.11 Tiempos de respuesta para FIFO (segundas pruebas) . . . . . . 82 Tabla 3.12 Tiempos de respuesta para RR (primeras pruebas) . . . . . . . 82 Tabla 3.13 Tiempos de respuesta para RR (segundas pruebas) . . . . . . . 82 Tabla 3.14 Tiempos de respuesta para DRR . . . . . . . . . . . . . . . . . . 83 Tabla 3.15 Tiempos de respuesta para DRR . . . . . . . . . . . . . . . . . . 83 Tabla 3.16 Tiempos de respuesta para FIFO, RR y DRR . . . . . . . . . . . 84 Tabla 3.17 Tiempos de descarga de audio y vídeo . . . . . . . . . . . . . . 84.

(14) XII. ÍNDICE DE CÓDIGOS. Código 2.1 Función _packet_in_handler . . . . . . . . . . . . . . . . . . . . 39 Código 2.2 Función _arp_handler (parte 1) . . . . . . . . . . . . . . . . . . . 40 Código 2.3 Función _arp_handler (parte 2) . . . . . . . . . . . . . . . . . . . 41 Código 2.4 Función _arp_handler (parte 3) . . . . . . . . . . . . . . . . . . . 42 Código 2.5 Función fifo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Código 2.6 Función round_robin . . . . . . . . . . . . . . . . . . . . . . . . . 43 Código 2.7 Función stats_reply_handler . . . . . . . . . . . . . . . . . . . . 46 Código 2.8 Función proc_index . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Código 2.9 Función def_round_robin . . . . . . . . . . . . . . . . . . . . . . 47 Código 2.10 Función add_flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Código 3.1 Conexión con Mininet usando SSH . . . . . . . . . . . . . . . . . 53 Código 3.2 Creación de la topologia usando Mininet . . . . . . . . . . . . . . 53 Código 3.3 Levantamiento del servidor web en el host h4 . . . . . . . . . . . 54 Código 3.4 Levantamiento del servidor web en el host h5 . . . . . . . . . . . 54 Código 3.5 Levantamiento del servidor web en el host h6 . . . . . . . . . . . 54 Código 3.6 Estableciendo la versión 1.0 de OpenFlow en el switch . . . . . . 54 Código 3.7 Creación de la VLAN y asociación de puertos . . . . . . . . . . . 58 Código 3.8 Creación de la instancia OpenFlow . . . . . . . . . . . . . . . . . 59 Código 3.9 Ingreso de la VLAN 50 a la instancia OpenFlow . . . . . . . . . . 59 Código 3.10 Información del controlador . . . . . . . . . . . . . . . . . . . . . . 60 Código 3.11 Asociación del controlador con la instancia . . . . . . . . . . . . . 61 Código 3.12 Hablilitación de la instancia OpenFlow . . . . . . . . . . . . . . . 61 Código 3.13 Habilitación de OpenFlow de manera global . . . . . . . . . . . . 61 Código 3.14 Inicio del funcionamiento del controlador . . . . . . . . . . . . . . 65 Código 3.15 Petición HTTP desde los clientes . . . . . . . . . . . . . . . . . . 67 Código 3.16 Ping hacia cualquier dirección IP. . . . . . . . . . . . . . . . . . . 68. Código 3.17 Comando para mostrar los flujos del switch . . . . . . . . . . . . . 68.

(15) XIII. RESUMEN. En el presente trabajo se realiza un estudio de las SDN (Software Defined Networks) y el controlador Ryu, para luego aplicar esta tecnología en el diseño e implementación de un balanceador de carga para servidores web dentro de una SDN. En el primer capítulo se revisa la teoría necesaria para la comprensión y el correcto desarrollo de este proyecto. En primer, lugar se exponen las definiciones y conceptos necesarios para entender las SDN, sus características y además varias de sus ventajas y desventajas con respecto a las redes tradicionales. A continuación se analiza el controlador Ryu, utilizado para el desarrollo de este proyecto. Se continúa con una breve revisión acerca de los servidores web y la necesidad de la distribución de carga en los mismos. Luego se realiza un breve estudio de los balanceadores de carga y su funcionamiento. Finalmente se efectúa un pequeño análisis de varios algoritmos que son la base para el desarrollo del balanceador de carga. En el capítulo dos se presenta el análisis de requerimientos realizado para el diseño de un balanceador de carga, después se eligen los criterios para el encolamiento en base a los algoritmos analizados en el capítulo uno, a continuación se realiza el diseño de cada etapa de la aplicación y se muestra el proceso de desarrollo de las mismas. En el capítulo tres se presenta la implementación de una SDN virtual, una SDN física y la aplicación que funcionará sobre estas. En primer lugar se muestra la SDN implementada en Mininet, para posteriormente pasar a la implementación de la SDN física, donde se revisan las características y la configuración del switch OpenFlow y de los equipos utilizados para los servidores y los clientes. Posteriormente se realizan las pruebas de la aplicación, tanto en Mininet como en la SDN física, para finalmente presentar y analizar los resultados obtenidos. En el capítulo cuatro se presentan las conclusiones y recomendaciones obtenidas del desarrollo de este proyecto..

(16) XIV. PRESENTACIÓN. Las necesidades de transmitir grandes cantidades de información de forma segura y eficiente han causado el continuo avance y desarrollo de las tecnologías de la información. Uno de estos avances es la arquitectura conocida como SDN (Software Defined Network ) que permite un mayor control sobre todos los dispositivos de interconexión de la red desde un solo punto lógico de administración. Las SDN son redes que en este momento se encuentran en continuo desarrollo por todas las potencialidades que tienen en aspectos de seguridad y de servicios que pueden ofrecerse de manera sencilla a través de las mismas. Internet en la actualidad es utilizada por la mayor parte de la población mundial para diferentes propósitos como por ejemplo realizar compras, leer, escuchar música, mirar vídeos, entre otros. Cada página web en Internet está alojada en un servidor web y puede tener visitantes de todas partes del mundo, por lo tanto, para sitios populares se utiliza más de un servidor web, ya que la cantidad de tráfico en un solo servidor podría causar una saturación y posterior caída del mismo, provocando pérdidas de tiempo y dinero. Para evitar este tipo de pérdidas se realiza una distribución del tráfico entre los diferentes servidores que alojan el mismo contenido, siendo este proceso transparente para el usuario. Esta distribución se realiza mediante un software o hardware especializado conocido como “balanceador de carga”, estos balanceadores de carga en el mercado tienen un alto costo y probablemente no estén al alcance de las compañías que están comenzando a desarrollarse. El gran avance tecnológico en las comunicaciones, la importancia de los sitios web en Internet y el alto costo de un balanceador de carga han inspirado al desarrollo de este Proyecto de Titulación denominado “DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN PARA BALANCEO DE CARGA PARA UNA RED DEFINIDA POR SOFTWARE (SDN)”. En este Proyecto se presenta la base teórica de las SDN, la implementación de una SDN virtual y una SDN física, el tema principal es el diseño e implementación de una aplicación para balancear la carga de servidores en una SDN. Este Proyecto ayuda a incursionar en la arquitectura SDN y demostrar las capacidades de las mismas. Se utiliza el controlador Ryu que además de estar en constante desarrollo es de uso libre y de código abierto, lo que implica que las aplicaciones realizadas para el mismo no tienen valor comercial alguno. Un servicio que pudiera.

(17) XV implicar un gran gasto utilizando el software o hardware de balanceo de carga en redes convencionales, en una SDN resultaría con un costo nulo..

(18) 1. CAPÍTULO 1 FUNDAMENTOS TEÓRICOS En el presente capítulo se revisará la teoría necesaria para la comprensión y el correcto desarrollo de este Proyecto de Titulación. En primer lugar se expondrán las definiciones y conceptos necesarios para entender las SDN(Software Defined Networks), sus características, además varias de sus ventajas y desventajas con respecto a las redes tradicionales. A continuación se analizará el controlador utilizado para el desarrollo de este proyecto, se continuará con una breve revisión sobre los servidores web y la necesidad de la distribución de carga en los mismos. Luego se revisará los balanceadores de carga y como funcionan. Finalmente se realizará un breve análisis de varios algoritmos que serán la base para el desarrollo de la aplicación concerniente a este proyecto.. 1.1. REDES DEFINIDAS POR SOFTWARE [25], [14] La ONF(Open Networking Foundation)1 menciona que las SDN son redes en las que se ha separado el plano de datos del plano de control. El plano de datos se ubica en cada dispositivo de la red, sea este un router o un switch. El plano de control se ha centralizado en un solo punto lógico llamado Controlador SDN, del cual se hablará más adelante. Las SDN tienen la intención de optimizar y simplificar las operaciones en la red acercando más las interacciones entre las aplicaciones y servicios de la red con los elementos de la misma; se optimiza las interacciones ya que los elementos de la red solo trabajan en el plano de datos y todas las decisiones las realiza el controlador SDN, de la misma manera se simplifican las operaciones, ya que las acciones son programadas en el controlador en vez de en cada dispositivo de la red. La interfaz de comunicación entre el controlador y los dispositivos de la red constituye el protocolo OpenFlow, del que se hablará a continuación. 1 La. ONF es una organización orientada al usuario, dedicada a difundir las SDN a través del desarrollo de estándares..

(19) 2 1.1.1. OPENFLOW [25], [26] Es un protocolo que fue ideado e implementado con fines de investigación en la universidad de Stanford. Su objetivo era permitir la creación de protocolos experimentales en las redes de los campus en las universidades y así no tener que crear una plataforma experimental desde cero para cada protocolo experimental. La idea creció, entonces se tuvo la visión de que OpenFlow puede reemplazar todas las funcionalidades de los protocolos de capas 2 y 3 en switches y routers comerciales. El modelo OpenFlow que difunde la ONF no es un protocolo en si, es un conjunto de protocolos y una API2 , los componentes principales de este se muestran en la Figura 1.1, donde se puede ver dos partes, los dispositivos de la red y el controlador.. Figura 1.1: Componentes principales del modelo OpenFlow [25] Los protocolos OpenFlow se dividen en dos: Protocolo de conexión, se encarga de varias tareas como: • Establecer un control de sesión. • Definir la estructura del mensaje para la modificación de flujos. • Recolectar Estadísticas. 2 API = Aplication Programming Interface, es un conjunto de funciones y métodos que ofrece una biblioteca para ser utilizada de forma fácil por otro software..

(20) 3 Protocolo de configuración y administración (of-config), basado en NETCONF3 , que tiene las siguientes funciones: • Asignar los puertos físicos del dispositivo de red a un controlador específico. • Definir el comportamiento del elemento de red en caso de desconexión del controlador. La primera versión de OpenFlow, disponible para ser instalada en equipos físicos es la 1.0.0 disponible desde Diciembre del 2009. La última versión de OpenFlow es 1.5 cuya documentación estuvo disponible a partir de Diciembre de 2014 en el sitio web de la ONF, cabe recalcar que los equipos físicos disponibles hasta ahora (Abril 2015) solo tienen implementación de las versiones 1.0.0 para producción y 1.3 para pruebas. 1.1.1.1.. Protocolo de conexión (Wire Protocol)[25], [27]. Antes de profundizar en el protocolo de conexión es necesario definir varios términos fundamentales que se utilizarán [26]. switch OpenFlow: Está constituído por una tabla de flujos (Flow Table) ,donde se realiza la búsqueda de la ruta de los paquetes para su reenvío, y un canal seguro hacia un controlador externo que administrará el switch utilizando el protocolo OpenFlow. Tabla de flujo: Contiene un conjunto de flujos(flows). Flujo: Es un conjunto conformado por valores de una cabecera OpenFlow, valores de contadores y acciones. Match: Se dice que un paquete hace match con un flujo cuando uno o varios valores de las cabeceras del paquete corresponden a los valores de la cabecera OpenFlow en el flujo. Las entradas de la tabla de flujo están formadas tal como se muestra en la Figura 1.2, donde se puede observar tres campos: la cabecera, los contadores y las acciones. 3 NETCONF. = Network Configuration Protocol, es un protocolo brinda herramientas para instalar, manipular y borrar la configuración de dispositivos de red, m’as información en [18]..

(21) 4 Cabecera: como se muestra en la Figura 1.3, la cabecera contiene los valores de los siguientes campos: • Puerto de Ingreso: Número de puerto del switch por el cual ingresó el paquete. • Ethernet-Dirección origen: Dirección física del dispositivo de origen. • Ethernet-Dirección destino: Dirección física del dispositivo destino. • Ethernet-Tipo: Entero en formato hexadecimal que identifica el tipo de paquete, por ejemplo: ARP4 = 0x0806, IP5 = 0x0800, IPv66 = 0x86DD, etc. • VLAN-ID: Identificador de VLAN7 . • VLAN-Prioridad: Prioridad del mensaje en la VLAN. • IP-Dirección origen: Dirección IP del origen del mensaje. • IP-Dirección destino: Dirección IP del destino del mensaje. • IP-TOS: Campo ToS8 de un paquete IP. • TCP9 /UDP10 -origen: Puerto de origen. • TCP/UDP-destino: Puerto destino. Contadores: se tiene contadores de cuatro tipos: por tabla, por flujo, por puerto y por cola, en la Tabla 1.1 se listan todos estos contadores. Los contadores de duración hacen referencia al tiempo desde que se instaló el flujo en el switch, el contador de errores recibidos incluye los errores de trama, de saturación y CRC11 , además de algún otro tipo de error recibido. 4 ARP. = Adress Resolution Protocol, es un protocolo que permite resolver la dirección física de un equipo mediante la dirección IP [4] 5 IP = Internet Protocol, es un protocolo de capa Internet del modelo TCP/IP utilizado para el direccionamiento de paquetes con direcciones de 32 bits [4]. 6 IPv6 = Internet Protocol version 6, es un Protocolo de capa Internet del modelo TCP/IP utilizado para el direccionamiento de paquetes utilizando direcciones de 128 bits. 7 VLAN = Virtual Local Area Network, es una Red de Area Local virtual, aislada de cualquier otra red configurada en el mismo equipo [7] 8 ToS = Type of Service, es un campo de la cabecera IP que es utilizado para dar prioridad de servicio en ciertas redes. 9 TCP = Transmision Control Protocol, es un protocolo orientado a conexión de capa de transporte del modelo TCP/IP 10 UDP = User Datagram Protocol, es un protocolo no orientado a conexión de la capa de transporte del modelo OSI 11 CRC = Cyclic Redundancy Check, es un código de detección de errores utilizado en redes y dispositivos de almacenamiento para verificar algún cambio inesperado en los datos a nivel binario..

(22) 5 Acciones: cada flujo está ligado a cero o más acciones, estas indican al switch que hacer con los paquetes que cumplan con los valores de la cabecera del flujo. En caso de no haber ninguna acción de reenvío indicada, el paquete será descartado. Las acciones a cumplirse para cada flujo se realizan en el orden especificado, en caso de no poder realizar las acciones en ese orden se producirá un error en el flujo y este no será insertado en la tabla de flujos. Las acciones pueden ser Requeridas u Opcionales, así como se muestran en la Figura 1.4, a continuación una breve explicación de las mismas. • Requeridas: Son las acciones que un switch OpenFlow debe soportar, estas son: ◦ Forward: Es la acción de reenvío de paquetes, esta acción es requerida hacia cualquier puerto físico del switch, así como a los siguientes puertos virtuales: ⋄ ALL: Indica el reenvío del paquete por todas las interfaces. ⋄ CONTROLLER: Indica que el paquete será reenviado hacia el controlador. ⋄ LOCAL: Permite a las aplicaciones OpenFlow acceder a los puertos del sistema operativo (SO) del cliente. ⋄ TABLE: Se utiliza para crear un flujo de trabajo con mútiples tablas12 en una secuencia ordenada. ⋄ IN_PORT: Indica que el paquete se reenviará por el puerto de entrada del mismo. ◦ Drop: Se da cuando un flujo no tiene acciones asociadas, por lo tanto cualquier paquete que cumpla con la cabecera del flujo será descartado. • Opcionales: Son las acciones que un switch OpenFlow no está obligado a soportar, pero si son soportadas pueden potenciar las funcionalidades del switch, estas son: ◦ Forward: Esta acción es opcional hacia los siguientes puertos virtuales: ⋄ NORMAL: Indica que los paquetes serán tratados de la forma tradicional, es decir que el switch OpenFlow funcione como un 12 Los. flujos de trabajo con múltiples tablas pueden ser utilizados desde la versió 1.3 de OpenFlow..

(23) 6 switch tradicional con sus comportamientos de inundación y aprendizaje. ⋄ FLOOD: Reenvía el paquete por todas las interfaces, excluyendo la de entrada. ◦ Enqueue: Reenvía el paquete a través de una cola asociada a un puerto, esto se utiliza para dar una Calidad de Servicio13 básica. ◦ Modify Field: Ayuda a la integración con otras redes, permite realizar modificaciones sobre campos en las cabeceras de los paquetes, por ejemplo: ⋄ Cambio de la dirección física de origen y/o destino del paquete ⋄ Cambio de la dirección IP de origen y/o destino del paquete. ⋄ Cambio de la prioridad en una cabecera VLAN. ⋄ Cambio de puerto TCP/UDP de origen y/o destino del paquete. Esta acción, aunque no sea de implementación obligatoria para los fabricantes, es la que abre el abanico de posibilidades de uso de una implementación OpenFlow.. Figura 1.2: Entrada (Flow) de una tabla de flujos OpenFlow 1.0.0[26]. Figura 1.3: Cabecera OpenFlow 1.0.0 [25]. 1.1.1.2. Protocolo de configuración y administración (Of-Config) [25], [26] La documentación de la primera versión oficial del protocolo Of-Config(1.0) está disponible desde diciembre de 2011 y estaba dirigida a dispositivos de red con soporte para OpenFlow 1.2. 13 QoS.-. es el rendimiento promedio de la red visto por los usuarios..

(24) 7 Contador Por Tabla Entradas Activas Búsquedas de paquetes Coincidencias Por Flujo Paquetes recibidos Bytes recibidos Duración (segundos) Duración (nanosegundos) Por Puerto Paquetes recibidos Paquetes transmitidos Bytes recibidos Bytes transmitidos Paquetes descartados Errores recibidos Errores transmitidos Errores de alineación de trama Errores de saturación Errores CRC Colisiones Por Cola Paquetes a transmitir Bytes a transmitir Errores de saturación a transmitir. Bits 32 64 64 64 64 32 32 64 64 64 64 64 64 64 64 64 64 64 64 64 64. Tabla 1.1: Contadores OpenFlow 1.0.0 [26]. Of-Config fue diseñado originalmente para configurar la información relacionada a OpenFlow en los elementos de la red. Este protocolo se estructura en torno a esquemas XML14 , modelos de datos Yang15 y el protocolo NETCONF. El servicio que envía los mensajes Of-Config hacia el switch OpenFlow se denomina Punto de Configuración OpenFlow, este puede ser provisto por software mediante un controlador OpenFlow o por cualquier sistema de gestión tradicional. En un switch OpenFlow se pueden crear varias instancias o redes virtuales OpenFlow ya sea con FlowVisor16 o cualquier otro modelo de virtualización. En la Figura 14 XML. = Extensible Markup Languaje, es un lenguaje de etiquetas que define reglas para la codificación de archivos en un formato que es comprensible tanto para humanos como para máquinas[36]. 15 Es un lenguaje de modelado de datos usado para modelar la configuración y el estado de los datos manipulados por el protocolo de configuración de red NETCONF [19]. 16 Es un controlador OpenFlow de proósito especial que actúa como proxy transparente entre switches OpenFlow y varios controladores, FlowVisor segmenta la red OpenFlow y cada sección se.

(25) 8. Figura 1.4: Acciones OpenFlow 1.0.0 [25] 1.5 se muestra la diferencia en como trabajan los protocolos Of-Config y OpenFlow. En un switch OpenFlow que tiene dos instancias lógicas OpenFlow y cada instancia la maneja un controlador diferente mediante el protocolo OpenFlow, mientras que la asignación de los recursos OpenFlow (como por ejemplo puertos del switch) a cada switch lógico la realiza el Punto de Configuración mediante el protocolo Of-Config. Resumiendo, el protocolo Of-Config fue diseñado para satisfacer las necesidades de configuración de OpenFlow 1.2, es decir cumple con las siguientes funcionalidades: Asignar uno o más controladores OpenFlow. Configuración de colas y puertos. Cambio del estado de los puertos remotamente. administra mediante un controlador diferente. [21].

(26) 9. Figura 1.5: Relación entre componentes, protocolo Of-Config y protocolo OpenFlow [27] 1.1.1.3. Mensajes OpenFlow [26] Para el desarrollo del presente proyecto es necesario conocer los mensajes del protocolo OpenFlow, a continuación se dará una breve revisión a los mensajes más importantes para la correcta realización de este proyecto. El protocolo OpenFlow soporta tres tipos de mensajes: controlador-switch, asincrónicos y simétricos.. 1.1.1.3.1.. Mensajes Controlador-Switch. Son mensajes enviados por el controlador hacia el switch y estos pueden o no requerir una respuesta, estos mensajes son utilizados principalmente para gestionar o revisar el estado del switch, entre estos están: Features: Una vez establecida la conexión entre switch y controlador, el controlador envía una petición (Features-request) hacia el switch y este último tendrá que responderle (Features-reply ) indicando las características de OpenFlow que soporta. Modify-State: Se utilizan para gestionar el switch, su función principal es añadir, eliminar y modificar flujos en las tablas de flujos..

(27) 10 Read-State: Este mensaje se utiliza para recolectar las estadísticas de las tablas de flujos, de cada flujo y de cada puerto. Send-Packet: El controlador utiliza este mensaje para enviar un paquete específico por un puerto del switch. Barrier : El controlador envía una petición al switch y espera por una respuesta un cierto tiempo, se utiliza para sincronización.. 1.1.1.3.2.. Mensajes Asincrónicos. Son mensajes enviados desde el switch hacia el controlador, sin que este último lo haya solicitado, a continuación los más importantes: Packet-In: Este mensaje se envía cuando un paquete que llega al switch no hace match con ninguno de los flujos instalados en el switch o cuando cumple con alguno y la acción asociada al mismo es “reenviar el paquete al controlador”. Flow-Removed: Se da cuando se borra una entrada de la tabla de flujos, ya sea por un mensaje Modify-State, por un temporizador de inactividad o por un temporizador fijo de tiempo de vida del flujo. Port-Status: Se envía este mensaje hacia el controlador cuando cambia el estado de un puerto (UP/DOWN). Error : El switch envía estos mensajes al controlador cuando detecta algún problema.. 1.1.1.3.3.. Simétricos. Pueden enviarse desde el controlador al switch o viceversa, sin que el switch o el controlador los hayan solicitado, se tiene tres mensajes de este tipo: Hello: Estos mensajes se intercambian entre switch y controlador al iniciar la conexión. Echo: Estos mensajes pueden ser usados para verificar: si un controlador está activo, ancho de banda o latencia. Estos mensajes pueden ser de petición o respuesta..

(28) 11 Vendor : Es un tipo de mensajes utilizado para ofrecer funcionalidades adicionales y realización de pruebas, en posteriores revisiones de OpenFlow el nombre del mensaje cambia a Experimenter [28]. 1.1.2. CONTROLADOR SDN [25], [32], [37] El controlador SDN es un software que configura, controla y administra los dispositivos de conectividad en una red OpenFlow. Las SDN son programables mediante el controlador, es decir las aplicaciones deben ser desarrolladas para cada controlador, este se comunicará con los dispositivos de conectividad mediante OpenFlow y realizará las tareas de configuración, instalación de flujos, administración, que se haya programado en la aplicación. Un controlador ideal debería proveer: Administración del estado de la red. Un modelo de datos de alto nivel que capture las relaciones entre los recursos que se administra, las políticas y los servicios prestados por el controlador. Una API moderna que facilite las interacciones entre controlador y aplicación. Una sesión de control segura mediante TCP entre el controlador y los elementos de la red. Un protocolo basado en estándares para configurar el estado de la red. Un mecanismo de descubrimiento de servicios, equipos y topología. Existe una gran variedad de controladores en el mercado, tanto Open Source17 como propietarios, una breve lista de algunos de ellos se muestra en la Tabla 1.2. Para el desarrollo de este Proyecto de Titulación se utilizará el controlador Ryu, por lo tanto se profundizará en los aspectos más importantes del mismo.. 1.2. RYU [9] Ryu no es solo un controlador SDN, es también un Framework 18 de red basado en componentes, es decir esá formado por una gran cantidad de librerías y recursos 17 Open. Source es el software de código abierto, de libre acceso. Framework es un marco de trabajo constituido por varios elementos como por ejemplo un modelo, librerías, un compilador o intérprete dependiendo del lenguaje, etc. 18 Un.

(29) 12 Controladores Privativos Nombre Desarrollador Active Broadband Controller Active Broadband Networks NorthStar Juniper Networks Big Network Controller Big Switch Networks Blue Planet SDN controller Cyan Inc ContexNet controller ConteXtream Active Fabric Controller Dell Application Policy Infrastructure Cisco Systems Controller (APIC) The HP Virtual Application Net- Hewlett-Packard (HP) works SDN Controller Smart Network Controller Huawei Technologies IBM SDN for Virtual Environ- IBM ments NSX Controller VMware Controladores Open Source Nombre Desarrollador NOX NOXRepo POX NOXRepo SDN Open Network Operating ON.Lab System (ONOS) OpenContrail Controller OpenContrail OpenDaylight OpenDaylight Project Floodlight Open SDN Controller Project Floodlight RYU Ryu SDN Framework Community Beacon Stanford University Trema Trema Tabla 1.2: Ejemplos de controladores y sus respectivos desarrolladores. que facilitan el desarrollo de aplicaciones, además puede ser utilizado como controlador de red en OpenStack19 . Ryu está escrito completamente en Python y trabaja con las versiones 2.6 en adelante pero todavía no es completamente funcional con Python 320 . 1.2.1. FUNCIONAMIENTO [34], [35] Las aplicaciones de Ryu utilizan un solo hilo de ejecución e implementan alguna funcionalidad al framework. El controlador utiliza una programación dirigida por 19 Más. informació de Ruy con Openstack en [38]. desarrolladores se encuentran activamente añadiendo el soporte para Python 3 pero aun no está completamente implementado. 20 Los.

(30) 13 eventos, es decir, las acciones que se realizan dependen de los eventos que ocurran en tiempo de ejecución. Cabe mencionar que los eventos son manejados como mensajes entre las aplicaciones. Cada aplicación de Ryu tiene una cola de tipo FIFO21 (First In - First Out)para recibir eventos, cada evento es procesado por el hilo de ejecución y no se pasará a otro hasta terminar el evento en curso. La API de Ryu permite crear eventos propios y manipuladores22 para eventos específicos o generar eventos preestablecidos. Para crear los manipuladores de eventos se utiliza el decorador23 ryu.controller.handler.set_ev_cls. 1.2.2. COMPONENTES [35] Los componentes que forman el framework Ryu se los puede clasificar por su funcionalidad de la siguiente manera: Ejecutables Componentes Base Controlador OpenFlow Codificador/Decodificador del protocolo de conexión OpenFlow Aplicaciones Librerías Librerías de Terceros A continuación se explicará brevemente los componentes de la clasificación mencionada. 1.2.2.1. Ejecutables El componente ryu-manager es el ejecutable principal que permite correr las aplicaciones24 desarrolladas. 21 FIFO = First In - First Out, es un concepto que dice: .El primero que entra es el primero que sale", se usa en teoría de colas, estructuras de datos. 22 Los manipuladores son más conocidos con el nombre de “Handlers”. 23 Un decorador es una función que recibe como parámetro otra función y retorna una función compuesta por las acciones de cada función[10]. 24 Cuando se habla de “aplicaciones” quiere decir las aplicaciones desarrolladas para Ryu..

(31) 14 1.2.2.2. Componentes Base ryu.base.app_manager,. se encarga de la la administración de las aplicaciones de Ryu,. tiene las siguientes tareas: Cargar la aplicación. Proveer de contextos25 para las aplicaciones. Direccionar mensajes entre aplicaciones. 1.2.2.3. Controlador OpenFlow El componente ryu.controller.controller es la parte fundamental del Controlador OpenFlow, este maneja las conexiones de los switches, además genera y enruta los eventos (mensajes OpenFlow) hacia la aplicación indicada. En esta clasificación también se encuentran componentes como: ryu.controller.dpset que se encarga del descubrimiento de enlaces, ryu.controller.ofp_event está a cargo de las definiciones de los eventos OpenFlow y ryu.controller.ofp_handler que tiene la tarea de manejar las negociaciones OpenFlow. 1.2.2.4.. Codificador/Decodificador OpenFlow. En esta sección se encuentran dos componentes para cada versión de OpenFlow, desde la versión 1.0 hasta la 1.4, estos componentes son: ryu.ofproto.ofproto_v1_x26. En este componente se puede encontrar las defini-. ciones de OpenFlow 1.x, estas incluyen por ejemplo el número de puerto TCP a utilizar o los valores correspondientes a los puertos que se utilizan para realizar la acción forward que se mencionó en la Sección 1.1.1.1. ryu.ofproto.ofproto_v1_x_parser Aquí se puede encontrar la implementación del. codificador y decodificador para OpenFlow 1.x. En este componente están las clases y funciones necesarias para crear los mensajes OpenFlow, reenviarlos, procesarlos, instalar flujos en el switch OpenFlow, modificarlos, entre otras acciones. 25 Los. 26 “x”. contextos o context son objetos Python utilizados de forma compartida entre aplicaciones. corresponde al numero de la versión, pudiendo ser esta 0, 2, 3 o 4..

(32) 15 1.2.2.5. Aplicaciones Como parte del framework Ryu están presentes varias aplicaciones implementadas para hacer uso del Controlador OpenFlow que este provee, estas aplicaciones pueden servir de ejemplo a los desarrolladores que están comenzando a programar para Ryu o puede utilizarse cualquiera de las funciones que esté en una aplicación en un nuevo código, ya que solo son archivos de texto plano escritos en Python. Entre las aplicaciones incorporadas en Ryu están: ryu.app.simple_switch.-. es una implementación de un switch capa 2 con Open-. Flow 1.0. ryu.app.rest.-. Es un API para utilizar REST27 .. ryu.app.simple_switch_13.-. Es una implementación para un switch capa 2 con. OpenFlow 1.3. ryu.app.ofctl_rest.-. Es una aplicación para utilizar servicios ofctl28. 1.2.2.6. Librerías En esta sección se tiene varias librerías implementadas con el propósito de facilitar la construcción o manipulación de protocolos, las librerías que se puede encontrar aquí son: ryu.lib.packet.-. esta librería contiene la implementación para codificar y de-. codificar paquetes de varios protocolos como TCP, IP, UDP, Ethernet, entre otros. ryu.lib.ovs.-. esta librería contiene las clases y métodos necesarios para inter-. actuar con el OVSDB29 . ryu.lib.of_config.- esta librería permite trabajar con Of-Config, ya que tiene las. clases y métodos para utilizar con el protocolo. 27 REST. = Representational State Transfer, es una arquitectura de software utilizada para servicios web [1]. 28 ofctl permite utilizar mensajes OpenFlow del tipo Controler-Switch (Sección 1.1.1.3)de forma sincroónica. 29 OVSDB = Open vSwitch Data Base Management Protocol, es un protocolo que fue utilizado para administrar y programar Open vSwitch cuando este fue desarrollado, porque OpenFlow no tenía las capacidades para hacerlo. [25].

(33) 16 ryu.lib.netconf.-. esta librería es una implementación de NETCONF, y se em-. plea en Of-Config. 1.2.2.7. Librerías de Terceros Son implementaciones en Python que se utilizan en las definiciones de otras librerías mencionadas con anterioridad, entre estas se tiene: ryu.contrib.ovs.-. esta librería contiene las clases y métodos necesarios para. realizar las conexiones con Open vSwitch y se utiliza para la implementación de la librería ryu.lib.ovs. ryu.contrib.oslo.config.-. es utilizada por las opciones en linea de comandos. de ryu-manager y los archivos de configuración. ryu.contrib.ncclient.- es una librería en Python para el cliente NETCONF, tam-. bién se utiliza para la implementación de la librería ryu.lib.of_config.. 1.3. SISTEMA DE ENCOLAMIENTO [2] Se puede encontrar sistemas de encolamiento diariamente en las actividades cotidianas como realizar una transacción en las oficinas de un banco, ingresar a un estadio de fútbol, comprar productos en un supermercado, etc. Para el desarrollo de este proyecto es importante entender el encolamiento en las redes, por lo que se explicará acerca de esto, pero sin profundizar en toda la teoría matemática que tiene como base. Un sistema de encolamiento es un modelo abstracto en el que se tienen dos conjuntos de participantes, los clientes y los servidores. En este modelo, los clientes solicitan servicios a los servidores, si los servidores no tienen capacidad de atender a todos los clientes en ese momento, se producirá un encolamiento, es decir se pondrá en cola a los clientes que no puedan ser atendidos en ese instante de tiempo hasta que un servidor termine de atender la solicitud en curso y pueda atender a otro cliente de la cola. Un sistema de encolamiento específico de interés para este proyecto es en el que se tienen servidores web30 y clientes que desean acceder a los servicios que estos 30 Un. servidor web, es un servidor que puede tener alojado cualquier tipo de contenido como audio, vídeo, paginas en texto plano, etc..

(34) 17 proporcionan. A continuación se expondrán los elementos que intervienen en este sistema. 1.3.1. CLIENTES Un cliente en el sistema de encolamiento mencionado con anterioridad es cualquier navegador web, consola de comandos o cualquier aplicación capaz de realizar peticiones web, es decir peticiones HTTP31 o HTTPS32 . 1.3.2. SERVIDORES WEB [8], [16] Un servidor web es un programa o aplicación capaz de atender y mantener peticiones web, ya sea en una intranet o en Internet. Algunos autores hacen una diferenciación entre un servidor web y un servidor de aplicaciones, para este documento, si el servidor ofrece algún servicio mediante HTTP/HTTPS, sea este una página web o una aplicación, se considerará un servidor web. El funcionamiento básico de un servidor web es el siguiente: el servidor espera por peticiones, cuando recibe una petición busca el recurso solicitado y lo envía como respuesta a la petición, finalmente vuelve a esperar por peticiones, ese ciclo se repite indefinidamente. 1.3.2.1. Tráfico web [16] Las peticiones web se realizan desde el cliente hacia el servidor, solicitando algún recurso alojado en el servidor, estas peticiones son realizadas utilizando los protocolos HTTP o HTTPS y generalmente se realizan mediante un navegador como: Firefox, Internet Explorer, Chrome, entre otros. Una vez que el servidor recibe una petición, inicia una conexión cliente-servidor y empieza el intercambio de paquetes entre cliente y servidor, dependiendo del tipo de contenido expuesto por el servidor. Este intercambio se realiza entre cada usuario solicitante y el servidor que atiende dicha solicitud y dependiendo de la capacidad de respuesta del servidor, este puede atender a varios clientes simultáneamente, pero el número de clientes puede aumentar casi indefinidamente, dependiendo del lugar de exposición del servidor, por lo que el tráfico en la red 31 HTTP. = HyperText Transfer Protocol, es un protocolo orientado a transacciones, sin estado, que se utiliza en Internet. 32 HTTPS = HyperText Transfer Protocol Secure, es un protocolo seguro, basado en HTTP, que utiliza un cifrado para proteger la información..

(35) 18 del servidor también puede aumentar hasta llegar al límite de procesamiento del servidor. Los clientes solo escriben el nombre o dirección IP del servidor que desean consultar en sus navegadores web, y el servidor responderá con la información solicitada. En la Figura 1.6 se puede ver la perspectiva de los clientes, estos solo ven el contenido del servidor.. Figura 1.6: Perspectiva cliente web Cuando un servidor web tiene un gran número de clientes generando una gran cantidad de tráfico33 es natural que un solo equipo físico o virtual se sature y no sea suficiente para satisfacer las necesidades de todos los clientes, por lo tanto es común que tener un clúster34 de servidores o varios servidores con la misma información para poder responder a todas las peticiones. Suponiendo que no se cuenta con un clúster de servidores, solo con servidores réplicas, para los usuarios de una página web (un servidor web) sería molesto tener que cambiar la dirección en el navegador si el servidor los atiende con un retardo 33 En. este caso, la cantidad de tráfico es relativa a la capacidad del o los servidores, ya que para un servidor de pocos recursos con contenido multimedia, el tráfico generado por unas decenas de clientes puede ser grande, mientras que para un clúster de servidores, varios millones de clientes pueden generar una cantidad de tráfico que se considere grande. 34 Un clúster en su modo más simple es un conjunto de dos o más computadores, que trabajan como un solo computador de mayor capacidad de procesamiento, para dar una solución a una problemática[30]..

(36) 19 considerable o no los atiende, los usuarios buscarían la información que necesitan en otra página (otro servidor). Esto implicaría pérdidas a corto y largo plazo para los dueños del sitio web, para evitar esta pérdidas se puede utilizar un enmascaramiento de todos los servidores detrás de una única dirección o nombre, este trabajo lo puede realizar un Balanceador de Carga. 1.3.3. BALANCEADOR DE CARGA [3],[31] Un balanceador de carga puede ser un equipo físico o un software, su trabajo es distribuir la carga35 entre varios servidores del mismo tipo, para este proyecto servidores web. Un balanceador de carga también puede tratar con los fallos de conexión de los servidores, es decir si el servidor deja de funcionar, el tráfico de este será enviado hacia otros servidores que estén en funcionamiento. Los balanceadores de carga tienen diferentes métodos para realizar su trabajo, estos métodos pueden ser manuales, automáticos o una combinación de ambos. En el método manual se programa directamente la regla en el balanceador, un ejemplo de este se muestra en la Figura 1.7, donde se puede ver el conjunto de servidores, el balanceador de carga y los clientes. En el balanceador de carga se tiene programado que en caso de fallar el servidor “a”, el tráfico de este se enviará al servidor “c”. Se puede deducir que este método de balanceo puede llegar a ser muy poco eficiente en una red, ya que se puede sobrecargar a un solo servidor en vez de distribuir la carga en varios. Por otro lado, los métodos automáticos son mas eficiente que los manuales ya que la carga se distribuye dinámicamente según algún patrón programado en el balanceador, estos patrones que realizan el balanceo se implementan de acuerdo a algún algoritmo de encolamiento. 1.3.3.1.. Algoritmos de encolamiento [15] [11]. Para el desarrollo de este proyecto se eligió tres algoritmos de encolamiento: FIFO, Round Robin y Deficit Round Robin. Estos serán la base de los métodos para balanceo de carga de la aplicación a implementarse. 35 Se. entiende por “carga” al tráfico generado por los clientes..

(37) 20. Figura 1.7: Balanceo de carga manual 1.3.3.1.1.. FiFo. (First in - First out ) El primero que entra, es el primero que sale, en el contexto cliente-servidor quiere decir que el primer cliente que realice la petición será atendido primero. La Figura 1.8 ilustra lo mencionado en el párrafo anterior. En esta se puede observar una nube de clientes y una nube de servidores, para este sistema nunca se pierde el orden, en el momento de hacer una petición, cada cliente se pone en cola y una vez que esté disponible algún servidor, el cliente que está primero en la cola sale de la misma, es atendido y el proceso continúa, no existe ningún tipo de priorización, todo depende de los tiempos de llegada. Un inconveniente con FiFo es el tamaño de la cola, si esta se llegara a llenar, los próximos clientes no serían atendidos, es decir sus peticiones solo serían ignoradas. Este modo de balanceo puede ser fácilmente implementado y puede llegar a ser útil como enlace entre una conexión de alta velocidad y una de baja velocidad..

(38) 21. Figura 1.8: FIFO 1.3.3.1.2.. Round Robin. Este algoritmo integra los servidores en un conjunto y les da un orden. Los servidores, desde el primero hasta el último, atenderán cada uno a un cliente, después de que el último atienda al cliente que le corresponda, otra vez atenderá el primero y continuará el ciclo hasta terminar de atender a todos los clientes. En la Figura 1.9 se muestra un ejemplo del proceso Round Robin con tres servidores, en la cola que se puede ver están los clientes enumerados según su llegada y a la derecha se puede observar un conjunto de servidores representado en un gráfico de tipo pastel que gira en sentido antihorario cada vez que un servidor atiende a un cliente.. 1.3.3.1.3.. Deficit Round Robin. Este algoritmo está basado en Round Robin, pero tiene varios parámetros adicionales que proporcionan una forma de encolamiento que considera el número de bytes que puede aceptar cada servidor en una ronda. En este algoritmo se consideran los siguientes parámetros: quantum, es el tamaño máximo de un paquete que puede ser recibido en la ronda actual por un servidor. deficit-counter, es un contador de deficit, es decir este aumenta si el tamaño del paquete es mayor al quantum. Para explicar el proceso de Deficit Round Robin se considera que cada servidor tiene su propia cola y solo procesará los paquetes que estén en su cola; además se asume que el quantum es fijo para cada servidor. Para empezar a recibir los paquetes se debe fijar los valores del quantum en un V. valor estático y deficit-counter en cero (q = valor dc = 0). A continuación se dan a conocer los pasos del proceso Deficit Round Robin:.

(39) 22. Figura 1.9: Round Robin con tres servidores. 1. Se actualiza el deficit-counter a su valor más el valor del quantum (dc = dc+q). 2. Se compara si el tamaño del paquete es menor que el deficit-counter (paquete ≤ dc). Si es menor, el paquete se envía al servidor y el deficit-counter se resetea a cero (dc = 0) y el servidor termina su turno. Si es mayor, el paquete se queda en la cola del servidor y espera para ser enviado en la siguiente ronda, el deficit-counter se iguala al valor del quantum (dc = q) y el servidor termina su turno. En la Figura 1.10 y Figura 1.11 se muestra el proceso Deficit Round Robin con tres servidores. Cada servidor tiene un quantum diferente, pero constante para todo el.

(40) 23 proceso, en las figuras existen dos partes claramente diferenciadas, los paquetes y los servidores, en cada paquete se tiene el orden de llegada y entre paréntesis el tamaño del mismo, en cada servidor se tiene los valores del deficit-counter y del quantum para cada paso en el proceso. 1. En ‘a’ se puede ver el arribo del primer paquete, de modo que comienza el proceso: dc1 = 0; q1 = 1000; paquete1 = 1800 dc1 = dc1 + q → dc1 = 0 + 1000 = 1000 dc1 < paquete1 → dc1 = q1 = 1000 El paquete1 se encola y el servidor termina su turno. 2. En ‘b’ se puede observar que el defict-counte del primer servidor no es cero y el segundo servidor atenderá al segundo paquete: dc2 = 0; q2 = 2000; paquete2 = 1100 dc2 = dc2 + q → dc2 = 0 + 1100 = 1100 dc2 > paquete2 → dc2 = 0 El paquete2 se envía al servidor y termina su turno. 3. En ’c’ el tercer paquete está por ser procesado: dc3 = 0; q3 = 1500; paquete3 = 1500 dc3 = dc3 + q → dc3 = 0 + 1500 = 1500 dc3 = paquete3 → dc3 = 0 El paquete3 se envía al servidor y termina su turno. 4. La parte ‘d’ de la Figura 1.11 presenta el inicio de la segunda ronda, por lo que es nuevamente el turno del primer servidor: dc1 = 1000; q1 = 1000; paquete1 = 1800 dc1 = dc1 + q → dc1 = 1000 + 1000 = 2000 dc1 > paquete1 → dc1 = 0 El paquete1 se envía al primer servidor y termina su turno encerando su deficit-counter. 5. En ‘e’ se muestra que el cuarto paquete está por ser atendido:.

(41) 24 dc2 = 0; q2 = 2000; paquete4 = 800 dc2 = dc2 + q → dc2 = 0 + 2000 = 2000 dc2 > paquete4 → dc2 = 0 El paquete4 se envía al segundo servidor y termina su turno. 6. En ‘f’ se ve el quinto paquete en la cabeza de la cola de llegada: dc3 = 0; q3 = 1500; paquete5 = 800 dc3 = dc3 + q → dc3 = 0 + 1500 = 1500 dc1 > paquete5 → dc1 = 0 El paquete5 se envía al tercer servidor y termina su turno.. Figura 1.10: Deficit Round Robin con tres servidores (Parte 1).

(42) 25. Figura 1.11: Deficit Round Robin con tres servidores (Parte 2) Este proceso se repetirá mientras haya paquetes en cola. Como se puede observar Deficit Round Robin trabaja de igual manera que Round Robin siempre y cuando los paquetes no excedan el tamaño del quantum. En el siguiente capítulo se diseñará y codificará la aplicación para balanceo de carga, que tendrá tres modos de balanceo, los mismos que se basarán en los algoritmos explicados en esta sección..

(43) 26. CAPÍTULO 2 DISEÑO Y DESARROLLO DE LA APLICACIÓN En este capítulo se presentará el análisis de requerimientos realizado para el diseño de un balanceador de carga, después se elegirá los criterios para el encolamiento en base a los algoritmos analizados en el capítulo anterior, a continuación se realizará el diseño de cada etapa de la aplicación y se mostrará el proceso de desarrollo en cada etapa.. 2.1. ANÁLISIS DE REQUERIMIENTOS [17] En esta sección se realiza el análisis de requerimientos para la aplicación a desarrollada. No existe un cliente que pueda ser parte del proceso, por lo tanto se analiza los requerimientos de un balanceador de carga básico y se adiciona los requerimientos para su funcionamiento en una SDN. Se consideran varios tipos de requerimientos como: ambiente físico, usuarios o factores humanos y funcionalidad. 2.1.1. AMBIENTE FÍSICO Los requerimientos de ambiente físico se refieren al lugar físico donde funcionará la aplicación. Con respecto a este tipo de requerimientos, se tiene: La aplicación debe funcionar con switches que soporten el protocolo OpenFlow como el Switch HP-Procurve 3500 de 24 puertos. 2.1.2. USUARIOS Y FACTORES HUMANOS Estos requerimientos se refieren a los usuarios de la aplicación y la capacitación acerca del uso de la misma. Estos requerimientos son: El acceso del usuario a la aplicación debe ser solo a nivel de configuración, por lo tanto es necesario que la configuración se realice desde un archivo externo.

(44) 27 a la aplicación, lo que evitará que el usuario tenga que editar el código de la aplicación. 2.1.3. FUNCIONALIDAD El análisis de este tipo de requerimientos dice lo que se necesita que haga la aplicación y como lo debe hacer. Las funcionalidades de la aplicación deben obedecer a los siguientes requerimientos: Debe trabajar como balanceador de carga para los servidores web. Debe trabajar en una red con soporte del protocolo OpenFlow. Debe enmascarar las direcciones de los servidores, es decir mostrar solo una dirección a los clientes. Debe tener tres modos de operación, basados en FIFO, Round Robin y Deficit Round Robin. Debe actuar cada vez que llegue un nuevo cliente.. 2.2. CRITERIOS DE ENCOLAMIENTO En esta sección se selecciona el criterio para distribuir la carga entre los servidores web. Estos criterios de distribución o balanceo de carga se basan en los algoritmos vistos en el Capítulo 1 y teniendo en cuenta los requerimientos extraídos del apartado anterior. Antes de elegir un criterio para el balanceo de carga, se consideró que la aplicación trabajaría en una SDN, por lo tanto de ser posible se trabajaría introduciendo flujos en las tablas de los switches, para reducir el tiempo de retardo de cada paquete. Por otro lado, los algoritmos de encolamiento mencionados en el capítulo anterior generalmente se implementan a nivel de paquetes, pero en el escenario que se maneja para este proyecto el procesamiento de cada paquete no sería algo eficiente, ya que cada paquete debería ir hasta el controlador, que es la entidad que realiza el procesamiento, y aumentaría el retardo en cada uno de estos. Después de analizar las condiciones mencionadas en el párrafo anterior se decidió realizar la selección, diseño e implementación de la aplicación a nivel de clientes, es decir, los criterios de encolamiento están orientados a distribuir clientes a cada servidor, no paquetes..

(45) 28 2.2.1. FIFO El criterio de encolamiento basado en FIFO es el que se representa en la Figura 2.1, en esta se puede observar un sistema en funcionamiento formado por varios servidores, el controlador Ryu, un switch OpenFlow y el arribo de los clientes que se puede notar en la parte a de la Figura.. Figura 2.1: Criterio de encolamiento basado en FIFO FIFO implica solo el orden de arribo, pero al tratarse de una aplicación que distribuye a los clientes, no solo basta con tener en cuenta el orden de llegada, por este motivo se decidió implementar un mecanismo de distribución a la salida del switch, este mecanismo distribuye los clientes de manera aleatoria entre los servidores disponibles, es decir, se conserva la base de FIFO en el switch, que es direccionar primero al cliente que llega primero, pero el servidor que lo atiende puede ser cualquiera de los disponibles, sin un orden especifico en estos, este comportamiento se puede ver en la parte b de la misma figura. 2.2.2. ROUND ROBIN La Figura 2.2 representa el criterio basado en Round Robin, aunque es parecida a la mostrada en la Sección 2.2.1, la diferencia fundamental entre estos dos es el mecanismo de distribución a la salida del switch, en este caso se puede ver que en b los clientes son distribuidos utilizando Round Robin, es decir, los servidores han sido ordenados y los clientes se reparten entre los servidores de forma cíclica, de uno en uno empezando por el primer servidor..

(46) 29. Figura 2.2: Criterio de encolamiento basado en Round Robin 2.2.3. DEFICIT ROUND ROBIN Después de analizar el algoritmo Deficit Round Robin, se concluyó que este solo podía ser implementado completamente a nivel de paquetes, como se explicó en la Sección 2.2 para este proyecto no es conveniente una implementación a nivel de paquetes, por lo tanto solo se utilizaron ciertos aspectos de Deficit Round Robin, como el control del número de bytes y el orden de tratamiento de clientes para la selección del criterio que se explica a continuación. En la Figura 2.3 se representa como funciona el sistema aplicando el criterio basado en Deficit Round Robin, se pueden diferenciar tres partes en esta figura: en a se tiene el orden de llegada de los clientes, en b se destaca la interacción entre el controlador Ryu y el switch OpenFlow, ya que se realiza una constante retroalimentación entre estos, lo que permite llegar a c que es el direccionamiento de cada cliente al servidor con menos carga en el momento de la petición.. 2.3. ETAPAS DE LA APLICACIÓN La aplicación se diseño en tres etapas, una etapa de recepción de paquetes, una de procesamiento y finalmente la etapa de creación de reglas. 2.3.1. RECEPCIÓN DE PAQUETES Para esta etapa, primero se considera si el paquete es ARP o no. Las direcciones de los servidores físicos están ocultas tras una dirección IP publica.

(47) 30. Figura 2.3: Criterio de encolamiento basado en Deficit Round Robin así como una dirección MAC válida, y la respuesta ARP se necesita únicamente para que los clientes puedan llenar sus tablas ARP, por lo tanto no es necesario que estas peticiones lleguen a los servidores físicos. Las únicas peticiones que llegarán a los servidores serán de tipo HTTP o HTTPS. 2.3.1.1.. Paquetes ARP. Para el tratamiento de las peticiones ARP, la aplicación trabaja como se muestra en el diagrama de flujo de la Figura 2.4, el cual muestra el funcionamiento en caso de recibir un paquete ARP de parte de un cliente. A continuación se explica el diagrama: La aplicación recibe la petición ARP. Se comprueba si el paquete se dirige hacia la dirección IP publica de los servidores. Se construye un paquete ARP de respuesta con la dirección publica. Se envía el paquete de respuesta ARP hacia el cliente que hizo la petición.. 2.3.1.2. Paquetes no ARP Para los paquetes que no son ARP, se trabaja como muestra la Figura 2.5, el proceso es: Se revisa la dirección de destino del paquete..

(48) 31. Figura 2.4: Funcionamiento en caso de paquete ARP Si no es la dirección publica, se descarta el paquete. Si es la dirección publica, se revisa el puerto destino, este debe ser el puerto 80 (HTTP) o el 443 (HTTPS). En caso de no ser ninguno de los puertos del item anterior se descarta el paquete. En caso que si sea uno de los puertos mencionados, este paquete pasa a la etapa de procesamiento.. 2.3.2. PROCESAMIENTO En la etapa de procesamiento es donde el controlador realiza un análisis del paquete que ingresó y decide hacia que servidor enviarlo de acuerdo al criterio de.

(49) 32. Figura 2.5: Funcionamiento en caso de paquetes que no son ARP balanceo que se esté utilizando, por lo tanto se tienen tres diferentes tipos de procesamiento, uno por cada criterio: FIFO, RR (Round Robin) y DRR (Deficit Round Robin). El funcionamiento general de esta etapa se puede observar en la Figura 2.6, donde se muestra como actuará la aplicación desde que inicia esta etapa, en a se realiza la selección del servidor, a continuación se explica más detalladamente este proceso para cada criterio de encolamiento. 2.3.2.1. Procesamiento FIFO En la Figura 2.7 se observa el trabajo que realizará la aplicación en la parte a de la Figura 2.6, si el criterio seleccionado fue FIFO. El procesamiento que se realiza en este caso es muy sencillo, solo se trata los paquetes en el orden de llegada y para enviarlo se selecciona un servidor aleatorio del conjunto de servidores disponibles..

(50) 33. Figura 2.6: Funcionamiento de la etapa de procesamiento. 2.3.2.2.. Procesamiento RR. En la Figura 2.8 se puede ver el funcionamiento de la aplicación en la parte a de la Figura 2.6, si el criterio seleccionado fue Round Robin. En un principio los servidores son ordenados en una cola, cada vez que llega un nuevo paquete hasta esta etapa, será seleccionado el primer servidor de la cola para que atienda al cliente que lo envió, una vez hecho este emparejamiento, el servidor pasa al final de la cola esperando nuevamente su turno. 2.3.2.3. Procesamiento DRR La Figura 2.9 muestra el proceso que realiza la aplicación cuando se está utilizando el criterio basado en Deficit Round Robin: 1. Llega un paquete desde un cliente al controlador..

(51) 34. Figura 2.7: Procesamiento FIFO 2. Se envía al switch una petición de estadísticas de los flujos. 3. De la respuesta del switch se extrae la cantidad de bytes que ha procesado el switch por cada flujo. 4. Se calcula la cantidad de bytes que se ha enviado a cada servidor. 5. Se selecciona el servidor con el menor número de bytes recibidos hasta el momento. Cabe recalcar que la petición de estadísticas se hace para cada paquete que llega hasta el controlador, además cada flujo tendrá un tiempo de vida corto para que las estadísticas de un flujo inactivo no afecten a la selección del servidor. 2.3.3. CREACIÓN DE REGLAS El objetivo principal de las reglas que crea la aplicación es asignar un servidor a cada nuevo cliente, y que ese cliente solo sea atendido por el servidor asignado, mientras el cliente no este inactivo por cierto tiempo. Para la creación de reglas se toma los siguientes datos que son recolectados en la fase de procesamiento del paquete, con excepción del tiempo de vida que se define en desde el principio en el archivo de configuración: Dirección IP del cliente. Dirección MAC del cliente..