Microceldas 802.11 de alta densidadbibing.us.es/proyectos/abreproy/91260/descargar_fichero/DRC_TFG.pdf · Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de

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/

https://es.statista.com/estadisticas/517654/prevision-de-la-evolucion-de-los-dispositivos-conectados-para-el-internet-de-las-cosas-en-el-mundo/

https://es.statista.com/estadisticas/517654/prevision-de-la-evolucion-de-los-dispositivos-conectados-para-el-internet-de-las-cosas-en-el-mundo/

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

http://www.sysadmit.com/2016/05/wifi-buenas-practicas-capitulo-1.html


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


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.


6

7


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


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


• 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

https://www.opennetworking.org/

13


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


▪ 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


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


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


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


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.


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


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.


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.


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.


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/


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


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


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


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/


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


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.


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


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.


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


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.


• 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.


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.


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


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.


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


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).


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.


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.


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


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


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.


56


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


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


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"


;;

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


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


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


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

########################################################################################

# #


# Description: Script para montar el escenario SDN con el controlador Floodlight en la RPI white (TFG) #

# #

# #

########################################################################################


#

# --------------- --------------- ---------------

# | | | | | |


# | | | | | |

# --------------- --------------- ---------------

# v(2) v(2)

# | |

# --------------------------------


ROOT_UID=0


USER_NO_ROOT=pi

HOME_DIR_NO_ROOT=/home/$USER_NO_ROOT

# Controller



# 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


MASK=255.255.255.0

function _mainMenu()

{

# Muestra el menu

while :

do

##############################


##############################


BRIDGE_EXIST=$?

clear


echo "### ###"

echo "### ###"











echo "### ###"

echo "### ###"

echo "#############################################################"

echo ""


read selection

case $selection in


1)

_createFL

;;


2)

_deleteFL

;;


Anexos

66

3)


;;


4)

_deleteSpecFL

;;


5)

clear

ifconfig | more

;;


6)


;;

# Muestra la version que se utiliza de OVS

7)

ovs-vsctl --version

;;


8)

_infoBridge

;;


9)


;;

# Sale del script

q|Q)


sleep 1

clear

exit

;;


*)


;;

esac


read waiter

done

}


##########################################################


##########################################################



echo "[INFO] Creando el bridge $BRIDGE"


ovs-vsctl set bridge $BRIDGE protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13 \

-- set bridge $BRIDGE other-config:hwaddr="c4:6e:1f:1c:b3:67"





else


fi

sleep 1

###########################################


###########################################



if [ $? -ne 0 ]; then


ovs-vsctl add-port $BRIDGE $IFACE1

echo "[INFO] Recargando cliente dhcp en interfaz $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




## Se identifican los diferentes puertos

ovs-vsctl set interface $IFACE0 ofport_request=1



ip r add default via $IP_CONTROLLER dev $BRIDGE

#############################################

# 3) Configura el controller en el bridge #

#############################################



## 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=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=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

}




}





dhclient -r -v $BRIDGE


else


fi



# Se reinician las conexiones dhcp

echo "[INFO] Arrancando cliente dhcp en $IFACE1"


sleep 1

ip r add default via $IP_DEFAULT dev $IFACE1

}



read bridgeDel



if [ $? -eq "0" ]; then



else


fi

}




_mainMenu

else


fi

7.1.3 Fichero FL_blackEscenario.sh

#!/bin/bash

########################################################################################

# #


# Description: Script para montar el escenario SDN con el controlador Floodlight en la RPI black (TFG) #

# #

# #

########################################################################################



#

# --------------- --------------- ---------------

# | | | | | |


# | | | | | |

# --------------- --------------- ---------------

# v(2) v(2)

# | |

# --------------------------------


ROOT_UID=0

USER_NO_ROOT=pi



BRIDGE=briBlack

IFACE0=eth0

IP_IFACE0=10.30.50.2

IP_IFACEVIRTUAL=10.20.40.4


MASK=255.255.255.0

function _mainMenu()

{

# Muestra el menu

while :

do

##############################


##############################


BRIDGE_EXIST=$?

clear


echo "### ###"

echo "### ###"











echo "### ###"

echo "### ###"

echo "#############################################################"

echo ""


read selection

case $selection in


1)

_createFL

;;


2)

Anexos

70

_deleteFL

;;


3)


;;

# Elimina unbridge del escenario FL

4)

_deleteSpecFL

;;


5)

