Microceldas 802.11 de alta...
Transcript of Microceldas 802.11 de alta...
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.
xv
Índice
Agradecimientos ix
Resumen xi
Abstract xiii
Índice xv
Índice de Tablas xvii
Índice de Figuras xix
Notación xxi
1 Introducción y Objetivos 1 1.1 Motivación 2 1.2 Objetivos 4
2 Conceptos Básicos 7 2.1 Introducción a Software Defined Networking (SDN) 7
2.1.1 Historia 7 2.1.2 Principios básicos [1] 8 2.1.3 ¿Por qué utilizar SDN? 10
2.2 Open Networking Foundation (ONF) 12 2.3 OpenFlow [2] 12
2.3.1 Tipos de switches 13 2.3.2 Tabla de flujos 13
2.4 Controlador SDN: Floodlight [3] 15 2.5 OpenVSwitch [4] 16
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 Anexos 61 7.1 Anexo A: Despliegue de escenario OVS 61
7.1.1 Fichero FL_pcEscenario.sh 61 7.1.2 Fichero FL_whiteEscenario.sh 64 7.1.3 Fichero FL_blackEscenario.sh 68
7.2 Anexo B: Ejecución Floodlight 72 7.2.1 Fichero fl_script.sh 72
7.3 Anexo C: Algoritmo de balanceo y ruta mínima 72 7.3.1 Fichero loopLinkSpeed.sh 72 7.3.2 Fichero findPath.py 77
7.4 Anexo D: Script de encaminamiento estático 78 7.4.1 Fichero normalTraffic.py 78 7.4.2 Fichero redTraffic.py 79
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/
3
3 Microceldas 802.11 de alta densidad
Con objeto de resolver el problema de la saturación de los APs, se han investigado diferentes
soluciones que pueden abarcar la problemática para las redes WiFi de alta densidad.
Estándares del IEEE. Con la evolución de los estándares de las redes Wifi, se ha ampliado la tasa a
la que pueden funcionar los equipos, así como la banda en la que emiten, siendo los nuevos
estándares totalmente compatibles con los anteriores. En la tabla 1-13 podemos observar las
características de cada uno.
Tabla 1-1. Estándares inalámbricos IEEE 802.11
• Adquirir nuevos puntos de acceso. Ante la saturación de los APs desplegados en los
entornos inalámbricos, se pueden seguir dos vías:
o Aumento del número de APs. Incrementando el número de los APs desplegados,
podemos abarcar tanto a un mayor grupo de usuarios como a una zona de cobertura
mayor.
o APs más sofisticados. La asquisición de APs con mayores capacidades permiten dar
servicio de forma más eficiente a un conjunto de usuarios, sin la necesidad de
comprar un gran número de equipos.
• Redes malladas con encaminamiento dinámico. Diseñando una red Wifi de alta densidad
completamente mallada, podemos gestionar el tráfico evitando las pérdidas de acceso en caso
de que un enlace caiga. Además, nos ofrece una gran redundancia, por lo que minimiza la
probabilidad de error. Estas redes se pueden implementar de dos formas:
o Protocolos de routing dinámicos. Utilizando protocolos dinámicos se pueden
comunicar las rutas hacia el destino entre vecinos de un mismo AS (IGP) o entre ASs
(EGP), quedando la red totalmente alcanzable. En el caso que se investiga, nos
interesan los protocolos intradominio o IGP, como pueden ser OSPF, RIP o IS-IS, ya
que la idea es mallar una red completa, la cual compone un AS.
o Redes SDN. Haciendo uso de redes SDN podemos focalizar la toma de decisión en
un único punto de la red, el controlador, de forma que desde ese punto se tiene una
vista completa de la red y se puede elegir la mejor ruta para llegar a un determinado
destino, lo cual facilita y automatiza su gestión.
Frente a estas posibles soluciones que se acaban de presentar, se realizó un estudio de cada una por
separado y se llegó a la conclusión de que la mejor opción es la implementación de una red SDN por
los motivos que se detallan a continuación:
1. Con las redes SDN se busca aprovechar el máximo de los recursos de cada equipo que
compone la red. Adquirir nuevo equipamiento puede ser una opción, pero implementando
algunas de las soluciones de red mallada nos evitamos un gasto innecesario en nuevo
equipamiento de red que podría dejar algunos equipos inutilizados.
3 Buenas prácticas estándares IEEE 802.11: http://www.sysadmit.com/2016/05/wifi-buenas-practicas-capitulo-1.html
Introducción y Objetivos
4
2. La utilización de protocolos IGP de encaminamiento dinámico permite a la red ser tolerante
ante fallos y adaptarse frente a cambios topológicos. Estos protocolos intradominio presentan
un problema, que a nivel de enlace (redes SDN) no afecta, ya que los diferentes APs que dan
servicio al usuario tienen que ofrecer un rango de direccionamiento diferente, puesto que en
caso contrario se crea una incoherencia en la red que afecta a la conectividad. Además, los
protocolos IGP no tienen ningún algoritmo que redirija el tráfico dinámicamente en función
de la carga de los APs.
3. Se va a hacer uso de Raspberrys Pi como elementos de red (APs) en modo de bridge. Con el
uso de redes SDN se pueden evitar los bucles propios de un bridge, redirigiendo el tráfico de
difusión o desconocido por un determinado puerto. Además, las redes SDN permiten una
fácil adaptación ante cualquier tipo de cambio en la red.
Por estos motivos que se acaban de comentar, se ha optado por la implantación de redes SDN para
este proyecto ya que es la única solución que aborda el problema en su totalidad, respondiendo a
cada requisito que se ha propuesto.
Con este trabajo, se pretende crear una pequeña red SDN con la que, mediante un controlador que
gestione y monitorice todo el tráfico de la red, poder enviar el tráfico entre los dipositivos por cada
una de sus interfaces, todo ello dependiendo del tráfico cursado por cada una de ellas y pudiendo ser
fácilmente adaptable a las necesidades del momento.
De esta forma, para eventos que aglutinen a una gran masa de personas, se pueden tener varios
puntos de acceso de bajo coste o microceldas, como Rapsberry Pi, con el fin de tener un alcance para
todo el evento y poder dar un buen servicio a los asistentes al mismo. Todo ello configurando el
controlador para que cada microcelda envíe tráfico por la interfaz más óptima, ya sea por tener un
menor número de saltos o por encontrarse menos saturada a nivel de tráfico. Además, si conocemos
previamente el punto donde se van a reunir gran parte de los asistentes del evento, podemos colocar
un mayor número de APs en esa localización.
En resumen, el objetivo final de estas microceldas es poder optimizar la experiencia de usuario en
grandes eventos, sin penalizar su conexión a Internet con el fin de poder compartir sus experiencias
en tiempo real y evitando una gran inversion en APs por parte del equipo organizador del evento.
1.2 Objetivos
En este trabajo fin de grado o TFG, se va a introducir el concepto de redes definidas por software,
también conocidas como SDN, con el fin de desplegar un escenario que pueda mejorar las
conexiones de red y con el objetivo de que cualquier empresa o usuario, sin necesitad de realizar una
gran inversión en la mejora de sus infraestructuras, pueda adaptarlas a las necesidades actuales,
mejorando la experiencia del usuario, reduciendo la saturación de los APs y aprovechando al
máximo los recursos de los equipos de red que tenga en su poder.
Se pretende dar con una solución, mediante el uso de SDN, a una red mallada que tenga conexiones
inalámbricas y que, cuando se produzca una saturación en uno de sus enlaces que supere un cierto
umbral preestablecido, pueda redirigir el tráfico de forma dinámica. El escenario compuesto por los
APs para una red WiFi de alta densidad es similar al que se puede ver en la figura 1-3.
5
5 Microceldas 802.11 de alta densidad
Figura 1-3. Red de alta densidad mallada
Para alcanzar este objetivo, se van a utilizar dos Raspberry Pi, que realizan las funciones de APs,
junto con un PC que, además de actuar como AP, actúa como puerta de enlace hacia Internet. Todo
ello integrado en un escenario SDN que nos va a proporcionar un mayor control sobre los elementos
de la red.
La red SDN nos permite gestionar la saturación de los APs, de forma dinámica y transparente para
los usuarios, redirigiendo el tráfico en función de la misma. Esto es posible porque las redes SDN
pueden interactuar con aplicaciones que cualquier usuario puede realizar. Por ello, se va a desarrollar
un software que interactúe con el controlador de la red SDN y realice el reenvío de tráfico. Este
software:
1. Identifica si el enlace de salida principal de un nodo con rutas alternativas está saturado.
2. Comprueba si los enlaces alternativos están disponibles para reencaminar los flujos que
ocupan un mayor ancho de banda por dichos enlaces.
3. Redirige el tráfico por los enlaces alternativos hasta que el enlace principal vuelva a tener un
caudal que no supere el umbral menos un factor de histéresis, para tener un escenario más
estable evitando tantas oscilaciones.
Con el escenario montado y el algoritmo de balanceo funcionando, se realizan una batería de pruebas
con el fin de verificar el correcto funcionamiento del sistema. Estas pruebas van a consistir en:
1. Envío de tráfico que no sature los enlaces de los APs.
2. Envío de tráfico que sature los enlaces de los APs.
3. Adaptación del escenario ante caídas en sus enlaces.
Introducción y Objetivos
6
7
7 Microceldas 802.11 de alta densidad
2 CONCEPTOS BÁSICOS
n esta sección se van tratar los conceptos referentes a las redes SDN, profundizando en la
interconexión entre los diferentes planos de su arquitectura y viendo el protocolo más
importante en las comunicaciones de una red SDN: OpenFlow.
2.1 Introducción a Software Defined Networking (SDN)
El concepto de redes SDN es el principio básico de este TFG. En los puntos que se muestran a
continuación se observa la evolución de las redes SDN, así como su arquitectura.
2.1.1 Historia
La evolución de las redes SDN se puede separar en tres etapas principales:
• Redes activas (1995 - 2000). Hasta su aparición las redes no eran programables, por lo que
su objetivo era poder programar cada nodo de la red, pudiendo formar una subred entre un
grupo de ellos.
• La separación del plano de control y el plano de datos (2001 - 2007). Hasta este
momento, con las redes activas, las redes no eran seguras ni fiables. Por ello, con el fin de
mejorar la gestión de las redes y convertirlas en más seguras y fiables, nació la idea de
separar el plano de control y el plano de datos.
• La aparición de la API OpenFlow (2007 - 2010). Para poder separar el plano de control del
plano de datos, se buscó centralizar el control lógico en un punto de la red. A tal fin, un gran
número de grupos de investigación siguieron el desarrollo basado en el proyecto 4D, que
indicaba la separación en 4 capas principales:
o Plano de datos. Encargado de procesar paquetes en función de unas reglas
configurables.
o Plano de descubrimiento. Encargado de recolectar el tráfico.
E
El éxito consiste en vencer el temor al fracaso
- Charles Augustin Sainte-Beuve -
Conceptos Básicos
8
o Plano de diseminación. Encargado de instalar reglas de procesado en los paquetes.
o Plano de decisión. Encargado de gestionar los paquetes desde un único punto
centralizado de la red.
2.1.2 Principios básicos [1]
Las redes definidas por software son el cúlmen de la separación entre el plano de control y el plano
de datos, centrando la toma de decisiones sobre los paquetes que atraviesan los equipos, en un único
punto de la red, el controlador. Desde el propio controlador podemos tener un control total sobre los
paquetes que atraviesan nuestra red de forma centralizada haciendo uso de las APIs que nos
proporcionan los mismos.
Utilizando SDN se puede gestionar la red en la que los equipos tengan el plano de control separado
del plano de datos, para que así los dispositivos que componen la red no tengan que tomar decisiones
de encaminamiento, ya que éstas son tomadas por el controlador y comunicadas a cada equipo,
agilizando el procesado de paquetes: permitiendo, bloqueando o redirigiendo tráfico en cada punto
de la red.
La arquitectura de las redes SDN tiene como fin desacoplar las funciones del plano de control de las
que pertenecen al plano de datos, haciendo que el control de la red sea programable y abstrayendo la
arquitectura de las aplicaciones y los servicios que la componen. Como elemento principal de éstas
se encuentra el protocolo OpenFlow, sobre el que se va a hablar detalladamente en el punto 2.3
OpenFlow.
Las características que encontramos en las redes basadas en SDN son:
• Programación del comportamiento de los datos de forma directa.
• Manejo centralizado desde un único punto, el controlador.
• Gestión, configuración, seguridad y optimización de recursos de forma dinámica.
• Implementación de soluciones estándar, lo cual simplifica su diseño y gestión.
La arquitectura que compone esta red se divide en 3 planos claramente separados:
9
9 Microceldas 802.11 de alta densidad
Figura 2-1. Arquitectura SDN4
Plano de datos. Contiene los dispositivos encargados de enviar el tráfico sin interferir en la toma de
decisiones de la red, como pueden ser switches o routers. Estos dispositivos consultan al controlador
la primera vez que recibe un paquete que no saben por dónde enviarlo. Para llevar a cabo esta
comunicación utiliza una interfaz SouthBound y se hace uso del protocolo OpenFlow. Esta interfaz
proporciona una colección de estadísticas del flujo de tráfico que atraviesa los nodos del escenario,
así como las órdenes de reenvío de paquetes, según las políticas del controlador. Los elementos que
componen este plano no toman ninguna decisión sobre el tráfico cursado y se describen a
continuación:
• Elementos de red. Estos elementos son los encargados de enviar tráfico en la red.
• Ruta de datos SDN. Componente lógico integrado en los elementos de red que proporciona
visibilidad y control sobre las capacidades de reenvío y procesamiento de paquetes del
equipo.
• Agente CDPI. Agente que se comunica con el driver alojado en el plano de control a fin de
enviar las estadísticas recolectadas, información de las capacidades de los nodos o notificar
eventos y recibir las políticas de reenvío por parte del controlador.
Plano de control. Es el elemento más crítico de la red, y por consiguiente el punto que más
protección debe tener, ya que es el que toma todas las decisiones, por medio del controlador. Actúa
de nexo entre el plano de datos y el plano de aplicación, proporcionando una vista centralizada de la
red a este último. A continuación, se muestran los elementos principales que componen este plano.
• Controlador SDN. Es el cerebro de la red. Toma todas las decisiones sobre el
encaminamiento del flujo que atraviesa los equipos del plano de datos.
4 Arquitectura SDN: https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/SDN-architecture-overview-1.0.pdf
Conceptos Básicos
10
• Agente NBI. Interfaz agente que se comunica con el driver alojado en el plano de aplicación
y proporciona una visión abstracta de la red a dicho plano.
• Driver CDPI. Se comunica con el agente CDPI que se encuentra en el plano de datos
enviándole las rutas seleccionadas para cada destino y recibiendo estadísticas y
características de los dispositivos.
Plano de aplicación. Este plano contiene las aplicaciones que permiten al controlador gestionar la
red haciendo uso de una interfaz NorthBound para la comunicación con el plano de control para
favorecer el manejo los dispositivos del plano de datos.
• Aplicación SDN. Comunica al controlador, por medio de una Interfaz NorthBound, el
comportamiento que tienen que presentar los dispositivos de la red, manejando así el flujo de
tráfico que la atraviesa.
• Driver NBI. Se comunica con el cliente del plano de control con el fin de proporcionar una
vista abstracta de la red y sus características a la aplicación.
El algoritmo encargado de realizar el balanceo en función de la saturación de los APs se va a
comportar como una aplicación (plano de aplicación) que le comunica al controlador (plano de
control) como redirigir el tráfico de los dispositivos (plano de datos) en función de unos parámetros
fijados.
2.1.3 ¿Por qué utilizar SDN?
La tecnología de la actualidad ha llevado a la red tradicional hasta sus límites. Es por ello que las
redes SDN han emergido con fuerza, ya que proporcionan flexibilidad y control sobre los elementos
de la red, obteniendo una mejor prevención frente a amenazas y mejorando las estructuras actuales.
Las redes tradicionales hasta ahora habían sido flexibles, gestionables y programables. No obstante,
con la aparición de la Cloud, los DataCenters y la demanda de ancho de banda de los nuevos
dispositivos que van apareciendo, las redes tradicionales se han vuelto mucho más complejas
dificultando su gestión.
Las redes SDN por su parte presentan un beneficio considerable en varios aspectos.
• Inversión mínima. Con estas redes, la adquisición de equipos, así como su implantación no
conlleva un gran coste.
• Centralización. Todas las tareas de mantenimiento, monitorización y gestión de la red se
encuentran alojadas en un único punto.
• Dinámico. Se adapta a los cambios en la red de forma dinámica.
• Optimización. Optimiza tanto recursos humanos, gestionando todo desde un punto central,
como recursos materiales, pudiendo aprovechar cada dispositivo al máximo.
• Filtrado. Con el uso de las aplicaciones SDN se pueden filtrar los paquetes que atraviesan
las redes de datos, permitiendo, redirigiendo o bloqueando los mismos.
• Balanceo de carga. Con el balanceo de carga entre diferentes enlaces se minimiza la
saturación de los canales, permitiendo que la QoS de los usuarios permanezca por encima de
un umbral mínimo establecido.
11
11 Microceldas 802.11 de alta densidad
• Tolerancia ante fallos. Todo el control de la red se encuentra en un punto de la misma. Esto
puede llegar a ser un problema si perdemos la comunicación con ese punto. Por ello se
pueden replicar los controladores en varios puntos de la red, de forma que uno de ellos haga
el papel de Master mientras que el resto sean Slaves, pudiendo cambiar de papel si no hay
conexión con el Master.
Figura 2-2. Beneficios de redes SDN5
Como SDN es de código libre, podemos crear nuestras propias aplicaciones que, interactuando con
el controlador, puedan gestionar todo el tráfico que atraviesa nuestra red para lograr distintos
objetivos, como pueden ser los mostrados en la figura 2-36.
Figura 2-3. Tipos de aplicaciones SDN
5 Beneficios SDN: https://communities.cisco.com/community/technology/datacenter/sdn/blog/2015/09/18/software-defined-network-8-big-benefits 6 Aplicaciones SDN: https://www.slideshare.net/junipernetworks/beesley-tokyo-interopenglishv31-copy
Conceptos Básicos
12
En este TFG nos vamos a centrar en una aplicación que va a gestionar el tráfico; de forma que, si el
tráfico supera un cierto umbral preestablecido por un enlace y este nodo tiene varios enlaces de
salida, se pueda redirigir ciertas MACs origen por ese enlace alternativo.
2.2 Open Networking Foundation (ONF)
La fundación Open Networking Foundation7 es una entidad sin
ánimo de lucro fundada en 2011 que se dedica a implantar y
promocionar las tecnologías SDN y NFV con el fin de migrar las
redes tradicionales en redes definidas por software a corto plazo.
Esta fundación ha ayudado a implantar la idea de desagregación entre el plano de control y el plano
de datos, concepto básico en las redes SDN. Además, proporciona soporte a los usuarios que quieren
cambiar su arquitectura de red para poder desenvolverse en la complejidad del nuevo escenario
presentado.
La ONF también está impulsando la creación de estándares de código abierto, entre los que se
encuentra OpenFlow, que se ha convertido en un pilar fundamental en la arquitectura de este tipo de
redes.
2.3 OpenFlow [2]
OpenFlow es el primer estándar de comunicaciones
definido entre el plano de datos y el plano de control de
una arquitectura SDN. Permite acceder y manipular el plano de datos de los dispositivos de red, ya
sean físicos o virtuales.
Su nacimiento se remonta a 2008, en la Universidad de Stanford, donde se comenzó a desarrollar lo
que hoy se conoce como SDN. Con el fin de permitir que cualquier usuario pudiera realizar
aplicaciones para controlar el flujo que atraviesa la red, desarrollaron el protocolo OpenFlow, que
permite la cominicación del controlador con el plano de datos, pudiendo manipular los equipos de
red como switches o routers.
Muchas compañías y startups se han encargado de dar soporte a este protocolo, la mayoría de ellas
pertenecientes a la ONF.
Las redes SDN que utilizan el protocolo OpenFlow permiten la adaptabilidad según la necesidad de
la misma, además de reducir operacionalmente la carga de los dispositivos, centrando toda la toma
de decisiones y la complejidad de la red en el controlador.
Los tipos de mensajes que soporta este protocolo son tres:
1. Mensaje controlador-switch. Iniciados por el controlador y útiles para la gestión de los
equipos del plano de control.
7 Página oficial ONF: https://www.opennetworking.org
13
13 Microceldas 802.11 de alta densidad
2. Mensaje asíncrono. Iniciados por los switches y utilizado para actualizar los eventos de red
en el controlador y así notificar cambios en la red.
3. Mensaje simétrico. Pueden ser iniciados tanto por el switch como por el controlador y se
envían sin petición previa.
2.3.1 Tipos de switches
En las redes SDN no solo existen los switches que están totalmente virtualizados, sino que existen
dos tipos de switches.
• Switches OpenFlow-only: este tipo de switches solo soporta el protocolo OpenFlow, sin ser
compatibles con las funciones de capa 2 y capa 3 del modelo OSI. Contienen como mínimo
una tabla de flujos, pudiendo tener más de una, que almacenan tanto los flujos que los
atraviesan como las acciones pertinentes que se hacen con cada uno de ellos.
• Switches OpenFlow-hybrid: estos switches, además de las operaciones propias del
protocolo OpenFlow también aceptan funciones de capa 2, como por ejemplo VLANs, y
funciones de capa 3, como ACLs, QoS o funciones de routing. Su complejidad a nivel
firmware es mayor que los anteriores, ya que es necesario que tengan un mecanismo que les
permita diferenciar unas funciones de otras. Estos son los tipos de switches que componen
nuestro escenario.
2.3.2 Tabla de flujos
Cada switch tiene al menos una tabla de flujos para permitir gestionarlos indicando, por ejemplo, el
puerto de salida para un determinado camino. Un camino o path indica el tráfico unidireccional entre
un origen y un destino.
2.3.2.1 Flujos
Los flujos OpenFlow se dividen en tres campos principales, como se muestra en la Tabla 2-1.
Campos de Cabecera Contadores Acciones
Tabla 2-1. Campos principales de flujos OpenFlow
• Campos de cabecera. Son el elemento más importante de los flujos, ya que sirven para
identificar cada uno de ellos. Por este motivo poseen diferentes campos para ser lo más
conciso posible a la hora de identificar a un flujo.
in_port dl_src dl_dst dl_type dl_vlan nw_src nw_dst IP proto tp_src tp_dst
Tabla 2-2. Campos de cabecera OpenFlow
o in_port: puerto por el que llegó el flujo al switch.
o dl_src: dirección MAC origen del flujo.
o dl_dst: dirección MAC destino del flujo.
o dl_type: protocolo de nivel 2 del flujo.
Conceptos Básicos
14
o dl_vlan: identificador de la vlan del flujo.
o nw_src: dirección IP origen del flujo.
o nw_dst: dirección IP destino del flujo.
o nw_type: protocolo de nivel 3 del flujo. Para que sea IPv4, este campo lleva el valor
0x0806.
o tp_src: puerto UDP/TCP origen del flujo.
o tp_dst: puerto UDP/TCP destino del flujo.
• Contadores. Se actualizan cada vez que encuentran una coincidencia, a fin de tener una
estadística. Estos contadores pueden ser por tabla, por flujo o por puertos. En la tabla 2-3 se
ven estos contadores agrupados según el tipo.
Tabla 2-3. Contadores OpenFlow
• Acciones. Referidas a las acciones realizadas sobre los diferentes flujos. Estas acciones
pueden ser ninguna, una o varias. Los dos tipos de switch que se han comentado
anteriormente soportan diferentes acciones.
o Acciones Requeridas. Son soportadas por los dos tipos de switches.
▪ ALL. Envía el paquete por todos los puertos excepto por donde recibió el
paquete.
▪ CONTROLLER. Encapsula y envía el paquete al controlador.
▪ LOCAL. Envía el paquete a la red virtual del propio dispositivo,
consumiendo él mismo el paquete.
▪ TABLE. Realiza acciones sobre la tabla de flujo de los paquetes salientes.
▪ IN_PORT. Envía el paquete por el puerto que lo recibió.
o Acciones Opcionales. Pueden ser soportadas únicamente por los switches OpenFlow-
hybrid.
15
15 Microceldas 802.11 de alta densidad
▪ NORMAL. Procesa el paquete como si fuera un equipo convencional,
redirigiendo el paquete a nivel 2 o nivel 3 del modelo OSI según las
funciones que soporte el equipo.
▪ FLOOD. Inunda todas las interfaces pertenecientes a la ruta mínima del árbol
de expansión STP.
2.4 Controlador SDN: Floodlight [3]
Como se ha comentado en varias ocasiones a lo largo de este
documento, el cerebro de una red SDN reside en el plano de
control, concretamente en el controlador del escenario.
Se ha elegido el controlador Open Source Floodlight dada su simplicidad de uso, su documentación
concisa y su API REST, que proporciona una información muy valiosa del estado de la red,
ayudando así a la automatización ante cambios en la misma.
Floodlight es un proyecto desarrollado en Java por Big Switch Network para implementar entornos
SDN bajo la licencia Apache. Su función principal es actuar como controlador SDN siendo el nexo
entre diferentes aplicaciones y el plano de datos, con el que se conecta haciendo uso del protocolo
OpenFlow para gestionar el comportamiento de los switches o routers. En la actualidad existe una
comunidad encargada del desarrollo y la mejora de este software a fin de seguir mejorando los
entornos SDN. El sitio web oficial de Floodlight ofrece unos códigos de ejemplo para ayudar a
desarrollar diferentes soluciones que interactúen con este controlador.
Conceptos Básicos
16
Figura 2-4. Controlador Floodlight
La forma en la que Floodlight consulta las estadísticas recolectadas en el plano de datos por los
switches es mediante el uso de una API REST integrada en el propio controlador. Con esta API,
además de obtener estadísticas, podemos comunicarnos con los switches para, por ejemplo, añadir
una regla estática de redirección del tráfico entrante por un puerto. Un ejemplo de uso de esta API se
ve en la figura 2-5.
Figura 2-5. Inserción de regla estática en Floodlight
2.5 OpenVSwitch [4]
Cuando hablamos de redes SDN, podríamos pensar en un entorno
totalmente virtualizado con equipos que consultan a un controlador y
procesan el tráfico de la red por sus puertos físicos. Uno de esos switches virtuales es OpenVSwitch,
pero ¿qué funcionalidad tienen estos switches?
17
17 Microceldas 802.11 de alta densidad
Figura 2-6. Arquitectura OpenVSwitch8
Los switches basados en OpenVSwitch son switches virtuales que funcionan bajo la licencia de
código abierto Apache 2.0. Estos switches siguen la arquitectura mostrada en la figura 2-6, teniendo
varias interfaces físicas, identificadas como Interface, que se conectan a un bridge OpenVSwitch
virtual el cual tiene conexiones con distintas interfaces virtuales con el fin de tener acceso a varias
máquinas virtuales. Como todo switch virtual, está basado en una solución a nivel software.
Su funcionalidad principal es permitir la automatización de la red a través de extensiones
programables, realizando la comunicación entre máquinas virtuales para poder resolver problemas de
red y tener una visión global del tráfico que atraviesa la red. En la figura 2-7 se pueden ver las
características más importantes de OpenVSwitch.
Figura 2-7. Características OpenVSwitch9
8 Arquitectura Openvswitch: https://www.slideshare.net/janghoonsim/virtualized-network-with-openv-switch 9 Características Openvswitch: http://openvswitch.org/features/
Conceptos Básicos
18
2.5.1 Gestión de paquetes
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.
15 Comparativa RPI: http://comohacer.eu/comparativa-y-analisis-raspberry-pi-vs-competencia/
33 Microceldas 802.11 de alta densidad
Raspbian, por su parte, tiene una comunidad encargada de mantener, dar estabilidad y soporte a este
SO, todo ello de una forma no lucrativa. Es por ello que los desarrolladores de esta plataforma se
sustentan con los donativos que la comunidad les ofrece.
4.1.3 Iperf16
Este software es una herramienta que está bajo la licencia BSD y tiene la funcionalidad de poder
medir el rendimiento de la red. Nos vamos a centrar concretamente en la versión 3 de iperf,
denominada iperf3, que ha sido desarrollada principalmente por ESnet y el laboratorio nacional de
Lawrence Berkeley, ya que es la que se ha utilizado en este TFG.
Esta herramienta soporta varios parámetros, entre los que nos vamos a centrar en los siguientes:
• Parámetros generales:
o -p, --port. Indica el puerto en el que se están escuchando o enviando peticiones,
según sea parámetro del servidor o del cliente respectivamente.
• Parámetros exclusivos del servidor
o -s. Ejecuta el comando en modo servidor.
o -D, --daemon. Ejecuta el servidor en segundo plano como un daemon.
• Parámetros exclusivos del cliente
o -c. Ejecuta el comando en modo cliente.
o -b, --bandwidth. El cliente transmite n bits/seg hacia el servidor.
En este escenario en concreto, se va a simular la conexión de dos clientes a las RPI que utilizan un
gran caudal a fin de realizar un balanceo de tráfico entre las interfaces que conectan el ordenador con
la RPI más próxima a él.
De esta forma, la generación de tráfico se realiza tal y como muestra la figura 4-3, siendo cada grupo
de usuarios dos clientes iperf3.
Figura 4-3. Flujo saliente de usuarios
En caso de que los flujos mostrados con color rojo y amarillo superen a un determinado umbral de
tráfico preestablecido del enlace principal (Ethernet) que une el ordenador portátil con la RPI y, entre
16 Sitio oficial iperf: https://iperf.fr
Escenario propuesto e implementación
34
ellos, el grupo que más tráfico produce en la red fuése el que está indicado con la línea amarilla, el
flujo quedaría tal y como muestra la figura 4-4.
Figura 4-4. Flujo saliente de usuarios con redirección por enlace alternativo
4.1.4 Hostapd
El servicio HostApd, que se encuentra bajo la licencia BSD, es un daemon para crear puntos de
acceso y autenticación de usuarios. Implementa los estándares IEEE 802.11 para la gestión de los AP
y IEEE 802.1X/WPA/WPA2/EAP para autenticación de usuarios.
Figura 4-5. Servicio HostApd
Este servicio se ejecuta en segundo plano y comprueba que los usuarios que quieran conectarse
cumplan con la autenticación y el cifrado que se hayan definido.
Existen varias formas de instalar este servicio. La más rápida y sencilla es instalar desde repositorios,
utilizando el siguiente comando para entornos Ubuntu:
dramos@dramos:~$ sudo apt-get install hostapd
Con el fin de configurar este servicio correctamente tenemos que realizar toda la configuración en el
fichero /etc/hostapd/hostapd.conf 17. Este es el fichero de configuración que se utiliza por defecto
17 Configuración HostApd: https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
35 Microceldas 802.11 de alta densidad
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
que utilizar, que en la figura 5-2 es de 30Mbps.
pi@whitepi:~$ iperf3 -c 10.20.40.1 -p <8081/8181> -b 10m -P 2
Figura 5-2. Conexión cliente-servidor iperf3
5.1.2 Conexiones entre switches
Las conexiones que se hacen entre los equipos que tienen instalado OpenVSwitch, como son las
RPI y el PC, se pueden hacer tanto por cable ethernet como por Wifi. En el escenario que se han
hecho las pruebas, todos los enlaces son ethernet excepto uno de los enlaces que une la RPI con
el PC.
Tal y como se ha comentado en la sección 4.2.2.1 Configuración OpenVSwitch, no se puede
hacer uso de protocolos de nivel 2 como STP o su variante RSTP, debido al bloqueo que se
efectúa en determinados puertos para evitar bucles, evitando poder realizar balanceo entre ellos.
A fin de evitar bucles que degraden el comportamiento de la red, pudiendo dejarla incluso
incapacitada, se investigaron diferentes alternativas.
45 Microceldas 802.11 de alta densidad
• MSTP. MSTP es una variante de STP que permite crear varias instancias, donde cada
una de ellas bloquea un puerto determinado, de forma que no bloquea los enlaces en su
totalidad. Esta opción no se ha podido desarrollar debido a que OVS no lo implementa en
la actualidad.
• Redirección de tráfico de difusión. Una forma de evitar bucles es indicarle a OVS las
rutas fijas de redirección de tráfico de difusión o desconocido. En un escenario simple
como el que tratamos es muy fácil ver los puertos por los que reenviar para no tener
bucles. Con el fin de que se pueda hacer escalable para todos los escenarios, se ha creado
un script que indica los puertos que atraviesa un equipo para llegar al controlador sin
ningún bucle, mostrando una salida similar a la información que aparece en la figura 5-3.
Figura 5-3. Descubrimiento de interfaces libres de bucles
Con la información que nos proporciona la salida de este script, se elige en el script que
genera el escenario OpenVSwitch, mostrado en el Anexo A, los puertos por los que enviar
el tráfico de difusión para evitar los bucles.
5.1.2.1 Conexiones ethernet
Las conexiones ethernet entre dispositivos se realizan siguiendo la tecnología Plug-and-Play que
permite al sistema funcionar conectando únicamente el cable entre los dispositivos.
Es necesario ver es la velocidad a la que negocian los dos equipos para poder medir de la forma
más exacta posible la saturación de los APs en base a esa velocidad. Para ello podemos usar
diferentes herramientas, entre la que se encuentran ethtool o mii-tool.
Pruebas y Resultados
46
Figura 5-4. Velocidad de negociación en enlace ethernet
5.1.2.2 Conexiones WiFi
Las pruebas de conexión por la interfaz WiFi del escenario no conecta de forma tan sencilla
como en el caso de las interfaces ethernet.
Para conectar dos equipos mediante una red WiFi hay que sincronizarlos previamente. Esta
sincronización se realizó de 2 formas diferentes:
• Red ad-hoc. Una red ad-hoc permite la conexión de dos equipos en una red inalámbrica
descentralizada, ya que no existe un emisor y un receptor, como en el caso de hostapd,
sino que ambos están preconfigurados como nodos de la red y realizan el mismo rol,
interconectándose mediante una clave precompartida. Esta tecnología no funcionó de
forma adecuada en el escenario OVS, ya que ambos equipos se interconectaban de forma
correcta antes de pertenecer a este escenario, pero tras incluirse en el mismo pierden toda
la comunicación. Esta pérdida de comunicación es provocada por la supresión de IP en
las interfaces del switch OVS.
• Hostapd. Una red con hostapd contiene un cliente y un servidor. En el escenario
propuesto, el servidor es el propio PC, mientras que el cliente es la Raspberry Pi. Para
que puedan comunicarse en un escenario SDN, hay que tenerlos previamente conectados
en un escenario no virtualizado, ya que en caso contrario produce error. Hay que
configurar una serie de características para el correcto funcionamiento:
• Para configurar correctamente la sincronización DHCP ,se necesita realizar las
acciones mostradas en la figura 5-5, conectando el cliente, que pasa a ser el
bridge OVS creado en lugar de la interfaz, con el servidor.
47 Microceldas 802.11 de alta densidad
Figura 5-5. Asignación DHCP de IP de gestión al bridge
• Con el fin de mantener la seguridad en el escenario, se intentó utilizar tanto WPA
como WPA2 en la red emitida por el PC. El inconveniente encontrado fue que los
equipos no terminan de realizar la autenticación. Analizando los paquetes
intercambiados entre los equipos utilizando wireshark, vemos que el problema se
encuentra en la propia autenticación del cliente:
▪ En WPA se reciben los mensajes de autenticación 1 y 4, imposibilitando
la autenticación del cliente.
▪ En WPA2 se reciben los mensajes de autenticación 1 y 2, con lo que
tampoco permite la autenticación del cliente.
Figura 5-6. Autenticación EAPOL (WPA2)
Ante esta situación, se tuvo que optar por una red abierta como alternativa. Esta
solución no era aceptable desde el punto de vista de la seguridad, por lo que se
implementó una funcionalidad que proporciona hostapd permitiendo crear una
lista blanca de direcciones MACs que pueden conectarse a la red, de forma que
evita casi en su totalidad la conexión de un usuario que no esté permitido. Los
equipos que pertenecen a este fichero de lista blanca son los APs del escenario.
Figura 5-7. Lista blanca de conexión a hostapd
• Para poder interconectarnos por la interfaz WiFi del escenario OVS con otros APs
del escenario, se necesita que la MAC del propio bridge sea la misma que la
MAC de la interfaz WiFi por la que nos vamos a conectar, ya que en caso
Pruebas y Resultados
48
contrario obtenemos un error en el escenario SDN y no detecta correctamente la
sincronización de dicho enlace. Es por ello que en el script de creación del
escenario se pone una dirección MAC fija para el bridge.
Figura 5-8. Asignación fija de MAC al bridge
5.1.3 Conexiones entre switch y controlador
La conexión entre un switch OVS y el controlador se realiza utilizando el protocolo OpenFlow. Se
pueden observar varias fases en dicha conexión:
• Creación del switch OVS: Cuando se crea el switch virtual, se tiene que indicar la IP del
controlador al que se le van a hacer las consultas sobre los flujos que lo atraviesan. Esa
indicación la podemos apreciar en la figura 5-9.
Figura 5-9. Asignación de controlador a OVS
• Búsqueda del controlador: en el momento que se indica la IP del controlador, el switch
comienza a preguntar sobre el equipo que contiene esa IP en la red.
Figura 5-10. Búsqueda del controlador
• Comunicación establecida: cuando el controlador responde a estos mensajes, en el switch
se puede comprobar que se ha establecido una comunicación correctamente.
49 Microceldas 802.11 de alta densidad
Figura 5-11. Conexión exitosa OVS-Controlador
5.2 Pruebas realizadas
En esta sección se van a tratar las pruebas de conceptos que se marcaron para verificar el correcto
funcionamiento del escenario SDN.
Antes de comentar las pruebas en concreto, se va a observar el estado del escenario en situación
normal, abarcando posteriormente cada una de las pruebas realizadas para ver la forma en que se
altera dicho escenario.
Para las pruebas realizadas se han utilizado una serie de scripts, que se incluyen en los anexos, en los
equipos del escenario, quedando estructurados de la siguiente forma:
• PC
• FL_pcEscenario.sh
• findPath.py
• RPI 1 (whitePi)
• FL_whiteEscenario.sh
• loopLinkSpeed.sh
• normalTraffic.py
• redTraffic.py
• sortFlow.py
• RPI 2 (blackPi)
• FL_blackEscenario.sh
Pruebas y Resultados
50
5.2.1 Escenario en estado normal
La red SDN, con todas las conexiones realizadas, queda compuesta por:
• Un PC, que contiene el controlador
• Dos RPI conectadas en cascada
• Dos enlaces alternativos entre el PC y una RPI
• Un enlace entre RPIs
En la interfaz web del controlador tenemos varias formas de verificar que el escenario está bien
montado:
1) Dashboard: En el dashboard se muestra una vista general del escenario y la configuración
del controlador. De esta forma, se puede ver tanto información básica del controlador: el
estado en que se encuentra, tiempo encendido o el rol; como información de red: número de
switches del escenario, hosts conectados, enlaces que hay entre ellos y puertos reservados.
Figura 5-12. Dashboard Floodlight
2) Switches: En la pestaña de switches pertenecientes al escenario podemos ver las MACs de
los equipos que hay conectados, así como su IP, verificando que están conectados los
equipos que se han incorporado a la red SDN. También nos indica cuando se conectaron los
equipos y el rol de cada uno de ellos (Master o Slave).
51 Microceldas 802.11 de alta densidad
Figura 5-13. Switches conectados al controlador
3) Links: En esta pestaña se pueden apreciar los enlaces que hay en el escenario, indicando la
MAC del equipo y el puerto OVS asignado, pudiendo así verificar que las conexiones se han
hecho de forma correcta. Es importante ver que el enlace es bidireccional, ya que en caso de
que sea unidireccional la conexión no es estable y habría que analizar el problema.
Figura 5-14. Enlaces del escenario
4) Topology: En esta pestaña podemos ver gráficamente como se realizan las conexiones de
nuestro escenario, observando las conexiones entre switches o entre hosts y switches,
verificando que dichas conexiones se realizan de forma correcta.
Pruebas y Resultados
52
Figura 5-15. Topología del escenario
5.2.2 Envío de tráfico inferior al umbral
En esta prueba, la interacción con el switch intermedio se basa en crear flujos estáticos para que
cualquier tráfico que reciba por algún enlace de entrada lo reenvíe por el enlace principal hacia el PC.
En el bridge creado en la RPI que está conectada directamente con el PC con dos enlaces
alternativos, se van a crear una serie de flujos estáticos para que todo lo que venga por el enlace de
entrada, que en el escenario OVS es el puerto 3, se redirija por el enlace principal, que es el puerto 1
OVS.
Figura 5-16. Reenvío por enlace principal
En la figura 5-16 se puede observar que no hay tráfico en el escenario, ya que la carga de todos los
enlaces está al 0%. En este caso, el script indica que el tráfico se va a enviar por el enlace principal.
53 Microceldas 802.11 de alta densidad
Cuando un equipo comienza a enviar tráfico y no supera el umbral de tráfico del enlace principal se
realiza una petición al controlador para crear una regla estática en el propio switch.
Figura 5-17. Inserción ruta estática por enlace principal
Se puede verificar que se ha insertado una nueva ruta estática en el bridge desde el terminal del
mismo, ya que apreciamos un mensaje similar al que muestra la figura 5-17. A fin de asegurarnos
que la ruta se ha creado correctamente, podemos analizar los flujos OVS del propio bridge y ver que
figura 5-18.
Figura 5-18. Ruta estática por enlace principal
5.2.3 Envío de tráfico superior al umbral
Esta prueba pretende verificar la redirección de determinado tráfico a través del enlace alternativo.
Concretamente se va a comprobar la carga del enlace principal que existe entre la RPI y el PC,
observando si está gestionando un tráfico superior al umbral, en cuyo caso se redirige por el puerto
alternativo.
A fin de superar el umbral de tráfico del enlace principal, se establece éste al 33% de su capacidad.
Además, se ejecuta un cliente iperf3 contra el puerto habilitado por el servidor en el PC, tal y como
muestra la figura 5-19.
Figura 5-19. Envío de tráfico superior al umbral
Pruebas y Resultados
54
Al igual que en la prueba anterior 5.2.2 Envío de tráfico inferior al umbral, podemos verificar dicha
redirección observando los flujos que tiene creados el propio bridge OpenVSwitch.
Figura 5-20. Ruta estática por enlace alternativo
En los mensajes que aparecen en el terminal, se indica el punto en el que el tráfico por el enlace
principal cae por debajo del umbral junto con un factor de histéresis y se vuelve a reenviar todo el
tráfico que aún no ha sido redirigido por el enlace principal.
Figura 5-21. Vuelta a la normalidad de tráfico del enlace principal
5.2.4 Caída de un enlace
Cuando se produce una caída de un enlace lo primero que se hace es comprobar si se trata de un
enlace entrante o saliente.
En caso de que se haya caído un enlace entrante, el equipo que ejecuta este script no puede actuar,
por lo que únicamente se notifica por la línea de comandos.
Si se trata de un enlace saliente, lo primero que se hace es consultar a la API de Floodlight para
obtener el enlace que se ha caído. Una vez obtenido el enlace que se ha caído, se limpian los reenvíos
de flujos que hay a través de ese enlace, activando una variable bandera. De esta forma, se evita
reenviar tráfico por dicho enlace ya que esas rutas no tendrían conexión.
Si el equipo que ha perdido un enlace no tiene más enlaces que le comuniquen con el controlador, se
obtiene un error cuando intentamos realizar una conexión al mismo, tal y como observamos en la
figura 5-22.
Figura 5-22. Petición errónea al controlador
5.2.5 Recuperación de un enlace
Cuando un enlace recupera, actualiza el número de enlaces activos en el escenario incrementando el
55 Microceldas 802.11 de alta densidad
número en dos unidades. Esto se hace así porque los enlaces, al ser bidireccionales, en el controlador
cuenta como si fueran dos enlaces unidireccionales.
El resultado obtenido varía en función del tipo de enlaces que conecta los equipos.
5.2.5.1 Enlace ethernet
Cuando un enlace ethernet recupera, el controlador lo registra bien y se muestra un mensaje
indicando que algún equipo ha recuperado.
Como en el caso de caída, se comprueba el enlace que ha recuperado para volver a contar con dicho
enlace en la redirección de tráfico. En este caso, no se limpia la tabla de reenvío ya que no se va a
aislar a ningún equipo de la red.
5.2.5.2 Enlace WiFi
Un enlace WiFi en el escenario SDN presenta un mal comportamiento cuando se recupera, ya que el
controlador no lo vuelve a identificar como un enlace de la red SDN.
La solución encontrada para que este enlace pertenezca al escenario de nuevo es:
• Sacar el puerto WiFi del escenario SDN.
• Reiniciar la interfaz DHCP.
• Volver a crear el puerto en el bridge OVS con dicha interfaz asociada.
• Eliminar la IP de esta interfaz.
Pruebas y Resultados
56
57 Microceldas 802.11 de alta densidad
6 CONCLUSIÓN Y LÍNEAS DE AVANCE
l inicio de este proyecto se marcaron una serie de objetivos que se han ido desarrollando a lo
largo de todo el proyecto obteniendo diferentes resultados. Estos objetivos propuestos eran:
1) Utilización de redes SDN en entornos de alta densidad
2) Desarrollo de un algoritmo que evite la saturación en los APs
3) Respuesta ante cambios topológicos
El objetivo 1) se ha desarrollado montando un escenario con tres APs, de los cuales dos de ellos
tenían dos enlaces entre sí, uno ethernet y otro wifi. En el enlace ethernet los resultados han sido
totalmente satisfactorios ya que al incluirlo al bridge OVS funcionaba sin ningún tipo de problemas.
El enlace wifi no ha funcionado tal y como se esperaba pues ha producido diferentes fallos de
conexión. En un primer momento, se trató de implementar un enlace ad-hoc entre los dos APs, pero
en el momento en que los enlaces se incluían en el bridge OVS perdían la conectividad. En un
segundo intento, se desplegó el servicio hostapd que también produjo una serie de problemas,
principalmente autenticando usuarios, que no se ha logrado solventar. Ante esta situación se optó por
utilizar el servicio hostapd dejando la red que conectaba estos enlaces sin seguridad y creando un
archivo de lista blanca, que permitiera únicamente a determinadas MACs la conexión, a fin de hacer
el enlace más seguro.
El objetivo 2) se desarrolló en una primera instancia para redirigir flujos en función de los puertos de
entrada. Como el escenario era simple, su funcionamiento fue correcto. No obstante, como se quería
hacer escalable el algoritmo, se optó por crear flujos estáticos en los propios switches para hacer la
redirección en base a la MAC origen. Tras realizar estos cambios en el script, el escenario reenviaba
flujos en función de la MAC origen sin ningún problema, por lo que los resultados se consideran
satisfactorios.
El objetivo 3) se comprobó desconectando determinados enlaces y viendo el comportamiento del
sistema. Con el enlace ethernet no hubo ningún problema ya que el sistema contabiliza
correctamente tanto la desconexión como la conexión del mismo. En el enlace wifi, una vez que se
desconectaba el cliente de la red y se volvía a conectar se perdía la comunicación completamente y
para recuperarla era necesario:
• Eliminar la interfaz del bridge OVS
A
Conclusión y Líneas de Avance
58
• Arrancar el cliente dhcp
• Incluir en el bridge OVS
• Quitar la IP asignada a la interfaz
Los resultados obtenidos en el objetivo 3) por tanto son:
• En el enlace ethernet son satisfactorios
• En el enlace wifi no se pueden considerar como tal, puesto que es complicado automatizar
esta caída y asegurar el funcionamiento ante cualquier situación.
A nivel personal, este proyecto ha supuesto un reto para mí ya que era una tecnología totalmente
nueva y al principio supuso un impedimento a la hora de asimilar los conceptos. Por ello considero
que me ha hecho crecer como persona, otorgándome un grado de soltura suficiente para poder
trabajar con esta tecnología. Además, he podido desarrollarme tanto en el ámbito de redes,
configurando los equipos del escenario, como en el de programación, con el código implementado
tanto en python como en shell script.
6.1 Líneas de avance
Este proyecto puede tener progresos siguiendo diferentes vertientes. En las siguientes subsecciones
se van a ver algunas posibles mejoras que podrían implementarse en este proyecto.
6.1.1 Integración con nuevos controladores
Como se ha visto a lo largo de este proyecto, el escenario SDN que se ha implementado para realizar
la prueba de concepto es Floodlight. Este se ha elegido por su potencia, principalmente en su API, y
su sencillez.
No obstante, no es el único controlador que existe en el mercado, ya que existen otros muchos
controladores como son OpenDayLight, OpenContrail, POX o Ryu entre otros.
Por lo que se puede ver el controlador que mejor se adapte al escenario deseado, ya sea por tener un
menor tiempo de respuesta, por tener una API potente o por cualquier otra característica.
6.1.2 Controlador distribuído
En repetidas ocasiones, se ha comentado que el punto más crítico de una red SDN es el controlador,
ya que si queda aislado de la red se perdería toda la conectividad de la misma.
Con objeto de paliar los efectos que pueda producir un ataque y no perder la conectividad de la red,
se puede crear un cluster de controladores en la que uno tenga el rol de Master y el resto tenga el rol
de Slave. De esta forma, si el Master queda aislado de la red, alguno de los controladores Slave se
hará cargo del control de la misma, evitando perder la conectividad.
6.1.3 Verificar carga de enlaces antes de reenviar por otro enlace
Durante el desarrollo de este TFG nos hemos centrado en evitar la saturación de los APs para poder
59 Microceldas 802.11 de alta densidad
dar un mejor servicio al usuario. No obstante, en estos momentos los scripts desarrollados para este
escenario no tienen en cuenta que antes de reenviar un flujo por uno u otro enlace este cambio sature
más el nuevo enlace que el actual, por lo que es conveniente verificar que el cambio no sobrecarga
más el enlace por el que se va a redirigir antes de realizar dicha redirección.
6.1.4 Calcular los bytes tx de cada flujo por segundo
Cuando se tiene que reenviar tráfico por un enlace alternativo, se comienza redirigiendo el flujo que
más bytes ha transmitido en el histórico. En realidad, en estos momentos la redirección no tiene
porqué afectar al equipo que más tráfico está produciendo en ese instante.
Es por ello que se podría mejorar el rendimiento del escenario verificando el tráfico de cada flujo por
segundo y, en función de eso, redirigir los flujos que más tráfico estén produciendo en ese instante.
6.1.5 Manejo de errores
El escenario propuesto funciona como se propuso al principio del desarrollo de este proyecto. No
obstante, hay puntos de los scripts que no manejan los errores de forma correcta como, por ejemplo,
cuando un equipo no tiene conexión con el controlador no realiza ninguna tarea para verificar el
estado de sus enlaces o reiniciar el escenario SDN.
Conclusión y Líneas de Avance
60
61 Microceldas 802.11 de alta densidad
7 ANEXOS
7.1 Anexo A: Despliegue de escenario OVS
7.1.1 Fichero FL_pcEscenario.sh
#!/bin/bash
##################################################################################
# #
# Author: David Ramos Cardoso #
# Description: Script para montar el escenario SDN con el controlador Floodlight en el pc (TFG) #
# #
# #
##################################################################################
# Notes: (i) => Nº puerto
#
# --------------- --------------- ---------------
# | | | | | |
# | blackPi |>(1)-----(3)<| whitePi |>(1)-----(1)<| Pc |
# | | | | | |
# --------------- --------------- ---------------
# v(2) v(2)
# | |
# --------------------------------
#
# Variables definidas
ROOT_UID=0
PORT_CONTROLLER=6653
IP_CONTROLLER=127.0.0.1
BRIDGE=briPc
IFACE0=eth0
IFACE1=wlan1
IP_IFACE0=10.20.40.1
IP_IFACE1=10.11.12.1
IP_DEFAULT=192.168.1.1
MASK=255.255.255.0 function _mainMenu()
{
# Muestra el menu
while :
do
##############################
# 0) Se comprueba si existen #
##############################
ovs-vsctl br-exists $BRIDGE
BRIDGE_EXIST=$?
clear
echo "##################### Escenario de red SDN #####################"
echo "### ###"
echo "### ###"
echo "### 1. Crear escenario FL ###"
echo "### 2. Eliminar escenario FL ###"
echo "### 3. Ver información de OVS ###"
echo "### 4. Eliminar bridge concreto ###"
echo "### 5. Ver información de interfaces ###"
echo "### 6. Ver flujos ###"
echo "### 7. Version OVS instalada ###"
echo "### 8. Configuración de bridge ###"
Anexos
62
echo "### 9. Información de interfaces ###"
echo "### q. Salir ###"
echo "### ###"
echo "### ###"
echo "################################################################"
echo ""
echo "Elija una opción: "
read selection
case $selection in
# Crea el escenario FL
1)
_createFL
;;
# Elimina el escenario FL
2)
_deleteFL
;;
# Muestra informacion OVS
3)
ovs-vsctl show | more
;;
# Elimina un switch OVS
4)
_deleteSpecFL
;;
# Muestra información de red
5)
clear
ifconfig | more
;;
# Muestra los flujos
6)
ovs-ofctl dump-flows $BRIDGE
;;
# Muestra la version
7)
ovs-vsctl --version
;;
# Muestra informacion de los bridges
8)
_infoBridge
;;
# Muestra informacion interfaces
9)
ovs-ofctl show $BRIDGE
;;
# Sale del script
q|Q)
echo "[INFO] Saliendo..."
sleep 1
clear
exit
;;
# Cualquier otra opcion
*)
echo "[ERR] Opción incorrecta"
63 Microceldas 802.11 de alta densidad
;;
esac
echo "[INFO] Presione intro para continuar..."
read waiter
done
}
function _createFL(){
##########################################################
# 1) Se crean los dispositivos dos bridges si no existen #
##########################################################
# 0 => Existen; 2 => No existen
if [ $BRIDGE_EXIST -eq "2" ]; then
echo "[INFO] Creando el bridge $BRIDGE "
ovs-vsctl add-br $BRIDGE
ovs-vsctl set bridge $BRIDGE other-config:hwaddr="70:62:b8:b4:88:74"
ovs-vsctl set bridge $BRIDGE protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
echo "[INFO] Se quita la IP a las interfaces físicas $IFACE0 y $IFACE1"
ifconfig $IFACE0 inet 0
ifconfig $IFACE1 inet 0
else
echo "[WARN] Ya existe el bridge $BRIDGE"
fi
sleep 1
###########################################
# 2) Se añaden los puertos a los switches #
###########################################
# Con comprobar una interfaz es necesario. Compruebo la última para mas seguridad
(ovs-vsctl list-ports $BRIDGE | grep $IFACE1) > /dev/null
if [ $? -ne 0 ]; then
echo "[INFO] Se crean las interfaces en el bridge"
### BRIDGE
ovs-vsctl add-port $BRIDGE $IFACE0 -- set interface $IFACE0 ofport_request=1 \
-- add-port $BRIDGE $IFACE1 -- set interface $IFACE1 ofport_request=2
echo "[INFO] Se configura la interfaz de gestión de $BRIDGE con $IP_IFACE0/$MASK"
ifconfig $BRIDGE $IP_IFACE0 netmask $MASK
#############################################
# 3) Configura el controller en cada bridge #
#############################################
echo "[INFO] Configurando el controlador en la direccion $IP_CONTROLLER:$PORT_CONTROLLER"
ovs-vsctl set-controller $BRIDGE tcp:$IP_CONTROLLER:$PORT_CONTROLLER
##########################################################################################
# 4) Se maneja el tráfico de difusión para que no haya bucles (Solo puerto 1 de salida) #
##########################################################################################
ovs-ofctl add-flow $BRIDGE "in_port=1,dl_dst=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff, actions=output:LOCAL"
ovs-ofctl add-flow $BRIDGE "in_port=2,dl_dst=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff, actions=output:LOCAL"
ovs-ofctl add-flow $BRIDGE "in_port=LOCAL,dl_dst=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff, actions=output:1"
else
echo "[WARN] Ya existen las interfaces"
fi
# Se muestran los switch y las interfaces
ovs-vsctl show
_infoBridge
}
function _infoBridge(){
echo -e "\n----------------- Información de bridges -----------------"
ovs-vsctl list bridge
}
Anexos
64
function _deleteFL(){
# Elimina el bridge completamente
if [ $BRIDGE_EXIST -eq "0" ]; then
echo "[INFO] Se elimina el bridge $BRIDGE"
ovs-vsctl del-br $BRIDGE
echo "[INFO] Se reinician las conexiones y el hostapd"
ifdown $IFACE0 && ifup $IFACE0
ifdown $IFACE1 && ifup $IFACE1
service hostapd restart
else
echo "[WARN] No existe el bridge $BRIDGE"
fi
}
function _deleteSpecFL(){
echo "Introduce el nombre del bridge: "
read bridgeDel
ovs-vsctl br-exists $bridgeDel
# Elimina los bridges completamente
if [ $? -eq "0" ]; then
echo "[INFO] Se elimina el bridge $bridgeDel"
ovs-vsctl del-br $bridgeDel
else
echo "[WARN] No existe el bridge $bridgeDel"
fi
}
# Se comprueba si es super usuario antes de permitir ejecutar el script
if [ $UID -eq $ROOT_UID ]; then
# Permite la ejecución del script
_mainMenu
else
echo "[WARN] Necesitas ser SU para ejecutar este script"
fi
7.1.2 Fichero FL_whiteEscenario.sh
#!/bin/bash
########################################################################################
# #
# Author: David Ramos Cardoso #
# Description: Script para montar el escenario SDN con el controlador Floodlight en la RPI white (TFG) #
# #
# #
########################################################################################
# Notes: (i) => Nº puerto
#
# --------------- --------------- ---------------
# | | | | | |
# | blackPi |>(1)-----(3)<| whitePi |>(1)-----(1)<| Pc |
# | | | | | |
# --------------- --------------- ---------------
# v(2) v(2)
# | |
# --------------------------------
# Variables definidas
ROOT_UID=0
65 Microceldas 802.11 de alta densidad
USER_NO_ROOT=pi
HOME_DIR_NO_ROOT=/home/$USER_NO_ROOT
# Controller
PORT_CONTROLLER=6653
IP_CONTROLLER=10.20.40.1
# Interfaces
IFACE0=eth0
IFACE1=wlan0
IFACE2=eth1
BRIDGE=briWhite
#IP por defecto
IP_IFACE0=10.20.40.2
IP_IFACE1=10.11.12.2
IP_IFACE2=10.30.50.1
IP_DEFAULT=10.20.40.1
MASK=255.255.255.0
function _mainMenu()
{
# Muestra el menu
while :
do
##############################
# 0) Se comprueba si existen #
##############################
ovs-vsctl br-exists $BRIDGE
BRIDGE_EXIST=$?
clear
echo "##################### Escenario de red SDN #####################"
echo "### ###"
echo "### ###"
echo "### 1. Crear escenario FL ###"
echo "### 2. Eliminar escenario FL ###"
echo "### 3. Ver información de OVS ###"
echo "### 4. Eliminar bridge concreto ###"
echo "### 5. Ver información de interfaces ###"
echo "### 6. Ver flujos ###"
echo "### 7. Version OVS instalada ###"
echo "### 8. Configuración de bridge ###"
echo "### 9. Información de interfaces ###"
echo "### q. Salir ###"
echo "### ###"
echo "### ###"
echo "#############################################################"
echo ""
echo "Elija una opción: "
read selection
case $selection in
# Crea el escenario FL
1)
_createFL
;;
# Elimina el escenario FL
2)
_deleteFL
;;
# Elimina el escenario FL
Anexos
66
3)
ovs-vsctl show | more
;;
# Elimina el escenario FL
4)
_deleteSpecFL
;;
# Muestra información de red
5)
clear
ifconfig | more
;;
# Muestra los flujos
6)
ovs-ofctl dump-flows $BRIDGE
;;
# Muestra la version que se utiliza de OVS
7)
ovs-vsctl --version
;;
# Muestra informacion de los bridges
8)
_infoBridge
;;
# Muestra informacion interfaces
9)
ovs-ofctl show $BRIDGE
;;
# Sale del script
q|Q)
echo "[INFO] Saliendo..."
sleep 1
clear
exit
;;
# Cualquier otra opcion
*)
echo "[ERR] Opción incorrecta"
;;
esac
echo "[INFO] Presione intro para continuar..."
read waiter
done
}
function _createFL(){
##########################################################
# 1) Se crean los dispositivos dos bridges si no existen #
##########################################################
# 0 => Existen; 2 => No existen
if [ $BRIDGE_EXIST -eq "2" ]; then
echo "[INFO] Creando el bridge $BRIDGE"
ovs-vsctl add-br $BRIDGE
ovs-vsctl set bridge $BRIDGE protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13 \
-- set bridge $BRIDGE other-config:hwaddr="c4:6e:1f:1c:b3:67"
ifconfig $IFACE0 inet 0
ifconfig $IFACE1 inet 0
67 Microceldas 802.11 de alta densidad
ifconfig $IFACE2 inet 0
else
echo "[WARN] Ya existe el bridge $BRIDGE"
fi
sleep 1
###########################################
# 2) Se añaden los puertos a los switches #
###########################################
# Con comprobar una interfaz es necesario. Compruebo la última para mas seguridad
(ovs-vsctl list-ports $BRIDGE | grep $IFACE0) > /dev/null
if [ $? -ne 0 ]; then
echo "[INFO] Se crean las interfaces en el bridge"
ovs-vsctl add-port $BRIDGE $IFACE1
echo "[INFO] Recargando cliente dhcp en interfaz $IFACE1"
ifdown $IFACE1 && ifup $IFACE1
ifconfig $BRIDGE inet 0
# Se reinician las conexiones dhcp
echo "[INFO] Arrancando cliente dhcp en $BRIDGE y eliminandolo de $IFACE1"
dhclient -v $BRIDGE
sleep 3
# Le pongo tambien la ip de IFACE0
ip address add $IP_IFACE0/32 dev $BRIDGE
ifconfig $IFACE1 inet 0
ovs-vsctl add-port $BRIDGE $IFACE0
ovs-vsctl add-port $BRIDGE $IFACE2
## Se identifican los diferentes puertos
ovs-vsctl set interface $IFACE0 ofport_request=1
ovs-vsctl set interface $IFACE1 ofport_request=2
ovs-vsctl set interface $IFACE2 ofport_request=3
ip r add default via $IP_CONTROLLER dev $BRIDGE
#############################################
# 3) Configura el controller en el bridge #
#############################################
echo "[INFO] Configurando el controlador en la direccion $IP_CONTROLLER:$PORT_CONTROLLER"
ovs-vsctl set-controller $BRIDGE tcp:$IP_CONTROLLER:$PORT_CONTROLLER
## Se maneja el tráfico de difusión para que no haya bucles (Puertos 2 (eth) y 3 de salida)
# Tfco Broadcast
ovs-ofctl add-flow $BRIDGE "in_port=1,dl_dst=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff,actions=output:3,LOCAL"
ovs-ofctl add-flow $BRIDGE "in_port=2,dl_dst=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff,actions=output:3,LOCAL"
ovs-ofctl add-flow $BRIDGE "in_port=3,dl_dst=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff,actions=output:1,LOCAL"
ovs-ofctl add-flow $BRIDGE "in_port=LOCAL,dl_dst=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff,actions=output:1,3"
# Tfco Multicast
ovs-ofctl add-flow $BRIDGE "in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=output:3,LOCAL"
ovs-ofctl add-flow $BRIDGE "in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=output:3,LOCAL"
ovs-ofctl add-flow $BRIDGE "in_port=3,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=output:1,LOCAL"
ovs-ofctl add-flow $BRIDGE "in_port=LOCAL,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=output:1,3"
else
echo "[WARN] Ya existen las interfaces"
fi
sleep 1
Anexos
68
# Se muestra el switch y las interfaces
ovs-vsctl show
_infoBridge
}
function _infoBridge(){
echo -e "\n----------------- Información de bridges -----------------"
ovs-vsctl list bridge
}
function _deleteFL(){
# Elimina los bridges completamente
if [ $BRIDGE_EXIST -eq "0" ]; then
echo "[INFO] Se elimina el bridge $BRIDGE"
dhclient -r -v $BRIDGE
ovs-vsctl del-br $BRIDGE
else
echo "[WARN] No existe el bridge $BRIDGE"
fi
ifdown $IFACE0 && ifup $IFACE0
ifdown $IFACE2 && ifup $IFACE2
# Se reinician las conexiones dhcp
echo "[INFO] Arrancando cliente dhcp en $IFACE1"
ifdown $IFACE1 && ifup $IFACE1
sleep 1
ip r add default via $IP_DEFAULT dev $IFACE1
}
function _deleteSpecFL(){
echo "Introduce el nombre del bridge: "
read bridgeDel
ovs-vsctl br-exists $bridgeDel
# Elimina los bridges completamente
if [ $? -eq "0" ]; then
echo "[INFO] Se elimina el bridge $bridgeDel"
ovs-vsctl del-br $bridgeDel
else
echo "[WARN] No existe el bridge $bridgeDel"
fi
}
# Se comprueba si es super usuario antes de permitir ejecutar el script
if [ $UID -eq $ROOT_UID ]; then
# Permite la ejecución del script
_mainMenu
else
echo "[WARN] Necesitas ser SU para ejecutar este script"
fi
7.1.3 Fichero FL_blackEscenario.sh
#!/bin/bash
########################################################################################
# #
# Author: David Ramos Cardoso #
# Description: Script para montar el escenario SDN con el controlador Floodlight en la RPI black (TFG) #
# #
# #
########################################################################################
69 Microceldas 802.11 de alta densidad
# Notes: (i) => Nº puerto
#
# --------------- --------------- ---------------
# | | | | | |
# | blackPi |>(1)-----(3)<| whitePi |>(1)-----(1)<| Pc |
# | | | | | |
# --------------- --------------- ---------------
# v(2) v(2)
# | |
# --------------------------------
# Variables definidas
ROOT_UID=0
USER_NO_ROOT=pi
PORT_CONTROLLER=6653
IP_CONTROLLER=10.20.40.1
BRIDGE=briBlack
IFACE0=eth0
IP_IFACE0=10.30.50.2
IP_IFACEVIRTUAL=10.20.40.4
IP_DEFAULT=10.30.50.1
MASK=255.255.255.0
function _mainMenu()
{
# Muestra el menu
while :
do
##############################
# 0) Se comprueba si existen #
##############################
ovs-vsctl br-exists $BRIDGE
BRIDGE_EXIST=$?
clear
echo "##################### Escenario de red SDN #####################"
echo "### ###"
echo "### ###"
echo "### 1. Crear escenario FL ###"
echo "### 2. Eliminar escenario FL ###"
echo "### 3. Ver información de OVS ###"
echo "### 4. Eliminar bridge concreto ###"
echo "### 5. Ver información de interfaces ###"
echo "### 6. Ver flujos ###"
echo "### 7. Version OVS instalada ###"
echo "### 8. Configuración de bridge ###"
echo "### 9. Información de interfaces ###"
echo "### q. Salir ###"
echo "### ###"
echo "### ###"
echo "#############################################################"
echo ""
echo "Elija una opción: "
read selection
case $selection in
# Crea el escenario FL
1)
_createFL
;;
# Elimina el escenario FL
2)
Anexos
70
_deleteFL
;;
# Elimina el escenario FL
3)
ovs-vsctl show | more
;;
# Elimina unbridge del escenario FL
4)
_deleteSpecFL
;;
# Muestra información de red
5)
clear
ifconfig | more
;;
# Muestra los flujos
6)
ovs-ofctl dump-flows $BRIDGE
;;
# Muestra la version
7)
ovs-vsctl --version
;;
# Muestra informacion de los bridges
8)
_infoBridge
;;
# Muestra informacion interfaces
9)
ovs-ofctl show $BRIDGE
;;
# Sale del script
q|Q)
echo "[INFO] Saliendo..."
sleep 1
clear
exit
;;
# Cualquier otra opcion
*)
echo "[ERR] Opción incorrecta"
;;
esac
echo "[INFO] Presione intro para continuar..."
read waiter
done
}
function _createFL(){
##########################################################
# 1) Se crean los dispositivos dos bridges si no existen #
##########################################################
# 0 => Existen; 2 => No existen
if [ $BRIDGE_EXIST -eq "2" ]; then
echo "[INFO] Creando el bridge $BRIDGE"
ovs-vsctl add-br $BRIDGE
ovs-vsctl set bridge $BRIDGE protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13 \
-- set bridge $BRIDGE other-config:hwaddr="b8:27:eb:55:1e:20"
71 Microceldas 802.11 de alta densidad
echo "[INFO] Se quita la IP a la interfaz física $IFACE0"
ifconfig $IFACE0 inet 0
else
echo "[WARN] Ya existe el bridge $BRIDGE"
fi
sleep 1
###########################################
# 2) Se añaden los puertos a los switches #
###########################################
# Con comprobar una interfaz es necesario. Compruebo la última para mas seguridad
(ovs-vsctl list-ports $BRIDGE | grep $IFACE0) > /dev/null
if [ $? -ne 0 ]; then
echo "[INFO] Se crean las interfaces en el bridge"
# Conecta con la interfaz física (untagged) (-- set port $IFACE0 trunks=3,4)
ovs-vsctl add-port $BRIDGE $IFACE0
echo "Se configura la interfaz $BRIDGE con $IP_IFACEVIRTUAL/$MASK"
ifconfig $BRIDGE $IP_IFACEVIRTUAL netmask $MASK
echo "La GW es: $IP_CONTROLLER"
route add default gw $IP_CONTROLLER $BRIDGE
#############################################
# 3) Configura el controller en el bridge #
#############################################
echo "[INFO] Configurando el controlador en la direccion $IP_CONTROLLER:$PORT_CONTROLLER"
ovs-vsctl set-controller $BRIDGE tcp:$IP_CONTROLLER:$PORT_CONTROLLER
else
echo "[WARN] Ya existen las interfaces concretas"
fi
sleep 1
# Se muestran los switch y las interfaces
ovs-vsctl show
_infoBridge
}
function _infoBridge(){
echo -e "\n----------------- Información de bridges -----------------"
ovs-vsctl list bridge
}
function _deleteFL(){
# Elimina los bridges completamente
if [ $BRIDGE_EXIST -eq "0" ]; then
echo "[INFO] Se elimina el bridge $BRIDGE"
ovs-vsctl del-br $BRIDGE
echo "[INFO] Se reinician las conexiones"
ifdown $IFACE0 && ifup $IFACE0
ip r add default via $IP_DEFAULT dev $IFACE0
else
echo "[WARN] No existe el bridge $BRIDGE"
fi
}
function _deleteSpecFL(){
echo "Introduce el nombre del bridge: "
read bridgeDel
ovs-vsctl br-exists $bridgeDel
# Elimina los bridges completamente
if [ $? -eq "0" ]; then
echo "[INFO] Se elimina el bridge $bridgeDel"
Anexos
72
ovs-vsctl del-br $bridgeDel
else
echo "[WARN] No existe el bridge $bridgeDel"
fi
}
# Se comprueba si es super usuario antes de permitir ejecutar el script
if [ $UID -eq $ROOT_UID ]; then
# Permite la ejecución del script
_mainMenu
else
echo "[WARN] Necesitas ser SU para ejecutar este script"
fi
7.2 Anexo B: Ejecución Floodlight
7.2.1 Fichero fl_script.sh
#!/bin/bash
############################################################
#### SCRIPT EJECUCION FLOODLIGHT ####
#### Author: David Ramos Cardoso ####
############################################################
# Declaracion de variables
USUARIO="$USER"
FL_DIR="/home/$USUARIO/floodlight/"
ERR_DIR="El directorio \"$FL_DIR\" no existe"
OPEN_ERROR_MSG="Hubo un problema al ejecutar floodlight"
# Ejecucion de floodlight
if [ -d $FL_DIR ]; then
cd "$FL_DIR"
if [ -f "target/floodlight.jar" ]; then
echo "[INFO] Ejecutando floodlight"
java -Djavax.net.debug=all -jar "target/floodlight.jar"
else
echo "[ERR] $OPEN_ERROR_MSG"
fi
else
echo "[ERR] $ERR_DIR"
fi
7.3 Anexo C: Algoritmo de balanceo y ruta mínima
7.3.1 Fichero loopLinkSpeed.sh
#!/bin/bash
#####################################################################
# #
# Author: David Ramos Cardoso #
# Description: Script encargado de visualizar la carga de cada enlace #
# y realizar el balanceo #
# #
#####################################################################
73 Microceldas 802.11 de alta densidad
ROOT_UID=0
PORT_CONTROLLER=8080
IP_CONTROLLER=10.20.40.1
BRIDGE=briWhite
SWITCH="00:00:c4:6e:1f:1c:b3:67"
INTERVAL="1" # Para obtener velocidad por segundo
## Interfaces del nodo
linksActivos=6
# Saliente
IF1=eth0
IF2=wlan0
# Entrante
IF3=eth1
# Velocidad de los enlaces
DATARATE_LINK1=`expr 100 \* 1000 ̀# Tasa máxima del enlace 1 (wlan0) kb/s
DATARATE_LINK2=`expr 100 \* 1000 ̀# Tasa máxima del enlace 2 (eth0) kb/s
DATARATE_LINK3=`expr 100 \* 1000 ̀# Tasa máxima del enlace 3 (eth1) kb/s
# Umbral que se pasa en cada enlace
THRESHOLD_1=`expr $DATARATE_LINK1 \/ 3 ` # 33%
THRESHOLD_2=`expr $DATARATE_LINK2 \* 3 \/ 4` # 75%
# Definimos los factores de histeresis para que no este cambiando continuamente
H_LINK1=`expr $DATARATE_LINK1 \/ 10 ̀# 10%
H_LINK2=`expr $DATARATE_LINK2 \/ 10 ̀# 10%
# Variable que indica que el tráfico no ha superado el umbral
NORMAL_TRAFFIC=1
# Puerto de entrada de trafico al dispositivo
PORT_IN=3
# Ficheros necesarios
IN_TRAFFIC_FILE="macInFile.log"
MAIN_FILE="normal_macs.log"
FILE_ALT_PATH="red_macs.log"
TMP_FLOW_FILE="tmpInFile.log"
# Variables que contienen el estado del enlace
LINK1_OK=0
LINK2_OK=0
function _loadCharge(){
## 0) Se obtienen los bytes tx y rx iniciales
R1=`cat /sys/class/net/$IF1/statistics/rx_bytes`
T1=`cat /sys/class/net/$IF1/statistics/tx_bytes`
R3=`cat /sys/class/net/$IF2/statistics/rx_bytes`
T3=`cat /sys/class/net/$IF2/statistics/tx_bytes`
R5=`cat /sys/class/net/$IF3/statistics/rx_bytes`
T5=`cat /sys/class/net/$IF3/statistics/tx_bytes`
## 1) Se espera el tiempo deseado (1seg)
sleep $INTERVAL
## 2) Se obtienen los bytes tx y rx finales
R2=`cat /sys/class/net/$IF1/statistics/rx_bytes`
T2=`cat /sys/class/net/$IF1/statistics/tx_bytes`
R4=`cat /sys/class/net/$IF2/statistics/rx_bytes`
T4=`cat /sys/class/net/$IF2/statistics/tx_bytes`
R6=`cat /sys/class/net/$IF3/statistics/rx_bytes`
T6=`cat /sys/class/net/$IF3/statistics/tx_bytes`
## 3) Se hace la diferencia de final - inicial por cada interfaz
T_BPS1=`expr $T2 - $T1`
R_BPS1=`expr $R2 - $R1`
Anexos
74
T_BPS2=`expr $T4 - $T3`
R_BPS2=`expr $R4 - $R3`
T_BPS3=`expr $T6 - $T5`
R_BPS3=`expr $R6 - $R5`
## 4) Se divide por 1000 para pasar a KiloBytes y se multiplica por 8 para que sea kbits/s
T_KBPS1=`expr $T_BPS1 \* 8 \/ 1000`
R_KBPS1=`expr $R_BPS1 \* 8 \/ 1000`
T_KBPS2=`expr $T_BPS2 \* 8 \/ 1000`
R_KBPS2=`expr $R_BPS2 \* 8 \/ 1000`
T_KBPS3=`expr $T_BPS3 \* 8 \/ 1000`
R_KBPS3=`expr $R_BPS3 \* 8 \/ 1000`
OCUP1=`expr $T_KBPS1 + $R_KBPS1`
OCUP2=`expr $T_KBPS2 + $R_KBPS2`
OCUP3=`expr $T_KBPS3 + $R_KBPS3`
CARGA1=`expr 100 \* $OCUP1 \/ $DATARATE_LINK1`
CARGA2=`expr 100 \* $OCUP2 \/ $DATARATE_LINK2`
CARGA3=`expr 100 \* $OCUP3 \/ $DATARATE_LINK3`
## 5) Se muestra cada segundo la diferencia
echo "[LOG] TX $IF1: $T_KBPS1 kb/s RX $IF1: $R_KBPS1 kb/s (Carga = $CARGA1%)"
echo "[LOG] TX $IF2: $T_KBPS2 kb/s RX $IF2: $R_KBPS2 kb/s (Carga = $CARGA2%)"
echo "[LOG] TX $IF3: $T_KBPS3 kb/s RX $IF3: $R_KBPS3 kb/s (Carga = $CARGA3%)"
echo ""
}
# Funcion que envia todo lo que recibe por los enlaces entrantes por el puerto 1
function _linkDefaultCheck(){
# Leo del fichero de macs entrantes y del de macs redirigidas y si no esta en nigun fichero, envio por puerto 1
python normalTraffic.py $PORT_IN
}
# Funcion que redirige el trafico por un enlace secundario
function _linkOutFlow(){
# Se comprueba que hay que redirigir y que no se ha superado el umbral
echo "Transmitido por $IF2 => $T_KBPS2 // UMBRAL 2 => $THRESHOLD_2"
while [ $NORMAL_TRAFFIC -eq "1" ] && [ $T_KBPS2 -lt $THRESHOLD_2 ];
do
# Si se cumple la condicion se redirige el trafico
python redTraffic.py $PORT_IN
_loadCharge
LOW_TRAFFIC_LINK1=`expr $THRESHOLD_1 - $H_LINK1`
if [ $T_KBPS1 -lt $LOW_TRAFFIC_LINK1 ]; then
echo "[INFO] El trafico del enlace $IF1 ha vuelto a la normalidad ( < $LOW_TRAFFIC_LINK1 kbps)"
NORMAL_TRAFFIC=0
fi
done
}
# Se comprueba cada segundo el flujo por sus interfaces
function _checkFlow(){
## Se comprueba si el trafico por el enlace por defecto (1) ha superado el umbral establecido
if [ $T_KBPS1 -le $THRESHOLD_1 ] && [ $LINK1_OK -eq 0 ]; then
echo "[INFO] Enviando trafico por enlace principal"
_linkDefaultCheck
elif [ $T_KBPS2 -le $THRESHOLD_2 ] && [ $LINK2_OK -eq 0 ]; then
echo "[INFO] Reenviando trafico por enlace alternativo"
NORMAL_TRAFFIC=1
_linkOutFlow
75 Microceldas 802.11 de alta densidad
else
echo "[ERROR] Todos los enlaces superan el umbral establecido"
fi
}
# Comprueba si están todos los enlaces
function _linkState(){
num_links=`curl http://$IP_CONTROLLER:$PORT_CONTROLLER/wm/core/controller/summary/json | jq '.["# inter-switch
links"]'`
# Si se cae un enlace
if [ $num_links -lt $linksActivos ]; then
l1_down=`curl http://$IP_CONTROLLER:$PORT_CONTROLLER/wm/core/switch/$SWITCH/port-desc/json | jq
'.port_desc[0].state' | grep "LINK_DOWN" ̀
l2_down=`curl http://$IP_CONTROLLER:$PORT_CONTROLLER/wm/core/switch/$SWITCH/port-desc/json | jq
'.port_desc[1].state' | grep "LINK_DOWN"`
# Si el enlace 1 esta caido
if [ "$l1_down" == " \"LINK_DOWN\"" ];then
echo "[ERROR] Enlace $IF1 caido. Borrando redirecciones que afectan a este enlace"
LINK1_OK=1
ovs-ofctl del-flows $BRIDGE out_port=1
# Si el enlace 2 esta caido
elif [ "$l2_down" == " \"LINK_DOWN\"" ]; then
echo "[ERROR] Enlace $IF2 caido. Borrando redirecciones que afectan a este enlace"
LINK2_OK=1
ovs-ofctl del-flows $BRIDGE out_port=2
# Si se ha caido otro enlace que no es saliente no me preocupo
else
echo "[ERROR] Algun enlace de entrada caido"
fi
linksActivos=$num_links
# Si se recupera un enlace
elif [ $num_links -gt $linksActivos ]; then
linksActivos=$num_links
l1_down=`curl http://$IP_CONTROLLER:$PORT_CONTROLLER/wm/core/switch/$SWITCH/port-desc/json | jq
'.port_desc[0].state' | grep "LINK_DOWN"`
# Se comprueba si el enlace 1 esta levantado
if [ "$l1_down" != " \"LINK_DOWN\"" ]; then
if [ $LINK1_OK -eq 1 ];then
echo "[INFO] Se ha recuperado enlace $IF1"
LINK1_OK=0
fi
# Se comprueba si el enlace 2 esta levantado
l2_down=`curl http://$IP_CONTROLLER:$PORT_CONTROLLER/wm/core/switch/$SWITCH/port-desc/json | jq
'.port_desc[1].state' | grep "LINK_DOWN"`
elif [ "$l2_down" != " \"LINK_DOWN\"" ]; then
if [ $LINK2_OK -eq 1 ];then
echo "[INFO] Se ha recuperado enlace $IF2"
LINK2_OK=0
fi
# Se indica que el enlace recuperado es un enlace entrante
else
echo "[INFO] Se ha recuperado algun enlace entrante"
fi
fi
}
Anexos
76
# Funcion que comprueba la existencia de ficheros y en caso de que no existan los crea
function _checkFiles(){
# Se comprueba el fichero donde se almacenan las mac de entrada
if [ ! -f "$IN_TRAFFIC_FILE" ];then
echo "[INFO] Creando archivo $IN_TRAFFIC_FILE"
touch $IN_TRAFFIC_FILE
else
echo "[WARN] Archivo $IN_TRAFFIC_FILE ya existente"
fi
# Se comprueba el fichero que contiene los flujos que van por el enlace principal
if [ ! -f "$MAIN_FILE" ];then
echo "[INFO] Creando archivo $MAIN_FILE"
touch $MAIN_FILE
else
echo "[WARN] Archivo $MAIN_FILE ya existente"
fi
# Se comprueba el fichero que contiene los flujos que van por el enlace alternativo
if [ ! -f "$FILE_ALT_PATH" ];then
echo "[INFO] Creando archivo $FILE_ALT_PATH"
touch $FILE_ALT_PATH
else
echo "[WARN] Archivo $FILE_ALT_PATH ya existente"
fi
# Se comprueba el fichero temporal que ayuda a calcular los bytes por segundo tx por flujo
if [ ! -f "$TMP_FLOW_FILE" ];then
echo "[INFO] Creando archivo $TMP_FLOW_FILE"
touch "$TMP_FLOW_FILE"
else
echo "[WARN] Archivo $TMP_FLOW_FILE ya existente"
fi
}
#########################################
###### Inicio del script ######
#########################################
# Se comprueba si es super usuario antes de permitir ejecutar el script
if [ $UID -eq $ROOT_UID ]; then
# Permite la ejecución del script
# Para comprobar una única vez la existencia de ficheros, se hace antes del bucle
_checkFiles
sleep 1
## Comienza la ejecución del script, verifica la carga de sus interfaces y realiza balanceo en funcion de saturacion
while :
do
# Aproximadamente tarda en torno a 1,15 segundos cada iteracion
# Se comprueba el estado de los enlaces
_linkState
# Se almacenan todos los flujos en un fichero y con el script se ordena por bytex tx
ovs-ofctl dump-flows $BRIDGE > $TMP_FLOW_FILE
python sortFlow.py
# Se comprueba la carga de cada enlace
_loadCharge
# Se comprueba si el flujo supera el umbral
_checkFlow
echo -e "-------------------------------\n"
done
else
echo "[WARN] Necesitas ser SU para ejecutar este script"
fi
77 Microceldas 802.11 de alta densidad
7.3.2 Fichero findPath.py
#!/usr/bin/python
##################################################################################
# #
# Author: David Ramos Cardoso #
# Description: Script en python para obtener las rutas posibles entre los #
# nodos de la red (TFG) #
# #
##################################################################################
import os
# Escenario de la red
# Primero se declaran los dispositivos con sus interfaces OVS
# y despues se detalla la conexion de sus interfaces
graph = {'10.20.40.1': set(['10.20.40.1-1', '10.20.40.1-2']),
'10.20.40.3': set(['10.20.40.3-1', '10.20.40.3-2','10.20.40.3-3']),
'10.20.40.4': set(['10.20.40.4-1']),
'10.20.40.1-1': set(['10.20.40.1', '10.20.40.3-1']),
'10.20.40.1-2': set(['10.20.40.1', '10.20.40.3-2']),
'10.20.40.3-1': set(['10.20.40.3', '10.20.40.1-1']),
'10.20.40.3-2': set(['10.20.40.3', '10.20.40.1-2']),
'10.20.40.3-3': set(['10.20.40.3', '10.20.40.4-1']),
'10.20.40.4-1': set(['10.20.40.4', '10.20.40.3-3'])}
numIfaces=0
######################## DEFINICION DE METODOS ######################
# # Obtiene las rutas alternativas que hay
def bfs_paths(graph, start, goal):
queue = [(start, [start])]
while queue:
(vertex, path) = queue.pop(0)
for next in graph[vertex] - set(path):
if next == goal:
yield path + [next]
else:
queue.append((next, path + [next]))
# Obtiene el la ruta mas corta
def shortest_path(graph, start, goal):
try:
return next(bfs_paths(graph, start, goal))
except StopIteration:
return None
############################ FIN DE METODOS ##########################
######## Se comienzan a ejecutar el programa
if __name__ == "__main__":
nodosCli=["10.20.40.3", "10.20.40.4"]
numCamino=1
for nodoCli in nodosCli:
print("\n------------ Rutas posibles para " + nodoCli + " ------------\n")
print("[INFO] La ruta mas corta para " + nodoCli + " es: " + repr(shortest_path(graph, nodoCli, "10.20.40.1")))
alt_paths=list(bfs_paths(graph, nodoCli, "10.20.40.1"))
loopIndex=0
for path in alt_paths:
print("Camino " + str(numCamino) + "\n")
print("Longitud de ruta (Sumando interfaces y disp. finales) es: " + str(len(alt_paths[loopIndex])))
if(loopIndex <= len(alt_paths)):
for ifaceIndex in alt_paths[loopIndex]:
interfaces=ifaceIndex.find('-')
# En caso que sea una interfaz y no el nodo no lo muestro
Anexos
78
if (interfaces != -1):
print("Device: " + ifaceIndex[0:interfaces] + " => Port OVS: "
+ ifaceIndex[interfaces+1:len(ifaceIndex)])
# Se mueve hasta el siguiente camino del escenario
loopIndex=loopIndex+1
numCamino=numCamino+1
print("")
for ruta in graph:
if (ruta.find('-')!=-1):
numIfaces=numIfaces+1
print "El numero de interfaces del escenario es: " ,numIfaces
7.4 Anexo D: Script de encaminamiento estático
7.4.1 Fichero normalTraffic.py
#!/usr/bin/python
##################################################################################
# # #
# Author: David Ramos Cardoso # #
# Description: Script en python para redirigir las direcciones MAC que se #
# conectan a un determinado puerto del switch (TFG) #
# # #
##################################################################################
# Librerias importadas
import argparse
import httplib
import json
import os
# Variables estaticas
IN_TRAFFIC_FILE = "macInFile.log"
FILE_ALT_PATH = "red_macs.log"
MAIN_FILE = "normal_macs.log"
NOT_FOUND = 1
PORT_CONTROLLER="8080"
IP_CONTROLLER="10.20.40.1"
SWITCH="00:00:c4:6e:1f:1c:b3:67"
BRIDGE="briWhite"
# Necesario para pasar comando por consola
parser = argparse.ArgumentParser()
parser.add_argument("port", help="Puerto de conexion al switch")
args = parser.parse_args()
if __name__ == '__main__':
# Se abren en modo lectura lis ficheros que contienen los datos
macInFile= open(IN_TRAFFIC_FILE, "r")
# Se lee linea a linea el fichero con el trafico entrante al dispositivo
for line in macInFile :
if NOT_FOUND == 1:
# Se obtienen los campos de la linea
field_line = line.split(",")
# Se comprueba cada campo para ver si contiene la mac origen
for field in field_line:
79 Microceldas 802.11 de alta densidad
# Se obtiene el puerto de entrada del trafico a encaminar
if "in_port" in field:
portIn=field.split("=")
# Se obtiene la MAC origen del flujo
if "dl_src" in field:
if portIn[1] == args.port or portIn[1] == "LOCAL" :
mac_src=field.split("=")
mac_src=mac_src[1].split(" ")
# Se abre el fichero en el que vamos a escribir
normal_lines = open(MAIN_FILE, 'a+')
alt_lines = open(FILE_ALT_PATH, "r")
if not mac_src[0]+"\n" in normal_lines and not mac_src[0]+"\n" in alt_lines:
print("[INFO] Nueva MAC que se envia por enlace principal "+
mac_src[0])
NOT_FOUND=0
# Se crea el flujo estatico para poner en el OVS
normal_lines.write(mac_src[0]+"\n")
os.system('ovs-ofctl add-flow '+ BRIDGE +' \"in_port='+
portIn[1] +',dl_src='+ mac_src[0] +',actions=output:1\"')
normal_lines.close()
alt_lines.close()
# Se comprueba si se ha encontrado o no
if NOT_FOUND != 0:
print("[INFO] No hay MACs sin encaminar")
else:
print("[INFO] Aun hay MACs sin encaminar")
# Se cierran los ficheros abiertos
macInFile.close()
7.4.2 Fichero redTraffic.py
#!/usr/bin/python
##################################################################################
# # #
# Author: David Ramos Cardoso # #
# Description: Script en python para redirigir las direcciones MAC que se #
# conectan a un determinado puerto del switch (TFG) #
# # #
##################################################################################
# Librerias importadas
import argparse
import httplib
import json
import os
# Variables estaticas
IN_TRAFFIC_FILE = "macInFile.log"
FILE_ALT_PATH = "red_macs.log"
MAIN_FILE = "normal_macs.log"
NOT_FOUND = 1
PORT_CONTROLLER="8080"
IP_CONTROLLER="10.20.40.1"
SWITCH="00:00:c4:6e:1f:1c:b3:67"
BRIDGE="briWhite"
# Necesario para pasar comando por consola
parser = argparse.ArgumentParser()
parser.add_argument("port", help="Puerto de conexion al switch")
Anexos
80
args = parser.parse_args()
if __name__ == '__main__':
# Se abren en modo lectura los ficheros que contienen los datos
macInFile= open(IN_TRAFFIC_FILE, "r")
altFile = open(FILE_ALT_PATH, "a+")
normalFile = open(MAIN_FILE, 'r')
altLines = altFile.readlines()
# Se leen las macs que se estan enviando por el enlace principal
all_lines = normalFile.readlines()
# Se lee linea a linea el fichero con el trafico entrante al dispositivo
for line in macInFile :
if "in_port=" + args.port in line or "in_port=LOCAL" in line and NOT_FOUND:
# Se divide la linea en los diferentes campos
field_line = line.split(",")
# Se comprueba cada campo para ver si contiene la mac origen
for field in field_line:
if "dl_src" in field:
# Se separa por =, por espacio y por / para eliminar saltos de linea
mac_src=field.split("=")
mac_src=mac_src[1].split(" ")
mac_src=mac_src[0].split("\\")
# Si es una mac que aun no esta redirigida se redirige
if not mac_src[0]+"\n" in altLines:
# No se siguen mirando las lineas porque esta ordenado por el
trafico generado
NOT_FOUND=0
print("[INFO] Nueva mac redirigida " + mac_src[0])
# Se elimina la mac que vamos a redirigir
delNormalMac = open(MAIN_FILE, 'w')
for line in all_lines:
# Si la linea no contiene la mac a borrar, se escribe
de nuevo en fichero
if not mac_src[0] in line:
delNormalMac.write(line)
delNormalMac.close()
altFile.write(mac_src[0]+"\n")
# Se hace la peticion curl para crear la regla de reenvio
os.system('ovs-ofctl add-flow '+ BRIDGE +' \"in_port='+
args.port +',dl_src='+ mac_src[0] +',actions=output:2\"')
# Aun hay macs que no se han desviado por la ruta alternativa
if NOT_FOUND == 0:
print("[INFO] Aun hay MACs de este puerto de entrada sin redirigir")
# En caso contrario ya se han pasado todas las macs al otro enlace
else:
print("[WARN] Todas las MACs de este puerto de entrada han sido redirigidas")
# Se cierran los ficheros abiertos
macInFile.close()
normalFile.close()
altFile.close()
81 Microceldas 802.11 de alta densidad
7.5 Anexo E: Script que ordena flujos por bytes tx en orden decreciente
7.5.1 Fichero sortFlow.py
#!/usr/bin/python
##################################################################################
# # #
# Author: David Ramos Cardoso # #
# Description: Script en python para ordenar el flujo del dispositivo #
# por numero de bytes transmitidos # #
# # #
##################################################################################
# Variables estaticas
IN_TRAFFIC_FILE = "macInFile.log"
TMP_FLOW_FILE = "tmpInFile.log"
# Se abre el fichero de flujos
tmpFile = open(TMP_FLOW_FILE, "r")
macInFile= open(IN_TRAFFIC_FILE, "w")
# Array vacio que contiene las lineas a insertar en el fichero
insert_lines = []
# Se lee linea a linea el fichero con el flujo del dispositivo
for line in tmpFile :
# Se divide la linea en los diferentes campos
field_line = line.split(",")
# Se comprueba cada campo para ver si contiene la mac origen
for field in field_line:
if "n_bytes" in field:
#Si el tamano es 0 esta vacio.
if len(insert_lines) == 0:
insert_lines.insert(0,line)
else:
# Se separa por =, por espacio y por / para eliminar saltos de linea
bytesTx=field.split("=")
indexList=0
for sweep_list in insert_lines:
# Se obtiene el campo de los bytes
byte_compare=str(sweep_list).split(",")
byte_compare=byte_compare[4].split("=")
# Se elimina el apostrofe del campo
byte_compare=byte_compare[1]
# Si se cumple se inserta en la posicion que toca
if int(byte_compare) < int(bytesTx[1]):
break
# Se aumenta el indice en el que se va a insertar
indexList=indexList+1
#print ("Se inserta en posicion " + str(indexList))
# Se inserta la linea en la posicion del array correspondiente
insert_lines.insert(indexList,line)
# Se insertan las lineas en el fichero ordenado
index_line=0
while index_line < len(insert_lines):
index_field=0
while index_field < len(insert_lines[index_line]):
macInFile.write(insert_lines[index_line][index_field])
index_field=index_field+1
index_line=index_line+1
Anexos
82
# Se cierran los ficheros abiertos
macInFile.close()
tmpFile.close()
83 Microceldas 802.11 de alta densidad
REFERENCIAS
[1] «https://www.sdxcentral.com/» Redes SDN.
[2] B. Heller, «OpenFlow Switch Specification» 2008, p. 33.
[3] «http://www.projectfloodlight.org/floodlight/» Página oficial de Floodlight.
[4] «http://openvswitch.org/» Página oficial de OpenVSwitch.