Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Microceldas 802.11 de alta densidad Autor: David Ramos Cardoso Tutor: Rafael Mª Estepa Alonso Departamento de Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2017
105
Embed
Microceldas 802.11 de alta densidadbibing.us.es/proyectos/abreproy/91260/descargar_fichero/DRC_TFG.pdf · Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Equation Chapter 1 Section 1
Trabajo Fin de Grado
Grado en Ingeniería de las Tecnologías de
Telecomunicación
Microceldas 802.11 de alta densidad
Autor: David Ramos Cardoso
Tutor: Rafael Mª Estepa Alonso
Departamento de Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2017
iii
Trabajo Fin de Grado
Grado en Ingeniería de las Tecnologías de Telecomunicación
Microceldas 802.11 de alta densidad
Autor:
David Ramos Cardoso
Tutor:
Rafael Mª Estepa Alonso
Profesor titular
Departamento de Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2017
Trabajo Fin de Grado: Microceldas 802.11 de alta densidad
v
Autor: David Ramos Cardoso
Tutor: Rafael Mª Estepa Alonso
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2017
El Secretario del Tribunal
vii
A mi familia
A mis amigos
A mis profesores
ix
Agradecimientos
A lo largo de los estudios universitarios en el grado de telecomunicaciones se producen una serie de
obstáculos sucesivamente, algunos más complicados que otros. Sin el apoyo de mi familia, y
principalmente de mi madre, mis hermanos y mi novia no habría conseguido superarlo de la forma en que
lo he hecho. Cuando ellos me veían agobiado o superado por la situación sabían brindarme aquello que
necesitaba, ya fuera una sonrisa, un consejo o un abrazo, y me hacían ver que no hay momento difícil que
100 años dure y que mantener la calma, el optimismo y una sonrisa ayuda a superarlo de una mejor
forma.
Por otra parte, durante este periodo universitario, se conocen a una gran variedad de personas cuyas
costumbres y hablas son diferentes entre sí. Esta aventura no solo sirve para formarnos académicamente,
sino que te enriquece como persona y te brinda una gran cantidad de experiencias enriquecedoras, algunas
buenas y otras no tanto, pero todas ellas únicas. Estas situaciones hacen posible que lo que simplemente
comenzó como un grupo de conocidos que se sentaban juntos en clase y quedaban para tomar algo se
convertían en unos buenos amigos. Todos ellos han marcado mi camino y me han hecho ser una mejor
persona hoy en día.
También me gustaría agradecer la paciencia, el trabajo y la dedicación que ha tenido Rafael Mª Estepa,
mi tutor de este trabajo fin de grado (TFG). Sin ello no habría conseguido finalizarlo, ya que ha sido
quien me ha orientado en el mismo, dándome documentación y tiempo para su desarrollo.
Quiero también mencionar que durante mi periodo universitario tuve la suerte de trabajar en diferentes
empresas como becario, realizando mis prácticas extracurriculares y curriculares, en Iwan 21 y redborder
respectivamente; en la primera de ellas me centré en el desarrollo web y tuve la suerte de coincidir con
Ramón Centeno, que me apadrinó laboralmente y tuvo una gran atención conmigo, enseñándome una
infinidad de cosas nuevas para mi, tanto a nivel laboral como a nivel personal.
En la segunda empresa me encargué de la integración de dispositivos de telecomunicaciones con grandes
fabricantes, como es el caso de Cisco o Fortinet, con el entorno redborder. Además, tuve la suerte de tener
como tutor a José Manuel Postigo, que más que un tutor era para mi un amigo, puesto que realizó una
parte de los estudios conmigo en el grado de telecomunicaciones. Él junto con Carlos Jiménez, me
brindaron todo el apoyo, material y conocimiento que necesité durante mis prácticas. Además, todo el
equipo de redborder mantenía un clima familiar, del cual me hicieron partícipe desde el primer momento.
Finalmente, quiero agradecer a todas las personas que se han cruzado en mi camino a lo largo de mi vida
y no se encuentran nombradas anteriormente, tanto de mi ambiente familiar, como universitario o laboral.
Todos ellos me han enseñado diferentes cosas que hoy en día puedo aplicar a cualquier ámbito de mi
vida.
David Ramos Cardoso
Estudiante en Grado de Ingeniería de las Tecnologías de Telecomunicación
Sevilla, 2017
xi
Resumen
El incremento exponencial del número de equipos conectados a la red provoca que la red cada
vez sea más compleja de gestionar y que los equipos que reciben y reenvían el tráfico en la red,
tales como switches o routers tengan que manejar un mayor flujo de datos.
Con el fin de mejorar la red y hacerla más dinámica se diseña un escenario SDN sencillo para
realizar una prueba de conceptos de la redes SDN y comprobar la flexibilidad que nos permite
esta tecnología. El problema que se aborda es el envío de datos por enlaces redundados entre dos
equipo con el fin de utilizar un enlace principal de envío y utilizando los enlaces alternativos
únicamente en caso de que el enlace principal esté saturado ofreciendo una calidad de servicio
mínima.
En este proyecto se va utilizar principalmente la tecnología OpenVSwitch y SDN, aunque
también se va a hacer uso de otros servicios como hostapd para crear puntos de acceso que
interconectan dos equipos mediante enlaces inalámbricos o iperf que simula el tráfico de
conexión de varios clientes a un mismo AP.
El objetivo que se persigue en este TFG es analizar el manejo de tráfico en una red SDN en la
que todo el tráfico sale hacia Internet por un único equipo que actúa como puerta de enlace y en
la que se realiza un balanceo de tráfico, basado en la saturación de los enlaces de los APs, en
función de las MACs origen.
Las pruebas realizadas nos ofrecen un resultado satisfactorio en enlaces ethernet, los cuales
aunque caigan y vuelvan a estar activos se integran correctamente en el escenario SDN. Sin
embargo, los enlaces WiFi arrojan un resultado no satisfactorio, puesto que si caen y recuperan,
no se integran en el escenario SDN y habría que integrarlos de forma manual en el mismo.
xiii
Abstract
Increase of computers connected to the network causes that the network to become more
complex to manage and that the devices that receives and forwards the traffic on the network,
such as switches or routers, has to handle a greater flow of data.
In order to improve the network and make it much more dynamic is designed a simple SDN
network to make a SDN concepts test for check the flexibility that this technology allows us.
The problem that we concern is the connection of redundant links between two computers,
allowing all traffic to be sent over a main link, forwarding traffic through an alternative or
secondary link if traffic is upper to threshold defined in the main link to offer a service with a
minimum quality of service.
This document use mainly OpenVSwitch and SDN technology, but it also use other services
such as hostapd to create access points that connect two devices through wireless links or iperf to
simulate traffic generated by users connections in the same AP.
The score of this TFG is to analyze how manage the traffic in a SDN network in which all the
traffic goes towards Internet by a single device that it acts as a gateway and the traffic is
balanced by overflowing in APs links by source MACs.
The result of the tests performed produce a successful result in ethernet links, which although its
fall and become active again its are correctly integrated in the SDN network. However, the
wireless links get an unsatisfactory result, because if its fall and recover, its are not integrated
into the SDN network and its would have to be integrated manually in the SDN network.
2.5.1 Gestión de paquetes 18 2.5.2 Servicios de OpenVSwitch 19
3 Algoritmo de encaminamiento dinámico basado en la saturación de los APs 21 3.1 Estructura de ficheros 24 3.2 Enlace caído 25 3.3 Comprobación de enlace principal 26 3.4 Comprobación de enlace alternativo 28 3.5 Verificación de tráfico del enlace principal 28
4 Escenario propuesto e implementación 31 4.1 Estructuras y servicios 32
4.1.1 Raspberry Pi 32 4.1.2 Sistema Operativo Raspbian 32 4.1.3 Iperf 33 4.1.4 Hostapd 34 4.1.5 isc-dhcp-server 36
4.2 Implementación del escenario 36 4.2.1 Escenario tradicional 37 4.2.2 Escenario SDN 38
5 Pruebas y Resultados 43 5.1 Interconexión de equipos 43
5.1.1 Conexiones de usuarios 43 5.1.2 Conexiones entre switches 44 5.1.3 Conexiones entre switch y controlador 48
5.2 Pruebas realizadas 49 5.2.1 Escenario en estado normal 50 5.2.2 Envío de tráfico inferior al umbral 52 5.2.3 Envío de tráfico superior al umbral 53 5.2.4 Caída de un enlace 54 5.2.5 Recuperación de un enlace 54
6 Conclusión y Líneas de Avance 57 6.1 Líneas de avance 58
6.1.1 Integración con nuevos controladores 58 6.1.2 Controlador distribuído 58 6.1.3 Verificar carga de enlaces antes de reenviar por otro enlace 58 6.1.4 Calcular los bytes tx de cada flujo por segundo 59 6.1.5 Manejo de errores 59
7.5 Anexo E: Script que ordena flujos por bytes tx en orden decreciente 81 7.5.1 Fichero sortFlow.py 81
Referencias 83
xvii
ÍNDICE DE TABLAS
Tabla 1-1. Estándares inalámbricos IEEE 802.11 3
Tabla 2-1. Campos principales de flujos OpenFlow 13
Tabla 2-2. Campos de cabecera OpenFlow 13
Tabla 2-3. Contadores OpenFlow 14
xix
ÍNDICE DE FIGURAS
Figura 1-1. Previsión de equipos conectados a la red 2012 - 2020 1
Figura 1-2. Comparación caudal teórico y caudal real en redes WiFi de alta densidad 2
Figura 1-3. Red de alta densidad mallada 5
Figura 2-1. Arquitectura SDN 9
Figura 2-2. Beneficios de redes SDN 11
Figura 2-3. Tipos de aplicaciones SDN 11
Figura 2-4. Controlador Floodlight 16
Figura 2-5. Inserción de regla estática en Floodlight 16
Figura 2-6. Arquitectura OpenVSwitch 17
Figura 2-7. Características OpenVSwitch 17
Figura 2-8. Gestión de paquetes 18
Figura 2-9. Gestión de paquetes 18
Figura 2-10. Módulos de OpenVSwitch 19
Figura 3-1. Módulos de OpenVSwitch 21
Figura 3-2. Diagrama de flujo del algoritmo de encaminamiento 23
Figura 3-3. Archivo tmpInFile.log 24
Figura 3-4. Archivo macInFile.log 24
Figura 3-5. Archivo normal_macs.log 24
Figura 3-6. Archivo red_macs.log 25
Figura 3-7. Petición REST que obtiene enlaces del escenario 25
Figura 3-8. Respuesta API REST 25
Figura 3-9. Caída de un enlace 26
Figura 3-10. Tráfico umbral de enlace principal superado 27
Figura 3-11. Reenvío por enlace principal 27
Figura 3-12. Reenvío por enlace alternativo 28
Figura 3-13. Reenvío al descender tráfico por debajo del umbral del enlace principal 29
Figura 4-1. Servicios que ejecutan los APs 31
Figura 4-2. Comparativa de modelos RPI 32
Figura 4-3. Flujo saliente de usuarios 33
Figura 4-4. Flujo saliente de usuarios con redirección por enlace alternativo 34
Figura 4-5. Servicio HostApd 34
Figura 4-6. Modificar fichero de configuración HostApd 35
Figura 4-7. Fichero hostapd.conf 35
Figura 4-8. Fichero dhcpd.conf 36
Figura 4-9. Comandos iptables 37
Figura 4-10. Comandos NFTables 38
Figuras 4-11 y 4-12. Configuración escenario general (izq) y específico de RPI (der) 39
Figura 4-13. Creación OVS 39
Figura 4-14. Interfaces OVS 40
Figura 4-15. Configuración escenario OVS 41
Figura 4-16. Interfaces de red con OVS 41
Figura 5-1. Apertura puertos del servidor iperf 44
Figura 5-2. Conexión cliente-servidor iperf3 44
Figura 5-3. Descubrimiento de interfaces libres de bucles 45
Figura 5-4. Velocidad de negociación en enlace ethernet 46
Figura 5-5. Asignación DHCP de IP de gestión al bridge 47
Figura 5-6. Autenticación EAPOL (WPA2) 47
Figura 5-7. Lista blanca de conexión a hostapd 47
Figura 5-8. Asignación fija de MAC al bridge 48
Figura 5-9. Asignación de controlador a OVS 48
Figura 5-10. Búsqueda del controlador 48
Figura 5-11. Conexión exitosa OVS-Controlador 49
Figura 5-12. Dashboard Floodlight 50
Figura 5-13. Switches conectados al controlador 51
Figura 5-14. Enlaces del escenario 51
Figura 5-15. Topología del escenario 52
Figura 5-16. Reenvío por enlace principal 52
Figura 5-17. Inserción ruta estática por enlace principal 53
Figura 5-18. Ruta estática por enlace principal 53
Figura 5-19. Envío de tráfico superior al umbral 53
Figura 5-20. Ruta estática por enlace alternativo 54
Figura 5-21. Vuelta a la normalidad de tráfico del enlace principal 54
Figura 5-22. Petición errónea al controlador 54
xxi
Notación
ACL Access Control List
AP Access Point
API Application Programming Interface
AS Autonomous System
CDPI Control Data-Plane Interface
DHCP Dynamic Host Configuration Protocol
DNS Domain Name Server
EGP Exterior Gateway Protocol
GW GateWay
IEEE Institute of Electrical and Electronics Engineers
IGP Interior Gateway Protocol
IP Internet Protocol
NAT
NBI
Network Address Translation
Nourthbound Interface
NFV Network Virtualization Function
ONF
OSI
Open Networking Foundation
Open System Interconnection
OVS OpenVSwitch
OVSDB OpenVSwitch DataBase
QoS Quality of Service
PC
REST
RPI
Personal Computer
REpresentational State Transfer
Raspberry Pi
SDN Software Defined Network
SO Sistema Operativo
STP Spanning Tree Protocol
TFG Trabajo Fin de Grado
VLAN
WPA
Virtual Local Area Network
Wi-Fi Protected Access
1
1 INTRODUCCIÓN Y OBJETIVOS
n la actualidad, con el uso masivo de diferentes aplicaciones y redes sociales, se hace
indispensable la utilización de dispositivos móviles conectados a la red. Esta necesidad da lugar
a un crecimiento exponencial de la conectividad de los dispositivos.
Figura 1-1. Previsión de equipos conectados a la red 2012 - 2020
E
La mejor forma de predecir el futuro es implementarlo.
- David Heinemeier Hansson -
Introducción y Objetivos
2
Tal y como se puede observar en el gráfico mostrado en la Figura 1-1, según el portal estadístico
Statista1 existe un crecimiento exponencial del número de dispositivos conectados a la red, siendo en
2012 en torno a los 8.7 billones de dispositivos y estimando que en 2020 esta cifra rondará los 50
billones a nivel mundial.
Este aumento de equipos se está centrando principalmente en equipos móviles conectados de forma
inalámbrica a la red, tales como SmartPhones, Tablets, SmartTv u otro dispositivo similar. Además
del aumento de equipos, las aplicaciones desarrolladas para ellos cada vez monitorizan más datos, lo
cual incrementa el caudal utilizado por cada equipo. Esta conexión masiva da lugar a que los puntos
de acceso WiFi tengan que gestionar una cantidad de tráfico mucho mayor, lo que puede provocar la
saturación de los AP que, a su vez, podría producir lentitud en el funcionamiento de la red e incluso
caídas en las conexiones de los usuarios.
Ante esta problemática, el mundo de las telecomunicaciones ha sufrido un proceso de adaptación,
modificando la infraestructura de red y migrando las redes físicas en redes virtuales. De esta forma,
se pueden aprovechar en mayor medida los recursos que cada equipo de acceso a la red proporciona,
ya sean APs, switches o firewalls, pudiendo separar un acceso físico en varios accesos lógicos y
balancear el tráfico que los atraviesa.
1.1 Motivación
Las redes WiFi de alta densidad2 nacen ante el aumento de dispositivos conectados a la red, lo cual
aumenta la complejidad tanto del diseño como de la gestión de la red. Estas nuevas redes Wifi
pretenden mejorar el comportamiento de las redes WiFi actuales.
• Son flexibles ante los cambios.
• Permiten realizar un balanceo de carga entre equipos.
• Muestran el porcentaje de uso de cada equipo.
• Permiten hacer redirecciones de orígenes o destinos en función de su dirección MAC.
El diseño de las redes WiFi de alta densidad difiere mucho del despliegue de la misma, ya que hay
factores externos que pueden afectar a la cobertura real de la red.
Figura 1-2. Comparación caudal teórico y caudal real en redes WiFi de alta densidad
1 Estudio de equipos conectados a la red: https://es.statista.com/estadisticas/517654/prevision-de-la-evolucion-de-los-dispositivos-conectados-para-el-internet-de-las-cosas-en-el-mundo/ 2 Redes Wifi de Alta Densidad: http://www.teldat.com/blog/es/wlan-what-are-high-density-networks/
Pese a que OpenVSwitch es mucho más complejo que un switch clásico, la mayor ventaja que ofrece
frente a los switches clásicos es la forma en que trata los paquetes. Esta forma de tratarlos se divide
en dos pasos:
• El paquete llega por primera vez. Cuando el paquete llega por primera vez al equipo, éste
no sabe cómo tratarlo, por lo que el equipo accede al espacio de usuario para comunicarse
con el controlador mediante OpenFlow y que, de esta forma, le indique cómo manejar ese
paquete. Así, el controlador inserta un flujo en la caché del switch.
• El paquete ya ha llegado con anterioridad. Si el paquete ha llegado previamente al equipo,
al tener instalado ya un flujo por parte del controlador en la caché del propio switch, éste no
tiene que volver a consultar al controlador, quedándose en el espacio del kernel.
La finalidad que persigue esta forma de tratar los paquetes es minimizar las consultas entre los
switches y el controlador de forma que el rendimiento de la red se vea mejorado. Se puede ver
claramente la forma en que se tratan los paquetes en la figura 2-8.
Figura 2-8. Gestión de paquetes10
Este tratamiento de paquetes se puede analizar en la captura que se ha realizado con wireshark de
la figura 2-9.
Figura 2-9. Gestión de paquetes11
10 Gestión de paquetes: https://commons.wikimedia.org/wiki/File:Openvswitch.jpg 11 Gestión de paquetes: https://commons.wikimedia.org/wiki/File:Openvswitch.jpg
19
19 Microceldas 802.11 de alta densidad
2.5.2 Servicios de OpenVSwitch
OpenVswitch contiene un conjunto de módulos o servicios que permiten al usuario acceder a los
flujos que atraviesan el equipo, así como insertar o borrar flujos estáticos entre otras funcionalidades.
Estos servicios se agrupan principalmente en 3 módulos:
• ovs-vswitchd. Es el proceso encargado de implementar las funcionalidades básicas de un
switch como son las VLANs, bonding o monitorización. Es el núcleo de OVS y se comunica
con los otros dos componentes con el uso del protocolo NetLink, para la conexión con el
módulo del kernel openvswitch_mod-ko, y con ovsdb-server mediante los sockets de UNIX,
con la utilización del protocolo OVSDB.
• openvswitch_mod-ko. Este módulo es el encargado de manejar la conmutación de paquetes.
Su objetivo es que sea simple y rápido, por lo que no tiene comunicación con otros
componentes mediante OpenFlow. La única comunicación que tiene es con el proceso ovs-
vswitchd mediante netlink a fin de saber qué hacer con los paquetes entrantes.
• ovsdb-server. Es un servidor ligero de bases de datos. Contiene los parámetros de
configuración de OVS que perduran aún tras el reinicio de un host. Algunas tablas que
pueden existir en la base de datos son Bridge, Port, Interface o Flow Table. Además, OVS
nos da una serie de comandos12 con los que poder modificar esta base de datos a partir de un
shell, entre los que destacan los siguientes:
o ovs-appctl. Ejecuta y configura daemons de OVS.
o ovs-dpctl. Administra los caminos OVS, configurando el módulo del kernel para
indicarlo.
o ovs-ofctl. Monitoriza y administra el switch OVS. Muestra información del estado
del switch tales como características, configuración y entrada de tabla.
o ovs-testcontroller. Permite un controlador OpenFlow simple que gestiona cualquier
número de switches para verificar la red.
o ovs-vsctl. Permite consultar y actualizar el componente ovs-vswitchd.
Figura 2-10. Módulos de OpenVSwitch13
12 Comandos de OVS: http://openvswitch.org/support/dist-docs/ 13 Componentes OVS: https://es.slideshare.net/teyenliu/the-basic-introduction-of-open-vswitch/9
Conceptos Básicos
20
21
3 ALGORITMO DE ENCAMINAMIENTO DINÁMICO
BASADO EN LA SATURACIÓN DE LOS APS
n esta sección vamos a ver la forma en que se abarca el problema de la saturación en los
enlaces de los APs. Para ello se va a diseñar un algoritmo encargado de relizar el balanceo de
tráfico entre los enlaces de salida redundados de un AP, siempre y cuando se haya superado un
cierto umbral de tráfico. Para comprobar que el algoritmo se comporta bien ante situaciones
complejas se va a realizar una prueba de concepto en la que vamos a exigir que haya cambios de
reenvíos de flujo en los APs.
Para llevar a cabo dicha prueba de conceptos se implementa el escenario de la figura 3-1 en el que
tenemos dos enlaces entre una RPI y el ordenador. Del mismo modo, el algoritmo se ha desarrollado
para que su funcionamiento se pueda extrapolar a otros escenarios más complejos realizando
pequeños cambios en el mismo.
Figura 3-1. Módulos de OpenVSwitch
E
El ordenador nació para resolver problemas que antes
no existían
- Bill Gates -
Algoritmo de encaminamiento dinámico basado en la saturación de los APs
22
En el escenario mostrado vamos a simular que cada equipo de red es un punto de acceso al cual
pueden conectarse varios usuarios para acceder a Internet. El escenario se encuentra compuesto
por dos ordenadores de bajo coste Raspberry Pi (RPI) y un ordenador portátil con el sistema
operativo Ubuntu 14.04 instalado. Los roles de cada dispositivo son los siguientes:
• Raspberry Pi: cada una actúa como un punto de acceso o AP que da conexión a un
grupo de clientes WiFi, abarcando una determinada zona de cobertura, a fin de diseñar
una red de alta densidad WiFi. Estos equipos no tienen conexión directa a Internet, por lo
que tienen que reenviar todo el tráfico a través del ordenador que está presente en este
escenario para proporcionar acceso a Internet.
• Ordenador (GW): este equipo actúa como pasarela entre la red interna del escenario
SDN e Internet. Al igual que las RPI, proporciona conexión a un grupo de usuarios WiFi
mediante un AP.
El escenario del que partimos es que las RPI tienen instalado OpenVSwitch y se comunican
mediante OpenFlow con un controlador SDN, que está alojado en el ordenador portátil, con el
fin ver cómo tienen que tratar el tráfico que reciben. El controlador SDN va a tomar la decisión
de redirigir o no el tráfico cursado por cada interfaz en función de la ocupación del canal. Esta
redirección se basa en las direcciones MAC origen.
Con el fin de redirigir el tráfico que atraviesa la red y poder balancear la carga entre los diferentes
enlaces de salida, se puede implementar el algoritmo que reenvíe:
• Cada MAC por un enlace. Esta redirección sería similar al algoritmo de balanceo Round
Robin14. De esta forma, cada MAC desconocida para el equipo se envía por un enlace,
siguiendo una rotación en anillo y consiguiendo que todos los enlaces tengan
estadísticamente el mismo número de flujos a través de ellos. El problema es que tener el
mismo número de flujos por enlace no quiere decir tener el mismo caudal, por lo que no es
un método válido para conseguir nuestro objetivo.
• Cada enlace de entrada por un enlace de salida. Este algoritmo de balanceo necesita tener
varios enlaces de entrada de tráfico para que sea efectivo. Se comporta realizando una
redirección fija de cualquier flujo que venga a través de un puerto por otro puerto de salida.
Este método, al igual que el anterior, hace prácticamente imposible que se evite la saturación
de alguno de los enlaces.
• Tráfico interno por un enlace y externo por otro. Este algoritmo hace una clara separación
de tráfico de un AP y tráfico del resto de APs. Es útil para dar preferencia o evitar retardos de
un grupo de usuarios conectados a un AP, pero no redirige tráfico en función de la carga de
un AP.
• Enlace menos cargado. Este algoritmo permite tener los enlaces totalmente balanceados y
permitiendo que cada uno contenga un caudal similar al resto. El problema de este algoritmo
es que puede elegir un enlace más lento o cuyo salto sea mayor, proporcionando a los
usuarios un mal servicio.
• Conmutar enlace si supera un umbral determinado. Con este algoritmo se define un
enlace principal y uno o varios alternativos. De esta forma reenvía todo el tráfico a través del
enlace principal, a menos que se supere un cierto umbral de saturación, en cuyo caso
comienza a redirigir el tráfico por los enlaces alternativos.
14 Algoritmos de balanceo: https://es.wikipedia.org/wiki/Balanceador_de_carga
23 Microceldas 802.11 de alta densidad
Entre las opciones que se han discutido, se va a utilizar el algoritmo de conmutación siempre que se
supere un cierto umbral de tráfico en el enlace principal para realizar la prueba de conceptos de la
que es objetivo este proyecto. Este algoritmo se va a encargar de redirigir el tráfico del escenario tal y
como se muestra en el diagrama de flujo de la figura 3-2, priorizando en la redirección las
direcciones MAC que producen un mayor flujo.
Figura 3-2. Diagrama de flujo del algoritmo de encaminamiento
Algoritmo de encaminamiento dinámico basado en la saturación de los APs
24
Analizando el diagrama, se puede deducir que:
1. El algoritmo comprueba cada poco tiempo (< 1,5 seg) si hay algún enlace caído. En caso
afirmativo elimina todos los flujos del enlace afectado.
2. Comprueba si el enlace principal está operativo y si el tráfico enviado por él supera un
determinado umbral predefinido. Si es así, intenta enviar tráfico por el enlace alternativo.
En caso contrario envía tráfico por el puerto de salida 1.
3. Comprueba si el enlace alternativo está operativo, si el tráfico enviado por él supera un
determinado umbral y si el enlace principal sigue sobrecargado. En caso afirmativo
comienza a enviar tráfico por el puerto de salida 2.
4. Comprueba si el tráfico del enlace principal ha disminuido por debajo del umbral más un
factor de histéresis, a fin de evitar demasiadas oscilaciones en los enlaces. En caso
afirmativo cambia el valor de la variable NORMAL_TRAFFIC a 0 para indicarlo. Si no es
así sigue redirigiendo tráfico por el puerto de salida 2.
En los siguientes apartados, se va a entrar en más detalle sobre cómo realiza el script cada uno de
los pasos en el algoritmo que se han comentado.
3.1 Estructura de ficheros
La ejecución de este script depende de la existencia de determinados ficheros en el sistema. Es
por ello que el script realiza una comprobación de la existencia de estos ficheros antes de ver el
estado de los enlaces y su carga. Estos ficheros son los siguientes:
• tmpInFile.log. Este fichero almacena los flujos que pasan por el dispositivo sin ningún
orden.
Figura 3-3. Archivo tmpInFile.log
• macInFile.log. Este fichero recibe el volcado de las MACs que recibe el switch por los
enlaces de entrada de tráfico y de su interfaz local, pero de forma ordenada.
Figura 3-4. Archivo macInFile.log
• normal_macs.log. Este fichero es el encargado de almacenar todas las MACs que se
redirigen por el enlace principal en el escenario presentado en este TFG.
Figura 3-5. Archivo normal_macs.log
• red_macs.log. Este fichero contiene el mismo formato que el anterior, pero contiene las
MACs que son redirigidas por el enlace alternativo.
25 Microceldas 802.11 de alta densidad
Figura 3-6. Archivo red_macs.log
3.2 Enlace caído
La primera comprobación que realiza el script tras comprobar los archivos y entrar en el bucle es ver
si hay algún enlace caído. Para ello hay declarada una variable que almacena el total de enlaces del
escenario, que se ha obtenido usando el script findPath.py del Anexo C. El script realiza una petición
a la API REST del controlador Floodlight para obtener el número de enlaces activos. Esta petición se
muestra en la figura 3-7.
Figura 3-7. Petición REST que obtiene enlaces del escenario
Figura 3-8. Respuesta API REST
Algoritmo de encaminamiento dinámico basado en la saturación de los APs
26
El siguiente paso es comprobar si el número de enlaces activos que ha obtenido de la petición se
corresponde con el número total de enlaces que hay en el escenario.
1. Cuando el número de enlaces obtenidos es menor que el número de enlaces predefinidos en
el script, lo cual indica que algún enlace se ha caído:
o Se limpia la tabla de flujos del switch que ha perdido un enlace y se elimina de los
ficheros las MACs asociadas al puerto de salida afectado.
o Se actualiza la variable que contiene el número de enlaces activos en el escenario,
decrementando su valor en dos unidades, ya que los enlaces son unidireccionales.
Figura 3-9. Caída de un enlace
2. Cuando el número de enlaces obtenidos es mayor que el número de enlaces predefinidos en
el script, lo que indica que algún enlace que estaba caído se ha recuperado.
o Actualiza el número total de enlaces activos en el escenario, incrementando su valor
en dos unidades, una por cada enlace unidireccional.
3.3 Comprobación de enlace principal
Tras verificar el estado de los enlaces conectados al dispositivo, el script comprueba que el estado del
enlace principal esté activo y que su carga haya superado o no el umbral que se ha establecido.
• Si el tráfico cursado por el enlace principal (t1) supera el umbral de tráfico predefinido para
ese enlace (u1), se pasa a comprobar el estado del enlace secundario, que se va a analizar en
el punto 3.4 Comprobación de enlace secundario.
27 Microceldas 802.11 de alta densidad
Figura 3-10. Tráfico umbral de enlace principal superado
• Si no se ha superado el umbral de tráfico predefinido, el script comienza a redirigir el tráfico
de entrada que aún no haya sido asignado a ninguna interfaz. En caso de que todo el tráfico
ya haya sido redirigido por alguna de las interfaces de salida, el script no tiene que ejecutar el
código de python, que se encuentra definido en el Anexo D.
Figura 3-11. Reenvío por enlace principal
1. Lee línea a línea el fichero de las MACs de entradas.
▪ Si hay una MAC sin flujo asignado, la redirige.
▪ Si hay una MAC con flujo asignado, pasa a otra línea.
2. Escribe en el fichero que contiene las MACs redirigidas por el puerto de salida
número 1.
3. Crea un flujo en el switch indicando que el flujo cuya MAC origen es el que se ha leído del fichero de MACs entrantes se envía por el puerto de salida número 1.
Algoritmo de encaminamiento dinámico basado en la saturación de los APs
28
3.4 Comprobación de enlace alternativo
En esta fase del script se comprueba si el tráfico que procesa el enlace alternativo es superior al
umbral, si el enlace está activo y si el enlace principal sigue sobrecargado.
• Si el tráfico que atraviesa el enlace alternativo supera el umbral, el enlace está caído o la
carga del enlace principal ha caído por debajo del umbral, salimos de esta comprobación sin
realizar ninguna configuración.
• Si el tráfico que atraviesa el enlace alternativo no supera el umbral, el enlace no está caído y
la carga del enlace principal sigue estando por encima del umbral predefinido menos un
factor de histéresis, el script ejecuta los siguientes pasos.
Figura 3-12. Reenvío por enlace alternativo
o Se ejecuta un script en python encargado de ver si las MACs ya han sido redirigidas.
▪ Si no se ha redirigido esa MAC, se marca para enviar por el puerto 2.
▪ Si se ha redirigido la MAC por el puerto 1, se redirige por el puerto 2,
eliminando dicha MAC del archivo que contiene los reenvíos por el puerto 1
y modificando el flujo en el switch.
▪ Si se ha redirigido la MAC por el puerto 2 no se realiza ninguna acción.
3.5 Verificación de tráfico del enlace principal
La última comprobación que hace el script es ver si el tráfico del enlace principal ha descendido por
debajo del umbral establecido más un factor de histéresis (h1). Este factor se aplica para dotar a la
red de estabilidad a la hora de realizar las funciones de encaminamiento.
29 Microceldas 802.11 de alta densidad
Figura 3-13. Reenvío al descender tráfico por debajo del umbral del enlace principal
31
4 ESCENARIO PROPUESTO E IMPLEMENTACIÓN
sta sección está dedicada a los componentes, tanto a nivel hardware como a nivel software, que
se han utilizado a la hora de desplegar el escenario propuesto en este TFG. En la figura 4-1 se
muestra el escenario junto con los servicios que hay instalados en cada AP.
Figura 4-1. Servicios que ejecutan los APs
Podemos ver que las dos RPI del escenario tienen instalados los mismos servicios, que son:
• Raspbian como SO
• Iperf como generador de tráfico
• OpenVSwitch para virtualizar el switch e introducirlo en el escenario SDN
Por otra parte, el PC tiene diferentes servicios, ya que su comportamiento en este TFG difiere de las
RPI.
• Ubuntu como SO
• Hostapd y isc-server-dhcp para actuar como AP
E
La prueba de toda verdad reside, sencillamente, en su
eficacia
- William James -
Escenario propuesto e implementación
32
• OpenVSwitch para virtualizar el switch e introducirlo en el escenario SDN
• Floodlight, que es el controlador del escenario
4.1 Estructuras y servicios
En este apartado se va a explicar de forma concisa los servicios que se han utilizado en el escenario,
así como la configuración que se ha tenido que implementar de ellos.
4.1.1 Raspberry Pi
El uso de estos equipos en el escenario es fundamental para que el coste de abordar una ampliación
de las infraestructuras no sea muy elevado, ya que estos equipos se comercializan por un precio igual
o inferior a 35$. En este TFG se han utilizado dos Raspberry Pi 2 model B. Se puede ver una
comparativa de los diferentes modelos de RPI existentes en el mercado en la figura 4-2.
Figura 4-2. Comparativa de modelos RPI15
Estos ordenadores poseen las funcionalidades básicas de los equipos basado en GNU/Linux, ya que
utiliza el sistema operativo Debian, como se va a ver en el apartado 4.1.2 Sistema Operativo Debian,
por lo que, pese a que tienen una mayor limitación hardware, contiene las funcionalidades de red
suficientes para abarcar el problema que nos acontece de una forma adecuada.
4.1.2 Sistema Operativo Raspbian
Las RPI del escenario que se han utilizado en este proyecto hacen uso del sistema operativo
Raspbian, que es una variación de Debian adaptada al hardware de las Raspberrys Pi, por lo que es
libre y gratuito.
Pese a que viene preparado y optimizado para estos pequeños ordenadores, este SO contiene en torno
a 35 mil paquetes precompilados para facilitar la instalación de los servicios que sean necesarios.
para este servicio, aunque se podría modificar a otro modificando el fichero /etc/default/hostapd, más
en concreto la línea que está marcada en la figura 4-6.
Figura 4-6. Modificar fichero de configuración HostApd
En este documento, se va a mantener el fichero de configuración por defecto. Por lo que la
configuración de este servicio se encuentra en /etc/hostapd/hostapd.conf y se muestra en la figura 4-
7.
Figura 4-7. Fichero hostapd.conf
En este fichero se declaran:
• La interfaz que va a actuar como AP
• El nombre de la red que se emite o SSID
Escenario propuesto e implementación
36
• El estándar wifi IEEE utilizado
• El canal en el que emite
• La autenticación que utiliza, que en este caso concreto es una red abierta
• Las macs que permite conectar por ese AP
Que la red sea abierta y tener que declarar un archivo de lista blanca de MACs se va a ver más en
detalle en el apartado 5. Pruebas y Resultados. El archivo de lista blanca contiene las MACs
permitidas, teniendo una MAC en cada línea del fichero.
4.1.5 isc-dhcp-server18
ISC DHCP es un software Open Source que implementa el servicio DHCP, el cual nos permite
obtener una dirección IP de forma dinámica. Tiene soporte tanto para IPv4 como para IPv6.
Funciona bajo la licencia ISC, que está basada en la licencia BSD. ISC está trabajando en el
desarrollo de un nuevo servidor DHCP llamado Kea. Este nuevo software se prevee que se implante
en la mayoría de servidores en un futuro, dejando a un lado ISC DHCP, a menos que no funcione
Kea, en cuyo caso se instalará ISC DHCP.
Debido a que el software Kea aún está en fase beta y que el servidor ISC DHCP nos otorga las
funcionalidades necesarias para la realización de este proyecto, se ha utilizado el servidor ISC DHCP
en el mismo.
La configuración de este servidor se encuentra definida en el fichero /etc/dhcp/dhcpd.conf. Su
configuración se fundamenta en definir el rango de direccionamiento que va a otorgar a los clientes,
del mismo modo que otras características de red como la puerta de enlace.
Figura 4-8. Fichero dhcpd.conf
4.2 Implementación del escenario
La implementación del escenario se divide en dos fases o escenarios:
• Primera fase: escenario tradicional.
• Segunda fase: escenario SDN.
18 Página oficial isc-dhcp-server: https://www.isc.org/downloads/dhcp/
37 Microceldas 802.11 de alta densidad
4.2.1 Escenario tradicional
Antes de desarrollar el escenario SDN se diseñó un escenario de red tradicional, en el que cada RPI
enruta por sí misma todo el tráfico y lo envía hacia el ordenador a fin de salir hacia Internet. En este
escenario, por tanto, tenemos tantos APs como RPIs más el ordenador.
El objetivo de desarrollar este escenario previamente es poder ver que las conexiones entre equipos
son correctas y que con la red tradicional también puede funcionar.
En este escenario, por tanto, es necesario tener instalado los servicios isc-dhcp-server y hostapd en
cada equipo de la red que tenga la necesidad de enrutar, además de tener reglas para evitar un mal
uso de la red. Estas reglas se pueden aplicar con los servicios iptables o nftables.
El problema de este escenario es que no contempla la redirección de tráfico en función de la
saturación de los enlaces, además de ser más lento al tener que consultar la tabla de encaminamientos
con cada paquete.
4.2.1.1 IPTables19
IPtables es un servicio de Firewall integrado en el kernel de Linux para gestionar las conexiones a
nivel de capa 3 o 4 del modelo OSI. Contiene una variante llamada ip6tables cuya funcionalidad se
centra en direcciones IPv6. No obstante, este software es sustituido definitivamente en detrimento de
nftables a partir del kernel 3.13 de Linux, ya que nftables contiene más capacidades de protección
que iptables.
Algunos comandos básicos de este iptables se muestran en la figura 4-9.
Figura 4-9. Comandos iptables
4.2.1.2 NFTables20
NFTables, al igual que IPTables, es un Firewall que se utiliza para proteger sistemas basados en
Linux.
Para poder aplicar políticas mediante NFTables, previamente tenemos que tener instalado NFTables
en el dispositivo final, ya que por defecto en Ubuntu 14.04 no viene instalado. Una vez que ya se
instala el servicio en el dispositivo, es hora de aplicar las políticas que se consideren oportunas.
Algunos ejemplos de políticas se muestran en la figura 4-10.
19 Wiki de IPTables: https://wiki.archlinux.org/index.php/Iptables_(Espa%C3%B1ol) 20 Wiki de NFTables: http://wiki.nftables.org/wiki-nftables/index.php/Main_Page
Escenario propuesto e implementación
38
Figura 4-10. Comandos NFTables
Este servicio presenta una serie de ventajas con respecto a iptables, ya que une las capacidades de
iptables, ip6tables, arptables y ebtables, por lo que es un servicio mucho más completo y seguro que
el resto.
4.2.2 Escenario SDN
Tras comprobar que el escenario tradicional funcionaba correctamente, tal y como se explica en la
sección 4.2.1 Escenario Tradicional, se van a comentar los requisitos que se siguieron para montar la
red SDN.
En este escenario se han utilizado principalmente dos servicios que no se utilizan en el entorno
tradicional: OpenVSwitch y Floodlight. Estos servicios se encuentran explicados detalladamente en
los puntos 2.5 OpenVSwitch y 2.4 Controlador SDN: Floodlight.
Además de estos servicios se utilizaron tanto un servidor DHCP (isc-dhcp-server) como un servicio
de AP Wifi (hostapd) entre los equipos que se conectaban de forma inalámbrica en el escenario.
Utilizando este tipo de redes, agilizamos el tráfico de los flujos que atraviesan la red, ya que cada
switch virtualizado realiza una única petición al controlador sobre cada flujo, reenviando el resto de
paquetes del mismo flujo por el puerto que indique el controlador en la consulta. Además, podemos
gestionar toda la red desde un único punto, haciendo que se adapte en cada momento a las
necesidades que haya, como por ejemplo el balance de carga en función de la saturación de los AP,
que es la prueba de conceptos que se pretende realizar.
4.2.2.1 Configuración OpenVSwitch
En el escenario desarrollado en este TFG, existen tres equipos que manejan tráfico: las dos RPI y el
PC, que contiene el controlador. La configuración de estos equipos a nivel de OpenVSwitch es muy
similar, por lo que se va a mostrar la configuración en uno de los equipos, más en concreto la
configuración del PC. No obstante, en la sección de anexos A se encuentran los scripts de
configuración de cada equipo detalladamente.
En la figura 4-11 se muestra un diagrama de flujos donde se ven los pasos que se han seguido, en
general, para la configuración de los APs como switches virtuales con OVS. El caso de la RPI que se
encuentra conectada directamente al PC es un caso particular por la conexión como cliente WiFi que
hay, por lo que su diagrama de flujo se muestra en la figura 4-12.
39 Microceldas 802.11 de alta densidad
Figuras 4-11 y 4-12. Configuración escenario general (izq) y específico de RPI (der)
Vamos a ver en más detalle, analizando el código del script, los pasos que sigue un AP de la red, en
concreto el PC, para crearlo con OVS y configurarlo.
Lo primero que hay que hacer para montar un switch virtual con OpenVSwitch, es crearlo y
configurar algunos parámetros generales como las versiones de OpenFlow que puede negociar en
una conexión.
Figura 4-13. Creación OVS
En la figura 4-13 se puede ver tanto la creación del switch como los protocolos que soporta para la
comunicación y una dirección MAC fija que tendrá el bridge. El parámetro de MAC fija se explicará
más en profundidad en la sección 5. Pruebas y Resultados. Además, como crea un bridge, que es un
equipo de nivel 2 en el modelo OSI, las interfaces que se vayan a añadir a este equipo no pueden
Escenario propuesto e implementación
40
tener ninguna dirección IP, por lo que también le quitamos la IP a esas interfaces. Si añadimos las
interfaces al bridge con una IP asociada, vamos a perder la conectividad por esas interfaces.
Simplemente hemos creado el switch, por lo que a continuación hay que añadir las interfaces
necesarias al bridge. Con el fin de poder gestionar el comportamiento del bridge también le añadimos
una dirección IP de gestión.
Figura 4-14. Interfaces OVS
En la figura 4-14 se puede ver como lo primero que se hace es añadir las interfaces al bridge
previamente creado y utilizamos una IP de gestión en el equipo.
A continuación, se añade la dirección del controlador con el que va a interactuar el equipo y se
gestiona el tráfico de difusión de los puertos del bridge, permitiendo que el tráfico de difusión
únicamente se encamine por el puerto 1 a fin de evitar bucles. No se hace uso del protocolo STP
porque este protocolo actúa bloqueando los puertos para que no haya bucles en el escenario y, de esta
forma, no se permite balancear el tráfico entre los dos enlaces.
Por tanto, al ejecutar este script se crea el switch, mostrando la información básica de las interfaces
que pertenecen al switch, así como las características que se han definido, tal y como muestra la
figura 4-15.
41 Microceldas 802.11 de alta densidad
Figura 4-15. Configuración escenario OVS
Finalmente, para comprobar que las interfaces del bridge están bien creadas, vemos las interfaces de
red configuradas en el equipo y tiene que ser algo similar a la figura 4-16. En ella podemos ver que
las interfaces que pertenecen al bridge OVS no tienen dirección IP y que el propio bridge tiene una
IP de gestión.
Figura 4-16. Interfaces de red con OVS
Escenario propuesto e implementación
42
4.2.2.2 Configuración Floodlight
En este escenario se hace uso de la API Rest21 para la gestión del escenario. Para ello hay una serie
de scripts que la utilizan con el fin de recolectar datos de puertos disponibles o editando reglas de
reenvío estática.
Estas peticiones se hacen con el fin de balancear el tráfico entre los enlaces disponibles. Un ejemplo
de uso de esta API es para analizar el estado de los enlaces del escenario y, así, poder modificar los
enlaces activos del sistema y actuar en consecuencia.
21 API REST de Floodlight: https://floodlight.atlassian.net/wiki/spaces/floodlightcontroller/pages/1343539/Floodlight+REST+API
43
5 PRUEBAS Y RESULTADOS
n este capítulo vamos a ver las pruebas que se han realizado con el escenario presentado,
centrándonos en los resultados obtenidos para cada una de ellas. Se va a comenzar viendo
desde las conexiones más externas de la red, las conexiones de usuario, hasta las más
internas, comunicación interna entre switch y controlador.
Como se ha comentado previamente, el objetivo de este escenario es poder balancear el tráfico
de los APs en redes WiFi de alta densidad en función de la saturación de los mismos con el fin
de aprovechar los recursos que nos ofrecen los equipos de la red.
5.1 Interconexión de equipos
Antes de poder realizar las pruebas de conceptos, es necesario que todos los equipos se conecten
correctamente entre sí, para que el escenario tenga total funcionalidad y los datos obtenidos sean
válidos. Por ello, se van a analizar las conexiones entre los dispositivos, comentando los
problemas que han surgido y la solución que se ha adoptado.
5.1.1 Conexiones de usuarios
El objetivo de este proyecto es desplegar una red WiFi de alta densidad por medio de APs. Estos
APs realizan NAT con las conexiones de los usuarios, de forma que no existen tantas direcciones
MACs diferentes en la red SDN reduciendo las consultas al controlador, de forma que agiliza la
gestión de flujos de la red.
En los APs se tiene que tener instalado un servidor dhcp y hostapd para permitir las conexiones
wifi a los usuarios. Como el objetivo de este proyecto es observar como se maneja el tráfico
entre switches, se han simulado las conexiones de usuarios con el software iperf3. De esta forma,
se genera un gran caudal desde cada equipo y se puede observar cómo manejan el tráfico.
E
El ignorante afirma; el sabio duda y reflexiona
- Aristóteles -
Pruebas y Resultados
44
En las dos RPI del escenario, se ha ejecutadon dos clientes iperf que conectan con un puerto del
servidor abierto en el PC, que se encuentra a la espera de conexiones. Estas conexiones se
realizan contra los puertos 8081 y 8181. Para utilizar el servidor iperf en segundo plano hay que
ejecutar el siguiente comando:
dramos@dramos:~$ iperf3 -s -p <8081/8181> -D
Figura 5-1. Apertura puertos del servidor iperf
Cuando el servidor iperf3 está escuchando conexiones en dichos puertos, se tienen que arrancar
los dos clientes que hay en cada RPI y conectarlos con estos puerto que hemos abierto, sin que se
solapen ente sí. En la conexión se puede indicar diferentes parámetros como el ancho de banda