clear

ifconfig | more

;;


6)


;;

# Muestra la version

7)

ovs-vsctl --version

;;


8)

_infoBridge

;;


9)


;;

# Sale del script

q|Q)


sleep 1

clear

exit

;;


*)


;;

esac


read waiter

done

}


##########################################################


##########################################################



echo "[INFO] Creando el bridge $BRIDGE"


ovs-vsctl set bridge $BRIDGE protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13 \

-- set bridge $BRIDGE other-config:hwaddr="b8:27:eb:55:1e:20"


echo "[INFO] Se quita la IP a la interfaz física $IFACE0"


else


fi

sleep 1

###########################################


###########################################



if [ $? -ne 0 ]; then


# Conecta con la interfaz física (untagged) (-- set port $IFACE0 trunks=3,4)


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 #

#############################################



else

echo "[WARN] Ya existen las interfaces concretas"

fi

sleep 1

# Se muestran los switch y las interfaces

ovs-vsctl show

_infoBridge

}




}






echo "[INFO] Se reinician las conexiones"


ip r add default via $IP_DEFAULT dev $IFACE0

else


fi

}



read bridgeDel



if [ $? -eq "0" ]; then


Anexos

72


else


fi

}




_mainMenu

else


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

#####################################################################

# #


# Description: Script encargado de visualizar la carga de cada enlace #

# y realizar el balanceo #

# #

#####################################################################


ROOT_UID=0



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=èxpr 100 \* 1000 ̀# Tasa máxima del enlace 1 (wlan0) kb/s

DATARATE_LINK2=èxpr 100 \* 1000 ̀# Tasa máxima del enlace 2 (eth0) kb/s

DATARATE_LINK3=èxpr 100 \* 1000 ̀# Tasa máxima del enlace 3 (eth1) kb/s

# Umbral que se pasa en cada enlace

THRESHOLD_1=èxpr $DATARATE_LINK1 \/ 3 ` # 33%

THRESHOLD_2=èxpr $DATARATE_LINK2 \* 3 \/ 4` # 75%

# Definimos los factores de histeresis para que no este cambiando continuamente

H_LINK1=èxpr $DATARATE_LINK1 \/ 10 ̀# 10%

H_LINK2=èxpr $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`





## 1) Se espera el tiempo deseado (1seg)

sleep $INTERVAL

## 2) Se obtienen los bytes tx y rx finales







## 3) Se hace la diferencia de final - inicial por cada interfaz

T_BPS1=èxpr $T2 - $T1`

R_BPS1=èxpr $R2 - $R1`

Anexos

74





## 4) Se divide por 1000 para pasar a KiloBytes y se multiplica por 8 para que sea kbits/s

T_KBPS1=èxpr $T_BPS1 \* 8 \/ 1000`

R_KBPS1=èxpr $R_BPS1 \* 8 \/ 1000`

T_KBPS2=èxpr $T_BPS2 \* 8 \/ 1000`

R_KBPS2=èxpr $R_BPS2 \* 8 \/ 1000`

T_KBPS3=èxpr $T_BPS3 \* 8 \/ 1000`

R_KBPS3=èxpr $R_BPS3 \* 8 \/ 1000`

OCUP1=èxpr $T_KBPS1 + $R_KBPS1`



CARGA1=èxpr 100 \* $OCUP1 \/ $DATARATE_LINK1`



## 5) Se muestra cada segundo la diferencia

echo "[LOG] TX $IF1: $T_KBPS1 kb/s RX $IF1: $R_KBPS1 kb/s (Carga = $CARGA1%)"



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=èxpr $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


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" ̀


'.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



# 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



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 ######

#########################################




# 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


fi


7.3.2 Fichero findPath.py

#!/usr/bin/python

##################################################################################

# #


# 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:


# 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

##################################################################################

# # #


# 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



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




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")


macInFile.close()

normalFile.close()

altFile.close()


7.5 Anexo E: Script que ordena flujos por bytes tx en orden decreciente

7.5.1 Fichero sortFlow.py

#!/usr/bin/python

##################################################################################

# # #


# Description: Script en python para ordenar el flujo del dispositivo #

# por numero de bytes transmitidos # #

# # #

##################################################################################



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




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


macInFile.close()

tmpFile.close()


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.

Documents

Microceldas 802.11 de alta densidadbibing.us.es/proyectos/abreproy/91260/descargar_fichero/DRC_TFG.pdf · Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de